6 ms·

> The point of standardized components is to provide reusable elements that can be used across all platforms and implementations, thus saving on the development

> The point of standardized components is to provide reusable elements that can be used across all platforms and implementations, thus saving on the development effort of upgrading and porting the code across implementations and even platforms. It's a shame that C++'s "standardized" components ARE COMPLETELY DIFFERENT on different platforms. Some of the C++ standard requires per-platform implementation work. For example std::thread on Linux and Windows obviously must have a different implementation. However a super majority of the standard API is just vanilla C++ code. For example std::vector or std::unordered_map. The fact that the standard defines a spec which is then implemented numerous times is absurd, stupid, and bad. The specs are simultaneously over-constrained and under-constrained. It's a disaster.

gumby 2y ago
I consider the current tradeoff to be a feature. It permits implementations to take advantage of target-specific affordances (your thread case is an example) as well as taking different implementation strategies (e.g. the small string optimization is different in libc++ and libstdc++). Also you may use another, independent standard library because you prefer its implementation decisions. Meanwhile they remain compatible at the source level.
- Maxatar 2y ago
  Unlike in C, in C++ it is not possible to use an independent implementation of the standard library. Clang is compatible with GCC's standard library/libstdc++ and MSVC's standard library because the clang compiler explicitly supports them, but it's not possible to use clang's standard library with GCC in a standard conforming way or interchange GCC's with MSVC's standard library. There are some hacks that let you use some parts of libc++ with GCC by using the nostdlib flag, but this disables a lot of C++ functionality such as exception handling, RTTI, type traits. These features are in turn used by things like std::vector, std::map, etc... so you won't be able to use those classes either, and so on so forth...
  - gumby 2y ago
    > Unlike in C, in C++ it is not possible to use an independent implementation of the standard library. It sure is, and is pretty easy to do. I know companies using EASTL, libcu++, and HPX, as well as more who use Folly and Abseil which have alternate implementations to much of the standard library. These days many languages have a single implementation so some people whose experience is only in those environment complain that C++ is “unnecessary complicated to use”. But a lot of that flexibility and back compatibility is what allows these multiple implementations to thrive while representing different points in the design/feature space.
    - Maxatar 2y ago
      None of those are implementations of the C++ standard library. None of them even live in the same namespace as the standard library so your claim that they remain compatible at the source level is nonsense. Just a simple Google search would reveal that you are wrong about this and what's worse is that you place the burden on me to have to disprove your wrong assertions as opposed to providing references that justify your position: Folly https://github.com/facebook/folly https://github.com/facebook/folly: "It complements (as opposed to competing against) offerings such as Boost and of course std. In fact, we embark on defining our own component only when something we need is either not available, or does not meet the needed performance profile." libcu++: https://nvidia.github.io/cccl/libcudacxx/ https://nvidia.github.io/cccl/libcudacxx/ "It does not replace the Standard Library provided by your host compiler (aka anything in std::) Incremental: It does not provide a complete C++ Standard Library implementation." Abseil: https://github.com/abseil/abseil-cpp https://github.com/abseil/abseil-cpp "Abseil is an open-source collection of C++ library code designed to augment the C++ standard library. Abseil is not meant to be a competitor to the standard library"
      - gumby 2y ago
        > Just a simple Google search would reveal that you are wrong about this and what's worse is that you place the burden on me to have to disprove your wrong assertions as opposed to providing references that justify your position: How rude. Have you used any of those libraries or perhaps relied on Google's "AI"-generated answer? > None of those are implementations of the C++ standard library. HPX, EASTL specifically are, the latter being heavily used in (unsurprisingly) the gaming comunity). libcu++ is for your target compilation. As for Folly and Abseil, I wrote "as well as more who use Folly and Abseil which have alternate implementations to much of the standard library" (i.e. not ful drop in replacements). So really I don't know what your point is: you made an assertion, then replied not to what I actually wrote but by simply doing a quick google search and using that as your conclusion. I have used all of HPX, Folly and Abseil but I guess the top of a google search result is more authoritative.
- forrestthewoods 2y ago
  Hard, hard disagree. If you want to support different implementation strategies it needs to be far more piecemeal. Not all or nothing. I mean there's only 3 meaningful implementation - libstdc++, libc++, and MSVC. And they aren't wholly interchangeable! Quite frankly if you value trying different implementation strategies then the C++ model is a complete and total failure. A successful model would have many, many different implementations of different components. The fact there are just 3 is an objective failure.
  - gumby 2y ago
    See my parallel reply: there are much more than just three, and all work with the three/four most dominant compilers these days as well as less dominant ones like EDG or Intel.
    - forrestthewoods 2y ago
      No, there are just 3 relevant standard implementations. There are numerous independent libraries that perform very similar but non-conformant functionality. My complaint is that the C++ standards committee should, when possible, release code and not a specification. They shouldn't release a std::map spec that 3 different vendors implement. The committee should write and release a single std::map implementation. It's just vanilla C++ after all. My proposal does not prohibit Abseil, Folly, etc from releasing their own version of map which may, and likely will, choose different constraints and trade-offs. Rust's standard library is not a spec, it's just code. There are many, many, many crates the implement the same APIs with different implementations and behavior. Sometimes those crates even get promoted and become the standard implementation. This is, imho, a far superior approach than the C++ specification approach.
      - gumby 2y ago
        > Rust's standard library is not a spec, it's just code. I consider this profound weakness, not a strength. Don’t get me wrong: I recognize the benefits in the short term! But really long lived languages like FORTRAN, Lisp, C++ have benefited hugely from a spec-based standards approach adopted from other engineering practice. They have also benefited from cross-fertilization from different implementations which influenced later standard and thus each other. This is why standards from building codes to electrical systems, to ships, manufacturing QC sampling, TCP/IP (and all the internet RFCs) and basically the entire corpus of ISO standards are spec based. If you want to build long-lived engineered systems it’s worth learning from people who figured out a lot of the metaprocesses the hard way, some of them for more than a century ago.
- jcelerier 2y ago
  > as well as taking different implementation strategies (e.g. the small string optimization is different in libc++ and libstdc++ As a user this is really not a good thing when the stdlib is tied to the platform. In the end the only sane thing to do if you want any reproducibility across operating systems is to exclusively use libc++ everywhere.
  - SleepyMyroslav 2y ago
    >In the end the only sane thing to do if you want any reproducibility across operating systems is to exclusively use ... no std library code in portable code. FTFY. Ofc there are no absolutes. In gamedev essential type info bits and intrinsics are either allowed back or wrapped. Algorithm library is another bit allowed for the most part ( no unstable sort and such ). I know your approach of 'one ring-libc++ to rule them all' is much more popular in community but gamedevs needed cross platform code for long time. It always had been working well regardless of the opinions.
    - gumby 2y ago
      > no std library code in portable code. FTFY. Just want to clarify what I think you meant: no std library code in portable binaries, something I agree with 100%. If you distribute in source, I believe almost always the opposite is true: relying on the standard library is probably a win. Not every time: some complex code bases have nonstandard requirements or can benefit from nonstandard code. Gaming is a good example of this.
      - SleepyMyroslav 2y ago
        I am not sure I understand. You declare a win with no explanations or reasons. What is so beneficial in having different implementation of same functionality? Why source being available makes difference? We can ignore cases of optimized per platform implementations because std was not made for that. None of platforms that make sense to support now were available back when current ABI was set in stone.
hoseja 2y ago
std::deque, a container with some quite useful theoretical properties, is completely unusable because the node size is not specifiable by the user and MSVC chose 16 bytes (I think, insanely small nonetheless).

gumby 2y ago

I consider the current tradeoff to be a feature. It permits implementations to take advantage of target-specific affordances (your thread case is an example) as well as taking different implementation strategies (e.g. the small string optimization is different in libc++ and libstdc++). Also you may use another, independent standard library because you prefer its implementation decisions. Meanwhile they remain compatible at the source level.

Maxatar 2y ago
Unlike in C, in C++ it is not possible to use an independent implementation of the standard library. Clang is compatible with GCC's standard library/libstdc++ and MSVC's standard library because the clang compiler explicitly supports them, but it's not possible to use clang's standard library with GCC in a standard conforming way or interchange GCC's with MSVC's standard library. There are some hacks that let you use some parts of libc++ with GCC by using the nostdlib flag, but this disables a lot of C++ functionality such as exception handling, RTTI, type traits. These features are in turn used by things like std::vector, std::map, etc... so you won't be able to use those classes either, and so on so forth...
- gumby 2y ago
  > Unlike in C, in C++ it is not possible to use an independent implementation of the standard library. It sure is, and is pretty easy to do. I know companies using EASTL, libcu++, and HPX, as well as more who use Folly and Abseil which have alternate implementations to much of the standard library. These days many languages have a single implementation so some people whose experience is only in those environment complain that C++ is “unnecessary complicated to use”. But a lot of that flexibility and back compatibility is what allows these multiple implementations to thrive while representing different points in the design/feature space.
  - Maxatar 2y ago
    None of those are implementations of the C++ standard library. None of them even live in the same namespace as the standard library so your claim that they remain compatible at the source level is nonsense. Just a simple Google search would reveal that you are wrong about this and what's worse is that you place the burden on me to have to disprove your wrong assertions as opposed to providing references that justify your position: Folly https://github.com/facebook/folly https://github.com/facebook/folly: "It complements (as opposed to competing against) offerings such as Boost and of course std. In fact, we embark on defining our own component only when something we need is either not available, or does not meet the needed performance profile." libcu++: https://nvidia.github.io/cccl/libcudacxx/ https://nvidia.github.io/cccl/libcudacxx/ "It does not replace the Standard Library provided by your host compiler (aka anything in std::) Incremental: It does not provide a complete C++ Standard Library implementation." Abseil: https://github.com/abseil/abseil-cpp https://github.com/abseil/abseil-cpp "Abseil is an open-source collection of C++ library code designed to augment the C++ standard library. Abseil is not meant to be a competitor to the standard library"
    - gumby 2y ago
      > Just a simple Google search would reveal that you are wrong about this and what's worse is that you place the burden on me to have to disprove your wrong assertions as opposed to providing references that justify your position: How rude. Have you used any of those libraries or perhaps relied on Google's "AI"-generated answer? > None of those are implementations of the C++ standard library. HPX, EASTL specifically are, the latter being heavily used in (unsurprisingly) the gaming comunity). libcu++ is for your target compilation. As for Folly and Abseil, I wrote "as well as more who use Folly and Abseil which have alternate implementations to much of the standard library" (i.e. not ful drop in replacements). So really I don't know what your point is: you made an assertion, then replied not to what I actually wrote but by simply doing a quick google search and using that as your conclusion. I have used all of HPX, Folly and Abseil but I guess the top of a google search result is more authoritative.
forrestthewoods 2y ago
Hard, hard disagree. If you want to support different implementation strategies it needs to be far more piecemeal. Not all or nothing. I mean there's only 3 meaningful implementation - libstdc++, libc++, and MSVC. And they aren't wholly interchangeable! Quite frankly if you value trying different implementation strategies then the C++ model is a complete and total failure. A successful model would have many, many different implementations of different components. The fact there are just 3 is an objective failure.
- gumby 2y ago
  See my parallel reply: there are much more than just three, and all work with the three/four most dominant compilers these days as well as less dominant ones like EDG or Intel.
  - forrestthewoods 2y ago
    No, there are just 3 relevant standard implementations. There are numerous independent libraries that perform very similar but non-conformant functionality. My complaint is that the C++ standards committee should, when possible, release code and not a specification. They shouldn't release a std::map spec that 3 different vendors implement. The committee should write and release a single std::map implementation. It's just vanilla C++ after all. My proposal does not prohibit Abseil, Folly, etc from releasing their own version of map which may, and likely will, choose different constraints and trade-offs. Rust's standard library is not a spec, it's just code. There are many, many, many crates the implement the same APIs with different implementations and behavior. Sometimes those crates even get promoted and become the standard implementation. This is, imho, a far superior approach than the C++ specification approach.
    - gumby 2y ago
      > Rust's standard library is not a spec, it's just code. I consider this profound weakness, not a strength. Don’t get me wrong: I recognize the benefits in the short term! But really long lived languages like FORTRAN, Lisp, C++ have benefited hugely from a spec-based standards approach adopted from other engineering practice. They have also benefited from cross-fertilization from different implementations which influenced later standard and thus each other. This is why standards from building codes to electrical systems, to ships, manufacturing QC sampling, TCP/IP (and all the internet RFCs) and basically the entire corpus of ISO standards are spec based. If you want to build long-lived engineered systems it’s worth learning from people who figured out a lot of the metaprocesses the hard way, some of them for more than a century ago.
jcelerier 2y ago
> as well as taking different implementation strategies (e.g. the small string optimization is different in libc++ and libstdc++ As a user this is really not a good thing when the stdlib is tied to the platform. In the end the only sane thing to do if you want any reproducibility across operating systems is to exclusively use libc++ everywhere.
- SleepyMyroslav 2y ago
  >In the end the only sane thing to do if you want any reproducibility across operating systems is to exclusively use ... no std library code in portable code. FTFY. Ofc there are no absolutes. In gamedev essential type info bits and intrinsics are either allowed back or wrapped. Algorithm library is another bit allowed for the most part ( no unstable sort and such ). I know your approach of 'one ring-libc++ to rule them all' is much more popular in community but gamedevs needed cross platform code for long time. It always had been working well regardless of the opinions.
  - gumby 2y ago
    > no std library code in portable code. FTFY. Just want to clarify what I think you meant: no std library code in portable binaries, something I agree with 100%. If you distribute in source, I believe almost always the opposite is true: relying on the standard library is probably a win. Not every time: some complex code bases have nonstandard requirements or can benefit from nonstandard code. Gaming is a good example of this.
    - SleepyMyroslav 2y ago
      I am not sure I understand. You declare a win with no explanations or reasons. What is so beneficial in having different implementation of same functionality? Why source being available makes difference? We can ignore cases of optimized per platform implementations because std was not made for that. None of platforms that make sense to support now were available back when current ABI was set in stone.

hoseja 2y ago

std::deque, a container with some quite useful theoretical properties, is completely unusable because the node size is not specifiable by the user and MSVC chose 16 bytes (I think, insanely small nonetheless).