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 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.
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.
I don't get your point at all. C++ has different casting operators (static_cast, const_cast, reinterpret_cast) that are strictly safer than C-style casts.
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.
> implicit casts between unrelated pointer types is only a warning in C
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.
You are right that the C standard only talks about diagnostics, but this doesn't change the fact that implicit casts between unrelated pointer types are not treated as hard errors.
Ok, but then compilers should really throw errors for these diagnostics by default. Why lump serious issues like incompatible pointer casts together with benign things like uninitialized variables?
(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...)
> Ok, but then compilers should really throw errors for these diagnostics by 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.
> ?? Uninitialized variables are also serious issues and also undefined behaviour.
Oh my, I meant to write "unused variables" facepalm. Uninitialized variables are of course a serious issue.
So back to my original point: you said that warnings in C are always a serious thing, but that's not really true. Warnings can range from more or less harmless to very serious. In fact, compilers recognize this issue by upgrading certain warnings to errors by default. See again my link to the GCC 14 post: https://gcc.gnu.org/gcc-14/porting_to.html.
> That's just not true. Compilers do issue certain warnings by default and they even treat some warnings as errors.
Because some warnings are just believed to be more serious, than others.
> In fact, compilers recognize this issue by upgrading certain warnings to errors by default.
Which I interpret as a culture shift, due to people complaining about it and also because the contemporary meaning and expectation of warnings for programming languages has shifted.
> Also, let's not forget that implicit casts between unrelated pointer types is only a warning in C.
I intended to argue against the "only a warning", because the meaning of a warning in C is something very serious. That is different from more modern languages, who may use this to inform you that you are no longer writing idiomatic code. Of course there are also exceptions, that you often need to enable explicitly. But the fact that something is a warning in C, doesn't mean it's nothing serious, quite the opposite. That's my point.
But you can't argue that a warning is less severe than a hard compiler error. Warnings can be supressed or ignored.
You were right to call out that the C standard only talks about diagnostics and the actual implementation is left to the compilers, but I don't think it really changes the actual argument I've been trying to make, namely that - unlike in C++ - implicit incompatible pointer casts are not a guaranteed compiler error.
More complex != stronger. A weak type system would imply that the type systems forgives type mismatches. C had this before it imported prototypes from C++ where you could call a function without declaring it first and if you got it wrong you got some error or crash. The only part where I think C++'s type system is meaningfully stronger than C are enumeration types.
> 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.
They make sense but reduce type safety, because once you add the cast the case might hide some real typing issue. I sympathize with the idea that the down-cast should be explicit though.
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).
and you CAN use static_cast to convert from void*; this silently keeps working if you refactor the void* into a matching-type pointer later, while raising a compilation error if you refactor to a different-type pointer.
Yes, a static_cast would be safe, but then most C++ seems to use a C-style cast because it is less clunky and then is less safe than the corresponding C code. The issue is not that the downcast is unsafe (it is, but once you have a void pointer you already accepted this), but that it becomes even less safe by adding a 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.
I see your point. It would be nice if a C-style cast behaved like a static_cast in C++, but that's not possible because of backwards compatibility. At least with GCC/Clang you can disable C-style casts altogether with '-Werror=old-style-cast'. (Maybe there is a similar option for MSVC.)
Yes, this is something that would need a new language edition to properly fix. Compiler vendors could split -Wold-style-cast into separate warnings for static_cast and other usage though so that you can only ban one of them.
The point is that, there is nothing else to be done with a void pointer, other then downcasting it, and it needs to be downcasted to be used. There is no other check that somehow validates the cast, so there is no upside to requiring the cast, while it does potentially silence accidental casts once the type changed.
You might be interested in the scpptool feature to help convert C code to a subset of C that will also compile as C++ (under clang++ at least) [1]. While many of the necessary modifications are fairly trivial, some of them aren't completely so. For example, C++ does not allow `goto`s that would skip over the declaration/initialization of a variable that would be accessible after the jump. So getting the C code to work as C++ can involve some (automatic) code restructuring.
Another annoying detail is that C++ doesn't seem to like forward references of `enum`s. That is, while
struct A* a_ptr;
is fine in both C and C++ even before `struct A` has been defined, apparently
enum A* a_ptr;
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++.
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.
I keep looking around and not finding any, so let me just try here before someone just takes it and slopifies it:
* 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:
- I can predefine if an array / variable is intended as input, output or both, simply with `intent(in)`, `intent(out)` etc.
- compiler can thus do checks for me if I'm breaking a contract.
- yet, since I pass by ref, I don't have to worry about memory not being used efficiently. This really matters once you deal with GB, TB or even PB worth of data going into a simulation over time - there's just no way to deal with that in a purely functional way.
- only where really necessary, you can still drop down to pointer semantics, e.g. for the outer glue code of a simulation that swaps outputs and inputs for the next time step.
- having `restrict`-by-default semantics here helps immensely. Imagine you have many arrays with lots of data to deal with, and your kernels access always several at a time to do calculations. In Fortran I can write it intuitively, while in C/C++ I must remember to specify `restrict` or to preload all point-inputs first into separate variables to direct the compiler. Otherwise the memory pressure increases, and by far most such physics simulations are memory bandwidth bound - every access counts.
* 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.
Not sure if you're aware, but defer is proposed for C2Y [1]. It's already available in Clang behind a compiler flag. It is interesting how the languages continue to diverge.
> 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.
Caring for the actual assembler output in selected critical pieces of code is not the same as ignoring the abstract machine model. What you claim is simply not the case if you check actual proficient systems programmers. Of which there are an astonishingly high share C and C++-but-mostly-C programmers.
Any user of compiled languages cares about Assembly, which is why regardless of the compiled language, an Assembler was always shipped alongside.
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.
It is the case that you can more easily know what happens when you don't use the wrong abstractions but stay in control. Highly-abstracted C++ code basically makes allocations and syscalls in the whitespace between the source code tokens.
You can't do systems software like that, you have to roll back the abstractions and roll back the use of pre-canned containers and libraries that you don't understand.
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.
There is not much real evidence for "devs wrongly assume" and as someone writing numerical code (clusters, NUMA, SIMD, etc.) I think C is still the ideal tool for this.
Assuming you mean the standard does not provide features for numa and simd? It doesn't necessarily have to. I think it is not surprising that you seem always bewildered that people still use C (as per your comments), as it seems you fundamentally do understand neither standardization nor systems programming.
such a strawman again... You don't want to be writing explicit platform specific SIMD most of the time. You just want to write a dumb function that doesn't do any non-obvious calls, doesn't cause thread contention, doesn't hide complexity, isn't going to be a nightmare to change later, no surprises.
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.
That is the entire point, yes. Reasoning about layers of completely imaginary entities is what demotivates me about C++ and Rust. Meanwhile, hardware bits are very real (and getting more expensive recently). Having implemented slices and generics in C, now C++ feels like Vietnam flashbacks.
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 "nor is the hardware a PDP 11". Byte access was the main new feature of the PDP 11 that C adopted. Are you saying being able to access individual bytes is not relevant on modern hardware?
Anyway, I do not see how this affects the design of C in a way that makes no sense anymore today (except that one could require CHAR_BIT to be eight, but there are still DSPs where this is not the case). I think people repeat the "the C design reflects the out-dated PDP-11 hardware" meme because it sounds smart while in reality it is just nonsense.
So when is WG14 standardising modern hardware into the C standard?
Basic stuff like SIMD, SIMT, without requiring users to go beyond language extensions, something that any programming language can offer in similar capacity?
Why does the language standard need to prescribe everything. It is a standardization of between existing compilers, they are allowed and intended to invent things. If anything the experience from C++ has shown, that writing too much behaviour into the standard accidentally has consequences on the possible performance. The C standard is descriptive, not prescriptive.
> 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.
About half of them read as "I tried to use C++ as a worse C" e.g. using struct initilisation instead of constructors, using malloc instead of new or new[].
My pet peeve with C++ is that the sequence point operator can be overloaded at which point it stops being a sequence point.
As the title indicate, this article is comparing construct-to-construct, not idiomatic code to idiomatic code. You probably won't use struct initialization in C++, yet the feature still exist, so it may be useful to someone to compare it to the similar feature in C.
That's the comma operator. I didn't know you could overload it! That's pretty crazy. However, I have never seen anyone do that. Do you have any real world examples?
See e.g. the very-popular Eigen library, in which the type CommaInitializer basically exists for the sole purpose of overloading `operator,`, allowing a cleaner matrix initialization syntax.
> 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.
> IMHO this "schism" was completely unnecessary and only happened because of ignorance and hubris
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").
Because Microsoft has been focusing on improved C# for low level coding, see recent update on memory model changes for C# 16/.NET 12 roadmap, Rust adoption, and good enough C++ support.
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.
> This was bad advice back then and is even worse advice today.
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.
> 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.
How did Clang handle differences between member declaration order and the order in which initializers appeared?
It's much more obvious when you look at the user's comment history.
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.
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.