(sorry been away from mail over the last 3 days)- I wanted to respond that JOAQUIN LOPEZ MU?Z Writes: "> If you'd care to sketch what kind of dynamic multi_index

you have in mind (from the user point of view) maybe we can come out with some solid design to implement in future releases of the lib. My intention is to stay away from relational stuff, but I'll go for a dynamic container if it can be made general purpose."

I *very* much want to take you up on this- tonight (about 12 hours from now) I will write something up and show you what I did.

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of JOAQUIN LOPEZ MU?Z Sent: Friday, October 15, 2004 12:06 PM To: boost@lists.boost.org Subject: Re: RE: [boost] Library Proposal: database (boost::db)

Hi Brian,

----- Mensaje original ----- De: Brian Braatz <brianb@rmtg.com> Fecha: Viernes, Octubre 15, 2004 6:56 pm Asunto: RE: [boost] Library Proposal: database (boost::db)

[...]

...

I am currently going down this exact path and wanted to share what I ran into:

1- Boost does not have a 2dim "Table<>" - i.e. a Recordset 2- Boost.multi_index only works with concrete structures I would love it if I could use that to make a dynamic Table\ recordset

What do you mean by concrete structures?

...

3- I have had to build my own Table<> by internally using boost.multiindex

Do you mean, you have actually built a Table<> class using Boost.MultiIndex?

[...]

...

I believe boost is missing a "recordset" analolgy and I would hope thatwhatever is created is not "struct only" like boost.multi_index. (don't get me wrong I LOVE the multi_index - it just doesn't work dynamically)

Well, in the past I thought about what a dynamic_multi_index_container (with run-time specification of indices) could look like: the implementation internals are not hard to solve with the same framework as Boost.MultiIndex, it is the interface that I don't have a clear idea about. Also, I don't envision a clear usage scenario for this, and there are RTTI-like issues involved as well (what should get<N>() return?)

If you'd care to sketch what kind of dynamic multi_index you have in mind (from the user point of view) maybe we can come out with some solid design to implement in future releases of the lib. My intention is to stay away from relational stuff, but I'll go for a dynamic container if it can be made general purpose.

On another topic, have you considered Arkadiy's RTL as another source of ideas/synergies? Seems like Arkady sort of diverted to his BOOST_TYPEOF facility, so I don't know what the current status of the lib is.

Joaquín M López Muñoz Telefónica, Investigación y Desarrollo