Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C constructs that still don't work in C++

lospino.so

Post reply on HN
Print view View original

41–50 of 182 posts

Re: C constructs that still don't work in C++

#41

Post by flohofwoe »

jalospinoso wrote: post #2

I wrote this after repeatedly seeing experienced C programmers hit the same sharp edges while moving into modern C++ codebases. Many of these differences are intentional and defensible from the C++ side. But some are still surprising because they invalidate patterns that were historically common, performant, or idiomatic in C. The interesting part to me isn’t "C vs C++," but where the languages diverged philosophical…

> I wrote this after repeatedly seeing experienced C programmers hit the same sharp edges while moving into modern C++ codebases.

...I've seen this more often in the opposite direction. Since C++ is stuck with a ca 1995 non-standard subset of C, C++ coders usually have a very outdated view of C.

> I’d also be curious which C constructs people still genuinely miss in modern C++.

Not implementing the full C99 designated init feature set was a huge missed opportunity in C++20. Every single feature of C99 designated init is important and clicks with the other features and the rest of the language, take one or two away and it becomes mostly useless (e.g. the order requirement in C++20 means that designated init is only useful for trvial structs).

It's especially tragic because Clang already had the full C99 designated init feature set in C++ mode implemented long before C++20 and it worked just fine.

> The interesting part to me isn’t "C vs C++," but where the languages diverged philosophically

