|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-01-22 08:59:54
Douglas Gregor wrote:
> On Wednesday 21 January 2004 10:27 am, Peter Dimov wrote:
>>>> bind(f, ref(a)) == bind(f, ref(b)); // true or false?
>>>
>>> Now _that_ is an interesting corner case.
>>>
>>> If we say it's "true", I think we're being true to the notion that
>>> reference_wrapper really is like a reference. But, of course, it's
>>> obvious to us that those two function objects won't always give the
>>> same results.
>>
>> Indeed, and note that "true" implies that it would be ill-formed
>> when a and b cannot be compared, which is rather common for
>> ref()-passed objects (identity semantics, noncopyable).
>
> I'm not sure that's a bad thing...
Time will tell. At the moment, it seems to me that ref(x) == ref(y) means &x
== &y (at least in bind() context).
>>> Whatever we do, I do not want reference_wrapper to have its own
>>> operator==.
>>
>> Sounds reasonable, although such an operator== doing a pointer
>> comparison is the technically trivial thing to do here.
>
> Right, but it changes the semantics of reference_wrapper<T> because
> the underlying operator== can be found through implicit conversion to
> T&.
Yes, you are right. But there's a corner case here, too. If the underlying
operator== relies on a user-defined conversion, it won't be found. I'm not
sure this is a bad thing. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk