Using STL in a library interface

V

Victor Bazarov

Daniel said:
Is it right, that it's not a very good idea to use STL datatypes
(std::string, std::list, ...) for library interfaces? Because someone
might try to use that library with a different STL implementation and
is going to run into trouble? Is there any workaround for this? Will
I have to write own datatypes or even fall back to primitive
datatypes like char* for strings?

It may not be a good idea to use those objects for _binary_ interfaces.
You should be fine using them for template interfaces. It should be
totally fine to use them for binary interfaces within the same version
of the compiler+library combo as you use to build the library.

V
 
D

Daniel Kay

Hello folks!

Is it right, that it's not a very good idea to use STL datatypes
(std::string, std::list, ...) for library interfaces? Because someone
might try to use that library with a different STL implementation and is
going to run into trouble? Is there any workaround for this? Will I have
to write own datatypes or even fall back to primitive datatypes like
char* for strings?

Thanks in advance,
Daniel
 
D

Daniel Kay

Victor said:
It may not be a good idea to use those objects for _binary_ interfaces.
You should be fine using them for template interfaces. It should be
totally fine to use them for binary interfaces within the same version
of the compiler+library combo as you use to build the library.

If I write my own string implementation I will end up getting in trouble
with different name mangling when different compilers are being used.
Right? Slowly I think there is no clean and safe way to create library
interfaces using c++ language features when it comes to compiler
independance. What a pitty... :(

Cya,
Daniel
 
R

Roland Pibinger

If I write my own string implementation I will end up getting in trouble
with different name mangling when different compilers are being used.
Right? Slowly I think there is no clean and safe way to create library
interfaces using c++ language features when it comes to compiler
independance. What a pitty... :(

If you want maximum portability then you must write a C interface for
your C++ library.

Best wishes,
Roland Pibinger
 
V

Victor Bazarov

Roland said:
If you want maximum portability then you must write a C interface for
your C++ library.

I believe that maximum portability can only be reached if the library is
shipped in the source code form. No need for C interface then. After
all, didn't we switch to using C++ to avoid having to go into C?

V
 
R

Roland Pibinger

I believe that maximum portability can only be reached if the library is
shipped in the source code form. No need for C interface then.

A C library can be used in most popular languages: Scripting
languages, ... even Java. A huge advantage.
After
all, didn't we switch to using C++ to avoid having to go into C?

You may write your library in C++ as long as you provide a C interface
:)

Best regards,
Roland Pibinger
 
C

carlosrf82

Well,
¿is not C++ a Standard? ¿is not STL a Standard Template Library?
I dont understand, if i'd want a API based on C++ and export C++ Class
¿why could not i use C++ STL?
The library that i 'd want to export also have many versions, and
probably more often releases than C++ STL.
 
D

Daniel Kay

carlosrf82 said:
Well,
¿is not C++ a Standard? ¿is not STL a Standard Template Library?
I dont understand, if i'd want a API based on C++ and export C++ Class
¿why could not i use C++ STL?
The library that i 'd want to export also have many versions, and
probably more often releases than C++ STL.

STL only defines the interface and behaviour of the templates. But every
STL Library will implement this a different way. sizeof(std::string)
could be 12 bytes for the STL shipped with the gcc and 16 bytes for a
different implementation.

Cya,
Daniel
 
I

Ivan Vecerina

carlosrf82 said:
¿is not C++ a Standard?

It is -- but the standard specifies the language and source code.
Not the binary representation of a compiled library.
¿is not STL a Standard Template Library?
I dont understand, if i'd want a API based on C++ and
export C++ Class ¿why could not i use C++ STL?

You can. But you may face problems because different
C++ platform may implement incompatible binary interfaces.
This is a platform specific issue: most operating systems
have a well-defined C binding interace -- which all compilers
and languages can adhere to.

However, only few platforms define a standard binary interface
for C++-specific features (e.g. exceptions), and for standard
library classes.

This just goes beyond the scope of the C++ language standard.


Ivan
 
E

Earl Purple

You can. But you may face problems because different
C++ platform may implement incompatible binary interfaces.
This is a platform specific issue: most operating systems
have a well-defined C binding interace -- which all compilers
and languages can adhere to.

It's not just that - there are also problems with heap management,
particularly if using a reference-counted implementation of
std::string.

I have a portable_string class (actually portable_basic_string
template) that actually is a bit like boost_array, has an implicit
constructor from a string and a non-implicit conversion back (you have
to call asString() to get a std::string back) and is reference-counted
for large strings. But because the destruction is done via a virtual
method of a deleter_base, it is safe. Originally this class was
intended to be very light so all you would do was create it, pass it
and then convert back to string locally. However in the end I
implemented most of the const methods on it. You cannot modify one
though other assigning it.

Now I said that my class uses something similar to boost_array. So you
will ask, why not just use boost_array? Because you might end up with
the same portability issues. First of all, not everybody has boost ,and
secondly there may possibly be different versions of boost_array
(someone uses a legacy version?).

Now, is all this a design flaw in C++? Should there be a C++ runtime
library?
 
C

carlosrf82

Ok!!. Thanks, i´ve got it!!
I now understand why Trolltech make QTL and do not use STL.
 
I

Ivan Vecerina

Earl Purple said:
It's not just that - there are also problems with heap management,
particularly if using a reference-counted implementation of
std::string.

The same happens with malloc/free if those two functions are
not provided directly by the OS. On some platforms, a C library
can face compatibility issues if it is used by a C application
that uses a specialized implementation of malloc/free.
I have a portable_string class (actually portable_basic_string [...]
But because the destruction is done via a virtual
method of a deleter_base, it is safe.

Sure, this is a classic trick, used by COM, and various C libraries
as well. This is in no way specific to C++ or its standard library.
Now, is all this a design flaw in C++?
Should there be a C++ runtime library?

Yes there should. But this is up to the platform/implementer.


Ivan
 
A

Alex Buell

Ok!!. Thanks, i´ve got it!!
I now understand why Trolltech make QTL and do not use STL.

It's because they abuse the langauge - they even have a preprocessor
for their 'extensions'.

I use gtkmm as it's very close to the STL, and indeed uses STL.
 
M

Michiel.Salters

Daniel said:
Hello folks!

Is it right, that it's not a very good idea to use STL datatypes
(std::string, std::list, ...) for library interfaces? Because someone
might try to use that library with a different STL implementation and is
going to run into trouble?

If they have a different implementation, your new's won't match their
delete's.
If name mangling differs, your function names won't match their
headers.

So, avoiding STL isn't sufficient. You can't use any feature that the
different
sides implement differently.

HTH,
Michiel Salters
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,008
Latest member
HaroldDark

Latest Threads

Top