Re: [boost] Review: Function library

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-06-08 10:10:39

On Friday 08 June 2001 03:09 am, you wrote:
> On Thursday, June 7, 2001, at 05:36  PM, Douglas Gregor wrote:
> >> I think that function<>::operator= should be implemented with a call to
> >> this->set() for simplicity.
> >
> > I didn't do this only because it would cost (yet another) copy of the
> > incoming function object.
>
> It wouldn't. The parameter is a reference, and passing it would not cost a
> copy. It would cost nothing (given a reasonable compiler with inlining on)
>   to call this->set instead of repeating the code.

Depends on the compiler you are using. Because some compilers don't yet have 
(working) function template partial ordering, sometimes the function objects 
are passed around by-value so that I can tell a function pointer from a 
function object using the type traits "is_pointer" template. It's an 
unfortunate hack required by several off the compilers.

> >> The library defines a class nil_t and an object nil. While it's nice to
> >> have these around, they are not mentioned in the documentation, and I'm
> >> not sure they belong in the function library. And I think the library's
> >> design works fine without these -- it seems more a matter of personal
> >> taste that they are included.
> >
> > They exist because we can't easily have:
> > boost::function<> f;
> > f = 0;
>
> True, but we have "f.clear()" for this.
>
> I agree that nil is nice, and if it's there "f = nil;" and "if (f == nil)"
> should work. But I don't think that nil is needed to make a reasonable
> function library.

It is just syntax, and doesn't affect the functionality at all.

> As I said, it seems a matter of personal taste that you've included them,
> and I'd prefer to introduce them across the library. It bugs me a bit to
> have a nil that does not work well with shared_ptr, for example.

It is a matter of personal taste, of course. I prefer the operator-centric 
interface (assignment operator, conversion to bool, == nil, etc.) to the 
object-oriented interface (set(), clear(), empty()) very strongly. shared_ptr 
could easily be made to work with nil (that's what the other thread is 
about...)

> >> The code that says "// Poison comparisons between functions" declares
> >> but does not define the == and != operators. Is this better than simply
> >> not defining the == and != operators for these particular parameter
> >> types? If this poisoning is necessary for == and !=, why isn't it
> >> necessary for other operators? Is there some way to make comparisons
> >> between functions fail at compile time rather than link time?
> >
> > Good point... yes, I can make the operators private members of
> > boost::function so using them would fail at compile time.
>
> You still didn't answer my question: "Is this better than simply not
> defining the == and != operators for these particular parameter types?"
> Why don't you get the desired effect by just leaving them not declared?
> Why is "poisoning" required?
>
> > The other operators aren't as much of a concern, because users accustomed
> > to
> > function pointers won't typically use operator< or operator+ on them.
>
> A program that uses those operators will get a compile time error.
>
> > Function pointers support operator== and operator!=, so I wanted to
> > explicitly poison them so it is certain that they are not (will not) be
> > supported by boost::function.
>
> I still don't get this "poisoning" concept. If there is no operator ==
> declared, there is no operator ==. It's not automatically created by the
> compile in the way that operator =, the copy constructor, the default
> constructor, and the destructor are. Isn't that right?

Yes, see Peter Dimov's post (conversion to const undeletable* allows 
operator== to work on function objects)

> >> Many of the ifdefs at the top of function_base.hpp to define BOOST_
> >> symbols look like they belong in boost/config.hpp instead.
> >
> > They do. They're in function_base.hpp so that I don't need to supply the
> > whole config.hpp. I didn't want to tie the boost::function package to any
> > specific version of the Boost libs while it was in development; the
> > ifdefs will move to config.hpp at some later point in time.
>
> If there was a comment that said that, I would be more than satisfied.
>
>      -- Darin

Sure.

        Doug