From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2004-02-17 12:48:25
"Robert Ramey" <ramey_at_[hidden]> wrote in message
> 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:
> > <count>3</count>
> > <item>65</item>
> > <item>108</item>
> > <item>108</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
> > <street1>24th Street</street1>
> >Needless to say the former representation is not very space efficient.
> >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
> 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
> >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
> fixing this. I love the MS IDE but it has lots of annoying features of
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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk