Using STL in a library interface

[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

[Victor Bazarov]

Daniel Kay wrote:

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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Daniel Kay]

Victor Bazarov wrote:

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.

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

[Roland Pibinger]

On Wed, 10 May 2006 21:39:33 +0200, Daniel Kay <da********@arcor.de>
wrote:

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

[Victor Bazarov]

Roland Pibinger wrote:

On Wed, 10 May 2006 21:39:33 +0200, Daniel Kay <da********@arcor.de>
wrote:

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.

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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Roland Pibinger]

On Wed, 10 May 2006 15:50:08 -0400, "Victor Bazarov"
<v.********@comAcast.net> wrote:

Roland Pibinger wrote:

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.

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

[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.

[Daniel Kay]

carlosrf82 wrote:

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

[Ivan Vecerina]

"carlosrf82" <ca********@gmail.com> wrote in message
news:11*********************@g10g2000cwb.googlegro ups.com...

¿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
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Brainbench MVP for C++ <> http://www.brainbench.com

[Earl Purple]

Ivan Vecerina wrote:

"carlosrf82" <ca********@gmail.com> wrote in message

¿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.

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?

[carlosrf82]

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

[Ivan Vecerina]

"Earl Purple" <ea********@gmail.com> wrote in message
news:11**********************@q12g2000cwa.googlegr oups.com...

Ivan Vecerina wrote:

"carlosrf82" <ca********@gmail.com> wrote in message

> ¿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.

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
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[Alex Buell]

On 11 May 2006 05:35:15 -0700, I waved a wand and this message
magically appeared from carlosrf82:

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.

--
http://www.munted.org.uk

Take a nap, it saves lives.

[Michiel.Salters]

Daniel Kay wrote:

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