5 ms·

A language shouldn't be this complicated. This is dangerous and impossible for teams full of juniors and busy people with deadlines. We're only human.

082349872349872 2y ago
I believe those teams just use constructors; this is a corner case, not SOP.
- echelon 2y ago
  C++ should start pulling things out of the language with new editions. It would improve quality of life dramatically.
  - falcor84 2y ago
    How about (C++)-- ?
    - Joel_Mckay 2y ago
      There was a C--, and it was an Assembly macro C like syntax based compiler. https://en.wikipedia.org/wiki/C-- https://en.wikipedia.org/wiki/C-- The GNU gcc/g++ was far more important to standardization than most people like to admit. Have a great day, =)
  - pjmlp 2y ago
    Rust style editions don't work with binary libraries, across compilers, or template code across editions, with semantic differences. That is why the epochs proposal was rejected. Additionally, the main reason many of us, even C++ passionate users, reach out to C++ instead of something else, is backwards compatibility, and existing ecosystem. When that is not required for the project at hand, we happily reach out to C#, D, Java, Go, Rust, Zig, Swift, Odin,.... instead.
    - jamincan 2y ago
      If Rust style editions can work across modules, why couldn't they work across binary libraries and so forth? The whole point is to allow the language to progress while maintaining backward compatability.
      - dathinab 2y ago
        they don't work with a backward compatible application binary interface or more specifically they only work with ABI stability if they ABI doesn't change between epochs which isn't a issue for Rust because: - it is cleanly modularized - it build a whole module "at once" - it doesn't have a "stable" ABI (outside of "extern/repr C" parts which don't contain non reprC parts rust doesn't even guarantee ABI compatibility between two builds in exactly the same context*(1)) - tends to build everything from source (with caching) - a lot of internees are intentionally kept "unstable" so that they can change at any time on the other side due to how C/C++ build things, doesn't have clean module isolation, how it chooses build units, how all of that is combined, how it's normal to include binaries not build by your project (or even you), how such binaries contain metadata (or don't) and how too much tooling relies on this in ways which make changes hard, how it doesn't have build-in package management, how it you specify compiler options and how compiler defaults are handled etc. come together to make that impossible in a certain way how you specify that you use C++11,17 etc. is the closest C++ can get to rust editions like initially it might seem easy to introduce syntax braking changes (which most rust edition changes boil down to) but then you realize that build units using other editions have to be able to read the header file and the header file e.g. in context of templates can contains any kind of code and that header includes aren't that much different too copy pasting in the header and that you don't have a standard package manager which can trace which edition a header has and endless different build systems and you kinda give up purely technically it _is fully possible to have rust like editions in C++_ but practically/organizationally in context of e.g. backward compatibility with build systems it's just way to disruptive to be practical
    - 0xffff2 2y ago
      > When that is not required for the project at hand, we happily reach out to C#, D, Java, Go, Rust, Zig, Swift, Odin,.... instead. Which is all well and good for us, the application developers. But if C++ wants to exist in the future as a thriving language (as opposed to moving in to the nursing home with Cobol and Fortran), then it needs to come up with some solution to remove cruft.
dataflow 2y ago
They can't pull the rug out now, but I highly recommend making your own clang-tidies to flag confusing constructs (like defaulted out-of-line constructors) and preventing them from being committed.
gosub100 2y ago
My guess is all these details are necessary to provide C++ "strong exception guarantee" against partially constructed objects. Perhaps if your member objects can throw exceptions, some of these pedantic initialization rules can come to the rescue and allow, say, a library implementor to limit initialization code to places where exceptions can be handled.
bun_terminator 2y ago
True, however in practice this is rarely an issue. You usually only use a tiny subset of construction rules. And if you ever make a mistake, they are easily caught by static analysis tools.
- smackeyacky 2y ago
  It’s quite a big issue. It’s actually a bit worse than the article makes out if you throw static objects into the mix and get race conditions where you don’t know which objects get constructed first. C++ has to be approached with caution even by experienced devs.
  - bun_terminator 2y ago
    experienced (and even the not so much) devs know the perils of static initialization and avoid it.
  - maccard 2y ago
    I agree with the parent - global initialisation order is a once-bitten-never-again, and the reality is that working in most codebases doesn't require understanding all of these rules - knowing the quirks is usually only required by one or two people and the rest can work with what they've got.
  - TinkersW 2y ago
    that is a novice issue, it is easily avoided
dathinab 2y ago
it being this complicated can be fine (if there isn't too much of it) but only if not knowing how the complicated parts work doesn't create any subtle issues and has reasonable compiler time errors and isn't fundamental needed to write any code Because then you can use the language without needing to know how exactly that complexity works and if you get it wrong you get a reasonable compiler error. And then decide to either spend some time to learn what you didn't know or you just write the code differently. But in either case you don't have a situation with a unexpected runtime error which should be impossible and where you have no good way to know where to even start looking.
- dathinab 2y ago
  its funny how people are down voting this when it's exactly the approach rust uses
jjmarr 2y ago
Working as a junior in a C++ codebase is great for my career because the skill floor is so high. Because it's so difficult to do anything there's a lot of room to distinguish myself. No other language creates as many problems for programmers as C++.
userbinator 2y ago
I've come to the conclusion that most if not all the complexity is largely to justify the existence of those who work on "moving the language forward".

082349872349872 2y ago

I believe those teams just use constructors; this is a corner case, not SOP.

echelon 2y ago
C++ should start pulling things out of the language with new editions. It would improve quality of life dramatically.
- falcor84 2y ago
  How about (C++)-- ?
  - Joel_Mckay 2y ago
    There was a C--, and it was an Assembly macro C like syntax based compiler. https://en.wikipedia.org/wiki/C-- https://en.wikipedia.org/wiki/C-- The GNU gcc/g++ was far more important to standardization than most people like to admit. Have a great day, =)
- pjmlp 2y ago
  Rust style editions don't work with binary libraries, across compilers, or template code across editions, with semantic differences. That is why the epochs proposal was rejected. Additionally, the main reason many of us, even C++ passionate users, reach out to C++ instead of something else, is backwards compatibility, and existing ecosystem. When that is not required for the project at hand, we happily reach out to C#, D, Java, Go, Rust, Zig, Swift, Odin,.... instead.
  - jamincan 2y ago
    If Rust style editions can work across modules, why couldn't they work across binary libraries and so forth? The whole point is to allow the language to progress while maintaining backward compatability.
    - dathinab 2y ago
      they don't work with a backward compatible application binary interface or more specifically they only work with ABI stability if they ABI doesn't change between epochs which isn't a issue for Rust because: - it is cleanly modularized - it build a whole module "at once" - it doesn't have a "stable" ABI (outside of "extern/repr C" parts which don't contain non reprC parts rust doesn't even guarantee ABI compatibility between two builds in exactly the same context*(1)) - tends to build everything from source (with caching) - a lot of internees are intentionally kept "unstable" so that they can change at any time on the other side due to how C/C++ build things, doesn't have clean module isolation, how it chooses build units, how all of that is combined, how it's normal to include binaries not build by your project (or even you), how such binaries contain metadata (or don't) and how too much tooling relies on this in ways which make changes hard, how it doesn't have build-in package management, how it you specify compiler options and how compiler defaults are handled etc. come together to make that impossible in a certain way how you specify that you use C++11,17 etc. is the closest C++ can get to rust editions like initially it might seem easy to introduce syntax braking changes (which most rust edition changes boil down to) but then you realize that build units using other editions have to be able to read the header file and the header file e.g. in context of templates can contains any kind of code and that header includes aren't that much different too copy pasting in the header and that you don't have a standard package manager which can trace which edition a header has and endless different build systems and you kinda give up purely technically it _is fully possible to have rust like editions in C++_ but practically/organizationally in context of e.g. backward compatibility with build systems it's just way to disruptive to be practical
  - 0xffff2 2y ago
    > When that is not required for the project at hand, we happily reach out to C#, D, Java, Go, Rust, Zig, Swift, Odin,.... instead. Which is all well and good for us, the application developers. But if C++ wants to exist in the future as a thriving language (as opposed to moving in to the nursing home with Cobol and Fortran), then it needs to come up with some solution to remove cruft.

dataflow 2y ago

They can't pull the rug out now, but I highly recommend making your own clang-tidies to flag confusing constructs (like defaulted out-of-line constructors) and preventing them from being committed.

gosub100 2y ago

My guess is all these details are necessary to provide C++ "strong exception guarantee" against partially constructed objects. Perhaps if your member objects can throw exceptions, some of these pedantic initialization rules can come to the rescue and allow, say, a library implementor to limit initialization code to places where exceptions can be handled.

bun_terminator 2y ago

True, however in practice this is rarely an issue. You usually only use a tiny subset of construction rules. And if you ever make a mistake, they are easily caught by static analysis tools.

smackeyacky 2y ago
It’s quite a big issue. It’s actually a bit worse than the article makes out if you throw static objects into the mix and get race conditions where you don’t know which objects get constructed first. C++ has to be approached with caution even by experienced devs.
- bun_terminator 2y ago
  experienced (and even the not so much) devs know the perils of static initialization and avoid it.
- maccard 2y ago
  I agree with the parent - global initialisation order is a once-bitten-never-again, and the reality is that working in most codebases doesn't require understanding all of these rules - knowing the quirks is usually only required by one or two people and the rest can work with what they've got.
- TinkersW 2y ago
  that is a novice issue, it is easily avoided

dathinab 2y ago

it being this complicated can be fine (if there isn't too much of it) but only if not knowing how the complicated parts work doesn't create any subtle issues and has reasonable compiler time errors and isn't fundamental needed to write any code Because then you can use the language without needing to know how exactly that complexity works and if you get it wrong you get a reasonable compiler error. And then decide to either spend some time to learn what you didn't know or you just write the code differently. But in either case you don't have a situation with a unexpected runtime error which should be impossible and where you have no good way to know where to even start looking.

dathinab 2y ago
its funny how people are down voting this when it's exactly the approach rust uses

jjmarr 2y ago

Working as a junior in a C++ codebase is great for my career because the skill floor is so high. Because it's so difficult to do anything there's a lot of room to distinguish myself. No other language creates as many problems for programmers as C++.

userbinator 2y ago

I've come to the conclusion that most if not all the complexity is largely to justify the existence of those who work on "moving the language forward".