Hello.
I'm trying to use the boost serialization library. I'm using Visual C++ 7.1
under Windows 2000. The Boost.Serialization library seems excellent, and its ease of use is great. However I'm having two problems
with it:
First Problem. Here's the code:
cdx::shrec_script script("");
std::ofstream ofs("compiled_shrec.txt");
boost::archive::text_oarchive oa(ofs);
oa << script; // close archive
ofs.close();
I get an error from boost static_assert, static_assert.hpp (below). Line 437 of regexconv.hpp refers to the "oa << script;"
statement. If I copy the script archive to a new const object:
const cdx::shrec_script temp_script(script);
And try to serialize the temp_script object, the error goes away, and everything (seems to) work okay. I don't really have a
problem with copying it, although it is inconvenient, in order to get this to work. However, the real problem is when I try to
de-serialize the class:
cdx::shrec_script script("");
std::ifstream ifs("compiled_shrec.txt");
boost::archive::text_iarchive oa(ifs);
ia << script; // close archive
ifs.close();
I get the same error (below). This is the big problem, because obviously the object needs to be non-const to be altered with the
new data. I tried doing the same trick as above to get it to work (copy to a const object), but I still get the
STATIC_ASSERTION_FAILURE error.
c:\Boost\include\boost-1_33\boost\archive\detail\oserializer.hpp(551) : error C2027: use of undefined type
'boost::STATIC_ASSERTION_FAILURE<x>'
with
[
x=false
]
c:\Boost\include\boost-1_33\boost\archive\detail\oserializer.hpp(551) : see reference to class template instantiation
'boost::STATIC_ASSERTION_FAILURE<x>' being compiled
with
[
x=false
]
c:\Boost\include\boost-1_33\boost\archive\basic_text_oarchive.hpp(78) : see reference to function template instantiation
'void boost::archive::save ::extended_type_info_typeid<class gps_position const >(void)"
(??0?$extended_type_info_typeid@$$CBVgps_position@@@serialization@boost@@AAE
@XZ) boost_test.obj : error LNK2019: unresolved external symbol "public: void
__thiscall boost::archive::text_oarchive_impl<class
boost::archive::text_oarchive>::save(class std::basic_string ::~basic_text_oprimitive boost_test.obj : error LNK2019: unresolved external symbol "public:
__thiscall boost::archive::basic_text_iprimitive ::~basic_text_iprimitive boost_test.obj : error LNK2019: unresolved external symbol "protected: void
__thiscall boost::archive::basic_text_iarchive<class
boost::archive::text_iarchive>::load_override(struct
boost::archive::class_name_type &,int)"
(?load_override@?$basic_text_iarchive@Vtext_iarchive@archive@boost@@@archive
@boost@@IAEXAAUclass_name_type@23@H@Z) referenced in function "private:
virtual void __thiscall boost::archive::detail::common_iarchive<class
boost::archive::text_iarchive>::vload(struct boost::archive::class_name_type
&)"
(?vload@?$common_iarchive@Vtext_iarchive@archive@boost@@@detail@archive@boos
t@@EAEXAAUclass_name_type@34@@Z)
boost_test.obj : error LNK2019: unresolved external symbol "public: void
__thiscall boost::archive::detail::basic_iarchive::load_object(void *,class
boost::archive::detail::basic_iserializer const &)"
(?load_object@basic_iarchive@detail@archive@boost@@QAEXPAXABVbasic_iserializ
er@234@@Z) referenced in function "public: static void __cdecl
boost::archive::detail::load_non_pointer_type ::basic_text_oprimitive boost_test.obj : error LNK2019: unresolved external symbol "public:
__thiscall boost::archive::basic_text_iprimitive ::basic_text_iprimitive Release/boost_test.exe : fatal error LNK1120: 17 unresolved externals
Build Time 0:01
I don't know whether your using 1.32 or CVS version. I also don't know the larger context which would be helpful to explain the issue here. First Problem ========= The general idea is that one use save(Archive & ar, const X & x, ...){ ar << x.members ; } load(Archive & ar, X &x, ...){ ar >> x.members; } OR serialize(Archive & ar, X &x ){ ar & x; } This permits const correctness in that Saving doesn't (and better not because of tracking) change the state of x while Loading will in change it. So a) if you're going to use the << operator make sure the operand is a const reference b) if you're going to use the >> operator make sure the operand is NOT a const reference c) if you're goingto use & it shouldn't be a const. d) If you can't easily do this, DONT make a copy use a cast instead. If you make a copy it will break tracking of redundant saves. Second Problem =========== This pain it the neck is resolved with the next version (1.33) where the serialization library implemetns auto_linking of the correct library for platforms which support it> For now you have to figure it out yourself.
there are a lot of libraries
the ones called ..wserialization are for wide characters - exclude them for now. That should leave only static and dynamic multi-thread versions.
so I tried each one (library). Each produced different results with different linker errors ranging from multiply defined symbols to unresolved externals. One did compile, however:
I assume you meant one did LINK however - great.
But the program crashes as soon as it is run with the error (an uncaught exception):
I'm assuming this may be related to the fact that the 's' in libboost_serialization-vc71-s.lib means that the lib is compiled for single threads, and this is a multi threaded program. But of course, I'm probably wrong.
Hmm using the s.lib with a mulit-threaded CRT library would do it. Try the folloing. a) Try to build and execute the demo program. b) Assuming your using the VC IDE. Look at the *.vcproj files that are included with the package and compare them with your own. c) once you've been able to get the demo to build in your environment, move on to your own app. Good luck. Robert Ramey
Robert Ramey wrote:
I don't know whether your using 1.32 or CVS version. I also don't know the larger context which would be helpful to explain the issue here.
I originally was using 1.32, but when I started having problems with Serialization (about three days ago), I pulled boost off of CVS .
This permits const correctness in that Saving doesn't (and better not because of tracking) change the state of x while Loading will in change it.
You offer great insight on this, it makes sense. I'll try it out as soon as possible and give a reply to let you know how I made out.
Second Problem =========== This pain it the neck is resolved with the next version (1.33) where the serialization library implemetns auto_linking of the correct library for platforms which support it>
Well, just an FYI then, the CVS version still doesn't work when using multi threaded CRTs. :) As I mentioned above, I'm using a 3 day old CVS. I can deal with it, though.
Hmm using the s.lib with a mulit-threaded CRT library would do it. Try the folloing.
a) Try to build and execute the demo program. b) Assuming your using the VC IDE. Look at the *.vcproj files that are included with the package and compare them with your own. c) once you've been able to get the demo to build in your environment, move on to your own app.
I'll take a look, but I've done the following: 1. Create a new project (I'm using Visual Studio .NET 2003) 2. Insert a new source file, paste the (first) example from the Serialization documentation. 3. Change to multi threaded CRTs. The project won't link. The only .lib file that the project will link up with is the serialization*s.lib (the exact name escapes me right now). This isn't to say I probably can't work around this (somehow). And although I *really* hate to scream "bug" and have it be a user error, I am starting to think there may actually be a problem with the library. Thanks again for your insight, it's much appreciated. Brett
Note that the test matrix indicates all demos and examples are compiling, linking, and executing without error with the current CVS and VC 7.1. Exceptions are shared_ptr (which is being addressed) and one of the demos - portable_archive (DLL version) which can't work with VC7.1 Of course these are all built with the bjam system. These problems occur from time to time and up until now have always been traced to a difference in setup between the bjam and the VC 7.1 IDE. I expect that will be the case as well here. One option is to use the solution in the vc7ide directory along with the projects for all the test and demos. Try to build one of the demos from there. (There might be some changes to be made for local directorynames etc). When you've got that, you can compare to your own IDE options. Good luck Robert Ramey
This isn't to say I probably can't work around this (somehow). And although I *really* hate to scream "bug" and have it be a user error, I am starting to think there may actually be a problem with the library.
Thanks again for your insight, it's much appreciated.
Brett
participants (2)
-
Brett Gmoser -
Robert Ramey