[boost] Re: Serialization16 - xml_oarchive std::string representation

From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2004-02-17 12:48:25

"Robert Ramey" <ramey_at_[hidden]> wrote in message
news:20040217170033.74F1431264_at_acme.west.net...
> 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.

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>'

> >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.

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