incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: AW: boost ?!
Date Wed, 20 Sep 2006 15:00:34 GMT
Duft Markus wrote:
> Urgl......
> I just saw that all (or most, don't known now) unresolved symbols look for *struct* std::char_traits....
This can't be correct, can it??

We do define struct (as opposed to class) char_traits. There is no
difference between class and struct from the language standpoint
(other the default access) and they should certainly be mangled
the same. It's an MSVC bug (or misfeature) that it mangles them

> I saw that boost has it's own char_traits somewhere....

As long as it's a specialization on a user-defined type there's
nothing wrong with doing that. But Boost cannot redefine the two
specializations of std::char_traits on char and wchar_t -- that
would violate the One Definition Rule.


> Cheers, Markus 
> -----Urspr√ľngliche Nachricht-----
> Von: Martin Sebor [] 
> Gesendet: Montag, 18. September 2006 17:34
> An:
> Betreff: Re: boost ?!
> Duft Markus wrote:
>>Hey again!
>>I'm currently fighting to get boost compiled with stdcxx... ;o) It 
>>seems, that boost uses both char and wchar_t versions of methods from 
>>stdcxx, which at least seems to compile, but cannot link, since there 
>>is no wchar_t impl in the stdlib15d.lib/.dll. Now my question is: can 
>>i somehow use 15d and 15D together on windows, so that both kind of 
>>symbols are present?
> The difference between 15d and 15D is that the first is a 32-bit build type (ILP32) while
the second is a 64-bit or wide one (LLP64 on Windows). The "wide" has nothing to do with wchar_t,
it refers to the width of the data type(s).
> Stdcxx has full support for wchar_t as long as the compiler supports it. Keep in mind
that the MSVC /Zc:wchar_t option changes the type and mangling of wchar_t and thus is a binary
incompatible option.
> Programs that link with the library must be compiled with same setting of the option
as the library (i.e., both on or both off).
> See
>>And there seem to be some differences from windows STL to this one in 
>>which files get included automatically from other includes and so on, 
>>since i need to explicitly include some files for some things to work 
>>(like std::hex and std::dec are not found, except i include istream or
> Stdcxx is much less promiscuous (i.e., a lot cleaner) than other implementations of the
C++ standard library when it comes to its headers introducing unnecessary names into scope.
std::hex and other manipulators are required to be declared in the header <ios> and
nowhere else so in order to use them you must include that header.
> Martin

View raw message