Re: [boost] [serialization][trunk] mingw non-wide char regressions

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2007-11-24 10:30:37

----- Mensaje original -----
De: John Maddock <john_at_[hidden]>
Fecha: Sábado, Noviembre 24, 2007 2:41 pm
Asunto: Re: [boost] [serialization][trunk] mingw non-wide char 
regressions
Para: boost_at_[hidden]

> "JOAQUIN LOPEZ MU?Z" wrote:
[...]
> >
> > codecvt_null.cpp deals exclusively with wchar_t functionality,
> > so it need not be in boost_serialization, only in
> > boost_wserialization. The attached patch corrects this. I've
> > checked it locally in a MinGW installation and it makes
> > (non-wide) serialization-dependent tests pass. OK to commit?
> 
> Please see 
> http://lists.boost.org/Archives/boost/2007/11/130828.php and 
> http://lists.boost.org/Archives/boost/2007/11/130831.php.
> 
> My machine is tied up at present: can you double check that moving 
> codecvt_null.cpp to boost_wserialization breaks dll building of 
> Serialization with msvc? (I'm 99% sure it will do if the header is 
> included by any of the sources).

My results:

1. codecvt_null.cpp moved from SOURCES to WSOURCES.
  - MSVC++ 8.0: all tests pass
  - MinGW 3.4.5: narrow char tests pass (only tested a handful)

2. codecvt_null.cpp moved from SOURCES to WSOURCES,
BOOST_ARCHIVE_DECL-->BOOST_WARCHIVE_DECL in codecvt_null.hpp,
BOOST_ARCHIVE_SOURCE-->BOOST_WARCHIVE_SOURCE in codecvt_null.cpp
(see attached diffs):
  - MSVC++ 8.0: all tests pass
  - MinGW 3.4.5: narrow char testspass (only tested a handful)

Why do you assume moving codecvt_null.cpp from SOURCES to
WSOURCES would break MSVC tests? If your concern is related
to the possibility that codecvt_null<wchar_t> member functions
aren't properly exported, take into account that exportability
is not controled by the library the .cpp is bundled into,
but only by the macros BOOST_[W]ARCHIVE_DECL and
BOOST_[W]ARCHIVE_SOURCE: having the narrow version or the wide
version of the macros in place make no difference, the
end result is that the member functions are imported/exported
as they should. Of course if we switch codecvt_null.cpp from
SOURCES to WSOURCES having the wide macros rather than the
narrow is the aesthetically consistent choice, but it makes
no difference from a practical point of view, AFAICS.

I don't have time now to additionally try Robert's suggestion
of wrapping the wchar_t-related stuff in codecvt_null.hpp
with a #ifndef BOOST_NO_STD_WSTREAMBUF guard, but I think
it's probably equivalent to the patches I've just tried.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo