Re: [boost] Re: Re: Re: Re: Re: relationaltableasanSTLcontainer--anyinterest?

From: Joel de Guzman (djowel_at_[hidden])
Date: 2002-11-01 23:31:43

----- Original Message ----- 
From: "Arkadiy Vertleyb" <vertleyb_at_[hidden]>

> 
> "Joel de Guzman" <djowel_at_[hidden]> wrote in message
> news:01ce01c28215$891a1ff0$0100a8c0_at_kim...
> 
> > BTW, if you wish to have the tup.field syntax, you might find
> > inspiration in boost.spirit closures. Example syntax:
> >
> >     struct my_tuple : tuple_fields<my_tuple, std::string, int, int>
> >     {
> >         member1 name;
> >         member2 id;
> >         member3 age;
> >     };
> >
> > Then:
> >
> >     my_tuple tup;
> >     std::cout << tup.name << std::endl;
> >
> > see http://spirit.sourceforge.net/index.php?doc=docs/v1_5/closures.html
> 
> Here you explicitly define your fields, which makes impossible something
> like projection or cross-product.

Perhaps. What I am just trying to say is that there are lots of ways
to do what you want to do without using a macro. What I presented 
are just examples.
 
> As far as boost::tuple is concerned, I need some time to consider pros and
> cons.
> 
> By the way, what are the objections against our current approach?  One, as I
> understand, the need for macro.  Another is that boost::tuple is already
> widely used throughout the library.  Anything else?

I'd say primarily the macro. The tuple is secondary. As I said, 
macros such as COLUMN are sure to clash with existing code. 
In a multi-library package such as boost, the convention
is to prefix it with BOOST_LIBRARY_NAME_. Thus, your
column macro will be something like 

    BOOST_LIBRARY_NAME_COLUMN.

and 

    BOOST_LIBRARY_NAME_FIELD

Ahh, the namespace "rel" I think is too short for a library and 
can potentially clash. 

> Just to re-iterate, we currently define a class for every column.  This
> class contains a placeholder for the value.  The name of this class serves
> as the column name.  Columns (classes) get combined in a typelist, which is
> passed to the tuple, which inherits from all of them.  Static_cast is used
> to access individual fields.

To reitarate, I really like your approach. What I think can be
improved, though, is the syntax. I'd really want to use an
in-memory data base in the near future.

Regards,
--Joel