10 ms·

Rethinking C++: Architecture, Concepts, and Responsibility

64 points by timeoperator 11mo ago

pjmlp 10mo ago
I still love C++ Builder, regardless of all Borland misteps that lead to where Embarcadero is today, it is the survivor of C++ RAD IDE tooling, Visual C++ never was as Visual as it name implies.
- kaiken1987 10mo ago
  Builder and Delphi 6 had a way to build and design UI's that worked smoothly that I've yet to see from a UI framework.
  - pjmlp 10mo ago
    Indeed, pity that they are only available to those of us that don't mind using the community editions, or work at companies that usually don't care that much about commercial licenses prices, meaning project delivery costs is measured in millions. Sure there is FreePascal and Lazarus, sadly it doesn't get enough love.
fsloth 10mo ago
I get the feeling author would just like to use a better language, like F# or Ocaml, and completely misses the point what makes C++ valuable. C++ is valuable, because the existing tooling enables you to optimize the runtime peformance of a program (usually you end up with figuring out the best memory layout and utilization). C++ is valuable becaus it's industry support guarantees code bases live for decades _without the need to modify them_ to latest standards. C++ is valuable because the industry tooling allows you to verify large areas of the program behaviour at runtime (ASAN etc). I simply don't understand what type of industrial use this type of theoretical abstraction building serves. Using the metaprogramming features makes code bases extremly hard to modify and they don't actually protect from a category of runtime errors. I'm speaking from experience. I would much rather have a codebase with a bit more boilerplate, a bit more unit tests and strong integration testing suite. The longer I use C++ the more I'm convinced something like Orthodox C++ is the best method to approach the language https://bkaradzic.github.io/posts/orthodoxc++/ https://bkaradzic.github.io/posts/orthodoxc++/ This keeps the code maintainable, and performant (with less effor than metaprogramming directed C++). Note: the above is just an opinion, with a very strong YMMV flavour, coming from two decades in CAD, real time graphics and embedded development.
- gpderetta 10mo ago
  sorry, I can't take something that argues for "printf" in favour of anything else seriously.
  - unwind 10mo ago
    The article argues that modern C++ has type-checked string formatting, so it does not argue for (unchecked) `printf()`, right?
    - vintagedave 10mo ago
      "The article" is ambiguous. The one this HN post is about does not argue for it, at all. But the one in the comment above directly says, > Don’t use stream (<iostream>, <stringstream>, etc.), use printf style functions instead. and has a code example of what they argue 'Orthodox C++' should be, which uses printf. I'm all for a more sensible or understandable C++, but not at the expense of losing safety. In fact I would prefer the other way: I still feel incredibly saddened that Sean Baxter's Circle proposal for Safe C++ is not where the language is heading. That, plus some deep rethinking and trimming of some of the worst edge behaviours, and a neater standard library, would be incredible.
      - gpderetta 10mo ago
        I was indeed referring to the 'Orthodox C++ article'.
  - jstimpfle 10mo ago
    I'll bite. printf might be unsafe in terms of typing, in theory, but it's explicit and readable (with some caveats such as "PRIi32"). The actual chance of errors happening is very low in practice, because format strings are static in all practical (sane) uses so testing a single codepath will usually detect any programmer errors -- which are already very rare with some practice. On top of that, most compilers validate format strings. printf compiles, links, and runs comparatively quickly and has small memory footprint. It is stateless so you're always getting the expected results. Compare to <iostream>, which is stateful and slow. There's also std::format which might be safe and flexible and have some of the advantages of printf. But I can't use it at any of the places I'm working since it's C++20. It probably also uses a lot of template and constexpr madness, so I assume it's going to be leading to longer compilation times and hard to debug problems.
yosefk 10mo ago
"Many—especially historically minded—developers complain that modern C++ compilers take longer to compile. But this criticism is short‑sighted. You cannot compare C++ compile times with compilation in other languages, because the compiler is doing something entirely different."
- gpderetta 10mo ago
  As a long-time C++ user I definitely complain that C++ takes long to compile. Then again, I always have.
