From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2006-05-01 08:12:54
----- Mensaje original -----
De: bwood <brass_at_[hidden]>
Fecha: Lunes, Mayo 1, 2006 0:45 am
Asunto: Re: [boost] [Boost Review] Do property_tree and
> Please correct me if I'm wrong, but it seems B.MI's
> serialization forces you to receive a B.MI instance with the
> same number of indices as was sent.
Correct. In fact, you're required to use the very
same type (i.e. container definition) on loading that
you used on saving.
> While on one level it is
> impressive that B.MI preserves the relative order of equal
> elements, it has a cost. If you have a B.MI with 3 indices
> in a server and only need one or two indices in a
> client, you have some work to do. In order to accomplish
> this I think you would have to receive a B.MI with the same
> indices as was sent and then write code that copies the
> contents of that B.MI to either a simpler B.MI or an STL
> container. Does the preservation of the relative order of
> elements matter more than this sort of flexibility?
Well, my approach to B.MI serialization looks to me a natural
one, in which if one saved a T then it is a T that it must
be loaded. AFAIK there's no scenario (excepting this
discussion) where loading Qs from saved Ts is ever
Now, I'm not denying the potential usefulness of a
serialization approach like you propose: it is just
that I don't have any feedback about how B.MI serialization
capabilities are being used to make an educated decision,
and what I settled for has at least the benefit of
consistency with other serialization implementations.
In the meantime, it is easy to have less stringent
serialization of B.MI containers by simply saving
their elements according to its first index (similarly to
what your own middleware service does), which can
be implemented without built-in support from B.MI itself.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk