Compiler error: try_put call is ambiguous (tbb::flow) EDIT: SOLVED

Compiler error: try_put call is ambiguous (tbb::flow) EDIT: SOLVED

ahelwer's picture

I have created the following simple program:

#include 

#include 
class Body {

public:

    std::string m_name;

    Body(std::string name) : m_name(name) { }

    void operator() (tbb::flow::continue_msg) const {

        printf("%sn", m_name.c_str());

    }

};
int main() {

    tbb::flow::graph g;

    tbb::flow::continue_node start(g, Body("Start"));

    start.try_put(tbb::flow::continue_msg());

    return 0;

}

However, when compiled with icc I get the following error:

flow.cpp(16): error: "tbb::flow::interface6::continue_node::try_put [with Output=tbb::flow::interface6::continue_msg]" is ambiguous start.try_put(tbb::flow::continue_msg()); ^ compilation aborted for flow.cpp (code 2) This is for the version of TBB that comes with Composer XE 2011 sp1.9.293. Why does this happen? It compiles just fine on other versions - specifically, it compiles with Composer XE 2011 sp1.6.233.

EDIT: I managed to find the problem.

Turns out when you're calling try_put on a continue node in the newest version of tbb, you have to specify that it's the continue_receiver try_put function you want. It conflicts with one of the other classes continue_node inherits from (not sure which one). So the call on line 16 looks like this:

start.tbb::flow::continue_receiver::try_put(tbb::flow::continue_msg());
Looks really ugly. I guess Intel is trying to say not to explicitly call try_put on continue nodes?

3 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Christopher Huson (Intel)'s picture

Hello, ahelwer,

Thanks for reporting the error. Part of the recent implementation of the multifunction_node involved factoring the function_node to reuse the code in the output array. This resulted in an extra overload of try_put for all nodes using the function_node output. (We wanted the same name, try_put(), to work with the output from multifunction_node.)

The test case for the continue_node did not detect the ambiguity because it used an explicit cast of the continue_node tothe receiver type that resolved it, so I didn't detect the error until shortly before the most-recent release (too little time to add the fix.)

The workaround is just what you discovered (explicit reference to receiver).

Regards,
Chris Huson

Christopher Huson (Intel)'s picture

Hello, ahelwer,

One additional note: just executing a try_put() to a node will cause tasks to be enqueued and executed. You might notice the test program gets a segmentation fault.

Because tasks are enqueued, you must execute

g.wait_for_all();

to ensure all the tasks complete before the end of the main program.

Regards,
Chris

Login to leave a comment.