3 ms·

passing a heap allocated thing from one c++ dll to another doesn't work. it's far better to define a C interface between binaries of any language and reintrodu

passing a heap allocated thing from one c++ dll to another doesn't work. it's far better to define a C interface between binaries of any language and reintroduce language specific semantics in a light client library

ncmncm 6y ago
You must be talking about Microsoft stuff not applicable here.
- mkoubaa 6y ago
  Not true. GCC broke compatibility with the memory layout of are string at c++11 and passing those between DLLs with versions of GCC on either side of that change will crash. The standard doesn't specify memory layout or ABI so as a general rule you can't do this. You can get around it by depending on implementation details like what is implicitly done by chromium
  - ncmncm 6y ago
    Now you are changing the subject. Allocation, which was the subject, happens the same way on either side of gcc's C++11 boundary. The C++11 break was required by the ISO Standard issued in 2011. The Gcc and libstdc++ maintainers are extremely careful to maintain ABI compatibility between widely-separated releases, where permitted by the Standard. You can happily call between code compiled with gcc-6 and gcc-10, release or debug, optimized or not. It is possible to deliberately vary ABI with compiler options, but nobody uses those for shared libraries they distribute, for obvious reasons, with the unique exception of choosing pre-C++11 vs post-C++11 ABI.
    - mkoubaa 6y ago
      I guess you're right. I still am wary about depending on this given the current conversation about ABI evolution with C++. And given that lots of languages can interop with C I think building C interfaces between binaries buys options
jcelerier 6y ago
> passing a heap allocated thing from one c++ dll to another doesn't work. this is chromium, everything is built from source with the same compiler, there is zero issue with doing that. This only does not work when using a DLL built with, say, visual studio 2008 and another built with 2015.
- mkoubaa 6y ago
  Actually a DLL built with the same version but with either a different c runtime library (e.g. MD or MT) or a different target (release or debug) will have this problem

ncmncm 6y ago

You must be talking about Microsoft stuff not applicable here.

mkoubaa 6y ago
Not true. GCC broke compatibility with the memory layout of are string at c++11 and passing those between DLLs with versions of GCC on either side of that change will crash. The standard doesn't specify memory layout or ABI so as a general rule you can't do this. You can get around it by depending on implementation details like what is implicitly done by chromium
- ncmncm 6y ago
  Now you are changing the subject. Allocation, which was the subject, happens the same way on either side of gcc's C++11 boundary. The C++11 break was required by the ISO Standard issued in 2011. The Gcc and libstdc++ maintainers are extremely careful to maintain ABI compatibility between widely-separated releases, where permitted by the Standard. You can happily call between code compiled with gcc-6 and gcc-10, release or debug, optimized or not. It is possible to deliberately vary ABI with compiler options, but nobody uses those for shared libraries they distribute, for obvious reasons, with the unique exception of choosing pre-C++11 vs post-C++11 ABI.
  - mkoubaa 6y ago
    I guess you're right. I still am wary about depending on this given the current conversation about ABI evolution with C++. And given that lots of languages can interop with C I think building C interfaces between binaries buys options

jcelerier 6y ago

> passing a heap allocated thing from one c++ dll to another doesn't work. this is chromium, everything is built from source with the same compiler, there is zero issue with doing that. This only does not work when using a DLL built with, say, visual studio 2008 and another built with 2015.

mkoubaa 6y ago
Actually a DLL built with the same version but with either a different c runtime library (e.g. MD or MT) or a different target (release or debug) will have this problem