Compiling Boost with STLPort under VC8?
Author
Has anyone compiled the Boost libraries under VC8 using STLPort (5.1.3 for me) as the stdlib? I know Boost 1.33 had support for STLPort under the VC7.1 compiler, but it doesn't specifically have a VC8+STLPort setting, and Boost 1.34 doesn't mention STLPort at all (I've read in the Boost mailing lists where people were doing it, but they were compiling with bjam parameters that I haven't seen documented anywhere).
I'm using STLPort in my current project, so I'd really like Boost to do the same for consistency. Why would there be no documentation on this? Boost 1.33 had better build instructions than 1.34 did. Any ideas on how to go about getting this setup?
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.
Author
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...
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.
Author
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 SneftelQuote: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...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
