News for hackers. Stuff that matters.
Re:The problem with C by pjc50 on Thursday September 03, 2020 @05:30AM (#24362293)
Are any of the C features that aren't present in C++ actually useful for something that doesn't have a better C++ alternative? I can't see main recursion as being particularly important (and I suspect a lot of compilers will let you do it even if the standard doesn't).
Re:The problem with C by flohofwoe on Thursday September 03, 2020 @05:44AM (#24362357)
C99 designated initialization is the big one. It almost feels like a new language and makes C++ look a bit silly with all its different initialization features. C++20 got a subset of C99 designated init, but it is so much restricted that it's practically useless for anything but very simple structs.
Re:The problem with C by jstimpfle on Thursday September 03, 2020 @05:57AM (#24362435)
Yup, designated initializers is a big one why I prefer C to C++.

Another big one is implicit casting of void ptrs. I cast void pointers to specific types A LOT. There are many situations where you have to cast void pointers (that come from an abstract API that only deals with untyped memory) to specific types (higher-level application code), and I can't really be sure, but I think there isn't a nice way to do that in C++.

It might be because C++ wants you to use their elaborate abstractions and templates, which in many situations is just fluff that makes programs harder to read and maintain.

Re:The problem with C by hellofunk on Thursday September 03, 2020 @06:26AM (#24362596)
You can cast void pointers in C++ as well, and it is very easy. The difference is that usually you would use a specific kind of cast that makes this clear to the reader.
Re:The problem with C by secondcoming on Thursday September 03, 2020 @06:49AM (#24362695)
reinterpret_cast was the canonical way of doing it in C++, but now I believe that this is actually UB and so modern C++ should use std::bless.

C++ also supports C-style casts but it's a code smell.

Re:The problem with C by jcelerier on Thursday September 03, 2020 @05:52AM (#24362397)
> but it is so much restricted that it's nearly useless.

that's a pretty harsh take on it - how would you design it considering that initialization order has to be respected (else a lot of use cases would break; it's definitely not uncommon to have a member of a struct to depend on a previous member being initialized) ?

I have yet to find a particularly blocking use of the feature when test-driving it - it's on the other hand a great boon for readability (and definitely puts a nail in the coffin of named function parameters proposals imho).

Re:The problem with C by flohofwoe on Thursday September 03, 2020 @05:57AM (#24362436)
The ordering requirement is indeed the biggest problem once you have structs with more than a handful of items (maybe one day Intellisense will help with this problem), but the missing array access and not being able to "chain" designators (.a.b.c = ...) are also painful omissions.

Clang has demonstrated long before C++20 that it is possible to use the full C99 designated-init feature set in C++, so I really don't understand why the C++ Committee had to cut down the feature when there was already a fully working implementation.

PS: as an example for where C++20 designated initialization breaks down, see for instance [1], I tried to replicate this code in C++20, but quickly gave up (with the main problem being that it is impossible to remember the correct declaration order in big "option bag" structs like this.

[1] https://github.com/floooh/sokol-samples/blob/e0a93a21b17a663...

Re:The problem with C by InfiniteRand on Sunday September 06, 2020 @10:51AM (#24391719)
Anonymous struts and unions allow fine grained control of memory layout in embedded code. (I am not 100% sure this is not UB but I have seen it in a lot of embedded code)

Not sure if this is impossible in C++, I think some of the alignment functionality added in the past several versions might cover this, but it is not as simple.

IMHO, Not a big reason since every compiler offers some non-standard keywords to cover this use case, but a reason nonetheless