----- Mensaje original ----- De: John Maddock <john@johnmaddock.co.uk> Fecha: Sábado, Noviembre 24, 2007 5:48 pm Asunto: Re: [boost] [serialization][trunk] mingw non-wide char regressions Para: boost@lists.boost.org
"JOAQUIN LOPEZ MU?Z" wrote:
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.
Hmm, as it stands:
1) When building the boost_serialization sources then the codecvt_null members are declared as exported, but aren't actually in the dll: in the past I've been hit by linker errors if you don't actually export everything you claim to, but strangely not in this case?
No, I've just double checked it. To make surer I've conducted the following experiment: I created a toy DLL with the following source: #include <iostream> void __declspec(dllexport) f(); void __declspec(dllexport) g() { std::cout<<"hello"<<std::endl; } and a minimal program using it: void __declspec(dllimport) g(); int main() { g(); }; and everything works fine if I link the latter with the import lib of the former. If I change g() to f() in the program above there's an unresolved linking error for f(). Building the lib generates no error or warning, so my conclusion is that a __declspec(dllexport) *declaration* has no effect on the object code and hence generates no exported symbols. This is MSVC++ 8.0, maybe it was different with other compilers of the family.
2) When building boost_wserialization sources other than codecvt_null.cpp then the codecvt_null are declared as imported, even though they are actually exported: that's normally a linker warning.
Yep, what you say is very sensible, but the fact is that I observe no warnings whatsoever. Anyway, to be on the safe side is better to use the W macro variants for codecvt_null.{hpp|cpp} as I see you're proposing at another post of yours. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo