Re: [boost] Serialization & XML (was Serialization Library

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-11-25 02:09:47

Dave Harris wrote:

>>You will not need any hooks; to fully bracket the data, you can use a
>>type-conversion trick made concrete below.
> 
> 
> It's a neat trick, but I'd rather not rely on tricks. I might want:

For now, I'm of the same mind. Let's use tricks when a real need is seen.
Explicit end marker is quite appropriate.

>>Yes; I had proposed in an earlier email a seperate serializor which 
>>included the name strings:
>>      return o << "bar" << bar << "foo" << foo ...
>>
>>This would provide the needed names to the system.
> 
> 
> As I understood it, this also relied on a trick - on the XML oarchive 
> assuming that alternate writes were names rather than values. If we sent 
> the same output to a different oarchive, it presumably wouldn't make that 
> assumption and they would be treated as values and repeated in the data of 
> each object serialised. That is quite an overhead. The alternative, that 
> non-XML archives also ignore alternate string writes, is bad too because 
> one archive format should not have to work to indulge vagarities of 
> another. A third alternative, for the object to somehow know when it is 
> writing to an XML archive and serialise differently, is also bad.
> 
> I think such tricks are a bad way to go. I would much rather have 
> something explicit like:
>     ar << tag("bar") << bar << tag("foo") << foo;

I wonder if this explicit enough. Not sure what is most common
use case, but I might want to specify names for several variables
and leave others unnamed, and is afraid of possible confusion.
A better way, IMO, would be:

    ar(bar, "bar")(foo, "foo")(biz);

Note that the third variable has no associated name. Yes, this
completely different from how data is written now. Maybe, "tag"
is OK, after all...

> 
> where the oarchive has a virtual function for writing tags. This also 
> allows:
>    ar << tag("point") << x << y;
> 
> where there is no need for the tags to alternate with values.
> 
> It'd be possible to implement such stuff on top of the current submission, 
> without adding virtual functions to the base classes, by using 
> dynamic_cast. Eg:
> 
>     struct tag {
>         tag( const char *str ) : str(str) {}
>         const char *str;
>     };
>     
>     basic_oarchive &operator>>( basic_oarchive &ar, const tag &t ) {
>         if (basic_tagged_oarchive *p =
>                  dynamic_cast<basic_tagged_oarchive *>( &ar ))
>              p->tag( t.str );
>         return ar;
>     }

I'd prefer virtual functin 'tag' to dynamic_cast.

> Personally I'd rather add the virtual functions, because I prefer to avoid 
> dynamic_cast<>. I'd rather have dynamic_cast<> than make assumptions about 
> alternate writes, though.

Hmm... do you prefer virtual function too? I don't see why we need assumptions
about alternate write, then. Just 'tag' method, if called, given a name for
the followng primitive or composite data item. Archives that do not care 
ignore the call.

> Really we are just talking about 3 functions: start_group(), end_group() 
> and tag(). People who don't need XML output wouldn't need to use them. In 
> practice I think using them would help a lot in producing human readable 
> output. We could probably get rid of the newline() function, for example.

It's harder. I'll need separate markers for sequences, maps/sets and 
composites. This way it's possible to serialize to Python code or YAML,
read the data in Python, and do something sensible with it.

- Volodya