From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-10 07:47:58
At 1:19 PM +0300 4/10/01, Peter Dimov wrote:
>From: "Jesse Jones" <jesjones_at_[hidden]>
>> At 12:02 AM +0300 4/10/01, Peter Dimov wrote:
>> >From: "Jesse Jones" <jesjones_at_[hidden]>
>> >> 6) Trying to invoke an empty function seems like a precondition
>> >> violation to me. Asserting instead of throwing seems preferable.
>> >I agree with most of your points, however invoking an empty function must
>> >throw for boost::function<T&> to be default constructable. (What would
>> >return from op() if it didn't throw?)
>> There's no need to return anything. The client failed to meet his
>> obligations so the function can do anything it likes. In this case it
>> will crash on most OSs. But that's OK. :-)
>But you need to return something for the code to compile.
>Returning *(T*)0 is not a good practice. :-)
You return the result of calling a nil function pointer. This will
crash on a decent OS, but that's hardly unusual for precondition
>I think that the exception-throwing version can be quite useful.
Why? This seems like an obvious precondition to me. We tell clients
not to invoke empty function objects. If they don't then we can do
whatever we want. In a debug build we should assert. In release
precondition violations should never happen, but of course they will
since testing is never perfect. The desired behavior is dependant on
the app, but few will want to throw on every violation. I have zero
problems with crashing in these cases. (Although as I've mentioned
before I'd prefer a customizable assert macro).
>FWIW, my own implementation first returned a default-constructed
>return_type, then I thought about changing it to a precondition violation,
>but in the end I decided in favor of the exception-throwing semantics. Why
>litter the code with
1) It parallels what you would do with an ordinary function pointer.
2) Why call a function if it's empty? Exceptions should be used for
errors. This smells too much like using exceptions to control program
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk