Andrey Tcherepanov wrote:
Oh, no... I think the fact that Boost.Function allows storing of null pointer ("there is no function to call") is a good thing!
Well, if you like the possibility of invoking undefined behaviour, it is surely a good thing. I would rather have the type system and the exception mechanism make sure that can never happen.
Otherwise it will need to store some sort of "default" function that returns ... seriously, what is default function would be? Say we have
Func<bool(void)> f;
That line would be an error. Not allowing function to be empty means no default constructor, obviously.
To disallow default constructor (no argument passes) completely will be way too limiting
I don't really see how. If you want a function that might or might not be there, you can use optional<function<sig> >.
it is a encapsulation of function with pointer to function sort-of behaviour, not reference to it.
Yes, the reason Boost.Function behaves that way is to be consistent with function pointers. But maybe it could actually try to be better than these and provide safer guarantees.
If you completely need to be sure that there is something to call underneath it (like to avoid thousand checks for empty value), just (wrap and) assign some dummy function.
Making a wrapper is of course possible. It seems fairly weird though to make a wrapper around an optional container to make it unoptional rather than the other way around. A component should have as little features as possible to be complete, and then one is to combine components to have more refined ones with more features. Also, I don't really know how Boost.Function behaves when copy constructors inside operator= throw, but depending on how it does it it could lead to a potential empty object. It's not really trivial to ensure the never-empty guarantee when using stack allocation (SBO). Putting dummy functions is of course out of the question.