Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at