From: Edward Diener (eddielee_at_[hidden])
Date: 2002-10-20 20:33:24
"Carl Daniel" <cpdaniel_at_[hidden]> wrote in message
> "Edward Diener" <eddielee_at_[hidden]> wrote in message
> > "Carl Daniel" <cpdaniel_at_[hidden]> wrote in message
> > news:aov8il$qoq$1_at_main.gmane.org...
> > > "Edward Diener" <eddielee_at_[hidden]> wrote in message
> > > Not true. std::wstring is no different than any other class (after
> > > it's written in C++ - all the source code is in the header). If two
> > modules
> > > that were compiled with different settings for /Zc:wchar_t attempt to
> > > exchange wstrings, there are two possibilities. !) If std::wstring is
> > > coming from a DLL or static library, then there will likely be errors
> > > link time.
> > No, there won't as long as the interface specifies just std::wstring.
> > name mangling only changes when wchar_t is part of a signature, but not
> > std::wstring is part of a signature.
> Are you sure the signature of std::wstring itself isn't different though?
> actually haven't checked - it would have been under the VC6 mangling
> but if they're treating the std:: classes specially (with abbreviated
> in the mangling) then you're absolutely right - there would be no
> at link time.
You are correct and I am not. I just checked for myself and std::wstring
also is different depending on which type of wchar_t is used, so the linker
will catch the mismatch there also.
So the problem is not that one's program will not work but that one won't be
able to link correctly. Still it is a problem that needs to be addressed by
3rd party libraries which have exported functions dealing in wchar_t or
std::wstring. I don't know if this has been discussed by Boost implementors
or not, or how it has been resolved. MS suggests overloading for both cases
in a single DLL:
"By providing overloads for both the unsigned short and __wchar_t variations
of wchar_t, you can create libraries that can easily be linked with code
compiled with or without /Zc:wchar_t and avoid the need to provide two
different builds of the library (one with and one without /Zc:wchar_t
This seems really messy to me since the same code must be duplicated in two
different places not only in the exported function but in everything else
internally which the exported function uses. In libraries built around
wchar_t and/or std::wstring this means most everywhere. I just don't like
the idea of duplicating function signatures all over the place. Furthermore
how does one split a std::wstring in a signature into two different function
signatures ? No, I don't like their recommended solution.
Better I think is that one has to create two DLLs that are identical, except
name, with one built with the /Zc:wchar_t switch and one not. They can use
the exact same files and one names them slightly differently on output and
uses the #pragma comment() technique I mentioned earlier to automatically
bring in the right one's import library to link.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk