From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-11-24 14:20:24
Douglas Gregor wrote:
> On Monday 24 November 2003 12:16 pm, Sam Partington wrote:
>>I see two problems with the current implementation of bool_testable :
>>1/ The is_convertible problem above.
>>2/ Binary logical expressions with a bool_testable derived class on either
>>side are ambgious in VC6, VC7, and VC7.1. Thus:
> I wouldn't hold this against bool_testable; it seems obvious to me that VC is
> wrong here.
>>Can we work around these problems? The original ptr-to-member design
>>avoids both of them, but introduces a problem if the user provides their
>>own integer conversion operators.
> There is no perfect solution, I'm afraid.
I guess the only solution is providing documentation for Peter's idiom
and show why users should use it instead of any other "solution" :)
>>Can we use enable_if or is_convertible to provide a best fit solution for
>>the class in question?
> Other than hacking is_convertible to first perform an is_base_and_derived
> check to deal specifically with bool_testable, I don't see a good way around
I also thought about this but it feels screwed. I don't want any
dependency for is_convertible to the operators library. Even if
is_convertible would offer an open plug-in architecture, this doesn't
feels right, although further investigating might be an option...
anyway, we have a better alternative...
>>My own feeling is that even if we can't find a solution to those two
>>problems then bool_testable is still a sufficiently useful addition to the
>>operators library for it to remain. I think it seems an obvious omission
>>from the operators library - providing all operators except bool
>>comparison. Of course this problem should be reflected in the documentation
>>if we cannot solve it.
As I said above, documenting Peter's idiom is an alternative. AFAICS the
best we have so far...
> extra work to make it pass. Assuming we can't find a clean is_convertible
> workaround, at what point is it just easier to follow the ptr-to-member
> Another (minor?) issue with bool_testable: either the documentation (or,
> better yet, the code) should note/enforce that bool_testable types should
> have operator== or operator!= unless the user explicitly creates them (see,
> e.g., the "poisoned" operator== and operator!= in the Function library). I'm
> not sure if this would suffice:
Both idioms don't have a problem with operator== / operator!=, so they
are equally good at that point. Two arbitrary bool_testables won't
compare as the comparison is ambiguous (bool or int?). Or were you
refering to a different example (or am I missing something)?
PS: I will ask Thomas for the fast-track-review...
-- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk