C constructs that still don't work in C++ • Hacker News Board

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

#31

Post by jstimpfle » Mon, May 25, 2026, 7:13 AM UTC

pjmlp wrote: post #25

jstimpfle wrote: post #22

Earlier quoted context omitted.

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

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.

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

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

#32

Post by cmovq » Mon, May 25, 2026, 7:33 AM UTC

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

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

#33

Post by maxloh » Mon, May 25, 2026, 7:50 AM UTC

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/

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

#34

Post by elch » Mon, May 25, 2026, 7:50 AM UTC

shakna wrote: post #30

uecker wrote: post #26

Earlier quoted context omitted.

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?

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

#35

Post by uecker » Mon, May 25, 2026, 7:57 AM UTC

elch wrote: post #34

shakna wrote: post #30

Earlier quoted context omitted.

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.

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

#36

Post by weinzierl » Mon, May 25, 2026, 8:07 AM UTC

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…

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.

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

#37

Post by uecker » Mon, May 25, 2026, 8:27 AM UTC

weinzierl wrote: post #36

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…

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

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

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

#38

Post by remix2000 » Mon, May 25, 2026, 8:28 AM UTC

maxloh wrote: post #33

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

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

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

#39

Post by cocoto » Mon, May 25, 2026, 8:28 AM UTC

arcadialeak wrote: post #24

Panzerschrek wrote: post #20

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.

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

#40

Post by saalweachter » Mon, May 25, 2026, 8:34 AM UTC

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…

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