Boost logo

Boost :

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 << << std::endl;
> >
> > see
> 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




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.


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