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

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

lospino.so

Post reply on HN
Print view View original

71–80 of 182 posts

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

#71

Post by mrec »

tardedmeme wrote: post #69
maxloh wrote: post #33

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

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

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

#72

Post by NooneAtAll3 »

zarzavat wrote: post #67
remix2000 wrote: post #38

Earlier quoted context omitted.

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

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…

yes monopolies are always a bad thing

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

#73

Post by uecker »

nicoty wrote: post #58
uecker wrote: post #46

Earlier quoted context omitted.

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 clunki…

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.

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

#74

Post by uecker »

lelanthran wrote: post #63
skrebbel wrote: post #53

Earlier quoted context omitted.

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.

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

#75

Post by tialaramex »

uecker wrote: post #46
bitwize wrote: post #42

Earlier quoted context omitted.

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.

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

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

#76

Post by uecker »

TuxSH wrote: post #54
flohofwoe wrote: post #49

Earlier quoted context omitted.

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

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

#77

Post by fuhsnn »

flohofwoe wrote: post #41
jalospinoso wrote: post #2

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

> I wrote this after repeatedly seeing experienced C programmers hit the same sharp edges while moving into modern C++ codebases. ...I've seen this more often in the opposite direction. Since C++ is stuck with a ca 1995 non-standard subset of C, C++ coders usually have a very outdated view of C. > I’d also be curious which C constructs people still genuinely miss in modern C++. Not implementing the full C99 designate…

> 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

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

#78

Post by cksk »

einpoklum wrote: post #62

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.

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

#80

Post by pjmlp »

uecker wrote: post #27
pjmlp wrote: post #25

Earlier quoted context omitted.

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.
Post reply on HN