C constructs that still don't work in C++ | Hacker News Reader

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

lospino.so

122 pointsjalospinoso174 comments

Some unmentioned incompatibilities I've encountered that makes a C header not directly usable in C++:

- 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

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 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."

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.

  Address white_house{
    .street = "1600 Pennsylvania Avenue NW",
    .city = "Washington",
    .state = "District of Columbia",
    .zip = 20500,
  };

For me this is the most important initialization in C that helps with clarity so much, I used mostly structs to have function parameters intialized like this

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++

Designated initializers were unofficially supported by GCC (and clang IIANM) since around when C++11 was supported. See:

https://godbolt.org/z/3aKaa7dnM

only if you specifically ask to get an error, would you actually get it.

Yeah you can even create linked lists of static data that way, as you can very well just take the pointer of an object here.

Designated initializers is one area where C feels much more expressive than C++. And that feature has been standard since C99.

restrict in C++ can't work well. One can mark pointer parameters with this attribute, but in C++ it's not recommended to pass raw pointers, std::string_view or std::span should be used instead, but there is no way to specify restrict for the internal pointer of these containers.

> std::string_view or std::span should be used instead

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.

Non-owning view over a single element should simply be a reference, you don’t care where this element is located.

That won't work with NULL.

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 catch up.

Some features were standardized back in 2023, yet not a single implementation supports them in 2026.

https://en.cppreference.com/cpp/compiler_support

https://cppstat.dev/

This is so true and it's a danger for other ecosystems too. Once the big corporations throw their weight in (be it in a committee or only informally) they make their use cases dominant regardless how niche they might be for the rest of the world.

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.

I think Rust has similar flaws as C++: too much unneeded complexity and abysmal compilation times.

unneeded complexity such as?

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.

Out of curiosity, what do you think is wrong with monomorphization-based polymorphism? The other alternatives I'm aware of are 1. type-erasure via v-table based dynamic dispatch (which Rust also has in the form of the `dyn` keyword), which has performance and memory-allocation overhead and 2. macros, which Rust also has and, if used for polymorphism, would essentially be like compile-time monomorphization, but clunkier.

Maybe I'm missing something though and there are other alternatives done differently in other languages?

The correct choice IMHO is type-erasure. It does not necessarily have overhead, because optimizers can specialize or devirtualize. Of course, this my depend on how you implement your language, but in C this works nicely. The problem with monomorphization is that it leads to exponential expansion, which later passes of the compiler can not unify again (at least this is much harder than not expanding in the first place). It should also fundamentally limit what you can do, because expansion has to stop at some point, but I haven't thought about this too much.

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.

I don't think the numbers bear out that "this works nicely" in C, it seems like you have worse perf numbers for some common cases like sorting ?

Not sure what numbers you are talking about. If you use qsort from the C library the comparison function will not be inlined, but if you provide your own, this is no problem.

> if you provide your own, this is no problem.

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".

It would also, but nobody cares enough because qsort is already fast enough for most things, and if you cared it is simply enough to do yourself. Are you doubting that C compilers can devirtualize function calls? Here is a small example that illustrates this. The compiler dervirtualizes all calls than folds the result: https://godbolt.org/z/E6cMMr8vx

Type-erasure does have an inherent overhead. Sure, optimizations can be made, but they can be fickle and specialization is basically implicit monomorphization.

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.

What inherent overhead does type-erasure have? The optimizer can always specialize just like for monomorphization. The difference is that it does not have to do this. Monomorphization specializes everything before the optimizer even has a chance to look the the code. So it fundamentally can not have advantages, only restrictions.

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.

The inherent overhead of type-erasure is the vtable. Which is funny, because you said you prefer one over the other at the end, when they are basically synonymous. The compiler may choose to devirtualize and specialize, but that isn't guaranteed. If you want this behavior, &dyn does the exact same thing.

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).

The vtable can be removed in all cases where you specialize by monomorphization, so the overhead compared to it is not really inherent.

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.

As I stated in my follow up, vtables can only be removed when the type information is still available, which, generally, aligns with specialization, except when dealing with libraries (even with LTO). You say the "vtable can be removed in all cases of monorphization", but that isn't guaranteed and often requires double guessing the compiler to ensure it still knows the type, where as monorphization makes it explicit when the compiler doesn't know the type anymore and that specialization must occur.

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.

I just noticed you said "The compiler can always specialize". That's indisputably false. That only happens if the compiler has enough information to infer the concrete type at the call point. Conditionals, collections, or anything that may throw doubt about original type info and their function implementations can (and normally will) disable specialization.

It can always specialize where you could do monomorphization.

Not necessarily. In pure theory, yes. But in pure theory, monomorphized code can be deduplicated too.

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.

The point is much easier to propagate information (and not accidentally lose it) than to deduplicate after specialiation, so I do not agree that this is only of theoretical relevance.

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).

You seem to be underestimating how easy it is to lose type information. Creating a array of type-erased is already enough to cause confusion, even if the surrounding code is enough to prove the array only has one type. If we are to assume perfect deductive ability for type-erasure, why not for monomorphism as well?

Monomorphization isn't premature optimizations either. It and type-erasure are semantically different. For instance, only monorphization can enable inlining of data structures (as devirtualizating an array of fat pointers involves dealing with ownership concerns, among other things). You either have to type-erase the array itself or box all the items, none of which are very ergonomic for a system-level programming. Also, in terms of performance, monomorphization generally makes the compiler's job easier overall in comparison to type-erasure (specially in Rust where types also encode lifetime), so I don't see the damage unless you are dealing with an extremely size-constrained environment or dealing with instruction cache misses (which is an indication of poor abstractions).

Finally, as stated elsewhere, it's trivial to implement any type-erasure polymorphism in a monomorphic system (save for very specific exceptions, related to hardware), but the reverse is not true. To do so reliably will require assistance of an external codegen tool, like the C macros, generally recreating monomorphism, but worse, as the compiler doesn't actually know the polymorphic code is related, making deduplication even harder.

I don't see why it would easy to lose type information in circumstances where you can do monomorphization. Note that I do not assume "perfect deductive ability". The practical observation is simply that it is far more effort to deduplicate than to clone.

I am not sure why either (I believe it is aliasing), here's an example: https://godbolt.org/z/9szhxoxrf

From the code, we can already tell all elements have the same type, but the compiler is already adding checks. One of the options would be to convert the array of fat pointers into a fat slice. But now you have to enlarge the slice's vtable with all possible item operations, even if we don't use them often. Alternatively, use monomorphism. Or use both.

I see, this is what you meant. GCC can not currently do this. But this also not something that would correspond to a monomorphic version. A polymorphic function over a generic array would be specialized to one member type via monomorphization. This would correspond to this: https://godbolt.org/z/nd333xeTP

A bit of a nitpick, but I think this would be closer to a generic array: https://godbolt.org/z/cfdPWb6zz

Still, adding a different typed array already breaks inlining, https://godbolt.org/z/zavojE8xK (type-erasure) vs. https://godbolt.org/z/barroPfsP (monomorphized).

Aside from being heavily optimization-dependant, thinking through this, I've realized that type-erasure is a bit of a premature abstraction. It forces programmers to use indirection and pass-by-reference/pointer. It forces functions to be type size and alignment-agnostic. That's why type-erasure can't express monomorphism proper, whereas the reverse is not true.

It is trivial to see that the compiler could do inlining also in this case. Your modification does not "break" inlining in the sense of making it impossible. In fact, just making the vtables "const" is enough and it does it: https://godbolt.org/z/oYv47xx8G Or adding "inline" would also do it. (But this not why your argument is wrong.)

The compiler chooses to not inline in your example. And this is the point: The compiler makes inlining decisions based on some heuristics exactly because inlining is not always an advantage (even if it is in toy examples), otherwise it would do it far more often. Implementing type-erasure gives it the freedom to do this while monomorphization hardcodes it. It takes away this freedom. You can get the same result as monomorphization by forcing certain inlining or function-cloning decisions, but the reverse is much harder: you can not automatically deduplicate the already expanded function. (in theory yes, in practice no)

The argument that for a language with type-erasure the inlining heuristics of this specific C compiler may not be ideal, is rather irrelevant. (but interprocedural value propagation is rather smart in principle)

My issue isn't that the modification made it impossible to inline, more so how trivial it was: I just added a different type. Generally, optimizations are disabled not because the compiler finds them inneficent, but because it lacks enough contextual information/intelligence to safely add it. So similar to what you said, in theory, the compiler can optimize type-erasure just like monomorphism, but, in practice, it lacks info to do so. Either by programmer accident, language/compiler limitations, or both.

Also, monomorphization doesn't actually take the compiler freedom away (on its own) to optimize. Similar to how type-erasure can be optimized to behave like monomorphization through devirtualization, monomorphized calls can be virtualized (which Swift shows). The problem is that it takes away transparency from the programmer. It also changes the semantics of the call behind the scene (type-erasure is strictly pass-by-pointers, monomorphism is not). That wouldn't work well for a low-level language.

But your example did not show that the compiler lacks the contextual information. My argument is exactly that in all cases where one can do monomorphization, this contextual information is trivially available because it simply a small part of what can be done with interprocedural constant-propagation anyhow. I think this is easy to see.

I am not commenting on your Gish Gallop of new arguments.

How did it not lack of contextual info? By adding "const", you provided more info to the compiler, and it decided it was safe to inline, despite no actual behavior change. My point is, despite the possibility, these optimizations are easy to disable by mistake.

Also, there's no gish-gallop. You said the compiler can optimize type-erasure like monomorphization, but not monomorphization like type-erasure, and I said that's not true: the compiler can, in fact, do that. I simply addressed your argument. The rest simply elaborates on why languages why might not do it.

No, you did not address my argument. You need to show that it is impossible (or hard) to do function cloning when using interprocedural constant-propagation in a situation where monomorphism does this. But nothing you said contradicts this and the fact that a C compiler may sometimes decide to inline or not a function is completely irrelevant to this question.

In fact, it was exactly my argument that it is an advantage of type-erasure that the compiler has more freedom. An example where the compiler does not specialize a function just demonstrates this flexibility.

I feel like you are attacking a strawman here. My point isn't that it's impossible to optimize, but such optimizations are fickle and easy to break by programmer error and require adequate language expressivity (although low-level languages generally provide that).

You say that the compiler made the decision to not inline it because it judged it to be the most efficient, yet, by adding the "const", thus adding more info, it did inline it. Why did the heuristics change here, even though the logic remained the same? I argue it's not because the compiler decided it would be more performant to not inline, but that it was acting on the side of caution.

Finally, if giving the compiler more freedom to make choices is your goal, then forcing it to start by either type-erasure or monomorphization is the wrong answer. The compiler should be free to choose type-erasure/monomorphization from the start in such case. However, that introduces limitations to the language. Since the generic function is prohibited from knowing the type size at compile time, it can't allocate space for it in the stack. Long story short, I think you'd be forcing the programmer into an abstraction they might not need nor would necessarily help them, and then hoping the compiler to optimize appropriately.

Personally, I care about expressivity and transparency, thus I think having both natively supported is preferable. But if one must be chosen over the other, monomorphism should come first, as you can build a vtable with it (also, there are many ways to build vtables and dynamically diapatch).

> no ISO standard

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".

It doesn't have to be ISO, but some organization which follows some official rules and not some entity dependent on industry donations.

LOL. You do know ISO/IEC 29500 exists right?

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.

I remember the story, but it was considered outrageous for a reason.

I'm sure it would be considered "outrageous" when the same happens outside an SDO too.

Well, one could consider Mozilla's management of firefox to be outrageous, but then, Google pays, so what to expect?

> its syntax

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.

Some of Rust's problems may be fixable, but they are not being fixed at the moment and with something as complex as Rust, this is unlikely. I do not think monomorphization is an implementation detail, rather than a fundamental language design mistake that is difficult to correct.

Beg to differ. After musing for while, I realized Rust could only have chosen monomorphism for its goals, thus it's not a fundamental design mistake, but a necessary choice. One of the overall philosophies is zero-cost abstractions, and only designing a polymorphic system with monomorphism in mind may provide that, because the alternative requires pointers (different type sizes, vtable, etc.).

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.

Except for compilation times, no it isn't the complexity of the language, it is the toolchain.

See Ada, D, Delphi,....

Granted, priorities, one cannot fix everything at the same time.

C++ has had it's own long periods of badly lagging/buggy implementations of the standards. It's better today but I'm not sure how much of that I'd credit/discredit that to the way the standards process works. So long as there is one quality implementation it doesn't matter much anyways.

Is that supposed to be a bad thing? I like having only one implementation. Multiple compilers is annoying for users, have to write "portable" code which can only target the lowest common denominator. Only when a feature ships in Clang, GCC and VC++ can you use it. Each compiler needs its own flags/project as well.

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.

It's a bad thing if you want your language to be truly portable and be able to work on anything

yes monopolies are always a bad thing

A programming language with a reference implementation is not a "monopoly", it's a standard. By having a common implementation to write code against we can avoid wasting time on pointless minutiae such as which features are portable in practice and which are not.

When a programming language community fractures into multiple incompatible implementations everyone is worse off.

> 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.

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.

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?

this compatibility sucks sometimes.

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.

> 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.

I don't think that's true? Nothing gets in the standard without substantial actual experience on at least an experimental compiler branch first. It's just not always your compiler.

`export template` was included in the C++98 standard without any experience, experimental or otherwise. The first implementation was achieved by EDG after enormous pain in the early 2000s, and their advice for any others attempting it was "don't". I'm not aware of anything else quite that egregious, though.

https://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2003/n14...

There were compilers that used the template export implementation, but not with that exact syntax. I think that's how cfront did templates.

The one big and tragic exception being modules...

C++11 GC, modules, contracts, linalg are good examples of not having a substantial actual experience before ratification.

Now, I rather have them than not, but it is still clunky.

I find variable-length arrays (i.e. arrays whose length is defined at run-time and typically live on the stack) to be kind of dangerous, and try to avoid them, even in C.

The array at the end of the struct is not a VLA on the stack. When you allocate the struct, you add enough extra to hold the contents of the array. VLAs on the stack are pretty much universally considered a bad idea, as far as I can tell.

A type of VLA I would like to see more of in C code however, is variable-length array parameters (void func(int n, int arr[n]);) and array pointers (int (*my_array)[n];).

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.

Why do you think they are dangerous?

If the VLA size is not controlled it gives an attacker a primitive for arbitrarily shifting the stack pointer. There isn’t any spec for what is a reasonable limit on a VLA size. https://dotat.at/@/2010-01-22-coroutines-in-less-than-20-lin...

Yes, attacker controlled size without limit is bad (and this is also true for heap allocations). For VLAs there is -Wvla-larger-than that can be used to ensure there is a hard limit. To understand the risks of VLAs one also has to compare it to the alternatives. A fixed-size array on the stack is basically always worse. alloca is substantially worse. heap allocation may be a bit better, but also much slower.

From the article:

  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.

C++ was a superset of C 30-ish years ago. Now, as the author correctly identifies, it is not as both have taken different evolutionary paths.

Already in C++98 there were differences.

?: has another execution priority.

Implicit cast scenarios are reduced in C++.

30 years ago, in C89 and pre-standard C++, it was the case that `int foo()` in C is a function that accepts any parameters, and in C++ it is a function with no parameters. In C89 you have to write `int foo(void)` if you want no parameters. This counterexample to C++ being a superset of C was well-known even back then.

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.

Perhaps in c-with-classes(Cpre)? To the extent that its output could be considered C.

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.

> a full-fledged parser

perhaps more accurately a fully fledged compiler (that emitted C)

You can pass a flag to clang to allow reordering field initializations in designator initializer thing. It makes the syntax super annoying in case of large structs anyway.

It doesn't matter unless you are using constructors or modifying some variables in the initialization expression anyway.

C++ the good parts is essentially C. If C had the concept of traits and generics or something like them like Rust there’d be no need for C++ and its ideas of mediocre inheritance and macros (templates).

Tbf, I'd say Rust's concepts of Trait Objects and Generics are better implementations (in general) of C++'s inheritance and templates, respectively, rather than entirely different things. I'd also add constexpr/const blocks to good ideas to add, or else generics/templates will be abused (yet again).

There is no inherit in Rust. If you choose to try and do OOP horror Rust makes this fairly painful

I know. I mentioned C++ inheritance because it's its default dynamic dispatch mechanism that I'm aware of.

Is there some kind of ambiguity inherent in designated initializers such that the field ordering requirement is necessary for C++ or is it rather just a quirk of the compiler authors’ choices?

Is there some sort of tool that checks headers for this stuff? On the occasion that I write a C library, I prefer it to be directly usable in C++.

You can just run it through a compiler in c++ language mode.

Compiler mode won't catch the `extern "C"` thing though. Both sides compile happily, link blows up on mangled names. What I do is just keep a throwaway .cpp in tests that #includes the header and calls a few of the public functions. Dumb but it's basically the only thing that ever catches that case before some downstream user does.

