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:[EMAIL PROTECTED]
Gesendet: Dienstag, 19. September 2006 09:37
An: [email protected]
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:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@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:
[EMAIL PROTECTED]@[EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@2@@std@@[EMAIL
PROTECTED]@[EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@2@@std@@[EMAIL
PROTECTED]@@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:[EMAIL PROTECTED]
Gesendet: Montag, 18. September 2006 17:34
An: [email protected]
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
