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