Re: [boost] An alternative approach to TypeErasure

Subject: Re: [boost] An alternative approach to TypeErasure
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-06-24 19:48:27

AMDG

On 06/24/2012 03:55 PM, Pyry Jahkola wrote:
> On 2012-06-24 14:21:32 +0000, Steven Watanabe said:
> 
>> I don't think your approach is fundamentally
>> very different from mine.
> 
> Not fundamentally. But what do you think about the API of my library? I
> found it easier to understand when you see the "member" functions almost
> as is in the template arguments, and you don't have to invent names like
> ostreamable for some more domain-specific functions.
> 

I believe that it should be possible
to give a decent name to any top-level
concept.  Of course, if your main concept
has multiple functions, it may not be
possible to give a good name to each one.
In this case, I think a convention like
has_push_back<void(int)> would be good
enough.

Overall, I'd say that I like the way
your interface looks, but I wouldn't
choose to do it that way, just because
I'm pedantic about the overload resolution
and ADL issues that I pointed out in
another post.

One of the things I dislike about your
interface is that it's necessarily based
on individual functions.  With mine,
composite concepts like copy_constructible<>
and forward_iterator<> are used in exactly
the same way as the base single-function
concepts.

Finally, I'm beginning to consider the
details of the definitions less important,
since I think the cleanest interface
for defining new members will end up
having to use macros.

// A concept called custom::has_push_back
// for a member function called push_back
// that takes 1 argument.  Example usage:
// has_push_back<void(int)>.
BOOST_TYPE_ERASURE_MEMBER((custom)(has_push_back), push_back, 1);

(I have an initial implementation of
this macro, but I still need to finish
the tests and documentation.  With variadic
templates I can eliminate the "1" argument.)

>> The way you handle template arguments
>> to poly::interface makes it impossible to
>> create this kind of mutually recursive any.
> 
> Hmm, that's right. But I'm a bit puzzled by not being able to think of a
> good real-world example of such problem.
> 

This kind of situation should happen
very rarely if ever.  I was just pointing
it out for the sake of completeness.

In Christ,
Steven Watanabe