4 ms·

Thee is an important difference between C++ and Rust: C++ tried to play the game by being a superset of C (even started as a precompiler to C) and many C progra

Thee is an important difference between C++ and Rust: C++ tried to play the game by being a superset of C (even started as a precompiler to C) and many C programs are valid C++ (well, many C programs aren't valid C, let's ignore that here) Thus C++ always carries C's legacy along so that there is always the C way of doing things, and then the C++ way of doing things. Rust cut that part of, while allowing to call C functions.

einpoklum 6y ago
Also, Rust has taken the path of backwards-incompatible changes, while the C++ language designers/committee go to great lengths to maintain near-perfect backwards compatibility with older versions of the language (and refuse to allow for ABI-breaking changes! Grr!)
- MaxBarraclough 6y ago
  > and refuse to allow for ABI-breaking changes! Did you mean API? The C++ ABI situation is famously unstable.
  - einpoklum 6y ago
    No, I did mean the ABI. See this paper, for example, about the argument: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1863r1.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p186... "there is a non-trivial amount of performance that we cannot recoup because of ABI concerns. We cannot remove runtime overhead involved in passing unique_ptr by value, nor can we change std::hash or class layout for unordered_map , without forcing a recompile everywhere etc. etc."
    - MaxBarraclough 6y ago
      Thanks for the link, interesting skim-read. I thought passing template instantiations over an ABI boundary was generally discouraged and thought to be asking for trouble. I guess this isn't really at odds with what the paper is saying though - it could still be that a lot of people are doing so. edit Thinking about Hyrum's Law, [0] mentioned in the article, makes me think perhaps there was an upside to Java firmly refusing to support any kind of ahead-of-time compilation for so long. It fully closed the door on any funny business distributing Java packages as brittle precompiled native-code blobs, ensuring the bytecode format remained the way that Java packages were distributed, presumably avoiding some fraction of the issues C++ now faces. Of course, Java still has backward-compatibility obligations, but unlike in C++ they align pretty well with API compatibility, if I understand things correctly. [0] https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
      - int_19h 6y ago
        There's nothing particular about template instantiations that makes them any different from any other object. The only problem with using them at ABI (or rather, linker) boundary is that instantiations have to be explicit - but that's what "extern template" is for.
  - jcelerier 6y ago
    > The C++ ABI situation is famously unstable. is a couple ABI breaks for std::string between C++98 and C++20 that unstable ? You can write code that uses std::string today and links against a .so built a long time ago (modulo compiler bugs of course, thus the various versions here: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Optio...). GCC & libstdc++ go to great lengths to preserve ABI compatibility.

einpoklum 6y ago

Also, Rust has taken the path of backwards-incompatible changes, while the C++ language designers/committee go to great lengths to maintain near-perfect backwards compatibility with older versions of the language (and refuse to allow for ABI-breaking changes! Grr!)

MaxBarraclough 6y ago
> and refuse to allow for ABI-breaking changes! Did you mean API? The C++ ABI situation is famously unstable.
- einpoklum 6y ago
  No, I did mean the ABI. See this paper, for example, about the argument: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1863r1.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p186... "there is a non-trivial amount of performance that we cannot recoup because of ABI concerns. We cannot remove runtime overhead involved in passing unique_ptr by value, nor can we change std::hash or class layout for unordered_map , without forcing a recompile everywhere etc. etc."
  - MaxBarraclough 6y ago
    Thanks for the link, interesting skim-read. I thought passing template instantiations over an ABI boundary was generally discouraged and thought to be asking for trouble. I guess this isn't really at odds with what the paper is saying though - it could still be that a lot of people are doing so. edit Thinking about Hyrum's Law, [0] mentioned in the article, makes me think perhaps there was an upside to Java firmly refusing to support any kind of ahead-of-time compilation for so long. It fully closed the door on any funny business distributing Java packages as brittle precompiled native-code blobs, ensuring the bytecode format remained the way that Java packages were distributed, presumably avoiding some fraction of the issues C++ now faces. Of course, Java still has backward-compatibility obligations, but unlike in C++ they align pretty well with API compatibility, if I understand things correctly. [0] https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
    - int_19h 6y ago
      There's nothing particular about template instantiations that makes them any different from any other object. The only problem with using them at ABI (or rather, linker) boundary is that instantiations have to be explicit - but that's what "extern template" is for.
- jcelerier 6y ago
  > The C++ ABI situation is famously unstable. is a couple ABI breaks for std::string between C++98 and C++20 that unstable ? You can write code that uses std::string today and links against a .so built a long time ago (modulo compiler bugs of course, thus the various versions here: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Optio...). GCC & libstdc++ go to great lengths to preserve ABI compatibility.