Serialization16 - xml_oarchive std::string representation
Jeff Flinn wrote:
Knowing next to nothing about xml, I'm surprised by xml archive file that I've generated which expresses std::string as in the following example:
<item> <count>3</count> <item>65</item> <item>108</item> <item>108</item> </item>
which corresponds to std::string("All")
Is this intended? Is this representation configurable? The demo_file.xml does not use this representation, rather it generates strings in the form:
<street1>24th Street</street1>
Needless to say the former representation is not very space efficient. For a text archive of 1.2MB I get an xml archive 21.5MB.
Hmmm were you sure to included boost/serialization/string.hpp (or maybe it should be left out). In any case the intention is that strings be automatically represented in a readable way and I would be curious as to how you accidently managed to get around that code.
I am unable to compile(VC7.1) the demo_xml_save project with the following error:
Compiling... demo_xml_save.cpp c:\boost\boost_1_31_0\libs\serialization\example\demo_xml_save.cpp(20) : fatal error C1055: compiler limit : out of keys
This is an issue with the VC 7.1 compiler under the IDE. I had the same thing using VC 7.0 . Its amazing to me they could ship this product without fixing this. I love the MS IDE but it has lots of annoying features of this type. Anyway, this problem doesn't appear when you build with the command line. Also I've had good luck in making it go away by cleaning the projects and rebuilding. If all else fails you can redefine certain macros such as assert with something like: #undef assert #define assert(x) x Which will effectively comment out the asserts which provoke the problem. Robert Ramey
Jeff Flinn wrote:
Knowing next to nothing about xml, I'm surprised by xml archive file that I've generated which expresses std::string as in the following example:
<item> <count>3</count> <item>65</item> <item>108</item> <item>108</item> </item>
which corresponds to std::string("All")
Is this intended? Is this representation configurable? The demo_file.xml does not use this representation, rather it generates strings in the
"Robert Ramey" <ramey@rrsd.com> wrote in message news:20040217170033.74F1431264@acme.west.net... form:
<street1>24th Street</street1>
Needless to say the former representation is not very space efficient.
For
a text archive of 1.2MB I get an xml archive 21.5MB.
Hmmm were you sure to included boost/serialization/string.hpp (or maybe it should be left out). In any case the intention is that strings be automatically represented in a readable way and I would be curious as to how you accidently managed to get around that code.
I am unable to compile(VC7.1) the demo_xml_save project with the following error:
Compiling... demo_xml_save.cpp c:\boost\boost_1_31_0\libs\serialization\example\demo_xml_save.cpp(20) : fatal error C1055: compiler limit : out of keys
This is an issue with the VC 7.1 compiler under the IDE. I had the same thing using VC 7.0 . Its amazing to me they could ship this product without fixing this. I love the MS IDE but it has lots of annoying features of
Yep, I've included boost/serialization/string.hpp which does: stl::save_collection<Archive, std::basic_string<U, Allocator> >( ar, t ); Which wraps each char in <item></item>. Leaving it out causes compilation error: C:\boost\boost_1_31_0\boost\serialization\access.hpp(104) : error C2039: 'serialize' : is not a member of 'std::basic_string<_Elem,_Traits,_Ax>' this
type.
My sentiments exactly!
Anyway, this problem doesn't appear when you build with the command line. Also I've had good luck in making it go away by cleaning the projects and
I'll give this a try. The problem seems related to the demo project that use wLibrary. I have not seen these problems in my own projects using serialization.
rebuilding. If all else fails you can redefine certain macros such as assert with something like:
#undef assert #define assert(x) x
Which will effectively comment out the asserts which provoke the problem.
Hmm, seems rather heavy handed in opening the door to real assertable conditions. Thanks, Jeff
participants (2)
-
Jeff Flinn -
Robert Ramey