Re: [boost] Formal Review Request: TypeErasure

Subject: Re: [boost] Formal Review Request: TypeErasure
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2012-05-24 13:11:59

On May 24, 2012, at 12:48 PM, Steven Watanabe wrote:

> Reflection is really a separate issue.
> 
>> I think our work has different strengths and weaknesses and I would love to find a way to blend it.
>> 
>> Compare:
>> struct vector_concept {
>> 	void push_back( int );
>> 	void push_front (int);
>> 	int size();
>> 	int front();
>> 	int at(int);
>> };
>> BOOST_REFLECT_ANY( vector_concept, (push_back)(push_front)(size)(front)(at) )
>> 
>> boost::reflect::any_ptr<vector_concept>  v( new std::vector<int>() );
>> v->push_back(5);
>> 
> 
> This is a nice interface, but it has several
> limitations that I see no way around:
> 
> a) It supports member functions only
        - does yours support member variables? 
        - or are you referring to more general concepts (operators, free functions, etc)

> b) Overloading is impossible
        - not quite, you would have to extend the macro to enumerate the signature of each method.  I did this in prior versions of the code.  

> Some problems can be solved with difficulty:
> 
> c) there's no way to know the number of arguments
>   at preprocessing time, so you can't declare
>   a regular function.
        that would be difficult.

> that acts something like this for simple cases, though.
> 
>> The way I see it, I was able to define 5+ methods on an interface in one line of easy to understand code.  If you could achieve something like this with your library then it would be a huge win.
>> Mine is implemented in a manner that results in sizeof(reflect::any_ptr) to grow with each member such as 'push_back' is really a public member functor.  Your approach does not have this overhead.
>> My approach allows visiting each member and dynamically specifying an implementation.  Yours enables many more concepts (operators, etc) to be implemented.   Mine could be used by any coder, yours requires one that can throughly understand templates and debug all manner of 'place holders'.   I consider myself skilled and would expect to have trouble implementing something like push_back, especially if it required complex usage of place holders.  Better documentation could help.
>> 
>> Clearly we are solving slightly different problems, and I would love to use your library as a high performance, lower overhead version of my reflect::any_ptr<>  class in places where I do not need some of the more dynamic features.
>> 
>> Good job!   I would probably vote to include it based upon the built-in concepts alone.   Some fancy macro help would seal the deal.
>> 
> 
> I did use macros in the implementation.
> Something like this wouldn't be very
> hard to implement:
> 
> BOOST_TYPE_ERASURE_MEMBER(push_back, 2)
> BOOST_TYPE_ERASURE_MEMBER(push_front, 2)
> 
What does the number 2 mean?   I think this would be great.

Good work, I will probably find use for your library in my own projects.

Dan

> In Christ,
> Steven Watanabe
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost