Re: [boost] function.hpp: some ideas

From: Doug Gregor (gregod_at_[hidden])
Date: 2001-05-03 12:53:32

On Thursday 03 May 2001 11:10, you wrote:
> > On Thursday 03 May 2001 03:26, you wrote:
> > > Idea 1:
> > > Support for 0 (and only 0) assignment could still be
> > > considered, it does however require a change in the
> > > interface. Here's the idea: 'function' defines an empty
> > > class in its private section, and adds an assignment
> > > operator which takes a pointer to this class. Now the
> > > user can _only_ assign 0 to it. Here's an example:
> > >
> > > class function {
> > >     class assign0 { };
> > > public:
> > >     function& operator=(const assign0 *)
> > >     {
> > >         clear();
> > >         return *this;
> > >     }
> > > };
> > >
> > > Problems arise when there's an assignment operator
> > > which has a parameter that could also be of type
> > > 'int', because then 0 assignment will use that
> > > operator. In function's case, this means that the
> > > assignment operator template has got to go:
> > >
> > >     template<typename Functor>
> > >     function& operator=([const] Functor [&]f)
> >
> > I doubt this will work. If I say:
> > function<...> f;
> > f = 0;
> >
> > The templated operator= will be invoked because when
> > Functor=int, it is a better match (const int& vs. const assign0*).
>
> Exactly, that's why the templated operator= has to be
> removed (that was what I was trying to say :).
>
> 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, because 
the extra copy would require another memory allocation and deallocation. I'm 
not sure the cost is worth it. 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 populace 
that this change is worth it.

> > One additional possibility would be to use the above assign*,
> > but declare a
> > namespace-level variable "nil" of that type and instead allow
> > "f = nil":
> >
> > namespace {
> >   const assign0* nil = 0;
> > }
>
> Yes, but I don't really like this approach, because then
> assign0 is too much exposed.
>
>
> Geurt

If assign0 is hidden in a detail namespace, user's know they've been warned 
not to dig that far into Boost internals. Note that the same thing done for 
"nil" here is done for "ignore" in the tuple code.

        Doug