Hacker News Reader

Comment by 112233 | Hacker News Reader

"This article was originally published in Polish in issue 4/2013" — a lot of excellent advice. Sad to see C++ have moved in last decade in a direction that makes writing efficient, simple low level code harder and harder :(

View on HN

Writing clear, concise, and efficient code in C++ has never been simpler or easier. The improvements in C++ over the last 15 years have been qualitative.

So many complex, esoteric, and difficult to maintain incantations that used to be required for efficient code generation are no longer necessary.

How do you process read-only mmaped data in C++, in accordance with the language rules? As an example.

I think there are lots of Unix APIs that are impossible to use without UB, e.g. SCM_RIGHTS (maybe io_uring as well?).

Implementations are free to define UB.

UNIX APIs are not implementations.

You compile programs for Unix using language implementations.

C++ implementations don't make any sort of special or unique accommodations for UNIX/POSIX APIs. For the most part calls into external libraries are firewalled and not optimized in a way that typically engenders undefined behavior, so POSIX APIs tend to work. But any external library would also work since it's not like POSIX is exclusively shielded or singled out in any particular way.

If a compiler for Linux time travels whenever you use SCM_RIGHTS, take it back for a refund - it's faulty.

You can try to request a refund for free software but the terms of the compiler explicitly state that undefined behavior is permitted to "time travel" and that there's nothing faulty about it. That's C++ for you ;P

That's not something that's unique to C++ though. For example, Rust has the same issue.

That was addressed circa C++17 IIRC, same with all of the technically UB surrounding DMA memory. You needed non-obvious incantations for some use cases but they were expressible. C++23 eliminated most of those incantations. Before all of this you had to use “blessed” incantations that were technically UB but which compilers needed to allow because the code was expressing a valid use case.

I find it crazy that popular systems languages didn’t have an explicitly valid way to deal with all of these ambiguous ownership and lifetime issues around memory until relatively recently.

Can you give some specifics? I feel like this is adjacent to my work and I'm not sure what you're referring to which makes me feel I've missed something important.

Not OP but I believe this is referring to defining a `volatile const` for a read only register which C++ does not allow because you would need to initialize a const. Not sure what the C++17 solution would be

I think it has become EASIER: for instance, since C++23 Rust-like move semantics can be used, which provides the compiler with extra information that can be leveraged for the generation of better code.

Or take constexpr - it permits to move computations to compile time that are complex and in older versions either had to be done at runtime, or an ugly workaround had to be used (e.g. assigning a mysterious literal pre-computed in another run or by hand).

> C++23 Rust-like move semantics can be used

What C++23 feature allows that?

Maybe this one?

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p22...

I think that's basically clarifying the conditions under which C++11-style moves can be performed.

The closest thing I can think of is trivial relocation [0] which matches the bitwise copy + no destructor on moved-from bits of Rust's moves, but that was only added to the draft for C++26 and was removed late in the process anyways [1].

[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p27...

[1]: https://herbsutter.com/2025/11/10/trip-report-november-2025-...

How? you can write exactly the same low level code today.

My thought too.

There are so many things that are expressible in C++ now that could not be without writing much more code or using per-compilation tools back then. The ability to run code at compile time that is not run at runtime is huge, #embed lets us make other tools output available without linker scripts or compiler specific tools that.

Also, most of the code from the past still works(from 10 years ago definitely works)

Shot in the dark, but maybe the OP is referring to the fact that these code conventions are explicitly discouraged by the C++ core guidelines. The SoA example falls afoul of the rule requiring T* to be used only for singular object pointers, for example.

Not a regular C++ programmer but wouldn’t you use std::span here instead? Sure it’ll carry a few redundant lengths but it makes using functions that take spans easier. When I do write C++ it’s usually for speed so I’m often working at the intrinsics level, though AI has gotten good enough at it that I now generally delegate this work to an agent.

Depending on the specific code, the compiler may even eliminate the redundant lengths.

Core guidelines, and any other pattern document, should be downstream of working code, not upstream.

Okay? The point of the guidelines is to document principles the committee's thinks "good" C++ should follow, within the much larger universe of possible C++ code.

So if you find good code that works a different way, do you update your beliefs on what good code is, or on whether that code is good?

To summarize, the grandparent comment lamented how it's sad that the modern language has diverged from the code in the article. Someone else pointed out that the code still works. I suggested that the complaint remains valid in spite of that because the language committee's core guidelines prohibit it. Notice I haven't mentioned my opinion at all.

You've responded to that suggestion with seemingly irrelevant comments. Do you see why I'm confused?

For what it's worth, my actual opinion is that the committee is usually wrong/misguided.

Yes? Instead, we have committee declaring large bodies of existing code invalid and non-conformant, because it does not fit their spherical cow C++. You would think, with amount of no-exceptions and no-rtti code out there, and feature being present in most compilers for decades, they would take a hint and reflect actual usage in their standard? No, why would they. Any C++ that has no exceptions, rtti or std:: namespace is invalid. Not even against guidelines.

the CCG isn't from the committee, but from Bjarne Stroustrup and Herb Sutter.

Bjarne is often in disagreement with the committee

eh, yes-ish, but only thanks to compiler writers. at one point committee went all-out enforcing their lifetime model, making bit_cast not an option. If your code accesses same data using different types, you are spelunking ruins with snake pits and lava. more and more stuff needs magic support code in std::, making no-lib code less and less possible (it used to be that with no-rtti and no-exceptions, you could use all c++ features and only needed cxa_at_exit, operator delete, and few other little things. NOT ANY MORE).

On one hand, you have consteval and stuff, letting you FINALLY initialize data at compile time (hey, 20 years late but still!)

on other hand, it is done in most non-debuggable way possible. try setting breakpoint or adding print to constexpr function that causes your requires clause to fail...

so no, newer C++ the language is not possible to use for low level work. The dialects that compiler makers support are. We will see for how long

> newer C++ the language is not possible to use for low level work

This seems like an overstatement. Can you elaborate with some examples from your particular domain?

In my domain, code size is critical, so we use -fno-exceptions and -fno-rtti from necessity, for a good reason. Which means our code is non-conformant C++. Committee forces everyone to have exceptions and rtti always.

Reply on news.ycombinator.com