Re: [boost] Optimization of MPL expression?

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2003-09-12 05:55:15

Brock Peabody ha escrito:

> OK, first I'd like to say that I think this is a great idea and your
> implementation looks very good.  A few questions/suggestions I thought of:
>
> 1) Why use index_list instead of letting the user choose one of the mpl
> containers?
>

I wanted to hide MPL from the user. Picture yourself a potential
average user reading the tutorial and, when it comes to the specification
of indices, being referred to the MPL documentation! She'd probably
be scared away. MPL is terrific, but IMHO is not a library every
programmer would want to be exposed to.
Besides, the MPL sequence used must be a forward sequence, not
every sequence is valid. A lot of technical mess for such a simple
application.

>
> 2) I can't think of any way to do it, but it would be nice to be able to
> say:
>
>    member<&employee::name>
>
> instead of:
>
>    member<employee,int,&employee::name>
>
> maybe this isn't possible.
>

I think it is not possible. There was a discussion about this very issue
some weeks ago, Dave Abrahams was very conclsuive about the
impossibility of having such an utility.
With macros, one can reduce the complexity a little to something
like

BOOST_MEMBER(employee,int,name)

or even one can have

BOOST_MEMBER(employee,name)

if typeof() is provided (which some compilers do provide).

If there's some consensus about this being desireable, it can be
plugged into the library in a matter of minutes.

>
> 3) What do you think of the possibility of automatically deducing (unique)
> indexes from key type?  For instance:
>
>    indexed_set<
>       employee,
>       unique<member<employee,std::string,&employee::name> >,
>       unique<member<employee,double,&employee::height> >,
>       unique<member<employee,double,&employee::weight> >
>    > employees;
>
>    cout << "Bob's age: " << employees.at("bob").age << endl;
>
> This is legal because there is only one unique key type that char* is
> convertible to.
>
>    cout << "Employee that weighs 150.3: " << employees.at(150.3) << endl;
>
> This is invalid because 150.3 could refer to height or weight.
>

This can be done, but would it be such an useful functionality? I guess
most classes used as elements of indexed_set will have some coincidence
of types (the likelihood growing as the number of indices do), rendering
this unusable. Consider

struct person
{
  string name;
  int age;
  int year;
};

typedef indexed_set</*indices on all members*/> person _set;
person_set ps;

cout << "Person whose name is Joe: " << employees.at("Joe") << endl;
cout << "Person whose name is Joe: " << *employees.get<age>find("Joe") << endl;
cout << "Person whose name is Joe: " << *employees.get<year>find("Joe") << endl;

The differences in syntax for essentially the same thing are awkard.
Worse yet, you could be forced to rewrite expression involving at() in terms of
find() if, say, you add a new index to the element class.

>
> ---
>
> Anyway, I know I have needed this type of library many times in the past and
> I think your implementation of it is excellent.  Have you submitted it for
> review?
>

Yes, a couple of days ago. It is not formal review, though.
Hopefully, it this gains some interest I would happily step
to formal stage, someday.

Thank you for your interest in indexed_set, regards,

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