[boost] Re: VC7 and wchar_t in Boost

From: Edward Diener (eddielee_at_[hidden])
Date: 2002-10-20 20:33:24

"Carl Daniel" <cpdaniel_at_[hidden]> wrote in message
news:aovdeb$tvn$1_at_main.gmane.org...
> "Edward Diener" <eddielee_at_[hidden]> wrote in message
> news:aovcam$m9u$1_at_main.gmane.org...
> > "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
all,
> > > 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
at
> > > link time.
> >
> > No, there won't as long as the interface specifies just std::wstring.
MS's
> > name mangling only changes when wchar_t is part of a signature, but not
if
> > std::wstring is part of a signature.
>
> Are you sure the signature of std::wstring itself isn't different though?
I
> actually haven't checked - it would have been under the VC6 mangling
rules,
> but if they're treating the std:: classes specially (with abbreviated
names
> in the mangling) then you're absolutely right - there would be no
detection
> 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
enabled)."

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.