|
Boost : |
From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2002-10-31 19:06:46
"Beman Dawes" <bdawes_at_[hidden]> wrote in message
news:4.3.2.7.2.20021031133216.01f165a0_at_mailhost.esva.net...
> It would be particularly useful if it worked well with a serialization
> library.
Sure.
RTL itself has no serialization and its usability depends on how well it can
work with serialization libraries. RTL will need some sort of serialization
to achieve persistence or support for client/server.
Let us look for our needs. There are 3 kinds of objects to serialize in RTL:
1. Relations and internally used classes (polices, etc.). They are compact
and I don't see any problems with serializing them using the serialization
library.
2. Table implementations, i.e. classes, which actually store data. Formally
they are not part of RTL, but to make RTL useful we need have them ASAP, and
they need to be serializable. Now we have only std::vector, but looking for
something like B-trees.
It is easy to serialize whole container (vector, map or B-tree); however,
such approach is inefficient.
Good table implementation requires partial serialization, (e.g. a node of
B-tree needed to be loaded and stored). It is complicated because a node
consists of one ore more user-defined objects.
3. User data. It can be either basic types, or user-defined class. User
expected to provide serialization for his/her classes. Size of image (in
bytes) may vary between different classes and between objects of the same
class.
If you you know how to address second issue, it will be very helpful.
> Might be an interesting test case for the serialization library review
next
> week.
Thanks for the invitation.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk