I've been developing a node based editor and figured the TBB Flow Graph would be a perfect fit for my application. However, I can't seem to figure out how to setup the graph. The problem is as follows (I'm also attaching an image to illustrate this):
I have a bunch of nodes, each of which have a varying (not known at compile time) number of input- and output sockets. The nodes that do not have any incoming connections (node 0 and 3 in the attached image) are considered to be root nodes and should be evaluated first. These nodes have edges to the "source_node" node which does N iterations (a run-time value that determines how many times the graph should be evaluated).
The sockets are simply value containers that can either hold an integer, a float, or any other type that is defined by my application (boost::variant)
Node 2 has an additional gray socket, this is simply to indicate that there could be an additional input there, this is not known at compile time.
Now the question is, how do I setup my graph so that each node has access to the values of each of the output ports to which it is connected? So, for example, node 2 needs 3 input values to be able to evaluate successfully. In this case, it needs to grab the values from both Node 0 and Node 3.
I've tried searching for examples, but all that I was able to find were examples dealing with a fixed number of inputs/outputs (e.g. a multifunction_node using a tuple)
Any help would be greatly appreciated!
If you are editing the graph at run time, you'll probably have to decide on a maximum number of ports (TBB terminology for what you called "sockets"), and either write all nodes with that number but only using those they actually need (although you may have to connect unused ports to dummy correspondents for that to work?), or do some form of type erasure where you have a handler that uses port number function arguments and translates them to port number template arguments in a subclass or so (try to do this with automatic code generation where you specify the maximum number of ports at generation time). Just my initial thoughts, but perhaps somebody else has already dealt with this and came up with a better solution?
It seems a recurring problem in C++, where sometimes you want to provide type safety and/or speed at build time, and sometimes you still want to provide flexibility at run time. If the latter is sacrificed for the former, the user may have to work around that. If the former is sacrificed for the latter, you only have the latter. Should TBB strive to have both? That seems like a lot of extra work (would it be worth the effort?), especially if the goal is to interoperate (if a general solution for that can even be found).