Re: [boost] [dynamic_any] multimethods

From: Steven Watanabe (steven_at_[hidden])
Date: 2006-11-30 15:50:39

AMDG

Alexander Nasonov wrote:

> Steven Watanabe wrote:
>   
>> > typedef any_tuple<_1, _1, _2,
>> >   where_<random_access_iterator<_1>, callable<_2, bool(deref_result<_1>, 
>> > deref_result<_1>)> > > sort_args;
>> > void sort_impl(mpl::at<sort_args, _1>::type&, mpl::at<sort_args, 
>> > _1>::type&, mpl::at<sort_args, _2>::type&);
>> > template<class Iter, class F>
>> > void sort(Iter begin, Iter end, F f) {
>> >     sort_args args(begin, end, f);
>> >     sort_impl(get<0>(args), get<1>(args), get<2>(args));
>> > }
>>     
> I don't quite understand how it's connected to dynamic_any::any 
> objects. Does object 1 stores an iterator to a beginning of a sequence 
> while object 2 stores past-the-end of the sequence?
Yes.  In a cpp file sort_impl would just be
void sort_impl(
    mpl::at<sort_args, _1>::type& begin,
    mpl::at<sort_args, _1>::type& end,
    mpl::at<sort_args, _2>::type& f) {
        std::sort(begin, end, f);
}

The idea was the each element of the tuple would be like a 
dynamic_any::any object
with operations on several elements like f(*begin, *next(begin)). So, in 
my example
deref_result<_1> is a placeholder for the type of *begin.  I think it 
would be defined something
like:
template<class>
struct deref_result : placeholder {};

I'm not sure about the functions.  Single functions should be defined 
almost like
what you already have except that there would be many placeholder types.
groups of functions like random_access_iterator need to be made possible.
template<class T>
struct random_access_iterator : compound_concept<...> {};

A similar effect could be achieved by simply putting a boost::tuple in a 
dynamic_any::any.
The advantage of this method is to allow individual objects to be copied 
independently.

I'm mostly wondering whether a significant proportion of the uses
of multimethods could be handled in this way.
>> > Would such a class be useful?
>> > Any better ideas for the interface?
>> > 
>> > The big problem is the amount of metaprograming needed.
>> > 10 operations were more than msvc 7.1 could handle with
>> > my version of dynamic_any::any<> and this is much worse.
>>     
> Definitely. I think, it this case we should find a good balance 
> between compile-time and runtime. I don't like an interface where 
> functions for different arguments variantions are registred at 
> runtime, but if there is no other solution, I can accept it. But in 
> this case it would be better to start with multimethods library and 
> then use it for dynamic_any. Originally, I wanted to get close to 
> untyped languages where you can multiply numbers and strings and 
> things like this. This means that you have a limited set of types 
> (bool, integers, floats, chars, strings and references to objects). 
> This set can be bigger in C++ because you may want to handle 
> references to different base classes differently but it's still, I 
> thought, can be enumerated in one place. All combinations of 20 types 
> gives 400 variants. It's big for mpl::vector but I believe modern 
> compilers can process typelists of this length if a library is 
> carefully crafted.
If the number of types is really fixed then variant would be a better 
solution, I would think.

The method I suggested before:
  template<class Operation, class T>
  struct overload;
allows all the variations associated with T to be loaded the first time
the constructor of dynamic_any::any runs.

Probably to make the lookup
efficient for large numbers of functions, some dynamic loading would be
needed anyway (unless there is some trick I haven't heard of for getting
a unique integer from a type at compile time).  What I currently have is
not very efficient.  It takes about 60 ns. per dispatch for all possible
combinations of a ternary function with 4 types (a total of 64). Compare 
that
to the single dispatch case which only takes about 6 ns.

In Christ,
Steven Watanabe