Compiling Boost with STLPort under VC8?

No ideas? Is this an uncommon configuration or problem?

It does seem like it, yes. There's little reason I can think of to use STLPort over VC8's native STL, so the intersection of people who use all of Boost, VC8, and STLPort would be rather small.

Really? VC8's STL is that good? I'm migrating from VC7.1, and I know it had several STL shortcomings (i.e. unimplemented standard functions). The other reason for using STLPort was to have a common STL implementation across all platforms, since my project is cross-platform.

Does this mean that STLPort is now rather antiquated for VC8 users? Are there any known issues with VC8's STL (like the dreaded "safe" libraries) that could make cross-platform development difficult?

After convincing myself in the past that STLPort was the safest way to go, I'm hesitant to just drop it again without knowing what I'm getting myself into...

Which unimplemented standard functions were those? I'm pretty sure that VC7.1's STL was complete, and VC7's as well (though it's been longer), in stark contrast to VC6's.... thing. In any case, yeah, it's a good implementation... standards-compliant enough that it'll interoperate fine with code written for a standards-compliant standard library, and as efficient as any standard library as long as the checked iterator stuff isn't turned on.

Quote:

Original post by Sneftel Which unimplemented standard functions were those? I'm pretty sure that VC7.1's STL was complete, and VC7's as well (though it's been longer), in stark contrast to VC6's.... thing. In any case, yeah, it's a good implementation... standards-compliant enough that it'll interoperate fine with code written for a standards-compliant standard library, and as efficient as any standard library as long as the checked iterator stuff isn't turned on.

std::uncaught_exception was there, but not implemented until 8.0, but that's the only thing I can come up with off the top of my head.

Here's the 7.1 MSDN Help on uncaught_exception - "As can be seen in the Visual C++ source file, uncaught.cpp, uncaught_exception always returns false even in cases where the standard specifies that it should return true.

See Knowledge Base article Q242192 for more information."

Huh. You learn something new every day. Of course, STLPort would have no way of implementing uncaught_exception.

I guess I was thinking of functions like vsnprintf(), which in VC7.1 only exist as _vsnprintf(). If I remember correctly there are quite a number of library functions renamed like that. Ultimately not a big issue in itself, but it leaves the impression of being less complete or compliant than STLPort.

Quote:

Original post by Nairou I guess I was thinking of functions like vsnprintf(), which in VC7.1 only exist as _vsnprintf().

vsnprintf() is there. You just have to #define _CRT_SECURE_NO_WARNINGS if you don't want the spurious warnings.

Quote:

Original post by Sneftel Quote: Original post by Nairou I guess I was thinking of functions like vsnprintf(), which in VC7.1 only exist as _vsnprintf(). vsnprintf() is there. You just have to #define _CRT_SECURE_NO_WARNINGS if you don't want the spurious warnings.

It's not really a spurious warning...

Alright, that is good to know, I guess VC8 is a big improvement then. :) I guess I'll just stick with VC8 without STLPort and see how it goes then. Thanks for all of the feedback on this!

Quote:

Original post by Washu It's not really a spurious warning...

The hell it isn't. vsnprintf() is not a security risk if properly used. If I try to use DeleteFile(), should I get a warning telling me to make sure not to delete anything important?

hi --

it's funny you ask about this, i've just been experimenting with it.
i was able to get boost 1.34 to compile against STLPort 5.1.3
i was using visual studio 2005.

the reason i was experimenting with it is because of this page which indicates that STLPort containers are faster than visual studios, and i use a lot of containers. i don't personally have any numbers to report, though :)


http://garrys-brain.blogspot.com/2007/01/development-stlport-versus-microsoft.html

anyways, i had the same experience you did -- there's almost no documentation, and some of the documentation that does exist is wrong.

here are the issues and solutions.

1) the version of stlport.jam that comes with boost 1.34.0 is bad, in that it will generate bad library names. what i ended up doing was making stlport.jam in boost look like this version from a nice man (David Deakins) on the internet:
http://lists.boost.org/boost-build/2007/08/17123.php

what i did was cut and paste the section of that post that has the full text of the stlport.jam file; avoid the section that is the patch.

he filed this bug with boost about the issues, but i'm not sure if it is resolved yet.
http://svn.boost.org/trac/boost/ticket/1177

2) you have to tell boost about stlport

in the user-config.jam, there needs to be a line telling boost about sltport.
i think it ends up something like

using stlport : 5.1.3 : c:/STLPort-5.1.3/stlport c:/STLPort-5.1.3/lib ; 

clearly, adjust those paths as you need to.
and i think you can omit the first version number, but i'm not sure.

off the top of my head, i can't remember where the user-config.jam file is, but i bet you can find it on your disk :)

3) don't use the msvc-stlport toolset.

although that seems like a reasonable thing to do, don't do it; it will generate library files again with the wrong names. basically, this is the command you need:

bjam --toolset=msvc-8.0 stdlib=stlport stage

or something very similar... but that required that you have set up the "using stlport" settings above.


i guess you might not be interested in trying this anymore, and i'm not sure if all of these steps are exactly right, or if i'm still missing something. however, maybe it will help you out.

thanks,
ryan.