- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have created the following simple program:
[cpp]#include
#include
class Body {
public:
std::string m_name;
Body(std::string name) : m_name(name) { }
void operator() (tbb::flow::continue_msg) const {
printf("%s\n", m_name.c_str());
}
};
int main() {
tbb::flow::graph g;
tbb::flow::continue_node<:FLOW::CONTINUE_MSG> start(g, Body("Start"));
start.try_put(tbb::flow::continue_msg());
return 0;
}[/cpp]
However, when compiled with icc I get the following error:
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:
flow.cpp(16): error: "tbb::flow::interface6::continue_node
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:
[bash]start.tbb::flow::continue_receiver::try_put(tbb::flow::continue_msg());[/bash] Looks really ugly. I guess Intel is trying to say not to explicitly call try_put on continue nodes?
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page