RE: [boost] Optimization of MPL expression?

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-09-12 11:57:15

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Joaquín Mª López Muñoz
> Sent: Friday, September 12, 2003 4:55 AM
> To: Boost mailing list
> Subject: Re: [boost] Optimization of MPL expression?
> 
> 
> 
> Brock Peabody ha escrito:
> 

[...]

> 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.

On the surface this seems like a good argument, but I really don't think we
want every boost library that needs typelists to roll their own just so the
users don't have to see the MPL.  If you want to hide the MPL and keep the
user from having to choose a container you could use a using declaration to
bring mpl::vector in to indexed_sets.

[...]

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

I think it's a good idea.  Macros are better than redundancy IMHO.

[...]

> 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.

You're completely right.  It seemed cool to me at the time because I was
thrilled that it was even possible, but it is a pretty bad idea.

[...]

> 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.

Good luck!  FWIW, I just put together a 'remote_function' library that uses
a similar naming technique:

   struct get_widget_count;
   struct set_widget_name;

   typedef mpl::list<
      named_function<get_widget_count, int ()>,
      named_function<set_widget_name, void (int,std::string)>
   > widget_functions;

   remote_function::client<widget_functions> client(ip_addr, port);

   cout << "Num widgets: " << client.call<get_widget_count>() << endl;

   client.call<set_widget_name>(2, "number 2");

I wonder if there is a name for this technique.  Maybe some day we'll be
able to do true compile time strings other than:

   boost::mpl::vector_c<char,'h','e','l','l','o'>

Brock