Portable STL implementation?

[John Smith]

Hi

I'm looking for a header-file only STL implementation. I know the vendors
provide one with compilers but often they are either buggy or has some other
problems.
My problem is that under Windows the different versions of the Microsoft
compiler are not compatible with each other. This means you can't compile
file with version X and link with version Y because you end up with linker
errors.

I've tried STLport but with lack of success. I have some problems getting it
working with AMD64 and under Mac OS X it doesn't compile cleanly either.

Any suggestions?

-- John

 

[pjp]

I'm looking for a header-file only STL implementation. I know the vendors
provide one with compilers but often they are either buggy or has some
other problems.

And you think free software is going to be better?

My problem is that under Windows the different versions of the Microsoft
compiler are not compatible with each other. This means you can't compile
file with version X and link with version Y because you end up with linker
errors.

It's rare that you can do that with *any* two major versions of a
compiler.

I've tried STLport but with lack of success. I have some problems getting it
working with AMD64 and under Mac OS X it doesn't compile cleanly either.

Any suggestions?

The nearest thing to what you want is probably our Unabridged Library.
It supplies essentially the same library (including STL, of course) on
VC++ versions from V6 on. You can also get it for multiple versions of
gcc, on a variety of platforms.

But it costs $.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Howard]

Hi

I'm looking for a header-file only STL implementation. I know the vendors
provide one with compilers but often they are either buggy or has some
other
problems.
My problem is that under Windows the different versions of the Microsoft
compiler are not compatible with each other. This means you can't compile
file with version X and link with version Y because you end up with linker
errors.

Do you really need to compiler and link seperately? Your code itself should
not have any dependency on the implementation of the STL, unless you're
using vendor-specific extensions, as far as I can tell. If the code is
portable, then won't it comple and link on any system? The only changes I
can think of when porting "portable" code between systems are related to the
"project settings" or "makefile", which are not related to the code you
write. For all my code that is portable, I have identical sources,
including any STL code or file includes. Only the projects (Code Warrior,
VC++, etc.) differ (and of course any platform-specific stuff, like graphics
or mouse handling). But perhaps I'm missing your point...?

-Howard

 

[John Smith]

Do you really need to compiler and link seperately?

Yes because my code is sent to users as a library and must be linked
together with users existing files.

Your code itself should
not have any dependency on the implementation of the STL, unless you're
using vendor-specific extensions, as far as I can tell. If the code is
portable, then won't it comple and link on any system?

Thats what I thought too. However reality turned out to be different.

The only changes I
can think of when porting "portable" code between systems are related to the
"project settings" or "makefile", which are not related to the code you
write. For all my code that is portable, I have identical sources,
including any STL code or file includes. Only the projects (Code Warrior,
VC++, etc.) differ (and of course any platform-specific stuff, like graphics
or mouse handling). But perhaps I'm missing your point...?

Yeah I have identical sources too.

Heres an example. Code which is compiled with Microsoft VC++.NET 2003 and
linked with VC++ 6.0:

xmllicrtw.obj : error LNK2001: unresolved external symbol "public: void
__thisca
ll std::_String_base::_Xran(void)const " (?_Xran@_String_base@std@@QBEXXZ)
xmllicrtw.obj : error LNK2001: unresolved external symbol "public: void
__thisca
ll std::_String_base::_Xlen(void)const " (?_Xlen@_String_base@std@@QBEXXZ)

If I would do it the other way around I would just get undefined VC++ 6.0
symbols instead.
I think the conclusion is that not all of Microsofts STL is written as
header files.

-- John

 

[John Smith]

Isn't your STL lib already part of VC++.NET 2003?

If so, it's resonable to assume the code will be giving me the same problems
as I described in my other post?

(More specificly that some std::string functions aren't written as inlines
but are written as cpp files which needs linking).

Thanks in advance.
-- John

 

[Pete Becker]

Yes because my code is sent to users as a library and must be linked
together with users existing files.

The problem here isn't just std::string or any other particular part of
the standard library. There are lots of details that change between MS
compiler versions. You need to provide a separate library for each compiler.

 

[John Smith]

The problem here isn't just std::string or any other particular part of

the standard library. There are lots of details that change between MS
compiler versions. You need to provide a separate library for each

compiler.

Yes I realise there are probably many things changed which I am not aware
of.

However IF the STL library is header-only then all the code will be inlined
in my own objects and thus there will be no external dependencies. Because
essentially this is the problem that I have.

Will Dinkumware purchasable library solve this requirement? Or will I need
to link with some libraries. The classes I am particular interested in are
string, map, list, vector and set.

Thanks in advance.
-- John

 

[Pete Becker]

However IF the STL library is header-only then all the code will be inlined
in my own objects and thus there will be no external dependencies. Because
essentially this is the problem that I have.

That's not right. If you mix DLLs built with different library versions
and you pass objects between DLLs the differences will kill you.
Quietly. Better to get a link error than to have to track down this sort
of random-looking failure.

Will Dinkumware purchasable library solve this requirement? Or will I need
to link with some libraries. The classes I am particular interested in are
string, map, list, vector and set.

If you build all of your application with the same library code then it
doesn't matter whether you have to link to a library or the code is all
inlined. So, no, our library is not header-only (that causes tremendous
code bloat) but if you use it in all of your code you won't run into
problems with inconsistency.

 

[John Smith]

If you build all of your application with the same library code then it

doesn't matter whether you have to link to a library or the code is all
inlined. So, no, our library is not header-only (that causes tremendous
code bloat) but if you use it in all of your code you won't run into
problems with inconsistency.

I have some additional questions but don't want to flood the newsgroup with
product specific things. How can I contact you in a more official way?

-- John

 

[Pete Becker]

I have some additional questions but don't want to flood the newsgroup with
product specific things. How can I contact you in a more official way?

(e-mail address removed)

 

[Stephen M. Webb]

compiler.

Yes I realise there are probably many things changed which I am not aware
of.

However IF the STL library is header-only then all the code will be inlined
in my own objects and thus there will be no external dependencies. Because
essentially this is the problem that I have.

All the code, including :perator new and its allies, exception throw
and catch mechanisms, RTTI, and all the other fun stuff from the C++
runtime? Perhaps there is something to what the people who wrote the
Microsoft libraries are saying.

 

[John Smith]

All the code, including :perator new and its allies, exception throw
and catch mechanisms, RTTI, and all the other fun stuff from the C++
runtime? Perhaps there is something to what the people who wrote the
Microsoft libraries are saying.

No I didn't ment everything. Besides I am talking about STL, not every C++
feature. Look at STLport. Everything except iostreams is written in headers.

-- John

 

[John Smith]

That's not right. If you mix DLLs built with different library versions

and you pass objects between DLLs the differences will kill you.
Quietly. Better to get a link error than to have to track down this sort
of random-looking failure.

Fortunatly I don't have any of that. I only have a library (*.lib) file with
a C front-end.

If you build all of your application with the same library code then it
doesn't matter whether you have to link to a library or the code is all
inlined.

Yes and that is exactly the problem. To point it out again:
1. STL provided from microsoft is different for every version and not
inter-compatible (6.0, 7.0, 7.1 and 8.0)
2. When you ship a (*.lib) library to end-users they will end up in linker
errors exactly because of this unless they link their code with my library
using exactly the same version of the compiler.
3. To solve this either I get rid of the dependencies to microsoft libraries
or I compile the same code with each compiler and provide seperate versions.

Naturally it's much better to get rid of the dependencies and I still havn't
found out wheter the Dinkumware library can help me.

-- John

 

[Pete Becker]

3. To solve this either I get rid of the dependencies to microsoft libraries
or I compile the same code with each compiler and provide seperate versions.

Every library I'm aware of ships different versions for different
compilers. Anything else is at best risky.

 

[msalters]

No I didn't ment everything. Besides I am talking about STL, not every C++
feature. Look at STLport. Everything except iostreams is written in

headers.

Is it? Every call to new goes to some code which is not part of
STLport.
And again, the implementation of new for compiler X might not match the
implementation of delete in compiler X+1. Now, if a ctor and dtor are
inlined (as you suggest they will be), they can be compiled with
different compilers. Boom.

Regards,
Michiel Salters