8 ms·

This is the only sane way of using C++. All C++ dependencies in the same repo, because there is no standard C++ ABI. I am compiling my C++ codebase with gcc, c

This is the only sane way of using C++. All C++ dependencies in the same repo, because there is no standard C++ ABI. I am compiling my C++ codebase with gcc, clang, emscripten to wasm, visual studio. Impossible if all dependencies are not present in a "third-party" folder. Google's Abseil library is intended to be used this way. Otherwise, use the C ABI between dependencies.

gpderetta 7y ago
> standard C++ ABI. All major OS have a standard, very stable C++ ABI. Some of them also guarantee a stable ABI for the library components. Of course you cannot use a library built for, say, Windows on Linux but that's true for all languages.
- jdsully 7y ago
  For windows that is a very recent change. The ABI used to change with every compiler rev. Further without buyin from the actual standard there’s no gurantee a breaking change won’t be forced by the standard at some point.
  - pjmlp 7y ago
    Not for libraries exposed as DLL or COM. Although one might argue that is only a C++ subset.
    - jdsully 7y ago
      COM is based off of the C ABI not C++. This was done specifically because C++ does not have a stable ABI.
      - pjmlp 7y ago
        There is no such thing as C ABI, rather Windows ABI, which you can even select several calling conventions, including Pascal based one. COM is based on the way Visual C++ lays out the VMT, and only masochists use it from bare bones C.
        int_19h 7y ago
        C ABI is basically structs + functions + function pointers. On Win32, functions and function pointers includes calling conventions, but that's not really important. COM is a C ABI in a sense that its spec defines everything in these terms. Yes, in practice it translates nicely to C++ vtables, but the stability guarantees are defined on the lower level.
        pjmlp 7y ago
        From that point of view, it is also a Pascal ABI.
        int_19h 7y ago
        Sure, and several dozen other languages. That's really what it is - the lowest common denominator that almost every language can work with.
        pjmlp 7y ago
        As the OS ABI should be.
        int_19h 7y ago
        This is a kind of a chicken and egg thing - it is the OS ABI because everybody supports it, and everybody supports it because it's the OS ABI. I think that the fact that it has the features that it does is mostly a coincidence of timing, and languages popular at the time on platforms that were popular enough. If it happened 15 years later, the feature set might have been larger.
  - userbinator 7y ago
    The ABI used to change with every compiler rev. That's only because they changed the standard library. The ABI itself didn't change much if at all, I believe you can still get the latest compiler to link with the far more compatible MSVCRT.DLL that's been there since the first Win32 OS (Win95).
    - jdsully 7y ago
      I guess it matters whether you consider name mangling to be a part of the ABI. Name mangling used to change quite frequently. Starting with VS 2015 Microsoft promised to make these changes much less frequent but AFAIK didn't promise to never make changes here. MSVCRT.DLL has kept stability but Microsoft makes no official promises about it. It's considered undocumented. Source: https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2019 https://docs.microsoft.com/en-us/cpp/build/reference/decorat...
      - userbinator 7y ago
        MSVCRT.DLL has kept stability but Microsoft makes no official promises about it. That's because it doesn't need to be said. Countless numbers of existing applications would break if it changed, and MS still cares enough about backward compatibility and knows that many huge and important customers depend on them to not do that.
        deleted 7y ago
        [deleted]
        jdsully 7y ago
        This is really moot since MSVCRT is a C runtime lib with MSVCPRT being the the C++ one. Again no stability guarantees are made with any of this. Microsoft promises backward compatibility but not forward compatibility. There is no promise you can link new code with old DLLs. Just that older binaries will still execute unmodified. Very recently with VS2015 they promised "some" forward compatibility and to make fewer changes. In practice there were things you could do to increase the chances of this working. But to call this "stable" would render the term meaningless.
- johannes1234321 7y ago
  Assuming all things use the same rtti and exception settings and all are using same C++ standard library (libstdc++ vs libc++) And then there are other flags - for instance when gcc/libstdc++ broke std::string in order to switch from a recounted string to a non-refcounted with small string optimisation in order to be C+11 compatible ... Sure, there are system defaults, but things vary and often recompiling everything and statically linking avoids those issues.

gpderetta 7y ago

> standard C++ ABI. All major OS have a standard, very stable C++ ABI. Some of them also guarantee a stable ABI for the library components. Of course you cannot use a library built for, say, Windows on Linux but that's true for all languages.

jdsully 7y ago
For windows that is a very recent change. The ABI used to change with every compiler rev. Further without buyin from the actual standard there’s no gurantee a breaking change won’t be forced by the standard at some point.
- pjmlp 7y ago
  Not for libraries exposed as DLL or COM. Although one might argue that is only a C++ subset.
  - jdsully 7y ago
    COM is based off of the C ABI not C++. This was done specifically because C++ does not have a stable ABI.
    - pjmlp 7y ago
      There is no such thing as C ABI, rather Windows ABI, which you can even select several calling conventions, including Pascal based one. COM is based on the way Visual C++ lays out the VMT, and only masochists use it from bare bones C.
      - int_19h 7y ago
        C ABI is basically structs + functions + function pointers. On Win32, functions and function pointers includes calling conventions, but that's not really important. COM is a C ABI in a sense that its spec defines everything in these terms. Yes, in practice it translates nicely to C++ vtables, but the stability guarantees are defined on the lower level.
        pjmlp 7y ago
        From that point of view, it is also a Pascal ABI.
        int_19h 7y ago
        Sure, and several dozen other languages. That's really what it is - the lowest common denominator that almost every language can work with.
        pjmlp 7y ago
        As the OS ABI should be.
        int_19h 7y ago
        This is a kind of a chicken and egg thing - it is the OS ABI because everybody supports it, and everybody supports it because it's the OS ABI. I think that the fact that it has the features that it does is mostly a coincidence of timing, and languages popular at the time on platforms that were popular enough. If it happened 15 years later, the feature set might have been larger.
- userbinator 7y ago
  The ABI used to change with every compiler rev. That's only because they changed the standard library. The ABI itself didn't change much if at all, I believe you can still get the latest compiler to link with the far more compatible MSVCRT.DLL that's been there since the first Win32 OS (Win95).
  - jdsully 7y ago
    I guess it matters whether you consider name mangling to be a part of the ABI. Name mangling used to change quite frequently. Starting with VS 2015 Microsoft promised to make these changes much less frequent but AFAIK didn't promise to never make changes here. MSVCRT.DLL has kept stability but Microsoft makes no official promises about it. It's considered undocumented. Source: https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2019 https://docs.microsoft.com/en-us/cpp/build/reference/decorat...
    - userbinator 7y ago
      MSVCRT.DLL has kept stability but Microsoft makes no official promises about it. That's because it doesn't need to be said. Countless numbers of existing applications would break if it changed, and MS still cares enough about backward compatibility and knows that many huge and important customers depend on them to not do that.
      - deleted 7y ago
        [deleted]
      - jdsully 7y ago
        This is really moot since MSVCRT is a C runtime lib with MSVCPRT being the the C++ one. Again no stability guarantees are made with any of this. Microsoft promises backward compatibility but not forward compatibility. There is no promise you can link new code with old DLLs. Just that older binaries will still execute unmodified. Very recently with VS2015 they promised "some" forward compatibility and to make fewer changes. In practice there were things you could do to increase the chances of this working. But to call this "stable" would render the term meaningless.
johannes1234321 7y ago
Assuming all things use the same rtti and exception settings and all are using same C++ standard library (libstdc++ vs libc++) And then there are other flags - for instance when gcc/libstdc++ broke std::string in order to switch from a recounted string to a non-refcounted with small string optimisation in order to be C+11 compatible ... Sure, there are system defaults, but things vary and often recompiling everything and statically linking avoids those issues.