-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams
"Brock Peabody" <brock.peabody@npcinternational.com> writes:
2) With this done it's not too hard to write a non-intrusive DSEL for binding on top of it. I wrote one that supports dependent tables, automatic mapping to STL containers, boost::optional, and common data types like boost::posix_time::ptime. A simple example of the language 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. No?
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?