"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 :(
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.
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.
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.
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
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.
OK. I would expect those flags to be required for most embedded work.
But I could imagine use cases for new-ish constructs like `constexpr`, `std::variant`, template constraints, and so on.
I don't quite follow what you are saying about the compilers. Are you saying that in future, compilers will have to choose between supporting new features and allowing non-conformant code?
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).
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].
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.
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.
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 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
112233 · · focus · HN ↗
fooblaster · · focus · HN ↗
beached_whale · · focus · HN ↗
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)
AlotOfReading · · focus · HN ↗
cjbgkagh · · focus · HN ↗
jandrewrogers · · focus · HN ↗
someonebaggy · · focus · HN ↗
AlotOfReading · · focus · HN ↗
someonebaggy · · focus · HN ↗
AlotOfReading · · focus · HN ↗
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.
112233 · · focus · HN ↗
tcfhgj · · focus · HN ↗
Bjarne is often in disagreement with the committee
112233 · · focus · HN ↗
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
t0mpr1c3 · · focus · HN ↗
This seems like an overstatement. Can you elaborate with some examples from your particular domain?
112233 · · focus · HN ↗
t0mpr1c3 · · focus · HN ↗
But I could imagine use cases for new-ish constructs like `constexpr`, `std::variant`, template constraints, and so on.
I don't quite follow what you are saying about the compilers. Are you saying that in future, compilers will have to choose between supporting new features and allowing non-conformant code?
jll29 · · focus · HN ↗
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).
creata · · focus · HN ↗
What C++23 feature allows that?
cherryteastain · · focus · HN ↗
<a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2266r3.html" rel="nofollow">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p22...
aw1621107 · · focus · HN ↗
aw1621107 · · focus · HN ↗
[0]: <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2786r13.html" rel="nofollow">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p27...
[1]: <a href="https://herbsutter.com/2025/11/10/trip-report-november-2025-iso-c-standards-meeting-kona-usa/" rel="nofollow">https://herbsutter.com/2025/11/10/trip-report-november-2025-...
jandrewrogers · · focus · HN ↗
So many complex, esoteric, and difficult to maintain incantations that used to be required for efficient code generation are no longer necessary.
112233 · · focus · HN ↗
senderista · · focus · HN ↗
someonebaggy · · focus · HN ↗
Maxatar · · focus · HN ↗
someonebaggy · · focus · HN ↗
Maxatar · · focus · HN ↗
someonebaggy · · focus · HN ↗
Maxatar · · focus · HN ↗
mdspan · · focus · HN ↗
jandrewrogers · · focus · HN ↗
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.
Agentlien · · focus · HN ↗
ab71e5 · · focus · HN ↗