Re: [boost] BOOST_DLLEXPORT in serialization

From: Edward Diener (eldiener_at_[hidden])
Date: 2006-09-18 08:18:18

Robert Ramey wrote:
> Note that the only reason for using __declspec on tis platform is
> that without it, programs compiled in release mode will optimize
> away code not explicitly referred to.  This breaks serialization
> of derived pointers.  So this is a hack to work around over-zealous
> compiler optimizaton.  This has been learned through painful and
> time consuming experience.  It is possible this solution is overkill
> in some cases, but there is no way to know without investing
> a lot more effort.
> 
> I have no idea if the serialization library will work with /clr.

You can check the predefined Visual C++ macro _MANAGED to determine 
whether or not code is being compiled with /clr. If it is defined, code 
is being compiled with one of the /clr options, else it is not. This 
would allow you to use __declspec(dllexport) only when _MANAGED is not 
defined. John Maddock made changes to type_traits, checking this macro, 
to enable it to be compiled when /clr is used.

> My intuition tells me I doubt it.

Theoretically one should be able to use the serialization library for 
non-.Net classes in mixed mode C++/CLI programming, since those classes, 
even when compiled with /clr, are considered standard C++ classes, and 
are supposed to accept standard C++ constructs entirely. I've done quite 
a bit of mixed-mode C++/CLI programming but I haven't practically tried 
to use the Boost serialization library with the non-.Net classes. I have 
successfully used other Boost libraries with the non-.Net classes, such 
as function, bind, regex, shared_ptr so the chances that the 
serialization library could work with those classes is high. All of the 
bugs I have found having to do with C++/CLI mixed-mode programming have 
to do with the inadequacies of the visual environment and not the 
standard C++ portion of the C++/CLI compiler per se.

>  If I had to do this I would
> consider using SWIG which I have used in another context
> (not using serialization) to integrate Boost components into
> .NET languages.

My experience with SWIG tells me that it is never the right way to use 
standard C++ with any partially standard environment.