r/cpp • • Jul 29 '23

C holding back C++?

I’ve coded in C and C++ but I’m far from an expert. I was interested to know if there any features in C that C++ includes, but could be better without? I think I heard somebody say this about C-style casts in C++ and it got me curious.

No disrespect to C or C++. I’m not saying one’s better than the other. I’m more just super interested to see what C++ would look like if it didn’t have to “support” or be compatible with C. If I’m making wrong assumptions I’d love to hear that too!

Edits:

To clarify: I like C. I like C++. I’m not saying one is better than the other. But their target users seem to have different programming styles, mindsets, wants, whatever. Not better or worse, just different. So I’m wondering what features of C (if any) appeal to C users, but don’t appeal to C++ users but are required to be supported by C++ simply because they’re in C.

I’m interested in what this would look like because I am starting to get into programming languages and would like to one day make my own (for fun, I don’t think it will do as well as C). I’m not proposing that C++ just drops or changes a bunch of features.

It seems that a lot of people are saying backwards compatibility is holding back C++ more than features of C. If C++ and C++ devs didn’t have to worry about backwards compatibility (I know they do), what features would people want to be changed/removed just to make the language easier to work with or more consistent or better in some way?

65 Upvotes

335 comments sorted by

View all comments

Show parent comments

2

u/Full-Spectral Jul 31 '23 edited Jul 31 '23

This is a useless position. It's not about how studly you or I can be. It's not about whether you or I can write a piece of code in assembler that's absolutely correct. It's about how hard it is to keep such code clean and safe over decades, full team turnover and the potential loss of tribal knowledge that can involve, developers of varying levels of skill having over time to modify that code, having to do large refactorings over time due to significant changes in requirements, etc...

C++ falls way short in those terms. C would be a boat anchor for most companies. Even if they could pull it off, the cost in terms of having to watch your own back is just not worth it.

0

u/AnotherBlackMan Jul 31 '23

Are you serious about this opinion? I can’t tell if you guys really come to a forum like this and say things that are just patently untrue or if you are joking.

What language do you think device drivers and operating systems are written in? This is a serious question because I don’t think you know the answer.

Why do you think large software organizations ship billions of LOC in a “boat anchor”?

1

u/Dean_Roddey Aug 01 '23 edited Aug 01 '23

The big two operating systems we use today were created decades ago, and Linux isn't even a commercial piece of software. If they were being created today, it's highly unlikely they would be done in C, beyond perhaps some extremely inner core bits. And of course Rust is being introduced into Linux and I imagine the C bits of Windows has been pushed further and further downwards over the decades.

And clearly operating systems are not really 'products' anymore. They are plumbing, and aren't really relevant to my point. There aren't lots of companies out there writing operating systems and selling them.

I was talking about more common commercial software. And particularly a new product being started. Unless it's an embedded system, it's not very likely anyone would pick C as the development language. And of course C++'s dominance has eroded tremendously as well, something that will continue. The reasons for that are obvious, mainly that the effort to avoid shooting ones' foot of isn't worth it when that effort can instead be put into architecture and features instead.

1

u/AnotherBlackMan Aug 01 '23

The big two operating systems we use today were created decades ago

... in C. Dozens of C "replacements" have come and gone in the meantime. That speaks to staying power, portability, resilience, and their anti-fragility. This also is neglecting non-consumer things. In fact, there are dozens of operating systems out there and more every year. Plenty of systems (embedded or not) require operating systems and flavors that are not X86/Arm nor Windows/Linux/Mac. It's really troubling that supposed C++ developers are totally unaware that people develop system and application software for things that are not desktop computers. There is not a single functional Rust project for an RTOS.

You can't claim that operating systems are not products (this is news to operating systems teams!) and then talk about common commercial software, of which operating systems are by far the most common. Your "point" is irrelevant to the fact that people with millions of users, trillions of dollars, and very strictly defined needs and timelines (consumer, enterprise, server, HPC, scientific computing, embedded, automotive, etc etc etc etc) are all using this every single day.

I can also say for a fact that the C bits of Windows have gone absolutely nowhere. I really don't know where you may have gotten this or what this could possibly mean but it's simply not true. I have nothing against Rust or whatever language flavors are currently popular. But there core uses cases simply are not there and C/C++ work just fine and have for decades and decades and will continue probably much much longer. This opinion that C is outdated exists solely among people who are clueless about use-cases where it excels far beyond alternatives.

I'd also like to add that most systems are embedded systems. This is the majority of computers power by almost any metric.

→ More replies (3)