Boost logo

Boost :

From: Fredrik Blomqvist (fredrik_blomqvist_at_[hidden])
Date: 2004-02-25 18:17:55

Arkadiy Vertleyb wrote:
> Dear Boosters,
> We would like to ask for an informal review of our Relational Template
> Library (RTL). In particular we would like to find out whether you
> think that:
> 1) relational algebra is a useful instrument for C++ programmers;
I believe I can see it's potential. It might take a while to become
commonplace but so did the STL and most of boost ;) On the other hand there
should be quite a lot of "database-folks" around that perhaps find this
pretty straightforward?

> 2) The solution based on template meta-programming is suitable for
> such library;
I don't think this is a problem, in fact I don't really see how it could be
made non-intrusive and type-safe and generic and efficient otherwise? (All
properties I expect to find in a modern boost-lib).

> 3) RTL itself is a good start, and, with some changes and
> corrections, can expect to eventially become part of Boost (if not --
Providing that no unforseen showstoppers are lurking in the code or concept
I'd say I'm fairly optimistic about it becoming an accepted boost component.

I would be interested in seeing some performance numbers though. And I would
guess I'm not alone. (This is a C++ crowd after all ;-) ). Providing some,
hopefully encouraging, data similar to what Joaquín did in the indexed_set
documentation for example would be a good start. My experience is that the
deeper sceptics quite often uses performace, rightfully or not, as a means
for rejection... ("virtual functions/smart pointers/rtti/STL/streams/ are
slow", "templates bloat code" etc..)

Finally, as I think David Bergman also expressed in an earlier mail about
RTL, it would(will!) be really interesting to see how the interaction with
RTL, iterator adaptors, a view lib (like VTL), a sequence-wrapped STL
(iterator_range or such) and Lambda functionality will evolve and shape the
future C++!

// Fredrik Blomqvist

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