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