From: Geurt Vos (G.Vos_at_[hidden])
Date: 2001-04-10 09:47:03
> On Tuesday 10 April 2001 09:21, you wrote:
> > > In any case, what definition of type-strictness are you using?
> > Well, I prefer no conversion at all, so only functions that exactly
> > match the signature are allowed. I can understand, though, that
> > implicit conversions might be desirable, and casting is absolutely
> > undesirable. It can be dangerous from time to time, though. e.g
> > using 'char' when 'int' is required. In the current implementation
> > of 'function', there's no protection against this. Maybe a policy
> > could solve it...
> This is no different from calling any other function. If I pass an int
> char, the compiler will likely give a diagnostic. The same diagnostic will
> occur with 'function'.
Calling a function is only half of what's going on, don't forget
about assigning to the instance, which is what I was referring to.
For calling a function, the implicit conversion (no matter how
dangerous) should simply apply, for assigning to the instance it
shouldn't as it doesn't for regular pointers to functions, which
is what you're trying to mimic here. Take the following code:
void (*p)(int) = MyFunc; // error! can't convert
boost::function<void,int> f(MyFunc); // ok, implicit conversion
The second construction might be useful, but is in this case
dangerous, particularly since there's no way to prevent it.
BC++ 5.5 coughs up the warning "Conversion may lose significant digits",
but in my experience this is the single most ignored warning. MSVC++
warns only at level 4, but I don't think you want to use this level.
It gets worse when user-defined conversions exist, which a compiler
can't warn about.
Concluding, I'm not saying that it shouldn't be possible to assign
functions for which there is no exact signature match. I'm just
saying it should be configurable (through a policy or whatever).
It should be possible to force signature equivalence.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk