<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 4/8/2015 14:34,
<a class="moz-txt-link-abbreviated" href="mailto:Jean-Michel.Perraud@csiro.au">Jean-Michel.Perraud@csiro.au</a> wrote:<br>
</div>
<blockquote
cite="mid:9657E5F32D0E5F4599B08172DA6CE8816485E8F0@exmbx02-cdc.nexus.csiro.au"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
<div style="direction: ltr;font-family: Tahoma;color:
#000000;font-size: 10pt;">I am actually currently aiming to use
an API deliberately in C, with opaque pointers, to avoid being
bound to one C++ compiler for all R packages (including on
Linux; for all I know the C++ name mangling scheme is compiler
specific irrespective of OSes and whether this is Microsoft's or
not).<br>
</div>
</blockquote>
Hi!<br>
<br>
Just a few small notes and pointers, perhaps some will be of use:<br>
<br>
(Some) level of application binary interface (ABI) compatibility
with gcc is among the stated goals of Clang:<br>
<a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/3217513/are-llvm-gcc-and-clang-binary-compatible-with-gcc-particularly-mingw-gcc-on-w">http://stackoverflow.com/questions/3217513/are-llvm-gcc-and-clang-binary-compatible-with-gcc-particularly-mingw-gcc-on-w</a><br>
// The incompatibility related to `std::string` mentioned in the
above is bound to go away in the upcoming GCC version; see "GCC 5
and the C++11 ABI":
<a class="moz-txt-link-freetext" href="http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/">http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/</a><br>
<br>
If you're on POSIX, then Itanium C++ ABI is also the de-facto
standard:<br>
<a class="moz-txt-link-freetext" href="https://mentorembedded.github.io/cxx-abi/abi.html">https://mentorembedded.github.io/cxx-abi/abi.html</a><br>
<br>
More on that:<br>
"This mangling scheme is used in Gnu C++ version 3.x.x and later
under several operating<br>
systems (Linux, BSD, Mac OS X IE32, Windows) and on several
platforms. It is described in<br>
"Itanium C++ ABI". The same scheme is used by Intel compilers for
Linux and Mac OS.<br>
Different variants are available for the Gnu compiler version 4.x.x
[...]"<br>
Source: <a class="moz-txt-link-freetext" href="http://www.agner.org/optimize/calling_conventions.pdf">http://www.agner.org/optimize/calling_conventions.pdf</a><br>
<br>
In particular, Clang makes a point of maintaining mangling
compatibility with GCC:<br>
<a class="moz-txt-link-freetext" href="http://clang.llvm.org/doxygen/ItaniumMangle_8cpp_source.html">http://clang.llvm.org/doxygen/ItaniumMangle_8cpp_source.html</a><br>
<br>
Now, all that being said, MSVC adheres to Microsoft ABI.<br>
"This complicates matters" (to put it mildly)...<br>
Unfortunately, this goes far beyond name mangling:<br>
"If name mangling was standardized, could I link code compiled with
compilers from different compiler vendors? Short answer: Probably
not."<br>
Why? <a class="moz-txt-link-freetext" href="https://isocpp.org/wiki/faq/compiler-dependencies#binary-compat">https://isocpp.org/wiki/faq/compiler-dependencies#binary-compat</a><br>
<br>
So, a compiled (binary) library made by MSVC, exposing a function
returning, say, an `std::string`, will almost surely fail to work
with client code built with GCC.<br>
In fact, MSVC reserves the right to break binary compatibility with
previous MSVC versions (on major versions updates).<br>
Incidentally, this is not unusual, and quite like GCC 5 breaking
binary compatibility with GCC 4 (with `std::string` being exactly
one of the differences).<br>
// Not sure what are the implications for binary shared libraries
used from R at this point (if any).<br>
<br>
Thus, as you've mentioned, some interface constraining may be
unavoidable.<br>
This is similar to the issues one encounters when exposing C++
libraries to C client code -- so some of the practices may be
applicable, too: <a class="moz-txt-link-freetext" href="https://isocpp.org/wiki/faq/mixing-c-and-cpp">https://isocpp.org/wiki/faq/mixing-c-and-cpp</a><br>
<br>
Dirk has asked for a tutorial "a blog post or tutorial about how to
constrain a code base to use only C in the interface".<br>
In this context, there are two resources that come to mind that
perhaps may be of some help here -- possibly at least as useful
starting points: "Hourglass Interfaces for C++ APIs" and "Beautiful
Native Libraries".<br>
<br>
Stefanus DuToit's "Hourglass Interfaces for C++ APIs" CppCon 2014
presentation covers the set of best practices for dealing with the
cross-platform ABI issues when exposing your libraries to the
outside world:<br>
Video: <a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=PVYdHDm0q6Y">https://www.youtube.com/watch?v=PVYdHDm0q6Y</a><br>
Slides:
<a class="moz-txt-link-freetext" href="http://www.slideshare.net/StefanusDuToit/cpp-con-2014-hourglass-interfaces-for-c-apis">http://www.slideshare.net/StefanusDuToit/cpp-con-2014-hourglass-interfaces-for-c-apis</a><br>
Code:
<a class="moz-txt-link-freetext" href="https://github.com/CppCon/CppCon2014/tree/master/Presentations/Hourglass">https://github.com/CppCon/CppCon2014/tree/master/Presentations/Hourglass</a>
Interfaces for C%2B%2B APIs<br>
Discussion:
<a class="moz-txt-link-freetext" href="https://www.reddit.com/r/cpp/comments/2mx1mm/hourglass_interfaces_for_c_apis/">https://www.reddit.com/r/cpp/comments/2mx1mm/hourglass_interfaces_for_c_apis/</a><br>
<br>
Armin Ronacher's "Beautiful Native Libraries" post (illustrated with
examples of writing a C++ library to be used from Python -- but
generally applicable to writing C++ libraries to be used from other
languages, too) also offers some useful advice on the best practices
and things to watch out for:<br>
<a class="moz-txt-link-freetext" href="http://lucumr.pocoo.org/2013/8/18/beautiful-native-libraries/">http://lucumr.pocoo.org/2013/8/18/beautiful-native-libraries/</a><br>
Discussion: <a class="moz-txt-link-freetext" href="https://news.ycombinator.com/item?id=6235671">https://news.ycombinator.com/item?id=6235671</a><br>
<br>
Other than that, libabigail -- <a class="moz-txt-link-freetext" href="https://sourceware.org/libabigail/">https://sourceware.org/libabigail/</a> --
may also come in handy:<br>
<a class="moz-txt-link-freetext" href="http://developerblog.redhat.com/2014/10/23/comparing-abis-for-compatibility-with-libabigail-part-1/">http://developerblog.redhat.com/2014/10/23/comparing-abis-for-compatibility-with-libabigail-part-1/</a><br>
<a class="moz-txt-link-freetext" href="http://developerblog.redhat.com/2014/10/28/comparing-abis-for-compatibility-libabigail-part-2/">http://developerblog.redhat.com/2014/10/28/comparing-abis-for-compatibility-libabigail-part-2/</a><br>
<br>
More forward-looking, but also offering a brief overview of the
existing issues and more pointers/references, is a proposal for the
C++ ABI standardization:<br>
<a class="moz-txt-link-freetext" href="http://isocpp.org/blog/2014/05/n4028">http://isocpp.org/blog/2014/05/n4028</a><br>
(PDF) <a class="moz-txt-link-freetext" href="https://isocpp.org/files/papers/n4028.pdf">https://isocpp.org/files/papers/n4028.pdf</a><br>
<br>
HTH!<br>
<br>
Best,<br>
<br>
Matt<br>
<br>
</body>
</html>