- rerdavies 10mo ago
  If only it would do something entirely different faster. :-( Somebody really needs to rethink the entire commitment to meta-programming. I had some hope that concepts would improve reporting, but they seem to actually make it worse, and -- if they improve compile times at all, I'm not seeing it. And it has nothing to do with historicity. Every time I visit another modern language (or use it seriously) I am constantly reminded that C++ compile times are simply horrible, and a huge impediment to productivity.
- ozgrakkurt 10mo ago
  This is also because llvm and gcc are just slow right? Are there any alternative c++ compiler that is faster maybe?
- pjmlp 10mo ago
  We can easily complain, because there were attempts to improve in the past like Energize C++ and Visual Age for C++ v4, or systems like Live++. However too many folks are stuck in the UNIX command line compiler mindset. I keep bumping into people that have no idea about the IDE based compilation workflows from C++ Builder and Visual C++, their multihreaded compilation, incremental compilation and linking, pre-compiled headers that actually work, hot code reloading, and many other improvments. Or the CERN C++ interpreters for that matter. Many don't seem to ever have ventured beyond calling gcc or clang with Makefiles, and nothing else.
- fsloth 10mo ago
simonask 10mo ago
From TFA: > C++ is often described as complex, hard to learn, and unsafe. That reputation is undeserved. The language itself is not unsafe. On the contrary: it is precise, honest, and consistent. What is unsafe is how it is used if it is misunderstood or if one remains in old patterns. I think this take needs to stop. It’s a longer way to say “skill issue”. Meanwhile, decades of industry experience have shown that the governing principles of even modern C++ make it incredibly hard (expensive) to deliver high quality software. Not impossible - there’s lots of examples - but unreasonably hard. C++ is fundamentally unsafe, because that’s how the language works, and if you think otherwise, you don’t know C++. There are patterns and paradigms that people use to limit the risk (and the size of the impact crater), and that’s helpful, but usually very difficult to get right if you also want any of the benefits of using C++ in the first place. Certain people will disagree, but I surmise that they haven’t actually tried any alternative. Instead they are high on the feeling of having finally grokked C++, which is no small feat, and I know because I’ve been there. But we have to stop making excuses. The range of problems where C++ is unequivocally the superior solution is getting smaller.
- instig007 10mo ago
  > The range of problems where C++ is unequivocally the superior solution is getting smaller. The range of issues where the superior solutions offer language features superior to the features of modern C++ is getting smaller too.
  - simonask 10mo ago
    There’s definitely holes, but I’m wondering what you are referring to here.
  - surajrmal 10mo ago
    The c++ features that get bolted on to replicate those in other languages tend to never reach parity because of all the legacy baggage they need to design around. Modules are not nearly as useful as one would hope. std::variant and std::optional are not nearly as ergonomic or safe to use as rust equivalents. coroutines are not exactly what anyone really wanted. If you're simply looking for checkboxes on features then I suppose you have a point. To be clear, I like and continue to use modern c++ daily, but I also use rust daily and you cannot really make a straight faced argument that c++ is catching up. I do think both languages offer a lot that higher languages like go and Python don't offer which is why I never venture into those languages, regardless of performance needs.
gwbas1c 10mo ago
> Library vendors must have the courage to create a new generation of libraries—libraries that consistently use concepts, typelists, ranges, and compile‑time mechanisms. Compiler vendors, in turn, are responsible for continuing this development and fully unlocking the new language means. > But all of us—the C++ developers—must go back to school. We must learn C++ anew, not because we have forgotten it, but because through evolution it has become a different language. Only those who understand the modern language constructs can use the new tools properly and unfold the potential of this generation of libraries. Once you get to that point, you might as well create and learn a different language.
- instig007 10mo ago
  > Once you get to that point, you might as well create and learn a different language. Nope, it's still incredibly valuable to be able to c++14 and c++26 two different translation units and then later link them together (all without leaving the familiar toolchains and ecosystems). That's how big legacy projects can evolve towards better safety incrementally.
  - MontagFTB 10mo ago
    If the Standard has anything to say about compatibility between different language versions, I doubt many developers know those details. This is breeding ground for ODR violations, as you’re likely using compilers with different output (as they are built in different eras of the language’s lifetime) especially at higher optimization settings. This flies in the face of modern principles like building all your C++, from source, at the same time, with the same settings. Languages like Rust include these settings in symbol names as a hash to prevent these kinds of issues by design. Unless your whole team is a moderate-level language lawyer, you must enforce this by some other means or risk some really gnarly issues.
    - PaulDavisThe1st 10mo ago
      > Languages like Rust include these settings in symbol names as a hash to prevent these kinds of issues by design. Historically, C++ compilers' name mangling scheme for symbols did precisely the same thing. The 2000-2008 period for gcc was particularly painful since the compiler developers really used it very frequently, to "prevent these kinds of issues by design". The only reason most C++ developers don't think about this much any more is that most C++ compilers haven't needed to change their demangling algorithm for a decade or more.
Jeff-Collins 10mo ago
[dead]
dustfinger 10mo ago
Despite all the critisism, C++ has been my favorite language for 20+ years. Nowadays I code 99% of the time in python and previously TypeScript, but all my personal for fun projects are in C++. I just enjoy coding in it so much more. I know I will get some heat for this, but I would love to live in an idealistic world where computers were still for hackers and it was all just about fun not profit. I was so inspired by the writings of Eric S. Raymond, I always hoped I would experience some of that. ~SIGH~. Maybe in my retirement.
- ActorNightly 10mo ago
  > but I would love to live in an idealistic world where computers were still for hackers This never changed. In the past, hacking was exploiting human errors in writing faulty code. These days, its pretty much the same thing except the faulty code isn't things like buffer overflows due to no bounds checking, but more higher level faulty software with things like password reuse, no 2 factor authentication, and so on.
  - dustfinger 10mo ago
    While that is partly what I meant, my notion was really about being creative, inventive and having a lot of fun hacking code or hardware without it being about work. I really meant these notions of hacking: - https://stallman.org/articles/on-hacking.html https://stallman.org/articles/on-hacking.html - https://stallman.org/articles/happy-hacking.html https://stallman.org/articles/happy-hacking.html - http://www.catb.org/~esr/faqs/hacker-howto.html http://www.catb.org/~esr/faqs/hacker-howto.html
recursivecaveat 10mo ago
It's okay to admit when C++ doesn't have a feature. std::variant is an approximation of sum type support. It's ergonomics are an absolute travesty as a result, any errors you get are going to be 5 pages of template gunk, and I'm sure that using it pervasively is terrible for compile times. It has been possible to construct a type safe unit library as demonstrated in the article for forever. I've never seen anyone use this ability in a production codebase, because a terrible library emulation of a feature is not a real feature. The notion that just using the new fancy types automatically makes everything memory safe has to stop. std::expected contains either a value or an error. If you call .value() and you're wrong you get an exception. If you call .error() and you're wrong you get undefined behaviour. This was added in C++23. Since there's no destructuring you have to call these methods btw, just don't make any mistakes with your preconditions! Regardless 90% of memory safety errors I see are temporal. Unless we completely ban references and iterators they will not be going anywhere. Using unique_ptr instead of new does not do anything when you insert into a map while holding a reference to an element. Developers also have to be able to make their own things. We can't pretend that absolutely everything we will ever need is bundled up in some perfect library. To write a typesafe application you need to be able to create your own domain specific abstractions, which to me precludes them looking like this: template <class ty> concept db_result_tuple = requires { typename remove_cvref_t<ty>; } && []<class... Es>(std::tuple<Es...>*) { return all_result_args_ok_v<Es...>; }( static_cast<typename std::add_pointer_t<remove_cvref_t<ty>>>(nullptr) );
- on_the_train 10mo ago
  > If you call .error() and you're wrong you get undefined behaviour. This was added in C++23. And it was fixed in c++26
- germandiago 10mo ago
  Well, it is bad to have error() do UB. It was slightly improved in C++26 under hardening: https://en.cppreference.com/w/cpp/utility/expected/error.html https://en.cppreference.com/w/cpp/utility/expected/error.htm...
trzy 10mo ago
I think they should chuck the STL and start over. I left C++ for a while and spent a lot of time in C# and Swift. Going back to C++ is painful because the interfaces feel very non-uniform and cumbersome. I also think that named parameters would go a long way toward improving the language. Lastly, explore some way to make possible a breaking change with "old C++".
hsaliak 10mo ago
When I got into computing, it was a refuge from societal expectations. Now you cannot code in whatever programming language because of societal expectations to do it safe, do it with modern libraries, with the right build system etc.. just do what you like. Its OK. Have fun.
Buford_Jones 10mo ago
The require too much information to just try the free version. I'll give up one of my throwaway emails, but I'm not giving a phone number.

64 points by timeoperator 11mo ago

pjmlp 10mo ago

I still love C++ Builder, regardless of all Borland misteps that lead to where Embarcadero is today, it is the survivor of C++ RAD IDE tooling, Visual C++ never was as Visual as it name implies.

kaiken1987 10mo ago
Builder and Delphi 6 had a way to build and design UI's that worked smoothly that I've yet to see from a UI framework.
- pjmlp 10mo ago
  Indeed, pity that they are only available to those of us that don't mind using the community editions, or work at companies that usually don't care that much about commercial licenses prices, meaning project delivery costs is measured in millions. Sure there is FreePascal and Lazarus, sadly it doesn't get enough love.

fsloth 10mo ago

I get the feeling author would just like to use a better language, like F# or Ocaml, and completely misses the point what makes C++ valuable. C++ is valuable, because the existing tooling enables you to optimize the runtime peformance of a program (usually you end up with figuring out the best memory layout and utilization). C++ is valuable becaus it's industry support guarantees code bases live for decades _without the need to modify them_ to latest standards. C++ is valuable because the industry tooling allows you to verify large areas of the program behaviour at runtime (ASAN etc). I simply don't understand what type of industrial use this type of theoretical abstraction building serves. Using the metaprogramming features makes code bases extremly hard to modify and they don't actually protect from a category of runtime errors. I'm speaking from experience. I would much rather have a codebase with a bit more boilerplate, a bit more unit tests and strong integration testing suite. The longer I use C++ the more I'm convinced something like Orthodox C++ is the best method to approach the language https://bkaradzic.github.io/posts/orthodoxc++/ https://bkaradzic.github.io/posts/orthodoxc++/ This keeps the code maintainable, and performant (with less effor than metaprogramming directed C++). Note: the above is just an opinion, with a very strong YMMV flavour, coming from two decades in CAD, real time graphics and embedded development.

gpderetta 10mo ago
sorry, I can't take something that argues for "printf" in favour of anything else seriously.
- unwind 10mo ago
  The article argues that modern C++ has type-checked string formatting, so it does not argue for (unchecked) `printf()`, right?
  - vintagedave 10mo ago
    "The article" is ambiguous. The one this HN post is about does not argue for it, at all. But the one in the comment above directly says, > Don’t use stream (<iostream>, <stringstream>, etc.), use printf style functions instead. and has a code example of what they argue 'Orthodox C++' should be, which uses printf. I'm all for a more sensible or understandable C++, but not at the expense of losing safety. In fact I would prefer the other way: I still feel incredibly saddened that Sean Baxter's Circle proposal for Safe C++ is not where the language is heading. That, plus some deep rethinking and trimming of some of the worst edge behaviours, and a neater standard library, would be incredible.
    - gpderetta 10mo ago
      I was indeed referring to the 'Orthodox C++ article'.
- jstimpfle 10mo ago
  I'll bite. printf might be unsafe in terms of typing, in theory, but it's explicit and readable (with some caveats such as "PRIi32"). The actual chance of errors happening is very low in practice, because format strings are static in all practical (sane) uses so testing a single codepath will usually detect any programmer errors -- which are already very rare with some practice. On top of that, most compilers validate format strings. printf compiles, links, and runs comparatively quickly and has small memory footprint. It is stateless so you're always getting the expected results. Compare to <iostream>, which is stateful and slow. There's also std::format which might be safe and flexible and have some of the advantages of printf. But I can't use it at any of the places I'm working since it's C++20. It probably also uses a lot of template and constexpr madness, so I assume it's going to be leading to longer compilation times and hard to debug problems.

yosefk 10mo ago

"Many—especially historically minded—developers complain that modern C++ compilers take longer to compile. But this criticism is short‑sighted. You cannot compare C++ compile times with compilation in other languages, because the compiler is doing something entirely different."

gpderetta 10mo ago
As a long-time C++ user I definitely complain that C++ takes long to compile. Then again, I always have.
rerdavies 10mo ago
If only it would do something entirely different faster. :-( Somebody really needs to rethink the entire commitment to meta-programming. I had some hope that concepts would improve reporting, but they seem to actually make it worse, and -- if they improve compile times at all, I'm not seeing it. And it has nothing to do with historicity. Every time I visit another modern language (or use it seriously) I am constantly reminded that C++ compile times are simply horrible, and a huge impediment to productivity.
ozgrakkurt 10mo ago
This is also because llvm and gcc are just slow right? Are there any alternative c++ compiler that is faster maybe?
pjmlp 10mo ago
We can easily complain, because there were attempts to improve in the past like Energize C++ and Visual Age for C++ v4, or systems like Live++. However too many folks are stuck in the UNIX command line compiler mindset. I keep bumping into people that have no idea about the IDE based compilation workflows from C++ Builder and Visual C++, their multihreaded compilation, incremental compilation and linking, pre-compiled headers that actually work, hot code reloading, and many other improvments. Or the CERN C++ interpreters for that matter. Many don't seem to ever have ventured beyond calling gcc or clang with Makefiles, and nothing else.
fsloth 10mo ago

simonask 10mo ago

From TFA: > C++ is often described as complex, hard to learn, and unsafe. That reputation is undeserved. The language itself is not unsafe. On the contrary: it is precise, honest, and consistent. What is unsafe is how it is used if it is misunderstood or if one remains in old patterns. I think this take needs to stop. It’s a longer way to say “skill issue”. Meanwhile, decades of industry experience have shown that the governing principles of even modern C++ make it incredibly hard (expensive) to deliver high quality software. Not impossible - there’s lots of examples - but unreasonably hard. C++ is fundamentally unsafe, because that’s how the language works, and if you think otherwise, you don’t know C++. There are patterns and paradigms that people use to limit the risk (and the size of the impact crater), and that’s helpful, but usually very difficult to get right if you also want any of the benefits of using C++ in the first place. Certain people will disagree, but I surmise that they haven’t actually tried any alternative. Instead they are high on the feeling of having finally grokked C++, which is no small feat, and I know because I’ve been there. But we have to stop making excuses. The range of problems where C++ is unequivocally the superior solution is getting smaller.

instig007 10mo ago
> The range of problems where C++ is unequivocally the superior solution is getting smaller. The range of issues where the superior solutions offer language features superior to the features of modern C++ is getting smaller too.
- simonask 10mo ago
  There’s definitely holes, but I’m wondering what you are referring to here.
- surajrmal 10mo ago
  The c++ features that get bolted on to replicate those in other languages tend to never reach parity because of all the legacy baggage they need to design around. Modules are not nearly as useful as one would hope. std::variant and std::optional are not nearly as ergonomic or safe to use as rust equivalents. coroutines are not exactly what anyone really wanted. If you're simply looking for checkboxes on features then I suppose you have a point. To be clear, I like and continue to use modern c++ daily, but I also use rust daily and you cannot really make a straight faced argument that c++ is catching up. I do think both languages offer a lot that higher languages like go and Python don't offer which is why I never venture into those languages, regardless of performance needs.

gwbas1c 10mo ago

> Library vendors must have the courage to create a new generation of libraries—libraries that consistently use concepts, typelists, ranges, and compile‑time mechanisms. Compiler vendors, in turn, are responsible for continuing this development and fully unlocking the new language means. > But all of us—the C++ developers—must go back to school. We must learn C++ anew, not because we have forgotten it, but because through evolution it has become a different language. Only those who understand the modern language constructs can use the new tools properly and unfold the potential of this generation of libraries. Once you get to that point, you might as well create and learn a different language.

instig007 10mo ago
> Once you get to that point, you might as well create and learn a different language. Nope, it's still incredibly valuable to be able to c++14 and c++26 two different translation units and then later link them together (all without leaving the familiar toolchains and ecosystems). That's how big legacy projects can evolve towards better safety incrementally.
- MontagFTB 10mo ago
  If the Standard has anything to say about compatibility between different language versions, I doubt many developers know those details. This is breeding ground for ODR violations, as you’re likely using compilers with different output (as they are built in different eras of the language’s lifetime) especially at higher optimization settings. This flies in the face of modern principles like building all your C++, from source, at the same time, with the same settings. Languages like Rust include these settings in symbol names as a hash to prevent these kinds of issues by design. Unless your whole team is a moderate-level language lawyer, you must enforce this by some other means or risk some really gnarly issues.
  - PaulDavisThe1st 10mo ago
    > Languages like Rust include these settings in symbol names as a hash to prevent these kinds of issues by design. Historically, C++ compilers' name mangling scheme for symbols did precisely the same thing. The 2000-2008 period for gcc was particularly painful since the compiler developers really used it very frequently, to "prevent these kinds of issues by design". The only reason most C++ developers don't think about this much any more is that most C++ compilers haven't needed to change their demangling algorithm for a decade or more.

Jeff-Collins 10mo ago

[dead]

dustfinger 10mo ago

Despite all the critisism, C++ has been my favorite language for 20+ years. Nowadays I code 99% of the time in python and previously TypeScript, but all my personal for fun projects are in C++. I just enjoy coding in it so much more. I know I will get some heat for this, but I would love to live in an idealistic world where computers were still for hackers and it was all just about fun not profit. I was so inspired by the writings of Eric S. Raymond, I always hoped I would experience some of that. ~SIGH~. Maybe in my retirement.

ActorNightly 10mo ago
> but I would love to live in an idealistic world where computers were still for hackers This never changed. In the past, hacking was exploiting human errors in writing faulty code. These days, its pretty much the same thing except the faulty code isn't things like buffer overflows due to no bounds checking, but more higher level faulty software with things like password reuse, no 2 factor authentication, and so on.
- dustfinger 10mo ago
  While that is partly what I meant, my notion was really about being creative, inventive and having a lot of fun hacking code or hardware without it being about work. I really meant these notions of hacking: - https://stallman.org/articles/on-hacking.html https://stallman.org/articles/on-hacking.html - https://stallman.org/articles/happy-hacking.html https://stallman.org/articles/happy-hacking.html - http://www.catb.org/~esr/faqs/hacker-howto.html http://www.catb.org/~esr/faqs/hacker-howto.html

recursivecaveat 10mo ago

It's okay to admit when C++ doesn't have a feature. std::variant is an approximation of sum type support. It's ergonomics are an absolute travesty as a result, any errors you get are going to be 5 pages of template gunk, and I'm sure that using it pervasively is terrible for compile times. It has been possible to construct a type safe unit library as demonstrated in the article for forever. I've never seen anyone use this ability in a production codebase, because a terrible library emulation of a feature is not a real feature. The notion that just using the new fancy types automatically makes everything memory safe has to stop. std::expected contains either a value or an error. If you call .value() and you're wrong you get an exception. If you call .error() and you're wrong you get undefined behaviour. This was added in C++23. Since there's no destructuring you have to call these methods btw, just don't make any mistakes with your preconditions! Regardless 90% of memory safety errors I see are temporal. Unless we completely ban references and iterators they will not be going anywhere. Using unique_ptr instead of new does not do anything when you insert into a map while holding a reference to an element. Developers also have to be able to make their own things. We can't pretend that absolutely everything we will ever need is bundled up in some perfect library. To write a typesafe application you need to be able to create your own domain specific abstractions, which to me precludes them looking like this: template <class ty> concept db_result_tuple = requires { typename remove_cvref_t<ty>; } && []<class... Es>(std::tuple<Es...>*) { return all_result_args_ok_v<Es...>; }( static_cast<typename std::add_pointer_t<remove_cvref_t<ty>>>(nullptr) );

on_the_train 10mo ago
> If you call .error() and you're wrong you get undefined behaviour. This was added in C++23. And it was fixed in c++26
germandiago 10mo ago
Well, it is bad to have error() do UB. It was slightly improved in C++26 under hardening: https://en.cppreference.com/w/cpp/utility/expected/error.html https://en.cppreference.com/w/cpp/utility/expected/error.htm...

trzy 10mo ago

I think they should chuck the STL and start over. I left C++ for a while and spent a lot of time in C# and Swift. Going back to C++ is painful because the interfaces feel very non-uniform and cumbersome. I also think that named parameters would go a long way toward improving the language. Lastly, explore some way to make possible a breaking change with "old C++".

hsaliak 10mo ago

When I got into computing, it was a refuge from societal expectations. Now you cannot code in whatever programming language because of societal expectations to do it safe, do it with modern libraries, with the right build system etc.. just do what you like. Its OK. Have fun.

Buford_Jones 10mo ago

The require too much information to just try the free version. I'll give up one of my throwaway emails, but I'm not giving a phone number.