On 4/8/2015 14:34, jean-michel.perr...@csiro.au wrote:
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).
Hi!
Just a few small notes and pointers, perhaps some will be of use:
(Some) level of application binary interface (ABI) compatibility with
gcc is among the stated goals of Clang:
http://stackoverflow.com/questions/3217513/are-llvm-gcc-and-clang-binary-compatible-with-gcc-particularly-mingw-gcc-on-w
// 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": http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/
If you're on POSIX, then Itanium C++ ABI is also the de-facto standard:
https://mentorembedded.github.io/cxx-abi/abi.html
More on that:
"This mangling scheme is used in Gnu C++ version 3.x.x and later under
several operating
systems (Linux, BSD, Mac OS X IE32, Windows) and on several platforms.
It is described in
"Itanium C++ ABI". The same scheme is used by Intel compilers for Linux
and Mac OS.
Different variants are available for the Gnu compiler version 4.x.x [...]"
Source: http://www.agner.org/optimize/calling_conventions.pdf
In particular, Clang makes a point of maintaining mangling compatibility
with GCC:
http://clang.llvm.org/doxygen/ItaniumMangle_8cpp_source.html
Now, all that being said, MSVC adheres to Microsoft ABI.
"This complicates matters" (to put it mildly)...
Unfortunately, this goes far beyond name mangling:
"If name mangling was standardized, could I link code compiled with
compilers from different compiler vendors? Short answer: Probably not."
Why? https://isocpp.org/wiki/faq/compiler-dependencies#binary-compat
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.
In fact, MSVC reserves the right to break binary compatibility with
previous MSVC versions (on major versions updates).
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).
// Not sure what are the implications for binary shared libraries used
from R at this point (if any).
Thus, as you've mentioned, some interface constraining may be unavoidable.
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:
https://isocpp.org/wiki/faq/mixing-c-and-cpp
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".
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".
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:
Video: https://www.youtube.com/watch?v=PVYdHDm0q6Y
Slides:
http://www.slideshare.net/StefanusDuToit/cpp-con-2014-hourglass-interfaces-for-c-apis
Code:
https://github.com/CppCon/CppCon2014/tree/master/Presentations/Hourglass
Interfaces for C%2B%2B APIs
Discussion:
https://www.reddit.com/r/cpp/comments/2mx1mm/hourglass_interfaces_for_c_apis/
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:
http://lucumr.pocoo.org/2013/8/18/beautiful-native-libraries/
Discussion: https://news.ycombinator.com/item?id=6235671
Other than that, libabigail -- https://sourceware.org/libabigail/ -- may
also come in handy:
http://developerblog.redhat.com/2014/10/23/comparing-abis-for-compatibility-with-libabigail-part-1/
http://developerblog.redhat.com/2014/10/28/comparing-abis-for-compatibility-libabigail-part-2/
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:
http://isocpp.org/blog/2014/05/n4028
(PDF) https://isocpp.org/files/papers/n4028.pdf
HTH!
Best,
Matt
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
