From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2005-08-14 22:24:42
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> On Behalf Of David Abrahams
> "Brock Peabody" <brock.peabody_at_[hidden]> writes:
> > 2) With this done it's not too hard to write a non-intrusive DSEL
> > binding on top of it. I wrote one that supports dependent tables,
> > automatic mapping to STL containers, boost::optional, and common
> > types like boost::posix_time::ptime. A simple example of the
> > might look like:
> > table("customer") [
> > *field("id") = &customer::id,
> > field("name") = &customer::name,
> > field("number") = &customer::number,
> > table("tax_exempt")[
> > -field("customer"),
> > field("state_id") = &tax_exempt_data::state_id
> > ]
> > = &customer::tax_exempt
> > ];
> This feels like it has some overlap with the serialization library.
I haven't studied Boost.Serialization in detail yet, but I'd say they
should overlap in at least a few ways:
1) Objects that support this interface should automatically support
Boost.Serialization. This will be useful if your objects live in
databases but are sent over sockets, for instance.
2) This library should use the same syntax as Boost.Serialization when
doing the same things.
3) The implementation may be able to exploit Boost.Serialization for
some compositions such as containers and pointers (and optional and
variant!) but I'm not sure.
Maybe the overlap is that the new library uses boost.serialization in
its implementation and supports a superset of its syntax?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk