Subject: Re: [boost] [review] Dataflow Review starts today, September 1st
From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-09-03 17:26:22
On Wed, Sep 3, 2008 at 12:34 PM, Emil Dotchevski
> On Wed, Sep 3, 2008 at 12:10 PM, Stjepan Rajko <stipe_at_[hidden]> wrote:
>> I have updated the generic support layer docs, and uploaded the new version:
> 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
Just to be sure - did you only see the generic support layer
referenced above or the entire documentation? The full docs are at:
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
> 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
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!