IMHO this "schism" was completely unnecessary and only happened because of ignorance and hubris by the C++ designers. Objective-C shows that C can be extended with radical new features but without messing up the "C side" (e.g. ObjC features don't overlap with C features, which means that ObjC is automatically compatible with the latest C standards).

In the end it's not a big deal of course, C and C++ are now entirely different languages and longterm that's for the better. Even the C++ peeps seem to have come to that realization and no longer recommend to "compile C in C++ mode" (like Herb Sutter in 2012 when trying to justify why MSVC had no C99 support: https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...):

    "We recommend that C developers use the C++ compiler to compile C code (using /TP if the file is named something.c). This is the best choice for using Visual C++ to compile C code."
This was bad advice back then and is even worse advice today. At least MSVC got "good enough" C99 support a couple of years later (in VS2015), but after a few hopeful years after 2019 it looks like MSVC development has completely stalled again.

Re: C constructs that still don't work in C++

#42

Post by bitwize »

remix2000 wrote: post #38
maxloh wrote: post #33

I think the problem is that C++ is a poorly designed language with a fundamentally flawed development process. Instead of letting compiler implementers decide which features to add and how to implement them, C++ employs a standards-first, top-down approach. Features are often defined by committee members who may not use modern C++ in their daily workflows, leaving it entirely up to the individual implementations to c…

Rust is impl-first bottom-up and it's stuck with a single implementation and GCC for Rust is still in the works, meanwhile C++26 reflection is already in GCC trunk.

Rust is also the systems programming language of the future. They're pretty much doing everything right.

Re: C constructs that still don't work in C++

#43

Post by m_mueller »

pjmlp wrote: post #7
jalospinoso wrote: post #2

I wrote this after repeatedly seeing experienced C programmers hit the same sharp edges while moving into modern C++ codebases. Many of these differences are intentional and defensible from the C++ side. But some are still surprising because they invalidate patterns that were historically common, performant, or idiomatic in C. The interesting part to me isn’t "C vs C++," but where the languages diverged philosophical…

I appreciate that restrict isn't there, because it is yet another UB source, programmer knows not to do errors kind of attitude, and secondly no one seems to care enough to write a language proposal for it.

I take it you probably never tried to use any of these languages for HPC. Without a language standard, you have two options there to compile decently performant executables: (1) compiler pragmas, (2) give up and drop to assembly code.

I should add here that there's also (3): Switch to Fortran, which made fundamentally different choices and is IMO the only fully supported higher-than-C level language that can produce HPC applications without fighting a compiler left and right.

Re: C constructs that still don't work in C++

#44

Post by mgaunard »

mike_hock wrote: post #11

The thing with the flexible trailing array member is a C++ design flaw. Now the fix wouldn't be to allow those "flexible arrays" in C++, at least not the way C has them, but it should have a concept (not that kind of concept) of types that are indeterminately sized at compile time and whose size is determined at construction. If you're allocating something on the heap anyway, you shouldn't be forced to pay for an ind…

There is no problem putting objects past the end of another object in C++.

I use this approach as part my zero-copy serialization library for what I call "out-of-line" sequences.

It does require smart usage of std::launder to be standards-compliant though.

Re: C constructs that still don't work in C++

#45

Post by einpoklum »

maxloh wrote: post #33

I think the problem is that C++ is a poorly designed language with a fundamentally flawed development process. Instead of letting compiler implementers decide which features to add and how to implement them, C++ employs a standards-first, top-down approach. Features are often defined by committee members who may not use modern C++ in their daily workflows, leaving it entirely up to the individual implementations to c…

C++ is a language with perfect 30-year backwards compatibility, and which mostly-maintains compatibility with another language it forked from (C), after 40 years of diverging development.

Rust is a language which isn't backwards-compatible, and certainly not compatible with source code in other languages.

Now, sure, Rust has its advantages, but - how can you fault C++ in the context of compatibility?

Re: C constructs that still don't work in C++

#46

Post by uecker »

bitwize wrote: post #42
remix2000 wrote: post #38

Earlier quoted context omitted.

Rust is impl-first bottom-up and it's stuck with a single implementation and GCC for Rust is still in the works, meanwhile C++26 reflection is already in GCC trunk.

Rust is also the systems programming language of the future. They're pretty much doing everything right.

What IMHO Rust does not get right and why I do not use it: long compilation times, high complexity, its syntax, polymorphism based on monomorphization, the requirement for many dependencies to get anything done, an ecosystem susceptible to supply-chain attacks, no ISO standard.

Re: C constructs that still don't work in C++

#47

Post by skrebbel »

maxloh wrote: post #33

I think the problem is that C++ is a poorly designed language with a fundamentally flawed development process. Instead of letting compiler implementers decide which features to add and how to implement them, C++ employs a standards-first, top-down approach. Features are often defined by committee members who may not use modern C++ in their daily workflows, leaving it entirely up to the individual implementations to c…

> committee members who may not use modern C++ in their daily workflows

Are you sure about this one? I don’t know exactly who’s in the committee these days but last I checked they were all hardcore C++ programmers with decades of experience from the trenches.

Re: C constructs that still don't work in C++

#48

Post by einpoklum »

m_mueller wrote: post #43
pjmlp wrote: post #7

Earlier quoted context omitted.

I appreciate that restrict isn't there, because it is yet another UB source, programmer knows not to do errors kind of attitude, and secondly no one seems to care enough to write a language proposal for it.

I take it you probably never tried to use any of these languages for HPC. Without a language standard, you have two options there to compile decently performant executables: (1) compiler pragmas, (2) give up and drop to assembly code. I should add here that there's also (3): Switch to Fortran, which made fundamentally different choices and is IMO the only fully supported higher-than-C level language that can produce…

Can you link to some writeup regarding how Fortran is preferential to C++ (or rather C++ plus compiler `__restrict`) in this respect?

Re: C constructs that still don't work in C++

#49

Post by flohofwoe »

uecker wrote: post #29
jalospinoso wrote: post #2

I wrote this after repeatedly seeing experienced C programmers hit the same sharp edges while moving into modern C++ codebases. Many of these differences are intentional and defensible from the C++ side. But some are still surprising because they invalidate patterns that were historically common, performant, or idiomatic in C. The interesting part to me isn’t "C vs C++," but where the languages diverged philosophical…

The "stronger type system" is mostly a myth in my opinion. It was true in the past in pre-prototype C. The void pointer rules are better in C IMHO as they avoid unneeded casts (that then remove more type safety) and FAMs and variably-modified types can express things C++ simply can't do well.

> The void pointer rules are better in C IMHO as they avoid unneeded casts

...so much this! A void pointer is an "any-pointer" by design. It shouldn't require casting from and to specific pointer types, that defeats the whole point of having void pointers in the first place.

Post reply on HN