5 ms·

I see this argument often. It is valid right until you get first multipage error message from a code that uses stl (which is all c++ code, because it is impossi

by 112233 10mo ago

I see this argument often. It is valid right until you get first multipage error message from a code that uses stl (which is all c++ code, because it is impossible to use c++ without standard library).

wheybags 10mo ago
And I see this argument often. People make too much fuss about the massive error messages. Just ignore everything but the first 10 lines and 99.9% of the time, the issue is obvious. People really exaggerate the amout of time and effort you spend dealing with these error messages. They look dramatic so they're very memeable, but it's really not a big deal. The percentage of hours I've spent deciphering difficult cpp error messages in my career is a rounding error.
- 112233 10mo ago
  Do you also consider that knowing type deduction is not necessary to fix those errors, unless you are writing a library? Because that is not my experience (c++ "career" can involve such wildly different codebases, it's hard to imagine what others must be dealing with)
1718627440 10mo ago
> it is impossible to use c++ without standard library Citation needed. This is common for embedded application, since why would anyone program a STL for that?
- OneDeuxTriSeiGo 10mo ago
  There's actually multiple standard libraries for embedded applications and a lot of the standard library from C++11 and on was designed with embedded in mind in particular. And with each std release the particularly nasty parts of std get decoupled from the rest of the library. So it's at the point nowadays where you can use all the commonly used parts of std in an embedded environment. So that means you get all your containers, iterators, ranges, views, smart/RAII pointers, smart/RAII concurrency primitives. And on the bleeding edge you can even get coroutines, generators, green threads, etc in an embedded environment with "pay for what you use" overhead. Intel has been pushing embedded stdlib really hard over the past few years and both they and Nvidia have been spearheading the senders and receivers concurrency effort. Intel uses S&R internally for handling concurrency in their embedded environments internal to the CPU and elsewhere in their hardware. (Also fun side note but STL doesn't "really" stand for "standard template library". Some projects have retroactively decided to refer to it as that but that's not where the term STL comes from. STL stands for the Adobe "Software Technology Lab" where Stepanov's STL project was formed and the project prior to being proposed to committee was named after the lab.)
  - gpderetta 10mo ago
    AFAIK Stepanov only joined Adobe much later. I think he was at HP during the development of the STL, but moved to SGI shortly after (possibly during standardization). The other apocryphal derivation of STL I have heard is "STepanov and Lee".
    - OneDeuxTriSeiGo 10mo ago
      AFAIK He started work on the STL at HP and then SGI based on his and Musser's work on Generic Programming but it didn't get the name STL until he was at the STL. This of course coming from Sean Parent who was and afaik still is quite close with Stepanov. Sean Parent of course being famous in his own right but also being notable for bringing Stepanov to Adobe and being the one to push for Stepanov to propose the STL to WG21 (the C++ ISO Std committee).
- 112233 10mo ago
  gladly! Since deep-linking draft pdf from phone is hard, here is the next best thing: https://en.cppreference.com/w/cpp/freestanding.html https://en.cppreference.com/w/cpp/freestanding.html freestanding requires almost all std library. Please note that -fno-rtti and -fno-exceptions are non-conformant, c++ standard does not permit either. Also, such std:: members as initializer_list, type_info etc are directly baked into compiler and stuff in header must exactly match internals — making std library a part of compiler implementation
  - 1718627440 10mo ago
    > Please note that -fno-rtti and -fno-exceptions are non-conformant, c++ standard does not permit either. I did not know that. My understanding was that C does not require standard library functions to be present in freestanding. The Linux kernel famously does not build in freestanding mode, since then GCC can't reason about the standard library functions which they want. This means that they need to implement stuff like memcpy and pass -fno-builtin. Does that mean that freestanding C++ requires the C++ standard library, but not the C standard library? How does that work?
    - 112233 10mo ago
      Honestly? No idea how the committee is thinking. When, say, gamedev people write proposal, ask for a feature, explain it is important and something they depend on and so on, it gets shot down on technicality. Then they turn around and produce some insane feature that, like, rips everything east to west (like modules), and suddenly voting goes positive. The "abstract machine" C++ assumes in the standard is itself a deeply puzzling construct. Luckily, compiler authors seem much more pragmatic and reasonable, I do not fear -fno-exceptions dissapearing suddenly, or code that accesses mmapped data becoming invalid because it didn't use start_lifetime_as
      - 1718627440 10mo ago
        So as to your understanding > freestanding C++ requires the C++ standard library, but not the C standard library is true? > The "abstract machine" C++ assumes in the standard is itself a deeply puzzling construct. I find the abstract machine to be quite a neat abstraction, but I am also more of a C guy.
OneDeuxTriSeiGo 10mo ago
Those aren't the ugly part of C++ and to be entirely honest reading those messages is not actually hard, it's just a lot of information. Those errors are essentially the compiler telling you in order: 1. I tried to do this thing and I could not make it work. 2. Here's everything I tried in order and how each attempt failed. If you read error messages from the top they make way more sense and if reading just the top line error doesn't tell you what's wrong, then reading through the list of resolution/type substitution failures will be insightful. In most cases the first few things it attempted will give you a pretty good idea of what the compiler was trying to do and why it failed. If the resolution failures are a particularly long list, just ctrl-f/grep to the thing you expected to resolve/type-substitute and the compiler will tell you exactly why the thing you wanted it to use didn't work. They aren't perfect error messages and the debugging experience of C++ metaprogramming leaves a lot to be desired but it is an order of magnitude better than it ever has been in the past and I'd still take C++ wall-o-error over the extremely over-reductive and limited errors that a lot of compilers in other languages emit (looking at you Java).
- ux266478 10mo ago
  To be fair to C++, the only languages with actually decently debuggable metaprograms are Lisp and Prolog. Modern C++ in general is so hostile to debugging I think it's astounding people actually use it.
- 112233 10mo ago
  Most of the time it's as uou say! But "I tried to do this thing" error is completely useless in helping to find the reason why the compiler didn't do the thing it was expected to do, but instead chose to ignore. Say, you hit ambiguous overload resolution, and have no idea what actually caused it. Or, conversely, implicit conversion gets hidden, and it helpfully prints all 999 operator << overloads. Or there is a bug in consteval bool type predicate, requires clause fails, and compiler helpfully dumps list of functions that have differet arguments. How do you debug consteval, if you cannot put printf in it? Not everyone can use clang or even latest gcc in their project, or work in a familiar codebase.
  - 10mo ago

by 112233 10mo ago

wheybags 10mo ago

And I see this argument often. People make too much fuss about the massive error messages. Just ignore everything but the first 10 lines and 99.9% of the time, the issue is obvious. People really exaggerate the amout of time and effort you spend dealing with these error messages. They look dramatic so they're very memeable, but it's really not a big deal. The percentage of hours I've spent deciphering difficult cpp error messages in my career is a rounding error.

112233 10mo ago
Do you also consider that knowing type deduction is not necessary to fix those errors, unless you are writing a library? Because that is not my experience (c++ "career" can involve such wildly different codebases, it's hard to imagine what others must be dealing with)

1718627440 10mo ago

> it is impossible to use c++ without standard library Citation needed. This is common for embedded application, since why would anyone program a STL for that?

OneDeuxTriSeiGo 10mo ago
There's actually multiple standard libraries for embedded applications and a lot of the standard library from C++11 and on was designed with embedded in mind in particular. And with each std release the particularly nasty parts of std get decoupled from the rest of the library. So it's at the point nowadays where you can use all the commonly used parts of std in an embedded environment. So that means you get all your containers, iterators, ranges, views, smart/RAII pointers, smart/RAII concurrency primitives. And on the bleeding edge you can even get coroutines, generators, green threads, etc in an embedded environment with "pay for what you use" overhead. Intel has been pushing embedded stdlib really hard over the past few years and both they and Nvidia have been spearheading the senders and receivers concurrency effort. Intel uses S&R internally for handling concurrency in their embedded environments internal to the CPU and elsewhere in their hardware. (Also fun side note but STL doesn't "really" stand for "standard template library". Some projects have retroactively decided to refer to it as that but that's not where the term STL comes from. STL stands for the Adobe "Software Technology Lab" where Stepanov's STL project was formed and the project prior to being proposed to committee was named after the lab.)
- gpderetta 10mo ago
  AFAIK Stepanov only joined Adobe much later. I think he was at HP during the development of the STL, but moved to SGI shortly after (possibly during standardization). The other apocryphal derivation of STL I have heard is "STepanov and Lee".
  - OneDeuxTriSeiGo 10mo ago
    AFAIK He started work on the STL at HP and then SGI based on his and Musser's work on Generic Programming but it didn't get the name STL until he was at the STL. This of course coming from Sean Parent who was and afaik still is quite close with Stepanov. Sean Parent of course being famous in his own right but also being notable for bringing Stepanov to Adobe and being the one to push for Stepanov to propose the STL to WG21 (the C++ ISO Std committee).
112233 10mo ago
gladly! Since deep-linking draft pdf from phone is hard, here is the next best thing: https://en.cppreference.com/w/cpp/freestanding.html https://en.cppreference.com/w/cpp/freestanding.html freestanding requires almost all std library. Please note that -fno-rtti and -fno-exceptions are non-conformant, c++ standard does not permit either. Also, such std:: members as initializer_list, type_info etc are directly baked into compiler and stuff in header must exactly match internals — making std library a part of compiler implementation
- 1718627440 10mo ago
  > Please note that -fno-rtti and -fno-exceptions are non-conformant, c++ standard does not permit either. I did not know that. My understanding was that C does not require standard library functions to be present in freestanding. The Linux kernel famously does not build in freestanding mode, since then GCC can't reason about the standard library functions which they want. This means that they need to implement stuff like memcpy and pass -fno-builtin. Does that mean that freestanding C++ requires the C++ standard library, but not the C standard library? How does that work?
  - 112233 10mo ago
    Honestly? No idea how the committee is thinking. When, say, gamedev people write proposal, ask for a feature, explain it is important and something they depend on and so on, it gets shot down on technicality. Then they turn around and produce some insane feature that, like, rips everything east to west (like modules), and suddenly voting goes positive. The "abstract machine" C++ assumes in the standard is itself a deeply puzzling construct. Luckily, compiler authors seem much more pragmatic and reasonable, I do not fear -fno-exceptions dissapearing suddenly, or code that accesses mmapped data becoming invalid because it didn't use start_lifetime_as
    - 1718627440 10mo ago
      So as to your understanding > freestanding C++ requires the C++ standard library, but not the C standard library is true? > The "abstract machine" C++ assumes in the standard is itself a deeply puzzling construct. I find the abstract machine to be quite a neat abstraction, but I am also more of a C guy.

OneDeuxTriSeiGo 10mo ago

Those aren't the ugly part of C++ and to be entirely honest reading those messages is not actually hard, it's just a lot of information. Those errors are essentially the compiler telling you in order: 1. I tried to do this thing and I could not make it work. 2. Here's everything I tried in order and how each attempt failed. If you read error messages from the top they make way more sense and if reading just the top line error doesn't tell you what's wrong, then reading through the list of resolution/type substitution failures will be insightful. In most cases the first few things it attempted will give you a pretty good idea of what the compiler was trying to do and why it failed. If the resolution failures are a particularly long list, just ctrl-f/grep to the thing you expected to resolve/type-substitute and the compiler will tell you exactly why the thing you wanted it to use didn't work. They aren't perfect error messages and the debugging experience of C++ metaprogramming leaves a lot to be desired but it is an order of magnitude better than it ever has been in the past and I'd still take C++ wall-o-error over the extremely over-reductive and limited errors that a lot of compilers in other languages emit (looking at you Java).

ux266478 10mo ago
To be fair to C++, the only languages with actually decently debuggable metaprograms are Lisp and Prolog. Modern C++ in general is so hostile to debugging I think it's astounding people actually use it.
112233 10mo ago
Most of the time it's as uou say! But "I tried to do this thing" error is completely useless in helping to find the reason why the compiler didn't do the thing it was expected to do, but instead chose to ignore. Say, you hit ambiguous overload resolution, and have no idea what actually caused it. Or, conversely, implicit conversion gets hidden, and it helpfully prints all 999 operator << overloads. Or there is a bug in consteval bool type predicate, requires clause fails, and compiler helpfully dumps list of functions that have differet arguments. How do you debug consteval, if you cannot put printf in it? Not everyone can use clang or even latest gcc in their project, or work in a familiar codebase.
- 10mo ago