Subject: Re: [boost] An alternative approach to TypeErasure
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-06-24 19:48:27
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
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
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
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:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk