5

Is wrapping a c++ library to C via opaque pointers gives a stable ABI interface ? I am clear about ABI interface and why c++ is not having a stable one. This has to do with name mangling and lot other stuff. I know C is very stable in that part. It is also easy to wrap a C library into various other languages compared to C++. These two are driving force to make a c API for my library.

When wrapping a C++ library to C the underlying code is still C++. I my case it is c++ with boost shared ptr and other dependencies.

So since the underlying code is in C++, how the ABI stability is achieved. Or in other words, there is still c++ stuff compiled in the shared library (.so, .dll etc..)

I would like to know how it works. Perhaps someone can provide me with an example that very well explains this stuff.

rkm
  • 892
  • 2
  • 16
  • 32
  • 1
    What sort of problems do you expect? I mean, you know *why* the C++ ABI us considered unstable, right? Di these same reasons apply in your case? – n. m. could be an AI Feb 25 '16 at 09:52
  • 1
    Possible duplicate of [.def files C/C++ DLLs](http://stackoverflow.com/questions/366228/def-files-c-c-dlls) – Dialecticus Feb 25 '16 at 09:54
  • 2
    Yes, of course there will be c++ stuff compiled into the library. But the interface will have a stable ABI and can be called from pretty much anywhere. Make sure you catch exceptions in API and convert them to old 70s return values. – Erik Alapää Feb 25 '16 at 09:58
  • @n.m., the problem is abi stability. and the solutions are 1) rewrite the whole code in C. 2) write a C wrapper for C++ code. I want to know "how it works" for the second option. I still need a c++ compiler even though I only need to build C wrapper dll – rkm Feb 25 '16 at 10:05
  • What are *specific* problems associated with ABI stability that apply to you? Specific problems look like this: "when X happens, customers will experience falilure Y doing Z". You should know your Xs Ys and Zs and evaluate them in the case of C-wrapped C++ library. If you don't know these things you perhaps should be asking about them first... – n. m. could be an AI Feb 25 '16 at 10:31
  • @n.m. code must be recompiled for all version of the compiler with every minor changes in the API in case of C++ and for C API this is not required as the ABI is stable. I don't know about other specific problems. Please tell me which are other problems. Are you saying the code must be re-written in C? – rkm Feb 25 '16 at 13:30
  • 1
    "Other specific problems" If your library links to the standard C++ library ABI x, and some other library links to the standard C++ library ABI y, then the two libraries may be unusable together (on some platforms at least). It doesn't matter which interface you export. This is a problem for all C++ libraries. "Are you saying the code must be re-written in C?" Are you saying C++ is unusable for writing libraries? Obviously C++ libraries exist, so somehow people are able to cope with ABI instability. – n. m. could be an AI Feb 25 '16 at 13:53
  • thanks @n.m. If I make C wrapper into a shared library and this shared library is generated on msvc2010. Could this be reused for other version of the same compiler? – rkm Feb 25 '16 at 16:33
  • 1
    [CppCon 2014: Stefanus DuToit "Hourglass Interfaces for C++ APIs"](https://www.youtube.com/watch?v=PVYdHDm0q6Y) might interest you – Thomas Feb 25 '16 at 19:36
  • Yes, specifically for MSVC this will work. – n. m. could be an AI Feb 27 '16 at 01:31

2 Answers2

4

Yes, you can create a stable C-Inteface for a C++ implementation. Of course, the C-Interface only offers C-features. Still it can be handy to use C++ for the actual implementation. Here an example where you have a single C++ implementation with function templates and you offer for some variants a C-Interface:

// Internal C++ implementation
template <typename T>
void
foo(T &a, const T &b)
{
    // do something
}


// C Interface
extern "C" {

void
sfoo(float *a, const float *b)
{
    foo(*a, *b);
}

void
dfoo(double *a, const double *b)
{
    foo(*a, *b);
}

} // extern "C"

So basically the compiler will generate different implementations for T=float and T=double:

  • Of course you don't have function overloading. So you have to do the name mangling handish. E.g. sfoo for float, dfoo for double, ... (You also can do this using the pre-processor in C. But it is not that nice to read and maintain.)
  • You don't have references. So instead of references the interface exposes non-const pointers.
Michael Lehn
  • 2,934
  • 2
  • 17
  • 19
1

Yes it would be the stable C ABI of the C compiler for your platform; if done properly, of course.

ddbug
  • 1,392
  • 1
  • 11
  • 25