NHacker Next
- new
- past
- show
- ask
- show
- jobs
- submit
login
Rendered at 15:05:15 GMT+0000 (Coordinated Universal Time) with Vercel.
- C `_Atomic(T)` and C++ `std::atomic<T>`. C++23 has C compatible header `stdatomic.h` that defines `_Atomic(T)`, but it's still problematic
- C `_Noreturn/noreturn` and C++ `[[noreturn]]`. C23 `[[noreturn]]` makes them compatible
- C inline and C++ inline are different. Good news is their `static inline` are the same
- C has anonymous struct. C++ doesn't. Both have anonymous union though
If you're allocating something on the heap anyway, you shouldn't be forced to pay for an indirection in order to have some variable-sized data in the object, you should just be able to put it all in the one allocation. (Sure, you can achieve that with placement new hackery but that certainly isn't "idiomatic" C++.)
Of course that's completely incompatible with the way allocation and construction work (storage has to be allocated before the constructor runs). Hence "design flaw" rather than "missing feature."
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.
Address white_house{
.street = "1600 Pennsylvania Avenue NW",
.city = "Washington",
.state = "District of Columbia",
.zip = 20500,
};
However C++ had at time no default initialization for unmentioned fields, so in 2017 I had to remove it when converting the code to C++
https://godbolt.org/z/3aKaa7dnM
only if you specifically ask to get an error, would you actually get it.
That is for when the owner is a std::string or an owning range respectively. But a raw pointer does still make sense as a non-owning view over a single element, doesn't it? I'm new to C++ so I might be wrong.
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 catch up.
Some features were standardized back in 2023, yet not a single implementation supports them in 2026.
Loosely coupling a language to its compiler is 20th century thinking for when programming languages were simple. It works for C because C is simple enough to be implemented over and over again. But for today's hyper complicated languages, multiple implementations is a pain for everyone.
When a programming language community fractures into multiple incompatible implementations everyone is worse off.
I'm sure I could argue with you about the actual technical differences but this part in particular is very, very stupid.
JTC1/SC22 † shouldn't exist at all. A committee structure is a bad way to do this work, and the practice of having periodic meetings - exclusively in person for much of the time these existed - actually makes it less rather than more useful.
ISO mandates a bunch of rules and procedures which surely make some sense if you're agreeing on thread dimensions for oil pipelines but are completely inappropriate for this work and yet because they're ISO committees the WG14 and WG21 processes are captured.
I don't think it makes good sense to use an SDO for this work, but if you must have an SDO for some reason beyond ego then you could do a lot better than ISO. Check out TC39 for example.
† The C and C++ standards committees are respectively Working Groups 14 and 21 of the Sub-committee on Programming Languages, SC22, of the (First and only) Joint Technical Committee between ISO and the IEC. Yes it's committees all the way down. "This programming language standard could have been an email".
ISO agreed that despite there being an existing, popular, broadly supported and open XML document standard they should define Microsoft's proprietary alternative OOXML as an international "standard". They even held votes repeatedly until the voters gave the "correct" answer... no worry about "industry donations" there.
Maybe I'm missing something though and there are other alternatives done differently in other languages?
I also think that where you want monomophization, macro seem fine. I do not think this necessarily has to be clunky, but this is just a guess.
If just "providing my own" would help why wouldn't the stdlib benefit too? You're going to have to spell out what you think can actually work here if you want me to believe there's "no problem".
Using C macros to replicate Rust's monomorphism has several drawbacks: they are inherently unhygienic, even in comparison to Rust's own; you can't set type-bounds; they aren't even a part of C proper, etc.
I prefer Rust's approach with the choice between generics, macros, dyn and Any.
C macros are certainly a proper part of C and one can also certainly add type-bounds. But yes, they are not ideal. Still, if one wanted to do this, one could certainly improve them a lot for type-generic programming. I would prefer this to having macros, generics, a const expression sublanguage, and vtables.
Specialization provides more opportunities for optimizations, whereas proper type-erasure (which bars specialization optimizations) doesn't due to lack of type information.
"C macros" are a part of the preprocessor, which runs before the actual C compiler. As such, it lacks all semantical information the C compiler would have at that point, such as function implementions. In practice, macros in C serve two purposes: manipulating C source code (which Rust macros can also do, but with more hygiene); specialization polymorphism, but worse (in which both Rust's generics and C++ templates do better).
Type-erasure can be undone by specialization. In contrast, monomorphization specializes the code first, at which point it becomes much more difficult to unify it again.
Sorry, my comment about preference was badly phrased: What I meant is that I prefer to make macros better, than having all the different but partially overlapping techniques in the same language. This is the complexity I am complaining about in both C++ and Rust.
The problem with your suggestion about macros is that it misunderstands the reason why different techniques exist. While they may overlap, they have different primary niches: Rust macros provide codegen and inline DSL, Rust generics/C++ templates provide monomorphism, C++ constexpr/Rust const fn evaluate expressions in compile time, etc.
Extending preprocessor macros, aside from requiring integration into the C language proper, would likely create something much more complex and with poor DX. Specially so if it tries to fulfill all niches, as each of them often operate at different abstraction levels, with different ergonomic requirements that are often at odds with each other.
Monomorphization often forces types information to flow, whereas type-erasure considers that a bonus. As such, a compiler may accidentally introduce opaque boundaries that hide type information. Even in cases where this is the programmer's fault and the type info is truly lost, in monomorphisation, that becomes an explicit error, while, for devirtualization, since it's just an optimization, the call is silently revirtualized (until someone notices it while profiling/decompiling). One has explicit intent, the other doesn't.
I agree that monomorphization has explicit rules that force specialization, I do not think this is an advantage at all because it is too rigid and one can introduce explicitness at the language level also for devirtualization where this is needed. In this sense, monomorphization is premature optimization which limits what can be expressed at the language level and makes the job of the optimizer much harder (and practically impossible to undo the damage completely).
I haven’t used rust, but having gotten used to C and C++ at a time, I expect that would happen with rust, too, if I started using it. Because of that, I think this is just a matter of familiarity.
> polymorphism based on monomorphization
Implementation detail (yes, there is only one implementation at the moment, but this means it can be changed without changing the language)
> the requirement for many dependencies to get anything done
Fixable if a party is willing to write or package together a fairly large set of dependencies into a single package.
> an ecosystem susceptible to supply-chain attacks
Fixable if that party is trustworthy. Also, for which languages is this less of a problem? You either have third-party libraries and a potential security problem, or you don’t, and need to write more code.
While, as discussed previously, devirtualization + inlining is a thing, it is not assured and relatively easy to disable. Writing a program relying on these optimizations would produce something bristle and error-prone, and building a polymorphic system around this would be antithetical to the Rust's ZCO philosophy.
Meanwhile, monomorphization can fit functions around the size of the type arguments and access method implementations directly, removing the need for any indirection in the first place. While indirection-based polymorphism can't reliably reimplement monomorphic polymorphism, the reverse is not true. You can reliably reimplement any indirection-based polymorphism with monomorphism, from fat pointers (in fact, Rust already has trait objects to help with that), class-based hierarchies, dynamic typing, etc.
See Ada, D, Delphi,....
Granted, priorities, one cannot fix everything at the same time.
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.
Now, I rather have them than not, but it is still clunky.
https://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2003/n14...
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?
for example you want to add nice feature to c++ with nice syntax, but there is a similar syntax somewhere in C that nobody uses, but you have to support it. you end up with nice feature with horrible syntax.
Eh, all of the committee members I've known are obsessed with modern C++, and "can this feature be implemented?" is definitely a blocker; numerous features got kicked down the road from C++0x to later versions because compilers weren't ready for them.
For example in Rust there is one big entity that currently pours a lot of energy into improving C++ interop. Now, this is not exactly a niche topic, but especially in a world where AI makes many rewrites possible that we wouldn't have daunted to think about a couple of years before, we shouldn't waste too much effort to save legacy companies enormous codebases at the detriment of our preferred language.
Compilers can often do some static bounds-checking of such arrays. But because those features had been introduced together with variable-length array stack variables , people have lumped them all together and thus shunned these features that could otherwise have added safety.
BTW, one thing you should never do is use variable-length array declarations and alloca() in the same function. As VLA variables have scope life-time and allocas have function life-time they are not compatible — and allocations could overlap. Yet, not all compilers (/versions) that support both warn when they are used together.
In 2019 I wrote a short survey of C constructs that do not
work in C++. The point was not that C is sloppy or that C++
is superior. The point was that C++ is not a superset of C,
and that C programmers crossing the border should know
where the checkpoints are.
Another well-known counterexample is implicit conversion from void*. In C89 you can do `int* foo = malloc(100);` but in C++ it requires an explicit cast from void* to int*.
I don't believe there was ever a time, even pre-standardization, when C++ was a strict superset of C; it always had little incompatibilities here and there.
It looks like you're right and the answer to when was C++ a superset of C may well be "never".
From the description, Cfront had always been a full-fledged parser that only happened to output C since the very beginning.
perhaps more accurately a fully fledged compiler (that emitted C)
?: has another execution priority.
Implicit cast scenarios are reduced in C++.
It doesn't matter unless you are using constructors or modifying some variables in the initialization expression anyway.
This takes the cake.
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 philosophically: object lifetime vs raw storage, stronger type systems, implicit conversions, ABI and optimization assumptions, and the boundary between "portable" and "works on my compiler."
I’d also be curious which C constructs people still genuinely miss in modern C++. For me, restrict is still near the top of the list.
Also, let's not forget that implicit casts between unrelated pointer types is only a warning in C. Fortunately, modern C compilers started treating it as an error by default because it caused so much harm: https://gcc.gnu.org/gcc-14/porting_to.html. In C++ this was always a compiler error.
A warning in C has the meaning of a "stern warning" aka. "That very much won't work, I warned you!". An error means, "I literally, don't what you mean".
Also as far as I know, the C standard only talks about diagnostics.
(Another pet peeve of mine is that missing returns in functions is not considered a hard error. GCC 16 does not even issue a warning by default when compiling C code, which is just crazy. "-Werror=return-type" is the first thing I do in every new C or C++ project. I don't understand how this is still not the default...)
That's because the default mode for compilers is to just shut up and compile this throw away code. Programmers know that you are expected to turn the warnings on and also nobody is manually invoking compilers directly. The default for build systems is often "-Wall -O2" anyway. Personally I prefer the status quo, I hate tools, that I just invoke and they start spamming my terminal. "Like, I know, that there will be issues, that's why I'm using you, but you don't need to tell me until I told you what exactly you are supposed to report me. Don't spam me until I ask you."
> Why lump serious issues like incompatible pointer casts together with benign things like uninitialized variables?
?? Uninitialized variables are also serious issues and also undefined behaviour. If anything they're more serious, because for pointer casts, it is likely that the types are compatible, but the compiler just doesn't know it, while truly uninitialized variables are always a real error. For the latter, the issue is rather, that the compiler often can't proof whether the variables are actually uninitialized. That's why it is more likely to meet a "maybe-uninitialized", a true "uninitialized" is rare in the wild.
I’m not arguing that that’s better, or worse, but it’s definitely true and by no means a myth.
I.e. most of the time the typing in real C++ code isn't meaningfully stronger than that found in C code.
...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.
You don't need to explicitly cast T* to void* (guaranteed to be safe), you only need to cast when converting out of void*.
The rules are basically the same as casting between pointer-to-derived-class and pointer-to-base-class and they make sense.
Yes, downcasting can be unsafe and should be used carefully, but what's the alternative? At least in C++ you can't cast between unrelated types without an explicit reinterpret_cast (or C-style cast).
It is also not clear what is gained by forcing programmers to add a cast. Void pointers should be used sparingly anyway.
If C++ programmers do not use modern safety features, that's really their fault. C-style pointer casts should be flagged in code review.
> but that it becomes even less safe by adding a C-style cast.
At least in C++ there is a safer option. If you really want to be on the safe side, you can even to a dynamic_cast (assuming your code base allows RTTI).
> It is also not clear what is gained by forcing programmers to add a cast.
I think the point is to make it explicit and stand out.
Another annoying detail is that C++ doesn't seem to like forward references of `enum`s. That is, while
is fine in both C and C++ even before `struct A` has been defined, apparently is not cool in C++ until after `enum A` has been defined.One arguable benefit of keeping your C code compatible with (or at least convertible to) C++, is that you can theoretically use scpptool's auto-translation feature as build step to produce memory-safe executables from C code via transpilation to a memory-safe subset of C++.
[1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
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.
There are some ATLAS TDAQ/HLT papers with my name on them.
Template metaprogramming, multi-threading, and custom IP protocols where much more relevant.
* built-in multidimensional arrays with efficient storage.
* related to this: built-in array intrinsics
```
real, dimension(100,100) :: A, B, C
C = A + B
```
this kind of code is already a close-to optimal "naive" implementation (not considering parallelization). so you start already at a solid place. then you can easily run it in parallel without too much specialized knowledge with OpenMP, OpenACC, MPI or even CUDA. the only thing you really need to be aware of when implementing your own loops/kernels: the intrinsic storage order, to optimize for cache hits.
* crucial: all the above amounts to a standard/best practice about how data is structured and formatted. everyone just uses the built-ins. Thus, interoperability between native Fortran numerical libraries is usually a complete non-issue. Meanwhile, Cpp has a fractured ecosystem with different array/vector types for its libraries. Converting between one and the other is usually a no-go.
* next, the intent plus pass-by-reference system. it combines IMO the best of both worlds of a functional vs. procedural approach:
* finally, a clean symbol definition system that decouples types from byte lengths. a `float` in fortran is just `real(4)`, a double is `real(8)`, a long int is `integer(8)` and so on. now, it's trivial to do a bit of preprocessing to switch the precision.However, the last part is where Cpp has a strong advantage: Well supported meta-programming (generics, templating or even just well supported pre-processors). Fortran's compilers come with a lot of built-ins, so the lack of these is less of an issue than you might think, but it's still a limiting factor. All that being said, a typical scientist doesn't tend to care and just wants to solve a particular problem rather than thinking in generalized frameworks - and that's why I find Fortran still serves them better for numerics than anything that came since.
[1] https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3734.pdf
C++ is 1990's Typescript for C++, while C folks still think is a portable Assembly instead of designed to an abstract machine model.
As such C++ community embraces high level abstractions and type systems improvements, whereas C wants to still code as targeting classical hardware.
> C [community] wants to still code
> many still don't know to distinguish
> the culture that... despite easy proof that isn't the case
> devs wrongly assume
> self inflicted complexity
> considered an advantage when argued by C folks
> when the same crowd points
> as the C crowd pretends it to be
You're arguing in this thread not by addressing what people are actually saying but by bringing up some hypothetical version of what "the C Community" thinks, then arguing with that.
Also it isn't a C invention to have the compiler dump the Assembly output instead of object code.
Now the culture that C language constructs in 2026 are still 1:1 to Assembly instructions, that pretty much prevails, despite easy proof that isn't the case at various compiler optimization levels.
Proficient devs, well many still don't know to distinguish what is their compiler, and what ISO says.
So it's all about understanding and control, not about some idea that C was defined in terms of assembly instructions, which it obviously is not. That's a total strawman.
Then get surprised when it doesn't map to the SIMD/SIMT NUMA machine their code actually executes on.
I am talking about self-inflicted complexity that is entirely within the C(++) machine model. Avoid that complexity and you're pretty good already. Only drop down to concrete hardware arch level where it makes sense. But largely, the C machine model is still very much suited as a model for actual hardware. Writing straightforward obvious code allows you to stay in control of memory layout and the data transformation paths. It easily gets you within <<2x of what you could achieve with hand coded assembler for the >90% of the code that are pretty boring and straightforward. And obviously you couldn't get the work done in time when coding everything in assembler.
I have seen plenty of self inflicted complexity in C, starting in the golden age of Yourdon Structured Method, and all those libraries that replicate C++ basic features with preprocessor macros.
https://replicated.wiki/blog/abc
Also when we eventually start talking to agents that perform the whole execution steps by themselves, that is kind of irrelevant.
Except for the lucky ones that still code to keep the infrastructure going, which is mostly C++.
If C would be so hardwired to the PDP-11 architecture it would have died with it. In reality C works just fine on all sorts of hardware (like GPUs) with only minor extensions.
I am also tired that language extensions in C to work around ISO defencies is considered an advantage when argued by C folks, while at the same time it is considered a language design fault when the same crowd points to other programming languages.
The PDP-11 had both 8 and 9-bit bytes. Thats a complexity that few programmers have to touch on, today.
Basic stuff like SIMD, SIMT, without requiring users to go beyond language extensions, something that any programming language can offer in similar capacity?
> something that any programming language can offer in similar capacity?
By your measure a lot of other languages don't offer anything to begin with, because they do not have a standard at all, only a reference implementation.
My pet peeve with C++ is that the sequence point operator can be overloaded at which point it stops being a sequence point.
https://gitlab.com/libeigen/eigen/blob/master/Eigen/src/Core...
...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...):
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.Having attempted to implement it correctly in slimcc, there are indeed some edge cases[1][2] that justify not adapting it fully.
[1] Unordered side effects; evaluation of expressions with overlapped destination is implementation defined but not listed as such (the wording in standard is "can potentially not be evaluated").
[2] Both GCC and Clang still get this wrong in 2026: https://github.com/llvm/llvm-project/issues/190858
Following on the Secure Future Initiative activities.
The C updates have been what is required to compile critical FOSS projects, or support big name customers on Windows.
Apple and Google are also not racing to adopt new clang versions on their platforms.
The languages have diverged a lot, it's true. Still, it is worth noting that all the code in TCPL 2nd Ed was compiled with Stroustrups C++ compiler, as there wasn't a C compiler available. Source: Preface/Acknowledgments.
How did Clang handle differences between member declaration order and the order in which initializers appeared?
https://www.godbolt.org/z/ex138rh51
(the warnings in C++ mode had only been added after C++20)
Edit: I should've had more conviction in my instincts, this is slop.
Curiously my comment above was on +3 karma last time I looked, but now it's on -2. It seems like the median HN user is getting worse at slop detection (or is otherwise ambivalent towards slop comments).
Perhaps be more careful in trying to make LLM output look like you wrote it yourself. The incongruent punctuation mark types, with curly apostrophes and straight double quotes mixed together in the same text, are a dead giveaway.