| 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