Re: [ALACPP] boost::function shortcoming

[Christopher Smith <x@xxxxxxxx>]

On Tue, 2003-07-29 at 23:44, Greg Underwood wrote:
> 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.

I think you can get around this by having the following regression
tests:

1) The test that boost::function<..> can wrap an arbitrary function.
2) The test that the target function works.
3) The test that the boost::function works as per the test in #2, but
invoking the boost:function.

> > 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()?

I believe the answer is pretty well summed up in that article is that
the process of coming up with what operator== should actually do is
fairly complex, may very well have unwanted side-effects, and they
didn't want to do the wrong thing. The article does suggest a logical
rules for implementing operator==, but I suspect some other problem will
probably show up with even his approach, and it'll take a little while
longer to get it totally right.

-- 
Christopher Smith <x@xxxxxxxx>
_______________________________________________
alacpp mailing list
alacpp@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/alacpp