On Mon, Jun 25, 2012 at 4:21 AM, Christoph Duelli <duelli@melosgmbh.de> wrote:
[...]

I have created a class callback that accepts two kinds of Boost.Functions:
one with, one without an error object.

[...]

Some code illustrating my question:

#include <boost/function.hpp>
class ServerError;

template<typename T>
struct callback
{
typedef boost::function<void(T)> cb_func;
cb_func callback_;
typedef boost::function<void(T,const ServerError&)> cb_err_func;
cb_err_func callback_err_;
callback(const cb_func &cb) : callback_(cb) {}
callback(const cb_err_func &cb) : callback_err_(cb) {}
};

static void xxx(int) {}

int main (int argc, char **argv)
{
// does not compile: ambiguous...
callback<int> cb(&xxx);
// does compile: but I'd like the compiler (or my lib) to automatically pick
// the right one
callback<int> cb(callback<int>::cb_func(&xxx));
return 0;
}

[...]

I think this might due to boost::function's templated constructor being unconstrained [1]:

template<typename F> functionN(F);

It looks to me, then, that a void (*)( int ) is, at least superficially, convertible to boost::function< Signature > regardless of Signature (hence the ambiguity), but the body of the converting constructor will only compile if Signature and void ( int ) are compatible. Perhaps worth it to add a boost::enable_if to the functionN constructor to restrict the class of function pointers that can bind to it.

> In the meantime I have found a possible workaround:
> If I change
> typedef boost::function<void(T,const ServerError&)> cb_err_func;
> to
> typedef boost::function<void(const ServerError&,T)> cb_err_func;
> the code does compile.

Okay, never mind, my theory above seem to run counter to this fact :(

- Jeff

[1] http://www.boost.org/doc/libs/1_49_0/doc/html/boost/functionN.html