Re: [boost] Re: Callbacks Again

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-19 14:07:50

In message <200011182216.OAA20114_at_[hidden]>, Jesse Jones
<jesjones_at_[hidden]> writes
>>> However the conversion
>>> rules make const void* much more type safe than bool's.
>
>Well maybe much was an over statement. :-) It is pretty safe though. It's 
>not like you can just treat a callback as a pointer. For example, "int* 
>p= (int*) callback" won't compile.
>
>>I've yet to see any arguments that convince me of this.  The opposite 
>>was decided for boost::any (though they removed the implicit 
>>conversion entirely, I believe, which may or may not be appropriate 
>>here).
>
>My recollection is that Kevlin thought a const void* conversion was 
>better than a bool conversion, but someone pointed out that that allowed 
>two any objects to be compared with bad results which was enough to shoot 
>down the conversion operator. Callbacks present exactly the same problem 
>any faced.
>
>From my POV I think bool conversions should pretty much never be used and 
>const void* conversions should only be used where you can provide 
>comparison operators yourself.

What finally convinced me of dropping the UDC on any was that any was a
combination of things. One of which was safety over convenience, and the
other is that the UDC is very much a smart pointer usage, which any
categorically is not.

For function smart pointers, the case is slightly different. For a
start, there is a strong and justified expectation that they look and
feel like pointers, including -- often -- conversion semantics.

I also tend to be reluctant to include named functions in interfaces
that otherwise use only operators, eg if empty is the only named
function in the interface (which in my function pointer classes it would
be) it looks inconsistent.

However, against this is some of the fun and games we know we can have
with both operator bool and operator const void *, and the
implementation/representation challenge presented by the latter case if
we are to choose a pointer. In this respect, it is like any (and
certainly that was the way I approached my implementation). But in spite
of the challenge, I lean towards exploring a conversion-based approach,
with relational operators disabled as necessary.

Clearly, if we stipulated that function objects should be in some way
comparable, we would have an obvious alternative path, but this path
definitely has the wrong kind of leaves, so is not really one to follow
(sorry, British Rail joke for those not in the know).

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________