By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,300 Members | 1,418 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,300 IT Pros & Developers. It's quick & easy.

Portable STL implementation?

P: n/a
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
Jul 23 '05 #1
Share this Question
Share on Google+
14 Replies


P: n/a
pjp
"John Smith" <jo********@x-formation.com> wrote in message
news:42*********************@dread16.news.tele.dk. ..
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

Jul 23 '05 #2

P: n/a

"John Smith" <jo********@x-formation.com> wrote in message
news:42*********************@dread16.news.tele.dk. ..
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


Jul 23 '05 #3

P: n/a
> 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
Jul 23 '05 #4

P: n/a
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
Jul 23 '05 #5

P: n/a
John Smith wrote:
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.


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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 23 '05 #6

P: n/a
> 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
Jul 23 '05 #7

P: n/a
John Smith wrote:

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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 23 '05 #8

P: n/a
> 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
Jul 23 '05 #9

P: n/a
John Smith wrote:

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?


su*****@dinkumware.com

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 23 '05 #10

P: n/a
"John Smith" <jo********@x-formation.com> wrote in message news:<d2**********@news.net.uni-c.dk>...
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.


All the code, including ::operator 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.

--
smw
Jul 23 '05 #11

P: n/a
>
All the code, including ::operator 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

Jul 23 '05 #12

P: n/a
> 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
Jul 23 '05 #13

P: n/a
John Smith wrote:
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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 23 '05 #14

P: n/a

John Smith wrote:

All the code, including ::operator 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.

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

Jul 23 '05 #15

This discussion thread is closed

Replies have been disabled for this discussion.