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