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

21–30 of 182 posts

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

#21

Post by pjmlp »

gritzko wrote: post #19
pjmlp wrote: post #9

Earlier quoted context omitted.

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.

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

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

#22

Post by jstimpfle »

pjmlp wrote: post #17
jstimpfle wrote: post #16

Earlier quoted context omitted.

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…

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.

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

#24

Post by arcadialeak »

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.

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

#25

Post by pjmlp »

jstimpfle wrote: post #22
pjmlp wrote: post #17

Earlier quoted context omitted.

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…

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.

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

#26

Post by uecker »

pjmlp wrote: post #21
gritzko wrote: post #19

Earlier quoted context omitted.

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?

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

#27

Post by uecker »

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.

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.

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

#29

Post by uecker »

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…

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.

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

#30

Post by shakna »

uecker wrote: post #26
pjmlp wrote: post #21

Earlier quoted context omitted.

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.

Post reply on HN