Re: RE: [boost] Optimization of MPL expression?

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2003-09-12 18:42:48

Hi Brock,

----- Mensaje Original -----
[...]
> 
> > 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.
> 

Well, there's an additional detail for aliasing these MPL sequences
as I do. Not only index_list is an MPL sequence, but also the
class tag<> for specifying tag names for a given index. Now, if
I drop the alias in index_list for consistency I'd have to do the same
in tag. But this cannot be done easily. Index specifiers unique
and non_unique accept either of the following two instantiantion
styles:

  [non_]unique<KeyExtractor,Compare=less<KeyExtractor::result_type> >
  [non_]unique<TagList,KeyExtractor,Compare=less<KeyExtractor::result_type> >

At first, this seems like it cannot be done, but in fact it can with
some MPL magic: the trick lies in accepting (at compile-time) up to
three template parameters and determining whether the first is
a tag list or not. This check cannot be (easily) done if TagList is just any
MPL forward sequence, so tag<> has some internal "markers"
to help do the job.

I hope I made myself clear, the issue is rather messy. Conclusion
is that I'd rather keep these aliases. I'm open to discussion, though :)
> 
> > 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.
> 

I'd like to have more opinions on this. Many boosters are macro
hackers for legitimate reasons.

> 
> 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");
> 

Looks good! What is the library aimed at? Planning on boosting it?

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

No standard name that I know of. We could call it "tagged types" :)

Best,

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