Re: [boost] any_function (callback) library

From: Doug Gregor (gregod_at_[hidden])
Date: 2001-04-09 22:26:50

On Monday 09 April 2001 05:51, you wrote:
> 1) I tried it with CodeWarrior 6.1 on the Mac and it seemed to work
> without any problems. The only change I had to make was to make the
> functions in the test file static.

Great - I'll add a smattering of statics.

> 2) I think there should be a few more tests. Something like the following:
> static int sum_ints(int x, int y) { return x+y; }
> static int sub_ints(int x = 0, int y = 0, int z = 0) { return x-y-z; }
> static std::string identity(const std::string& s) { return s; }
>
>    // compatible types
>    any_function<int, short, short> sum(sum_ints);
>    assert(sum(2, 3) == 5);
>
>    any_function<std::string, char*> ident(identity);
>    assert(ident("foo") == "foo");
>
>    // default arguments
>    any_function<int, int, int> sub(sub_ints);
>    assert(sub(10, 2) == 8);
>
>    any_function<int> sub2(sub_ints);
>    assert(sub2() == 0);
>
>    // cases which should fail to compile
> //  assert(sub(10) == 10);
> //  assert(sub(1, 2, 3, 4) == 10);

I'll add these (and others - need to have testcases for references, arrays, 
etc. for completeness).

> 3) It may be desirable to be able to assign a function that returns a
> result to an any_function that returns void.

Yes, it is desirable. This of course means that I can't rely on void returns 
at all.

> 4) Pointing an any_function at a member function is going to be an
> awfully common operation. IMO this is common enough that it's worth
> adding another ctor: ie "any_function(this, &MyObject::Method)"
> instead of "any_function(bind(this, &MyObject::Method))".

It doesn't hurt anything, though it is a bit of code duplication. Might as 
well add it.

> 5) I agree with Peter that boost::function is a better name.
>
> 6) Trying to invoke an empty function seems like a precondition
> violation to me. Asserting instead of throwing seems preferable.

I disagree because using an assertion means that the check might be turned 
off. If that happens, any_function will cause a segmentation violation. At 
least throwing an exception gives some form of recovery.

> 9) The void* conversion operator allows for comparisons. This sounds
> OK to me, but the current implementation won't produce meaningful
> results.

It can be made not to link with a better-matching, undefined version of 
operator==:

  template<typename F1R, typename F1T1, typename F1T2, typename F1T3, 
           typename F1T4, typename F1T5, typename F1T6, typename F2R, 
           typename F2T1, typename F2T2, typename F2T3, 
           typename F2T4, typename F2T5, typename F2T6>
  bool operator==(
        const any_function<F1R, F1T1, F1T2, F1T3, F1T4, F1T5, F1T6>&,
        const any_function<F2R, F2T1, F2T2, F2T3, F2T4, F2T5, F2T6>&);

Similarly for other operations that are valid with const void*.

        Doug