Passing std::string in a library API

We are currently building an API for a certain library. Part of the interface requires the library to get and return to the user classes such as vector and string.

When trying to simulate use of the library in a simple scenario, in debug mode the system crush when delivering a string as an input.

I believe there is a different representation of the string class in debug or release mode. Then our library assumes to receive a certain representation, read a data member incorrectly and crush along the way. So what is the best way method to transferring STL objects in an API. The target OS is windows XP compiled with MSVC 8, although the library user will use windows their compiler might (and probably will) be different Ideas we had so far:

Change string to char* - But then developers might be baffled with the responsibility of releasing the memory.
Use our own version of String – I don't want to develop another private implementation of string.
Release to the user debug version and release version.
Ask people on Stack overflow for some option we miss or don’t understand, or just hear from their experience - done.

You should avoid passing STL objects between different binary modules.

For string, you have to rely on const char* for read only parameter and char*, <buffer size> for input parameters...

For vectors, it could be a bit more difficult especially if you have to change the content of the vector...

About your ideas:

You are right, but the convention usually is that you can't store the passed pointer (you have to do your local copy).
At the end you would have the same issue unless you have the same binary representation on debug and release version of your implementation.
This may be harmful if you use different versions/implementation of STL in the two binary modules (unless you are sure that the library user will use the same STL).

For down-voters: please add an explanatory comment so we can understand what's wrong...

Lorenzo 2010-07-02 16:57:58

Please explain what you mean by "binary modules".

anon 2010-07-02 16:59:04

@Neil: for example an .exe and a .dll, or a statically linked library, or in general any two compiled modules that will be linked together. If they use different implementations of STL... opps.

Lorenzo 2010-07-02 17:00:55

@lorenzo I pass strings, vectors etc. to static libraries all the time with zero problems. Of course, the libraries must be compiled with the same compiler as the executable, but the same would be true for C code, if the library and executable shared memory management duties.

anon 2010-07-02 17:03:35

@Neil: I thought that C (not really sure fore C++) has binary compliance (between different implementations) at linker level when the same calling convention is used. You are almost true about memory management: you can't `free` memory with a C library that was mallocated with another C library, for this reason the operating system allocator is used when designing libraries (at least on Windows).

Lorenzo 2010-07-02 17:09:36

@Lorenzo No, there is no standard for C binary compatibility, though on most platforms there is a default one. And when I design libraries, I don't normally consider the platform, certainly I don't call things like GlobalAlloc().

anon 2010-07-02 17:12:47

Just to expand on Lorenzo's point a little: you should check that both are using exactly the same debug or non-debug copy of the C runtime DLL. If there's a mismatch or either are static then it's not going to work.

Rup 2010-07-02 17:13:36

@Neil: hmm you're right... the C ABI compatibility is actually enforced by the ABI used by system calls on a specific platforms...

Lorenzo 2010-07-02 17:15:23

@Rup: exactly, however if you are designing a library, you shouldn't force the customer to use a specific STL implementation...

Lorenzo 2010-07-02 17:17:51

@Lorenzo. Actually, not - the binary ABI is enforced (if that's the word) by the most popular compiler and linker. System calls (on Linux at least) are actually called by invoking a software interrupt.

anon 2010-07-02 17:18:01

@Neil: I don't deal with OS from the sixties :-) Jokes aside, in Windows system calls are C functions, so the calling convention using there is the de facto standard ABI (you can argue that the actual system call is done with a syscall ASM call even on Windows, but the developer is not supposed to deal with that).

Lorenzo 2010-07-02 17:23:56

@lorenzo UNIX is an OS from the 70s, Windows an OS from the 80s and Linux an OS from the 90s. Also, Windows doesn't really document what is and is not a systems call, which is commonly taken to be a switch into kernel mode. None of this has anything to do with the C ABI, of course.

anon 2010-07-02 17:32:15

@lorenzo If you provide a binary library, you must force the library to use the same (not a specific) Standard Library implementation as the caller.

anon 2010-07-02 17:34:11

@Neil: UNIX is from 1969, and Linux is so UNIX-like that can't be considered a 90s design. However it was clearly a joke.

Lorenzo 2010-07-02 19:57:09

@Neil: the documented way to call Windows system services is to use the Windows API, which is a collection of C function. The calling convention of these C functions, plus the alignment requirements, is the de facto standard C ABI in Windows.

Lorenzo 2010-07-02 19:58:56

But it is not so reasonable to force a specific STL version IMHO...

Lorenzo 2010-07-02 17:24:54

@Lorenzo: You use the STL of your compiler. If you have a free compiler like GCC, then you make your users update. If you have a paid, more versioned compiler like MSVC, you just compile against MSVC8,9,10.

DeadMG 2010-07-02 18:01:44

@DeadMG: but if you compile your library with a given compiler, if you export STL objects you will force the user of the library to use the same environment in its application.

Lorenzo 2010-07-02 21:42:33

@Lorenzo: Libraries aren't compatible between CPUs and such anyway. Once you have the same target, it's not unreasonable to use the same compiler.

DeadMG 2010-07-03 10:22:52

@DeadMG: OK, so I'm the library vendor (assume Windows and a DLL) and choose to use Intel C++ 10 compiler and sgi STL. The cutomer will not be aware of what library and compiler I am using, as he will get the binary module. He will use MSVC 7 with the stock STL. My library exports STL string and vectors, are the two implementations compatible?

Lorenzo 2010-07-03 11:35:03

@Lorenzo: That's why you use the majority compiler for your platform. MSVC Express is free.

DeadMG 2010-07-03 13:56:17

ansaurus

tags:

views:

answers:

Passing std::string in a library API

related questions