[Rcpp-devel] Rcpp built with the visual c++ compiler - possible uses

[Matt D.]

On 4/8/2015 14:34, Jean-Michel.Perraud at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20150408/ce054502/attachment.html>