5 ms·

So it's not the modern C++ features that cause the yak-shaving, but wanting to use these features on a RHEL6 instance with a compiler that does not support thes

by bipson 9y ago

So it's not the modern C++ features that cause the yak-shaving, but wanting to use these features on a RHEL6 instance with a compiler that does not support these modern features. I'm specifically stating this (obvious observation), because the headline might lead someone to believe that the features are at fault. The features are great and should considerably reduce yak shaving. Going a step further, we've all been there. I once spent weeks building STLPort and boost, so I could avoid re-writing and extending an existing project against a C++ compiler from 2006, and more importantly, the WinCE 6.0 API (with weird timers and everything - ugh), and use a kind-of portable, recent version of C++, with extended features. I deeply questioned every single professional decision I had made the prior years. This had nothing to do with yak-shaving, but with how much platform-specific code you would end up prior to C++11, and how much simple, every-day functionality you had to write again and again. C++11 and later are a huge leap in this regard IMO, and for everyone stuck with an old compiler: Consider using boost.

fndrplayer13 9y ago
I think this is a great summary. C++11 is a huge leap forward if you can start fresh and/or only target C++11 compatible systems. Personally, I've also been down the road of trying to get older systems (also RHEL6) to run C++11 code via a hand-built compiler and it was an exercise in absolute frustration. And yes, Boost was the answer to some of this. Another thing you can try if you're in a well-abstracted code-base is to write wrappers around some of this functionality. Eg, if C++11 or greater is available, use the STL functionality, else use Boost and/or whatever legacy thing we hand-built. The obviously crappy part of this is that your functionality can/will diverge on multiple platforms.
eXpl0it3r 9y ago
It's a real click-bait title. Using incompatible versions of anything will sooner than later cause issues. It's not related to C++ or C++ features at all, it's simply that in this case the version of the compiler supporting newer C++ features, wasn't compatible with the rest of the system. However, ABI incompatibility is a real pain in C++ and one of the main reasons why I don't judge anyone building C libraries instead. While RHEL6 is just one example, you'll run into this issue all the time when developing on Windows. Here, either your C++ compiled libraries match 100% with the compiler used for to compile your application or it will simply not work. In 99.99% of the time you get a symbol issue with std::string you can be certain it's runtime library issue/compiler incompatibility.
- majewsky 9y ago
  > It's not related to C++ or C++ features at all, it's simply that in this case the version of the compiler supporting newer C++ features, wasn't compatible with the rest of the system. But it is related to C++. When Go releases an update, I can grab the new compiler and just compile my stuff and the resulting binaries have very little dependency on the runtime (I may need to use the right libc or libssl version, but that's a job for Docker). "But that's only because Go bakes the runtime into the binary!" - Exactly. - "Okay, that may make stuff easier, but it has huge disadvantages!" - I'm aware. The point is that the "system yak shaving" (as the submission calls it) is very much related to C++ and its features and how C++ compilers implement these.
  - eXpl0it3r 9y ago
    You can just as easily link the runtime libs statically, it's even mentioned in the article, but since not everyone does that (for reasons), you might still run into issues, when linking to other applications. "not related" might have been some bad wording, but the point is that it's not an issue of the C++ language or any C++ features, but it's because of how the tooling and libraries for C++ have been invented. (And because there's no standard ABI.)
    - jgh 9y ago
      Even if you do link statically you can still run into issues like the std::string one you mentioned earlier. For example WebRTC builds itself with Clang and on Linux, at least as of last year, and I was having trouble with libc++ on Linux (stupidly I neglected to write down what the issue I was running into was, just that there was an issue) so I wasn't able to use Clang to build my project. As you can imagine that results in some fun because std::string and std::__cxx11::basic_string are two different things.
      - gpderetta 9y ago
        clang, modulo bugs, is fully C++ ABI compatible with GCC (they both follow the intervendor Itanium ABI) on unix systems. Make sure you use the same standard library for all components because libstdc++ and libc++ are different implementations with completely different object layouts. Usually libstdc++ is the system standard library implementation on most Linux flavours (i.e. it is part of the OS ABI), so unless you have specific requirements, go with that (specifically, it should work fine with clang). libstdc++ ABI changed between C++03 and C++11 (that's probably the issue you are having with the string), but even in C++11 mode it is possible to use the old ABI (it is a compile time parameter), if you are willing to put up with the old reference counted strings, O(N) std::list::size and other minor things. If you can it is better to move the the new libstdc++ ABI of course, because the old one might not be maintained forever (it has been unchanged since GCC 3.6, though). Windows is a pain because while the compiler ABI itself hasn't changed in a very long time (although undocumented I believe it has been fully reversed engineered), VC++ doesn't promise a stable library ABI and in fact it has breaking changes every major release.
tlb 9y ago
You get the same problem on current systems if you try to use C++17 features. For instance, template arg deduction only works on Clang 5, but most Ubuntu 16 systems have Clang 3.8.
ziotom78 9y ago
> Consider using Boost Atlas, would it be that simple. A few years ago I was in a similar situation to the one described here, and I tried to switch to Boost. Things went bad piety soon, as this old post of mine described: http://ziotom78.blogspot.it/2014/07/c11.html http://ziotom78.blogspot.it/2014/07/c11.html

by bipson 9y ago

fndrplayer13 9y ago

I think this is a great summary. C++11 is a huge leap forward if you can start fresh and/or only target C++11 compatible systems. Personally, I've also been down the road of trying to get older systems (also RHEL6) to run C++11 code via a hand-built compiler and it was an exercise in absolute frustration. And yes, Boost was the answer to some of this. Another thing you can try if you're in a well-abstracted code-base is to write wrappers around some of this functionality. Eg, if C++11 or greater is available, use the STL functionality, else use Boost and/or whatever legacy thing we hand-built. The obviously crappy part of this is that your functionality can/will diverge on multiple platforms.

eXpl0it3r 9y ago

It's a real click-bait title. Using incompatible versions of anything will sooner than later cause issues. It's not related to C++ or C++ features at all, it's simply that in this case the version of the compiler supporting newer C++ features, wasn't compatible with the rest of the system. However, ABI incompatibility is a real pain in C++ and one of the main reasons why I don't judge anyone building C libraries instead. While RHEL6 is just one example, you'll run into this issue all the time when developing on Windows. Here, either your C++ compiled libraries match 100% with the compiler used for to compile your application or it will simply not work. In 99.99% of the time you get a symbol issue with std::string you can be certain it's runtime library issue/compiler incompatibility.

majewsky 9y ago
> It's not related to C++ or C++ features at all, it's simply that in this case the version of the compiler supporting newer C++ features, wasn't compatible with the rest of the system. But it is related to C++. When Go releases an update, I can grab the new compiler and just compile my stuff and the resulting binaries have very little dependency on the runtime (I may need to use the right libc or libssl version, but that's a job for Docker). "But that's only because Go bakes the runtime into the binary!" - Exactly. - "Okay, that may make stuff easier, but it has huge disadvantages!" - I'm aware. The point is that the "system yak shaving" (as the submission calls it) is very much related to C++ and its features and how C++ compilers implement these.
- eXpl0it3r 9y ago
  You can just as easily link the runtime libs statically, it's even mentioned in the article, but since not everyone does that (for reasons), you might still run into issues, when linking to other applications. "not related" might have been some bad wording, but the point is that it's not an issue of the C++ language or any C++ features, but it's because of how the tooling and libraries for C++ have been invented. (And because there's no standard ABI.)
  - jgh 9y ago
    Even if you do link statically you can still run into issues like the std::string one you mentioned earlier. For example WebRTC builds itself with Clang and on Linux, at least as of last year, and I was having trouble with libc++ on Linux (stupidly I neglected to write down what the issue I was running into was, just that there was an issue) so I wasn't able to use Clang to build my project. As you can imagine that results in some fun because std::string and std::__cxx11::basic_string are two different things.
    - gpderetta 9y ago
      clang, modulo bugs, is fully C++ ABI compatible with GCC (they both follow the intervendor Itanium ABI) on unix systems. Make sure you use the same standard library for all components because libstdc++ and libc++ are different implementations with completely different object layouts. Usually libstdc++ is the system standard library implementation on most Linux flavours (i.e. it is part of the OS ABI), so unless you have specific requirements, go with that (specifically, it should work fine with clang). libstdc++ ABI changed between C++03 and C++11 (that's probably the issue you are having with the string), but even in C++11 mode it is possible to use the old ABI (it is a compile time parameter), if you are willing to put up with the old reference counted strings, O(N) std::list::size and other minor things. If you can it is better to move the the new libstdc++ ABI of course, because the old one might not be maintained forever (it has been unchanged since GCC 3.6, though). Windows is a pain because while the compiler ABI itself hasn't changed in a very long time (although undocumented I believe it has been fully reversed engineered), VC++ doesn't promise a stable library ABI and in fact it has breaking changes every major release.

tlb 9y ago

You get the same problem on current systems if you try to use C++17 features. For instance, template arg deduction only works on Clang 5, but most Ubuntu 16 systems have Clang 3.8.

ziotom78 9y ago

> Consider using Boost Atlas, would it be that simple. A few years ago I was in a similar situation to the one described here, and I tried to switch to Boost. Things went bad piety soon, as this old post of mine described: http://ziotom78.blogspot.it/2014/07/c11.html http://ziotom78.blogspot.it/2014/07/c11.html