On Wed, Sep 3, 2008 at 12:34 PM, Emil Dotchevski <emil@revergestudios.com> wrote:
On Wed, Sep 3, 2008 at 12:10 PM, Stjepan Rajko <stipe@asu.edu> wrote:
I have updated the generic support layer docs, and uploaded the new version: http://www.dancinghacker.com/code/dataflow/dataflow/support.html
I just had my first glance at the dataport library documentation and I find it insufficient. Are there any examples on how the library is to be used? Are there any functions that are documented? For example, where is the documentation for the component_operation function template?
Just to be sure - did you only see the generic support layer referenced above or the entire documentation? The full docs are at: http://www.dancinghacker.com/code/dataflow/ BTW, the generic support layer is only provided as an implementation detail of the Dataflow.Signals layer (which is the focus of this review). The documentation of the generic support layer may be helpful in understanding how the library works, but it is by no means complete.
Many people understand the general concepts, but the devil is in the details, and so I think that good documentation is critical for a dataflow library.
A few questions:
I haven't looked closely but I noticed that the library uses operator overloading to connect ports. What is the rationale for using operator overloading?
operators are just syntactic sugar. Instead of a >>= b one can write connect(a,b). The rationale is my belief that in some cases, operator expressions might be more readable and concise. E.g., a >>= b >>= c; instead of connect(a,b); connect(b,c); Ultimately, the user can use whichever method he or she prefers.
Are weak connections supported? Can I connect two nodes in such a way that the connection automatically tears down if one of the components is destroyed?
I used to take advantage of the trackable functionality provided by Boost.Signals (it's just a matter of the library components inheriting from the appropriate class), which accomplishes this goal. At some point, I dropped it partly because the upcoming thread_safe_signals library didn't support that functionality (but I think things may have changed in the meantime), and partly because I ran into a case which didn't seem to be handled correctly by Boost.Signals (Doug Gregor thought it looked like a bug in Boost.Signals, but I never looked into it much further). I can reintroduce support for the trackable functionality in the library if desired (perhaps as an option). Thanks for taking a look! Stjepan