C++ library API. Using converter classes instead of plain C api - c++

Question

This question is about C++ <-> C++ interoperability.
As is well known implementation of standard library classes/functions may differ across different vendors. Moreover implementation may differ even within same library vendor, when using different compiler keys, configuration (Debug/Release), etc.
Due to that reason, many library developers shifts to old plain C-style API.
Which leads to uglish error-prone interfaces.
For instance, in order to get string from some function, interfaces like Win GetCurrentDirectory function are used:
DWORD WINAPI GetCurrentDirectory(
__in DWORD nBufferLength,
__out LPTSTR lpBuffer
);
three parameters + some boilerplate code on both sides(checking if buffer size was enough, etc) just to get simple string.
I am thinking to use some auxiliary adapter/proxy class, which will do all conversions automaticly, and can be simply reused.
Something like:
#include <string>
#include <algorithm>
#include <iostream>
#include <ostream>
class StringConverter
{
char *str; // TODO: use smart pointer with right deleter
public:
StringConverter(const std::string &user_string) // Will be defined only at user side
{
str=new char[user_string.length()+1];
(*(std::copy(user_string.begin(),user_string.end(),str)))=0;
}
operator std::string() // Will be defined only at library side
{
return std::string(str);
}
~StringConverter()
{
delete [] str;
}
};
StringConverter foo()
{
return std::string("asd");
}
int main(int argc,char *argv[])
{
std::cout << std::string(foo()) << std::endl;
return 0;
}
http://ideone.com/EfcKv
Note, I plan to have defenition of conversion from user string to StringConverter only at user side, and defenition of conversion from StringConverter to library string only inside library.
Also, right deleter should be used (from right heap).
What do you think about such approach?
Are there some major pitfalls?
Are there some superior alternatives?

Answer 1

This technique will work in some cases where standard data types are incompatible, but in others it will fare no better: name mangling differences and class memory layout differences (vptrs and tags) come to mind.
This is why C APIs are preferred.
But you can improve usability by burying the C API where the library caller never needs to see it. Then add a thin, idiomatic C++ overlay that provides the visible library interface. In some cases the thin overlay code can be used on both caller and library side, each compiled in its own environment: flags, link conventions, etc. Only C data types are exchanged. The simpler these data types are, the more compatibility you'll obtain.
The layer also takes care that memory allocation and deallocation occur on the same side of the API on a per object basis, as your code does. But it can be more flexible. For example, it's possible to arrange for an object allocated in the caller to be deallocated in the library and vice versa.
// library.h for both caller and library
// "shadow" C API should not be used by caller
extern "C" {
void *make_message(char *text);
char *get_text_of_message(void* msg);
void send_message(void *msg); // destroys after send.
}
// Thin C++ overlay
class Message {
void *msg;
public:
Message(const std::string &text) {
msg = make_message(text.c_str());
}
void send() {
if (msg) send_message(msg);
else error("already sent");
msg = 0;
}
std:string getTextString() {
return std:string(get_text_of_message(void* msg));
}
}