From: Geurt Vos (G.Vos_at_[hidden])
Date: 2001-05-04 03:07:31
> > When there's no op=(const Functor &), assignment to
> > 0 will call op=(const assign0 *). Assignment to a
> > functor/function will simply call the (non-explicit)
> > templated constructor.
> Ah, interesting. We'd pay for this usefulness in efficiency, however,
> the extra copy would require another memory allocation and deallocation.
> not sure the cost is worth it.
Well, you could use reference counting :)
> The general feeling was that the "f = 0"
> syntax was less obvious than "f.clear()" (even though it mimics function
> pointer syntax better), so it would be tough to convince the general
> that this change is worth it.
Hmm, I would say if I can assign a function pointer, it is
only natural that I can also assign 0. Additionally, since
'if (f)', or better 'if (f !=/== 0)' is possible, it again
makes 'f = 0' an obvious possibility.
Then to clear, everyone will understand what will happen
when clear() is called. However, its counterpart: set() does
not exist, which might be seen as not-really-consistent.
Note that I'm not saying support for 'f = 0' is crucial, I'm
just saying that IMO 'it's not obvious' is not a very strong
> If assign0 is hidden in a detail namespace, user's know they've been
> not to dig that far into Boost internals. Note that the same thing done
> "nil" here is done for "ignore" in the tuple code.
One should not repeat the errors of the past...
...but seriously, 'nil' specifically for 'function' doesn't
feel right. There's nothing 'function' about 'nil'. I mean,
'nil' on its own is not related to function (at least that
is not how the user will see it). Having a general boost::nil
in e.g. nil.hpp or whatever sounds (somewhat) better.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk