Linux: C++ Abstract class as shared object API

Question

i read this article on C++ DLL API-s. Would the "C++ Mature Approach: Using an Abstract Interface" also work on linux with different compilers (exe and .so compiled with different compilers)? I couldn't find anything online that confirms/denies it for linux systems. In the article the author says that it works for windows because COM technology works with other compilers.

To understand the question please read at least the "C++ Mature Approach" Chapter of the article.

Answer 1

Yes and no.

There's no guarantee that different compilers will the implement virtual function calls in the returned interface class in the same way - and if that is the case then it will fail catastrophically (or will silently corrupt stuff ... even more fun). But if I recal correctly - modern g++, clang and intel on linux seem to handle it the same way and so should be interoperable at this level.

However there's a further gotcha not mentioned in the article, and this applies to both linux and windows. If you take this approach the only things you can pass about are

1. interfaces
2. simple types like int
3. Types where you carefully control the in memory layout.

This means you cant have a function in your interface like void withVector(std::vector<int> v) since the different standard libraries of the compilers may layout the internals of the vector differently. In fact this can change between compiler versions, standard library versions, and even with compiler settings.

So you'll need to create a IIntVector that wraps std::vector and then use withVector(IIntVector& v).

You can run into the same issues if you pass or return any non-interface classes of your own.

An old example where this bit me was passing a boost::shared_ptr between compilation units, where in one case a lock member was in the class and in the other no lock existed - this means the objects had different expected sizes and resulted in (silent) stack corruption. Fun for the whole development team.

I've found it's less error-prone to use a pure C bridge between the two sides and provide a utility layer in C++ that the DLL creator can build and use that calls the pure C bridge. But even in C its not trivial.

In the C case you still need to watch out for changes in the data structures caused by compiler settings (but they are rarer) and you also need to be careful that one compiler doesn't insert padding into your structures that the other does not.