Jon Stewart on 30 Jul 2003 16:16:27 -0000


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [ALACPP] boost::function shortcoming


> > Of course another approach is to make a dummy function that just toggles
> > a flag if it is called, and then test if boost::function invokes that
> > function.
> 
> But that's not what I want to test.  That just tells me that the over-all 
> system works, that I can assign an arbitrary function to the 
> boost::function<...> magic.  What I want to test is if a particular function 
> was in fact assigned to a particular boost::function<...> foo;.  IE: foo == 
> funcptr;.  Without the ability to do that, I have to form the oppinion that 
> this feature of boost is rather under-implemented.


Well, how is something like this:

static int fooCounter = 0;

void Foo(void)
{
  ++fooCounter;
}

void testFunction(void)
{
  boost::function<> fn;
  TEST_ASSERT(0 == fooCounter);

  fn(); // I forget if this is safe...

  TEST_ASSERT(0 == fooCounter);
  fn = &Foo;
  fn();
  TEST_ASSERT(1 == fooCounter);
}

not testing what you want? It's roundabout, but it is testing a particular 
instantiation of a boost::function.

Now you don't get to write code which makes decisions based off the 
"value" of a boost::function. But that's not a very good thing to do in 
the first place. If you need to have some conditional logic, it belongs in 
a virtual function, or it belongs in the function that the boost::function 
is referring to.


> > Given that operator== is deliberately left undefined, and the way they
> > are doing their abstraction, I can't see a way to do what you want.
> 
> Gavin and I spent some time looking at the docs but didn't come to an 
> understanding of why they deliberatly left == undefined... anyone care to 
> clarify?  They said something about some sort of loophole caused by the 
> safe_bool()?


They allow an implicit conversion to type safe_bool, which I presume lets 
you write code like this:

void Foo(boost::function<> fn)
{
  if(fn) // tests whether fn is empty
  {
    ...
  }
}

However, I think they explicitly mean to disallow operator==. But they 
can't just not declare it as then the comparison between two 
boost::functions would invoke the conversion and you'd end up comparing 
their safe_bool values. Therefore, they declare it to keep the implicit 
conversion from happening, but leave it undefined to give you an error if 
you actually try to use it.

I think they don't want you to use it because it's somewhat difficult to 
explain what equality means for boost::function. I'll investigate further.



Jon
-- 
Jon Stewart
stew1@xxxxxxxxxxx
_______________________________________________
alacpp mailing list
alacpp@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/alacpp