|
Boost : |
From: Jesse Jones (jejones_at_[hidden])
Date: 2000-11-17 19:57:26
>On Fri, 17 Nov 2000 15:31:35 -0800
>Jesse Jones <jejones_at_[hidden]> wrote:
>
>> >> >> This makes it tougher to include the bool
>> >> >> conversion (how do we know if a functor has a real target or
>> >> >> not?), which I consider essential.
>> >> >
>> >> >The bool conversion can be handled by inclusion of a default
>> >> >constructor that sets the "impl" pointer to null.
>> >>
>> >> Yep (of course a const void* conversion would be better than bool).
>> >
>> >Would it? Didn't we decide the opposite for boost::any?
>>
>> Yep. Now that I think about it void*'s aren't quite right here either. If
>> all you had were free functions you could return the function address. This
>> would still allow you to compare differently typed callbacks, but at least
>> you'd get the correct results. However you can't really do this with
>> functors...
>
>I don't think that comparison of callbacks should be an issue. The standard
>library functors cannot be compared, so unless we are going to extend the
>notion of a callback target beyond that of a functor, we shouldn't be
>dealing with comparisons.
But we know that we want to have some sort of empty test. If we do this
with a bool or const void* conversion operator users will be able to
compare any two callback objects, but in all probability this will return
false unless you're dealing with the exact same callback on the left and
right. We can document that comparisons don't work as expected, but it
seems better to arrange for a compile error if the user does something
wrong.
-- Jesse
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk