I may have missed a discussion here but there is a problem creating any
exported interfaces for VC7 using wchar_t. The problem involves the fact
that VC7 actually supports two different types for wchar_t, the previous
typedefed type and the C++ standard native type. The end user chooses which
type he wants to use by either specifying the /Zc:wchar_t compiler switch,
or its appropriate equivalent in the IDE, or not.

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.

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.

Has anybody at Boost addressed this issue in Boost libraries ? Are two
different versions of libraries supporting wide characters being distributed
for VC7 or has the decision been made to only support the legacy VC typedef
and not the C++ standard built-in character type for VC7 ? Inquiring minds,
such as people who work with such libraries in their own code, want to know
<g> .




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost