# boost function conversion woes

This topic is 2895 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Suppose I have
typedef boost::function<void (double,double)> voidFunct_2dbl;
typedef boost::function<void ()> voidFunct_void;


The compiler claims that the call to AddAction is ambiguous, even though neither type can be converted to the other. What can I do?

##### Share on other sites
Can you post the code that's actually generating the error?

I probably couldn't answer your question without doing some experimentation and/or research myself, but if you're trying to pass in an arbitrary function object, the compiler would (presumably) have to try to resolve the ambiguity by trying to match the argument with function's own constructor template. Whether or not it can do this, I'm not sure (again, I'd have to research it a bit).

If you're just looking for a solution though, I imagine that if you were to make the boost::function typedefs public (if they're not already) and then call AddAction() like this:
my_object.AddAction(MyType::voidFunct_2dbl(my_function_object));
Then that would resolve any possible ambiguity.

##### Share on other sites
Here's the code that generates the error

        myManager->AddEntity((new TriggerBrush(myManager, 70,0,1540,768, false))            ->AddAction(trigStartColossusFight(myManager,mycfmanager)));

    class trigStartColossusFight    {        const entitymanager_ptr myManager;        const cf_collmanager_sptr myCFmanager;        public:        trigStartColossusFight(entitymanager_ptr targetmanager, cf_collmanager_sptr collisionmanager);        void operator()(double arg1, double arg2);    };

##### Share on other sites
Hm, I'm afraid I don't have any insights beyond what I mentioned earlier. My best guess is still that the compiler, for whatever reason, isn't able to resolve the ambiguity by way of the function constructor template.

I may be overlooking something though - maybe someone else will spot this thread and provide some additional feedback. In the absence of a better answer though, I'd recommend just giving the functions different names, or trying my previous suggestion (that is, making the argument type explicit so as to resolve the ambiguity).

• 9
• 10
• 18
• 13
• 10