undefined

[-]

So maybe you can answer the following question I have: what is a "protected abstract virtual base pure virtual private destructor," and when was the last time you needed one?" At least with C, I understand the feature set and how they interact.

[-]

Just because a feature is there doesn't mean you have to use it.

Additionally the example isn't even possible, at least make ridiculous examples that compile.

by jjmarr224 days ago|

[-]

Don't use inheritance and you won't have to find out.

by rramadass224 days ago|

[-]

This is just silly. C++ gives you a smorgasbord of multi-paradigm features. Everything has its place and you can mix and match your needed featureset based on project needs, team skillset etc. You don't have to know or learn everything.

[-]

Some people will do as much as they can to hurt themselves, only to avoid using C++.

Note as the newer versions are basically C++ without Classes kind of thing.

by glouwbug224 days ago|

[-]

I think the main appeal is subset lock-down and compile times. ~5000 lines in C gets me sub second iteration times, while ~5000 lines in C++ hits the 10 second mark. Including both iostream and format in C++ gets any project up into the ~1.5 second mark which kills my iteration interests.

Second to that I'd say the appeal is just watching something you've known for a long time grow slowly and steadily.

by kilpikaarna224 days ago|

[-]

This, and the two pages of incomprehensible compiler spam you get when you make a typo in C++.

[-]

Depends pretty much on where you do such typo.

If you mean templates, a kind of solved problem since C++17 with static_assert and enable_if, moreso in C++20 with concepts.

[-]

Use binary libraries and modules, alongside incremental compilation and linking.

by glouwbug223 days ago|

[-]

I can't really afford the link time optimization losses

by pjmlp223 days ago|

[-]

It is called link time optimization for a reason.

by glouwbug222 days ago|

[-]

Which kills my iteration interests ;)

[-]

I see it the other way round. People hurt themselves by using C++. C++ fans will never understand it, but it you can solve your problem in a much simpler way, this is far better.

[-]

We won't, because C++ is Typescript for C.

It offers us safety features for arrays and strings, that apparently WG14 will never add to C.

Didn't so in 40 years, and still remains to be seen what will be done with the current trend of cybersecurity laws.

Then there is the whole basic stuff like proper namespaces instead of the ridiculous prefix convention.

This from a point of view of C++ ARM defacto standard back in the 1990's, not even considering anything else.

I see more possibilities for people to hurt themselves using C than C++, since 1993 when I added C++ to my toolbox.

[-]

The stl is also unsafe by default and not actually safer than what you can also do in C.

I debugged enough problematic C++ code to know that people can hurt themselves badly with it.

[-]

Contrary to C standard library, all C++ compilers have provided safe versions of their standard libraries, predating C++98, enabled in debug mode.

Even if non standard, all major C++ compiler vendors have provided similar features on their standard library, and is now officially supported in C++26.

I have debugged enough C memory corruption issues with strings and arrays, that I would thought by now WG14 would actually care to fix the root cause, 40 years in.

[-]

The C standard library does not have containers, so I do not see how this sentence makes any sense. The reality is that C++ STL is in practice not really safer than C arrays, and although you can activate bounds checking, there remain many gotchas. But I am happy to see that bounds checking is now becoming official with C++26. For C arrays you get bounds checking in practice with -fsanitize=bounds. For containers, you would need a library in C that does bounds checking. So in both languages it is possible to get bounds checking if you want to.

[-]

A compiler extension only available in clang is not C, so nope, there is no solution available in ISO C, and apparently never will be one.

Also to note that said extension only exists because Apple did the work WG14 did not bothered to do for the last 40 years, and as way to improve interop with safe Swift.

by uecker223 days ago|

[-]

The compiler extension is also available in GCC at least, and it was you who cited extensions.

by pjmlp223 days ago|

[-]

Doesn't change the fact that isn't on ISO C.

At least WG21 eventually did the correct thing and placed those extensions into the standard, even if due to governmental pressure.

Also while enabling bounds checking has been a common configuration option in all C++ compilers, clang and GCC aren't all C compilers.

This kind of discussion is also quite telling that nothing will change on WG14, maybe eventually who knows, C2y might finally get fat pointers if voted in, and then we will see during the following decades whatever fruits that will bare.

by uecker223 days ago|

[-]

That WG21 made finally made its containers safer is great, but the C standard library does not have containers. You can still have your own bounds checked containers just fine in C, as you could in the past.. ISO C simply does not matter as much as you like to pretend - for trolling I must assume.

When we will have a standard for bounds checking arrays and pointers remains to be seen, but this does not stop anyone from using the non-standard tools available today.

by TuxSH224 days ago|

[-]

IMHO C++ scales far better for large, self-contained, personal projects though it requires slightly more initial investment.

And if you're targeting PC, you might be better off using Python to begin with (if perf is not a concern)

[-]

What specifically makes it scale better in your opinion?

by TuxSH224 days ago|

[-]

- "All" C libraries use some form of namespacing (the typical mylib_dosomething kind of name); actual namespaces mean you don't write these prefixes over and over again when in the same namespace

- "Most" C projects do basic OOP, many C projects even do inheritance via composition and a fair few of these do virtual dispatch too

- Templates (esp. since C++20), lambda functions, overloads and more recently coroutines (which are fancy FSM in their impl), etc. reduce boilerplate a lot

- Containers (whether std:: or one's own) are far easier to work with in C++, a lot less boilerplate overall (GDB leveraged this during their migration iirc)

- string_view makes non-destructive substring manipulation a lot easier; chrono literals (in application code) make working with durations a lot more readable too

In the past decade or two, major projects like GCC and GDB have migrated from C to C++.

Obviously, C retains advantages over C++, but they are fairly limited: faster build times, not having to worry about exposing "extern C" interface in libraries, not having to worry about controversial features like exceptions and (contextually) magic statics and so on...

by rramadass223 days ago|

[-]

Nicely said!

One other key thing is encapsulation provided via various C++ syntax which is missing in C (where only file scope is possible).

by waynecochran225 days ago|

[-]

Not always a viable option -- especially for embedded and systems programming.

by Too224 days ago|

[-]

In embedded you are typically stuck on some ancient proprietary compiler and can't take advantage of the latest C versions. Even less so if you need safety standards like MISRA.

That of course doesn't help you with the switch away from C. The question is why they keep updating the language. The only ones with valid reasons to not upgrade to some more sane language can't take advantage of the new features.

by _proofs224 days ago|

[-]

i work in an embedded space in the context of devices and safety. if it were as simple as "just use c++ for these projects" most of us would use a subset, and our newer projects try to make this a requirement (we roll our own ETL for example).

however for some niche os specific things, and existing legacy products where oversight is involved, simply rolling out a c++ porting of it on the next release is, well, not a reality, and often not worth the bureaucratic investment.

while i have no commentary on the post because i'm not really a c programmer, i think a lot of comments forget some projects have requirements, and sometimes those requirements become obsolete, but you're struck with what you got until gen2, or lazyloading standardization across teams.

by sim7c00224 days ago|