7 ms·

> 2. Non-goals > 2.1. Stable language and library ABI > 2.2. Backwards or forwards compatibility > 2.3. Legacy compiled libraries without source code or abil

> 2. Non-goals > 2.1. Stable language and library ABI > 2.2. Backwards or forwards compatibility > 2.3. Legacy compiled libraries without source code or ability to rebuild For fucks sake, C has been stable for decades but somehow C++ just can't manage? This is such an obnoxious attitude. At least let us automatically generate a set of C-style functions that take an opaque void* representing a C++ class instance if you can't be bothered to do the work.

google234123 6y ago
Calm down my friend. Why should C++ be exactly like C? There are reasons that C is a declining language. Also, I don't get why you think they have obnoxious attitude? They do go into detail for each point, I don't think your characterization is fair.
- _bxg1 6y ago
  If anything it seems like C++ is the one in decline. C is still the only option for lots of use-cases; C++ is a) succumbing to feature-bloat and b) having different parts of its userbase siphoned off by Go, Rust, Swift, even C# (games; both Unity and Godot).
  - jonstewart 6y ago
    C++ has been greatly reinvigorated this past decade with language and compiler modernization. Few C++ programmers decamped to Go; most of Go’s adoptees came from Python. Go doesn’t have all that much to offer a C++ programmer.
    - dodobirdlord 6y ago
      > Go doesn’t have all that much to offer a C++ programmer. Concurrency and parallelism without debugging hell is huge.
      - gumby 6y ago
        C++ will be getting a concurrency model, likely in C++23. As with other language features the position papers and implementations refer not only with their authors’ experience with C++ efforts (libuv, asio, pthreads) but other languages as well, such as go.
      - pjmlp 6y ago
        C++20 offers both with very nice graphical debuggers, which Delve isn't really a match for.
        abjKT26nO8 6y ago
        What graphical debuggers for C++ do you recommend?
        pjmlp 6y ago
        Visual C++ ones.
        abjKT26nO8 6y ago
        That's not really an option for me when I debug C++ that is run on a Linux or Android TV. It also wouldn't be an option when I used to work with C++ that was used on Linux servers. That's a big chunk of C++ use. While I have your attention, I see your comments here in C++ threads quite often. You seem to like the language and at the same time you have some experience with simpler languages like Oberon. My experience with C++ has been that people happily go on to create giant inheritance hierarchies, with no restraint for multiple inheritance to the point that it's so unmanagable that nobody knows where things go and what actually happens. With all that inheritance, they lose track that the same thing has actually been copied tens of times between different classes and now these tens of classes have code that is basically copy-pasted and who knows what benefit anyone has from all this inheritance. Google engineers are one of the offenders when it comes to overuse of inheritance. Then, modern C++ allegedly fixes some warts, but IME it introduces more of them. E.g. the initialization fiasco (I honestly can't say with 100% confidence what braces do when you initialize std::vector). Then there is this thing that when you create a lambda like so: [&] { ... } And then move it to a function which will create lambdas of this form, just with different captures: std::function<void()> create_lambda(args...) { return [&] { ... }; } The second version will crash later when you run the lambda. Because it turns out that "[&]" just copies the stack pointer and isn't syntactic sugar for enumerating all the variables that you capture. This was non-obvious to me and it was really hard to track down the first time I encountered this problem. I think "[&]" is broken. Similarly, std::thread crashing in destructor when the user doesn't call std::thread::join, nor std::thread::detach. The ambiguity of syntax... I just don't buy that "modern C++" makes things particularly better. It sometimes makes them worse. Don't you experience the same fatigue as I do? EDIT: Oh, I just remembered another thing: at a previous job we discovered that MinGW's implementation of std::random_device just returned 0 every time. It is major facepalm for MinGW, but also for the C++ standard for making this behaviour allowed (yes, it's actually compliant with the standard). And even after it was fixed, there are still systematic issues with this whole randomness API. E.g. you can't actually seed it properly[1]. [1]: https://codingnest.com/generating-random-numbers-using-c-standard-library-the-problems/ https://codingnest.com/generating-random-numbers-using-c-sta...
  - vips7L 6y ago
    Swift? I didn't know it had much use outside of mac/iOS. It seems like a cool language otherwise.
    - _bxg1 6y ago
      It just recently got official support for Windows and Linux, and it had low-key Linux support for a while before that. I've heard of people writing web servers in it. Like Go, it compiles directly to native machine code.
      - vips7L 6y ago
        Isn't it still slower than GO because of referencing counting?
        _bxg1 6y ago
        Depends what you mean by slow. Go is garbage-collected, Swift is reference-counted. Each has advantages and disadvantages. But also, that doesn't apply to stack-allocated values. It's not as simple as one being faster than the other.
  - pjmlp 6y ago
    The only thing keeping C around are FOSS UNIX clones and embedded developers that are religiously stuck with C89 and their PIC compiler extensions. Even Arduino like boards use C++ nowadays. Unity and Godot have their graphics engine written in C++. Rust, Swift are dependent on LLVM, written in C++. Go, it isn't really in the same league of programmer expressiveness.
    - worik 6y ago
      I have spend the quarantine hacking in C. On FreeCIV. Still used lots and lots of places
      - pjmlp 6y ago
        Same can be said by any programming language, C is the Cobol of systems programming languages, so as long as there UNIX FOSS clones it won't go away.
      - hannofcart 6y ago
        Freeciv fan here. What are you working on in it?
        worik 6y ago
        Forked Attitude AI and making a rules based AI
    - saagarjha 6y ago
      There are lots of performance sensitive tools, language runtimes, and cross-platform libraries written in C.
      - pjmlp 6y ago
        And even more written in C++. Should we start counting which ones?
        6y ago
- cozzyd 6y ago
  It makes C++ much less useful to write a library in (or, you have to maintain a fragile C layer). I take it you've never had to deal with a libstdc++ ABI boundary before?
  - google234123 6y ago
    You can continue working in a world without the small string optimization if you want. There is already precedent.
    - CoolGuySteve 6y ago
      I want a world where the compiler knows when it can use that optimization instead of me bludgeoning it with a global define. Like you said, it's not even that far fetched.
      - gumby 6y ago
        It’s a library feature not as compiler feature so you can’t really get out of telling the compiler which library to use, Eben if what you say is nothing (meaning “default library”)
  - adrianN 6y ago
    Maintaining a C layer is standard practice for many libraries because that enables their use from a variety of programming languages. Consequently, the tooling around that is quite mature.
    - cozzyd 6y ago
      Sure, but if C++ had a stable ABI, then it would be more practical to directly wrap it. SWIG has some support for C++, after all, and there are a lot of C++ wrappers (e.g. ROOT, pybind11 and Boost.Python can all automagically generate python bindings for C++), but guess what happens when you mix libraries compiled with different std::basic_string ABIs...
- throw_m239339 6y ago
  > There are reasons that C is a declining language. Unfortunately, it is not. C++ is certainly too complicated, that's why it failed at replacing C, and that's why Rust will fail at replacing C as well.
  - dodobirdlord 6y ago
    Fortunately for Rust it's very easy to use a simple subset of the language. Lots of tough borrowing issues don't show up if you stick to the stack, and you can get very far with just the stack and some heap allocated vectors and maps. Not everybody needs to implement an async runtime.
  - pjmlp 6y ago
    It only failed on UNIX FOSS clones and embedded C only boards. All major C compilers are written in C++ nowadays. Apple OSes use C++ for device drivers, GPGPU programming and their compiler infrastructure. Google OSes use legacy C drivers for Linux and everything else is a mix of C++, Java, Rust, using micro-kernel like architecture where each driver gets their own process. On Windows it has been long considered persona non-grata and everyone advised to either move to C++ or adopt Clang (also provided via VS installer) if they insist in using C. VC++ only supports C to the extent required by ISO C+++ compliance. One of the reasons OpenCL lost to CUDA was the initial refusal of Khronos to offer similar C++ tooling, making many researches jump to NVidia.
    - saagarjha 6y ago
      > Apple OSes use C++ for device drivers Embedded C++, and the kernel is pure C.
      - pjmlp 6y ago
        Embedded C++ is a C++ subset, it is as valid C++ example as those embedded C dialects that aren't able to fully support the ISO C standard library, yet people still call them C. And as of Driver Kit introduction, 100% full C++ is now an option. In a couple of years from now, when the full transition of kernel extensions to user space modules is complete, the kernel will be the only C piece left. Which Apple most likely won't bother to rewrite due to the historical baggage of mixing BSD with Mach code that probably no one is willing to re-write.
codewiz 6y ago
These things come with a performance cost and constraints on how the language can evolve. I would argue that C++ needs to increase the pace of change if it wants to remain relevant. Rust, Go, Swift and Kotlin are though competition, while C++20 is still lacking in agility, safety and modularity.
- CoolGuySteve 6y ago
  What's more modular and agile than being able to link another library you didn't compile yourself without worrying about your language version or compiler? C++ build systems are already worse than all the languages you mentioned in part because there's no module support. I also disagree that it would hurt performance. If the logic contained in "-D_GLIBCXX_USE_CXX11_ABI=0" was formalized to allow backwards compatibility, libraries would snap together more easily while still preserving inlining better than C ABI exports are able to.
  - dodobirdlord 6y ago
    > What's more modular and agile than being able to link another library you didn't compile yourself without worrying about your language version or compiler? The point of the document is to lay out the goals and priorities of the authors, not to argue that they are universally applicable. The authors compile everything from scratch with the same version of the compiler, down to the OS kernel.
- titzer 6y ago
  > Rust, Go, Swift and Kotlin are though[sic] competition, while C++20 is still lacking in agility, safety and modularity. What is the point of fighting to stay relevant by going after use cases that are being served by these other languages? Is it just to win and have more "mind share"? Is it to make the biggest tribe? That seems like a social goal, not a technical one.
  - dodobirdlord 6y ago
    It defends their investment, both in the skills they have built up and the existing code that they have created.
Figs 6y ago
These aren't the standard's committee's goals. They're Google's, NVIDIA's, and the other proposal author's goals. As a community, we absolutely should reject this proposal and insist that the standards committee continue to support compatibility. Repeating Python3's mistake in C++ would be a nightmare!
dodobirdlord 6y ago
> This paper describes the goals and priorities which the authors believe make C++ an especially effective programming language for our use cases. That said, our experience, use cases, and needs are clearly not those of every user. We aren’t pushing to directly build consensus on these points. Rather, this is presented as a vehicle to advertise our needs from C++ as a high-performance systems language. The authors are (mostly) at Google. They build their binaries from scratch from a monolithic source repo with a reproducible build system every time they want to deploy software. Their use case is unusual and they recognize that. The document lays out their justification for what they prioritize and why, for example, they would happily sacrifice backwards compatibility or nonstandard architecture support for more performance.
jcelerier 6y ago
> For fucks sake, C has been stable for decades but somehow C++ just can't manage? the -std=c++03 mode of the compiler is pretty stable... but not many people care about that anymore. If they cared google would be building their next kernel in C, not in C++
- gpderetta 6y ago
  you can compile with -std=c++20 and still use the C++03 ABI (of course std::string will not be compliant then). The two flags are unrelated.
hoseja 6y ago
The ABI breaks when you change string implementation to use an optimization for small strings. Therefore you can't optimize them without breaking ABI. C has no strings. The optimization was considered vital enough for a rare break to actually happen but there are multiple such clear wins that cannot be implemented because of ABI stability. Sometimes it's a major pain to have to keep piling the cruft on.

google234123 6y ago

Calm down my friend. Why should C++ be exactly like C? There are reasons that C is a declining language. Also, I don't get why you think they have obnoxious attitude? They do go into detail for each point, I don't think your characterization is fair.

_bxg1 6y ago
If anything it seems like C++ is the one in decline. C is still the only option for lots of use-cases; C++ is a) succumbing to feature-bloat and b) having different parts of its userbase siphoned off by Go, Rust, Swift, even C# (games; both Unity and Godot).
- jonstewart 6y ago
  C++ has been greatly reinvigorated this past decade with language and compiler modernization. Few C++ programmers decamped to Go; most of Go’s adoptees came from Python. Go doesn’t have all that much to offer a C++ programmer.
  - dodobirdlord 6y ago
    > Go doesn’t have all that much to offer a C++ programmer. Concurrency and parallelism without debugging hell is huge.
    - gumby 6y ago
      C++ will be getting a concurrency model, likely in C++23. As with other language features the position papers and implementations refer not only with their authors’ experience with C++ efforts (libuv, asio, pthreads) but other languages as well, such as go.
    - pjmlp 6y ago
      C++20 offers both with very nice graphical debuggers, which Delve isn't really a match for.
      - abjKT26nO8 6y ago
        What graphical debuggers for C++ do you recommend?
        pjmlp 6y ago
        Visual C++ ones.
        abjKT26nO8 6y ago
        That's not really an option for me when I debug C++ that is run on a Linux or Android TV. It also wouldn't be an option when I used to work with C++ that was used on Linux servers. That's a big chunk of C++ use. While I have your attention, I see your comments here in C++ threads quite often. You seem to like the language and at the same time you have some experience with simpler languages like Oberon. My experience with C++ has been that people happily go on to create giant inheritance hierarchies, with no restraint for multiple inheritance to the point that it's so unmanagable that nobody knows where things go and what actually happens. With all that inheritance, they lose track that the same thing has actually been copied tens of times between different classes and now these tens of classes have code that is basically copy-pasted and who knows what benefit anyone has from all this inheritance. Google engineers are one of the offenders when it comes to overuse of inheritance. Then, modern C++ allegedly fixes some warts, but IME it introduces more of them. E.g. the initialization fiasco (I honestly can't say with 100% confidence what braces do when you initialize std::vector). Then there is this thing that when you create a lambda like so: [&] { ... } And then move it to a function which will create lambdas of this form, just with different captures: std::function<void()> create_lambda(args...) { return [&] { ... }; } The second version will crash later when you run the lambda. Because it turns out that "[&]" just copies the stack pointer and isn't syntactic sugar for enumerating all the variables that you capture. This was non-obvious to me and it was really hard to track down the first time I encountered this problem. I think "[&]" is broken. Similarly, std::thread crashing in destructor when the user doesn't call std::thread::join, nor std::thread::detach. The ambiguity of syntax... I just don't buy that "modern C++" makes things particularly better. It sometimes makes them worse. Don't you experience the same fatigue as I do? EDIT: Oh, I just remembered another thing: at a previous job we discovered that MinGW's implementation of std::random_device just returned 0 every time. It is major facepalm for MinGW, but also for the C++ standard for making this behaviour allowed (yes, it's actually compliant with the standard). And even after it was fixed, there are still systematic issues with this whole randomness API. E.g. you can't actually seed it properly[1]. [1]: https://codingnest.com/generating-random-numbers-using-c-standard-library-the-problems/ https://codingnest.com/generating-random-numbers-using-c-sta...
- vips7L 6y ago
  Swift? I didn't know it had much use outside of mac/iOS. It seems like a cool language otherwise.
  - _bxg1 6y ago
    It just recently got official support for Windows and Linux, and it had low-key Linux support for a while before that. I've heard of people writing web servers in it. Like Go, it compiles directly to native machine code.
    - vips7L 6y ago
      Isn't it still slower than GO because of referencing counting?
      - _bxg1 6y ago
        Depends what you mean by slow. Go is garbage-collected, Swift is reference-counted. Each has advantages and disadvantages. But also, that doesn't apply to stack-allocated values. It's not as simple as one being faster than the other.
- pjmlp 6y ago
  The only thing keeping C around are FOSS UNIX clones and embedded developers that are religiously stuck with C89 and their PIC compiler extensions. Even Arduino like boards use C++ nowadays. Unity and Godot have their graphics engine written in C++. Rust, Swift are dependent on LLVM, written in C++. Go, it isn't really in the same league of programmer expressiveness.
  - worik 6y ago
    I have spend the quarantine hacking in C. On FreeCIV. Still used lots and lots of places
    - pjmlp 6y ago
      Same can be said by any programming language, C is the Cobol of systems programming languages, so as long as there UNIX FOSS clones it won't go away.
    - hannofcart 6y ago
      Freeciv fan here. What are you working on in it?
      - worik 6y ago
        Forked Attitude AI and making a rules based AI
  - saagarjha 6y ago
    There are lots of performance sensitive tools, language runtimes, and cross-platform libraries written in C.
    - pjmlp 6y ago
      And even more written in C++. Should we start counting which ones?
      - 6y ago
cozzyd 6y ago
It makes C++ much less useful to write a library in (or, you have to maintain a fragile C layer). I take it you've never had to deal with a libstdc++ ABI boundary before?
- google234123 6y ago
  You can continue working in a world without the small string optimization if you want. There is already precedent.
  - CoolGuySteve 6y ago
    I want a world where the compiler knows when it can use that optimization instead of me bludgeoning it with a global define. Like you said, it's not even that far fetched.
    - gumby 6y ago
      It’s a library feature not as compiler feature so you can’t really get out of telling the compiler which library to use, Eben if what you say is nothing (meaning “default library”)
- adrianN 6y ago
  Maintaining a C layer is standard practice for many libraries because that enables their use from a variety of programming languages. Consequently, the tooling around that is quite mature.
  - cozzyd 6y ago
    Sure, but if C++ had a stable ABI, then it would be more practical to directly wrap it. SWIG has some support for C++, after all, and there are a lot of C++ wrappers (e.g. ROOT, pybind11 and Boost.Python can all automagically generate python bindings for C++), but guess what happens when you mix libraries compiled with different std::basic_string ABIs...
throw_m239339 6y ago
> There are reasons that C is a declining language. Unfortunately, it is not. C++ is certainly too complicated, that's why it failed at replacing C, and that's why Rust will fail at replacing C as well.
- dodobirdlord 6y ago
  Fortunately for Rust it's very easy to use a simple subset of the language. Lots of tough borrowing issues don't show up if you stick to the stack, and you can get very far with just the stack and some heap allocated vectors and maps. Not everybody needs to implement an async runtime.
- pjmlp 6y ago
  It only failed on UNIX FOSS clones and embedded C only boards. All major C compilers are written in C++ nowadays. Apple OSes use C++ for device drivers, GPGPU programming and their compiler infrastructure. Google OSes use legacy C drivers for Linux and everything else is a mix of C++, Java, Rust, using micro-kernel like architecture where each driver gets their own process. On Windows it has been long considered persona non-grata and everyone advised to either move to C++ or adopt Clang (also provided via VS installer) if they insist in using C. VC++ only supports C to the extent required by ISO C+++ compliance. One of the reasons OpenCL lost to CUDA was the initial refusal of Khronos to offer similar C++ tooling, making many researches jump to NVidia.
  - saagarjha 6y ago
    > Apple OSes use C++ for device drivers Embedded C++, and the kernel is pure C.
    - pjmlp 6y ago
      Embedded C++ is a C++ subset, it is as valid C++ example as those embedded C dialects that aren't able to fully support the ISO C standard library, yet people still call them C. And as of Driver Kit introduction, 100% full C++ is now an option. In a couple of years from now, when the full transition of kernel extensions to user space modules is complete, the kernel will be the only C piece left. Which Apple most likely won't bother to rewrite due to the historical baggage of mixing BSD with Mach code that probably no one is willing to re-write.

codewiz 6y ago

These things come with a performance cost and constraints on how the language can evolve. I would argue that C++ needs to increase the pace of change if it wants to remain relevant. Rust, Go, Swift and Kotlin are though competition, while C++20 is still lacking in agility, safety and modularity.

CoolGuySteve 6y ago
What's more modular and agile than being able to link another library you didn't compile yourself without worrying about your language version or compiler? C++ build systems are already worse than all the languages you mentioned in part because there's no module support. I also disagree that it would hurt performance. If the logic contained in "-D_GLIBCXX_USE_CXX11_ABI=0" was formalized to allow backwards compatibility, libraries would snap together more easily while still preserving inlining better than C ABI exports are able to.
- dodobirdlord 6y ago
  > What's more modular and agile than being able to link another library you didn't compile yourself without worrying about your language version or compiler? The point of the document is to lay out the goals and priorities of the authors, not to argue that they are universally applicable. The authors compile everything from scratch with the same version of the compiler, down to the OS kernel.
titzer 6y ago
> Rust, Go, Swift and Kotlin are though[sic] competition, while C++20 is still lacking in agility, safety and modularity. What is the point of fighting to stay relevant by going after use cases that are being served by these other languages? Is it just to win and have more "mind share"? Is it to make the biggest tribe? That seems like a social goal, not a technical one.
- dodobirdlord 6y ago
  It defends their investment, both in the skills they have built up and the existing code that they have created.

Figs 6y ago

These aren't the standard's committee's goals. They're Google's, NVIDIA's, and the other proposal author's goals. As a community, we absolutely should reject this proposal and insist that the standards committee continue to support compatibility. Repeating Python3's mistake in C++ would be a nightmare!

dodobirdlord 6y ago

> This paper describes the goals and priorities which the authors believe make C++ an especially effective programming language for our use cases. That said, our experience, use cases, and needs are clearly not those of every user. We aren’t pushing to directly build consensus on these points. Rather, this is presented as a vehicle to advertise our needs from C++ as a high-performance systems language. The authors are (mostly) at Google. They build their binaries from scratch from a monolithic source repo with a reproducible build system every time they want to deploy software. Their use case is unusual and they recognize that. The document lays out their justification for what they prioritize and why, for example, they would happily sacrifice backwards compatibility or nonstandard architecture support for more performance.

jcelerier 6y ago

> For fucks sake, C has been stable for decades but somehow C++ just can't manage? the -std=c++03 mode of the compiler is pretty stable... but not many people care about that anymore. If they cared google would be building their next kernel in C, not in C++

gpderetta 6y ago
you can compile with -std=c++20 and still use the C++03 ABI (of course std::string will not be compliant then). The two flags are unrelated.

hoseja 6y ago

The ABI breaks when you change string implementation to use an optimization for small strings. Therefore you can't optimize them without breaking ABI. C has no strings. The optimization was considered vital enough for a rare break to actually happen but there are multiple such clear wins that cannot be implemented because of ABI stability. Sometimes it's a major pain to have to keep piling the cruft on.