> restrict: a C promise, not a C++ contract

This takes the cake.

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.

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.

[1] https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3734.pdf

Because the communities aren't the same.

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.

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.

Except modern C also has plenty of abstractions, devs wrongly assume it doesn't.

Then get surprised when it doesn't map to the SIMD/SIMT NUMA machine their code actually executes on.

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.

Why should it be, the language doesn't expose any of it.

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.

I do certainly understand it, by the eyes of C++, Rust, Ada, Object Pascal, Modula-2, D.

Systems programming is not primarily about programming languages though...

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.

So abstractions are desired then?

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.

Most of these methods and ideas turned out to not work, neither in messy C libraries, nor in C++ or other languages.

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.

https://replicated.wiki/blog/abc

Yet C23 isn't K&R C any longer, nor is the hardware a PDP 11.

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++.

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?

Might more mean that we've standardised on a few things like what a byte even is.

The PDP-11 had both 8 and 9-bit bytes. Thats a complexity that few programmers have to touch on, today.

IIRC PDP-11 was a 16 bit word machine with an 8-bit byte. Maybe you remember PDP-10 with 4x9=36 bit words?

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?

Ah, the "what is not standardized does not exist" argument again.

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.

On the 11, the UNIBUS was 18 bit, the program space was 16 bit, and addressing was 22 bit. So it depended if you were using I-space or D-space.

Actually, if you were mad enough to use the feature, the Dec10 had 6-bit "bytes" - 6 to a word.

It is, however hardly something unique to C, as the C crowd pretends it to be.

The PDP-11 myth is getting a bit tired by now ;)

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.

Just like plenty of other programming languages.

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.

Yeah, a continuous memory model is used, because it is convenient, not because some old hardware happen to use it.

> C folks still think is a portable Assembly

> 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.

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.

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

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.

Long time ago at CERN.

There are some ATLAS TDAQ/HLT papers with my name on them.

Template metaprogramming, multi-threading, and custom IP protocols where much more relevant.

Did you use an LLM to write this comment? (I don't mean this as an accusation, I'm uncertain. I'm just trying to calibrate myself.)

Edit: I should've had more conviction in my instincts, this is slop.

It didn't stand out to me on first read but pangram gives it a high confidence rating as being written by AI.

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).

You were right to call out. I upvoted your comments.

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.

> It shouldn't require casting from and to specific pointer types

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.

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.

> They make sense but reduce type safety

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.

> but then most C++ seems to use a C-style cast

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.

Lack of ergonomics around static_cast is language problem. The "most safe" of the casts should not be this verbose.

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.

I don’t understand your point at all, C++ objectively has a much stronger type system. It’s turing complete!

I’m not arguing that that’s better, or worse, but it’s definitely true and by no means a myth.

I don't think GP meant "it's completely made up", I think he meant the distinction doesn't matter most of the time.

I.e. most of the time the typing in real C++ code isn't meaningfully stronger than that found in C code.

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.

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.

That's what I addressed in the first paragraph, a warning in C is a serious thing, not just some random nuisance.

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.

> That's because the default mode for compilers is to just shut up and compile this throw away code.

That's just not true. Compilers do issue certain warnings by default and they even treat some warnings as errors. See https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

> ?? 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.

> Because some warnings are just believed to be more serious, than others.

Yes, that is my entire point. For some reason you were arguing against it.

I didn't intend to.

> 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.

In don't think this is required in C++ either.

> 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").

[2] Both GCC and Clang still get this wrong in 2026: https://github.com/llvm/llvm-project/issues/190858

> 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 simply reorders them, same behaviour as in C:

https://www.godbolt.org/z/ex138rh51

(the warnings in C++ mode had only been added after C++20)

Hrm, I take it that was considered too footgun-y for the committee?

> 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.

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.

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++.

[1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

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.

What's the "sequence point operator"?

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.

https://gitlab.com/libeigen/eigen/blob/master/Eigen/src/Core...

Thanks!

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.

> isn’t "C vs C++,"

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.

Man this table is disturbing. "Same", same as?

Please stop using c++. It has a way too complex syntax creating a hard dependency on beyond reasonable "real-life" compilers and runtimes.

Reply on news.ycombinator.com