I just tried compiling some source code in Microsoft VS 2005, with /clr turned on. It turned up the following error: boost/serialization/void_cast_fwd.hpp(26) : error C3389: __declspec(dllexport) cannot be used with /clr:pure or /clr:safe It appears that BOOST_DLLEXPORT, defined in boost/serialization/force_include.hpp, is always defined to __declspec(export). This is surely incorrect, is it not? The reason I bring this up is that it resolved a mysterious build "issue" I'd been having ever since I started using serialization (which occurs with native code generation on VC++): even though I only used serialization in an executable (i.e., the source got compiled to a .exe), the compiler was also producing an import library and export file, as it would for a DLL! I am guessing that this is due to the fact that functions are being "exported" from the executable via BOOST_DLLEXPORT. Sure enough, if I removed serialization from my source code, the exp and lib files disappeared. While this might only be slightly annoying, I can't help but think that the semantics of __declspec(dllexport) within a non-DLL are undefined at best. I don't know enough about the serialization library to understand this problem in enough detail to offer an alternative.
Damien Fisher wrote:
While this might only be slightly annoying, I can't help but think that the semantics of __declspec(dllexport) within a non-DLL are undefined at best.
__declspec(dllexport) is well-defined in an EXE, it declares the functions as exported. You can then link to them from the DLLs if you like. Its use in the serialization library is probably unintended, though.
On 9/17/06, Peter Dimov <pdimov@mmltd.net> wrote:
Damien Fisher wrote:
While this might only be slightly annoying, I can't help but think that the semantics of __declspec(dllexport) within a non-DLL are undefined at best.
__declspec(dllexport) is well-defined in an EXE, it declares the functions as exported. You can then link to them from the DLLs if you like. Its use in the serialization library is probably unintended, though.
Well that's my "learn-something-new-everyday" factoid for today :) (obvious in retrospect). It took me a bit of tinkering to realize why the .lib/.exp files were getting generated, so either fixing the problem, or putting a note in the FAQ explaining why this is needed, would be helpful.
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. My intuition tells me I doubt it. 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. Robert Ramey Damien Fisher wrote:
I just tried compiling some source code in Microsoft VS 2005, with /clr turned on. It turned up the following error:
boost/serialization/void_cast_fwd.hpp(26) : error C3389: __declspec(dllexport) cannot be used with /clr:pure or /clr:safe
It appears that BOOST_DLLEXPORT, defined in boost/serialization/force_include.hpp, is always defined to __declspec(export). This is surely incorrect, is it not?
The reason I bring this up is that it resolved a mysterious build "issue" I'd been having ever since I started using serialization (which occurs with native code generation on VC++): even though I only used serialization in an executable (i.e., the source got compiled to a .exe), the compiler was also producing an import library and export file, as it would for a DLL! I am guessing that this is due to the fact that functions are being "exported" from the executable via BOOST_DLLEXPORT. Sure enough, if I removed serialization from my source code, the exp and lib files disappeared.
While this might only be slightly annoying, I can't help but think that the semantics of __declspec(dllexport) within a non-DLL are undefined at best. I don't know enough about the serialization library to understand this problem in enough detail to offer an alternative. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 9/18/06, Robert Ramey <ramey@rrsd.com> 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.
If you have the time, could you explain to me exactly what the problem is (or show me a program highlighting the problem)? How can the code be needed for serialization if it isn't actually "used" from the compiler's point of view?
I have no idea if the serialization library will work with /clr. My intuition tells me I doubt it. 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.
It definitely won't if you use dllexport, but there shouldn't be any reason why it can't work apart from that.
Damien Fisher wrote:
On 9/18/06, Robert Ramey <ramey@rrsd.com> 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.
If you have the time, could you explain to me exactly what the problem is (or show me a program highlighting the problem)? How can the code be needed for serialization if it isn't actually "used" from the compiler's point of view? A quite common problem when dealing with factories and such things. 'Niftycounters' can be used to counter this, i.e. forcing code in a cpp to be referenced by including it's header.
How this applies to serialization is a matter unbeknowns to me though. :) /Marcus
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.
participants (5)
-
Damien Fisher -
Edward Diener -
Marcus Lindblom -
Peter Dimov -
Robert Ramey