Duft Markus wrote:
> OMG, i'm so blind...... I messed up 12d and 15d, maybe those should get other names ;o)
now it's all clear why it can't work....
Yes, container iterators have different types between debug and
optimized builds, with std::string and std::vector being plain
pointers for efficiency. This makes the two kinds of builds
incompatible with one another.
>
> Anyway thanks for your time, and sorry for messing around in here!
No problem. Glad you got it worked out.
Martin
PS I haven't played with wgcc too much yet but I like the concept.
In fact, I've been thinking about writing a similar tool for some
time, one that would provide a uniform interface to all compilers
(i.e., the same set of compiler options across all). Have you
considered enhancing wgcc in this way?
>
> Cheers, Markus
>
> -----Ursprüngliche Nachricht-----
> Von: Duft Markus [mailto:Markus.Duft@salomon.at]
> Gesendet: Dienstag, 19. September 2006 09:37
> An: stdcxx-dev@incubator.apache.org
> Betreff: AW: boost ?!
>
> Hm, the struct thing was completely wrong, sorry....
>
> Ok, i just digged a little into this:
>
> For example one of the unresolved symbols is:
>
> __imp_?begin@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEPADXZ
>
> Which would be:
>
> __declspec(dllimport) public: char * __thiscall std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> >::begin(void)
>
> The Stdcxx library has symbols some symbols which are close:
>
> __imp_?begin@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE?AV?$__rw_debug_iter@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PADPAD@__rw@@XZ
>
> Which would be:
>
> __imp_public: class __rw::__rw_debug_iter<class std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> >,char *,char *> __thiscall std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >::begin(void)
>
> I now think that somehow there is a problem with the headers thinking they need to compile
debug iterators (in build 15d!?) and when using the lib, they think something else ;o// i
looked at my config.h but there was nothing i could see in there. I attached it, maybe you
can see something.
>
> Cheers, Markus
>
> -----Ursprüngliche Nachricht-----
> Von: Martin Sebor [mailto:sebor@roguewave.com]
> Gesendet: Montag, 18. September 2006 17:34
> An: stdcxx-dev@incubator.apache.org
> 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 http://msdn2.microsoft.com/en-us/library/dh8che7s.aspx
>
>
>>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
>>so....)
>
>
> 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
|