[boost] Re: VC7 and wchar_t in Boost

From: Edward Diener (eddielee_at_[hidden])
Date: 2002-10-20 18:00:05

"Carl Daniel" <cpdaniel_at_[hidden]> wrote in message
news:aov8il$qoq$1_at_main.gmane.org...
> "Edward Diener" <eddielee_at_[hidden]> wrote in message
> news:aov76u$h57$1_at_main.gmane.org...
> > The exported function changes mangled signature depending on the type of
> > wchar_t chosen by the end user. And of course the different types may be
> > different sizes, I'm not sure.
>
> Fortunately, they're the same.  AFIAK, only GCC on Linux defines wchar_t
as
> other than 16 bits.
>
> >
> > Boost has at least one library of which I know there are wchar_t
> interfaces,
> > regex++, and possibly other implementations where functions and/or
member
> > functions pass or return wchar_t objects from a DLL rather than through
> just
> > a header file implementation. If the DLL is created with one type of
> wchar_t
> > for VC7 and the end user decides to use the other type of wchar_t,
program
> > havoc and crashes will likely occur. Of course becasue the exported
> > interfaces are different, this will be caught at link time before the
run
> > time problem occurs. The problem no doubt extends to std::wstring which
is
> a
> > sequence of wchar_t characters, but that mismatch will not be caught at
> link
> > time and only runtime.
>
> 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.

>  2) If std::wstring is all inline, everything will "work fine",
> since the two types really are identical, even though they have different
> names.

If the two types are both the same size, then no problems will occur unless
the interpretation of the value changes because one is considered unsigned
and the other is not.
>
> It is a mess though...  :|

The issue of a library exporting function with wchar_t and the user getting
link errors because they are using the other type of wchar_t still exists.
If the two different types are really the same, both the equivalent in size
and signedness to an unsigned short in VC7, then MS changing the name
mangling signature for functions depending on which type is chosen seems
like an odd decision.