4 ms·

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

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.
      - Fronzie 9y ago
        Microsoft is working towards binary compatiblity: 2015 and 2017 have (some) compatibility: https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017 https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2...
lkrubner 9y ago
It isn't clickbait because it is such a common situation. I would say in the majority of cases when I try to use the bleeding edge of any one technology, I end up dealing with a nightmare of version conflicts with the remaining technology that's relevant to the system I'm working on. I think articles like this are worth reading, because they illuminate a specific case of a very widespread condition that we all face as software developers.
- hermitdev 9y ago
  I agree. Until recently, at work, I was targeting 3 different versions of gcc (Ubuntu 16, 14 & 12 so I think gcc 4.4-5.4). It's not just an issue of what language & library features they support, it's also an issue of which compiler flags to use. Is it --std=c++0x, --std=c++1y, something else? Toss in there, I also have to compile a subset of libraries for Windows. Even when you use frameworks to isolate yourself from OS nuances, you may still have compatibility issues. Like, using the ACE library. What does the function you pass to ACE_Thread to spawn return? On posix systems, it returns void*. So, if you want to suppress compiler warnings (-Wzero-as-null-pointer-constant), you return nullptr. Oops, now your code breaks on Windows, because ACE_THR_FUNC_RETURN there is a DWORD, and no conversion from nullptr to DWORD. On yet other systems, it returns int. So, how do you have your warning free code on all the systems? Ugh: preprocessor.
  - gpderetta 9y ago
    it is 2018, just use std::thread. ACE belongs to the 90s.
    - hermitdev 9y ago
      I agree, and we're working towards that, but you know: legacy code.
      - gpderetta 9y ago
        Full disclosure, the code base I'm currently working on is in the same situation...
johndubchak 9y ago
I believe the first thing a developer should do, when wanting to use the new features of modern C++, is download a stable (current) release (in source format) of either Clang or GCC, compile and install it and proceed from there. Then you can usually get around all of the incompatibilities.
pjmlp 9y ago
I remember the days of OSes not written in C, where the C ABI wasn't the same as the OS ABI, with each compiler having their own view. Even old proprietary UNIX compilers had their own set of compatibility issues.

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.
    - Fronzie 9y ago
      Microsoft is working towards binary compatiblity: 2015 and 2017 have (some) compatibility: https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017 https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2...

lkrubner 9y ago

It isn't clickbait because it is such a common situation. I would say in the majority of cases when I try to use the bleeding edge of any one technology, I end up dealing with a nightmare of version conflicts with the remaining technology that's relevant to the system I'm working on. I think articles like this are worth reading, because they illuminate a specific case of a very widespread condition that we all face as software developers.

hermitdev 9y ago
I agree. Until recently, at work, I was targeting 3 different versions of gcc (Ubuntu 16, 14 & 12 so I think gcc 4.4-5.4). It's not just an issue of what language & library features they support, it's also an issue of which compiler flags to use. Is it --std=c++0x, --std=c++1y, something else? Toss in there, I also have to compile a subset of libraries for Windows. Even when you use frameworks to isolate yourself from OS nuances, you may still have compatibility issues. Like, using the ACE library. What does the function you pass to ACE_Thread to spawn return? On posix systems, it returns void*. So, if you want to suppress compiler warnings (-Wzero-as-null-pointer-constant), you return nullptr. Oops, now your code breaks on Windows, because ACE_THR_FUNC_RETURN there is a DWORD, and no conversion from nullptr to DWORD. On yet other systems, it returns int. So, how do you have your warning free code on all the systems? Ugh: preprocessor.
- gpderetta 9y ago
  it is 2018, just use std::thread. ACE belongs to the 90s.
  - hermitdev 9y ago
    I agree, and we're working towards that, but you know: legacy code.
    - gpderetta 9y ago
      Full disclosure, the code base I'm currently working on is in the same situation...

johndubchak 9y ago

I believe the first thing a developer should do, when wanting to use the new features of modern C++, is download a stable (current) release (in source format) of either Clang or GCC, compile and install it and proceed from there. Then you can usually get around all of the incompatibilities.

pjmlp 9y ago

I remember the days of OSes not written in C, where the C ABI wasn't the same as the OS ABI, with each compiler having their own view. Even old proprietary UNIX compilers had their own set of compatibility issues.