----- Mensaje original ----- De: John Maddock <john@johnmaddock.co.uk> Fecha: Sábado, Noviembre 24, 2007 2:41 pm Asunto: Re: [boost] [serialization][trunk] mingw non-wide char regressions Para: boost@lists.boost.org
"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