9 ms·

> Except for inlineable functions and templates in C++—which become a greater and greater fraction of code the more "modern" your C++ gets. The C++ ABI is curr

> Except for inlineable functions and templates in C++—which become a greater and greater fraction of code the more "modern" your C++ gets. The C++ ABI is currently not portable anyway. So the concern about templates (or any C++ features) forcing you to put the implementation into the header file would not apply in the scenario dllthomas was referring to: If you want to distribute your library as a binary object and a separate source-form interface/header today, you'll have to use a (wrapper) C API. Regardless of how "modern" the C++ code is. Of course, it would be nice to have portable C++ objects some time in the future which would change things... :)

jjnoakes 10y ago
> If you want to distribute your library as a binary object and a separate source-form interface/header today, you'll have to use a (wrapper) C API. This is only true if you want to target different compilers. If you ship your binaries targeting a specific compiler (which is what just about every company does that I've ever worked with), you don't have any abi issues.
- paulasmuth 10y ago
  Actually, you can even have incompatibilities with the same compiler and different compile flags. So to reliably build a "semi-portable" c++ object one would have to ensure that all objects are compiled with the exact same (i.e. same version of the compiler/same compiler source code) and with the exact same flags. I'm sure there are some compiler vendors that offer ABI backwards-compatibility but it's not part of the C++ language per-se. See this article by Herb Sutter on the topic: https://isocpp.org/files/papers/n4028.pdf https://isocpp.org/files/papers/n4028.pdf
  - jjnoakes 10y ago
    Oh I'm well aware; as my comment indicated, I've been doing this a long time. I didn't want to get in to the full details in a HN comment, but yes, there's definitely a few things you have to coordinate on between vendors if you want to ship C++ libraries that work together.
pjmlp 10y ago
> If you want to distribute your library as a binary object and a separate source-form interface/header today, you'll have to use a (wrapper) C API. Regardless of how "modern" the C++ code is. Not really. Those of us on Windows make use of COM, or since Windows 8, UWP components (formally known as WinRT).
- paulasmuth 10y ago
  Yes, but this is only a solution if your library is only targeting windows. If you want users of any standards-compliant C++ implementation to be able to use your library today, you'll still have to go with c-abi symbols or ship the sources. All other worakrounds are vendor-specific and not part of the standard. [Of course even objects containing only C symbols are not portable across platforms either, but at least the C ABI/calling convention is more or less strictly defined for any given target platform. Assuming no other platform-specific stuff like glibc is used]

jjnoakes 10y ago

> If you want to distribute your library as a binary object and a separate source-form interface/header today, you'll have to use a (wrapper) C API. This is only true if you want to target different compilers. If you ship your binaries targeting a specific compiler (which is what just about every company does that I've ever worked with), you don't have any abi issues.

paulasmuth 10y ago
Actually, you can even have incompatibilities with the same compiler and different compile flags. So to reliably build a "semi-portable" c++ object one would have to ensure that all objects are compiled with the exact same (i.e. same version of the compiler/same compiler source code) and with the exact same flags. I'm sure there are some compiler vendors that offer ABI backwards-compatibility but it's not part of the C++ language per-se. See this article by Herb Sutter on the topic: https://isocpp.org/files/papers/n4028.pdf https://isocpp.org/files/papers/n4028.pdf
- jjnoakes 10y ago
  Oh I'm well aware; as my comment indicated, I've been doing this a long time. I didn't want to get in to the full details in a HN comment, but yes, there's definitely a few things you have to coordinate on between vendors if you want to ship C++ libraries that work together.

pjmlp 10y ago

> If you want to distribute your library as a binary object and a separate source-form interface/header today, you'll have to use a (wrapper) C API. Regardless of how "modern" the C++ code is. Not really. Those of us on Windows make use of COM, or since Windows 8, UWP components (formally known as WinRT).

paulasmuth 10y ago
Yes, but this is only a solution if your library is only targeting windows. If you want users of any standards-compliant C++ implementation to be able to use your library today, you'll still have to go with c-abi symbols or ship the sources. All other worakrounds are vendor-specific and not part of the standard. [Of course even objects containing only C symbols are not portable across platforms either, but at least the C ABI/calling convention is more or less strictly defined for any given target platform. Assuming no other platform-specific stuff like glibc is used]