Stjepan, I finally finished this week's task for GSoC, so here is my review of your headers: ***1. Documentation*** 1.0: What I like: - You provide excellent motivating examples - You have good arguments for why one should use the library - Your concepts are well thought out - You have extensive code examples that clearly have taken you a lot of time and thought to produce - All of the code examples provide a good depth of what the library is capable of doing 1.1: Nit Picks - Table 1. is hard to read on my monitor, and determine what, if any, hierarchy exists - The section titled "Namespace Use" should be in a section called "How to use this documentation" - In the section named "Dataflow.Signals - based on Boost.Signals", you should indicate that the example encountered previously in the documentation is Dataflow.Signals, or provide another example - The section labelled "Creating your own signal receiver (slot)" should continue using the "fused vs unfused" table paradigm - On page "Disconnecting", 0u is not a number. - You should provide examples of compiling/linking your program for those who do not exclusively use bjam. - There should be a table for all of the components that acts as a "use me when..". When I was trying to write my example, I had only a vague idea of when I should use any of the components, and wasn't sure if I was doing something wrong. I used primarily filter<> and counter<>, as my storage needs were more complicated than I could discern the storage<> class being helpful (I may be wrong.. I only had a few hours to try to do this). ***2. The library:*** 2.1: What I Like: - The "blueprint" layer sounds fantastic. - It is very generic, allowing for all kinds of possibilities, but provides enough specific examples that one can see how it would be useful - I like the networking examples using Boost.Asio 2.2 Questions: - What is useful about a "chain"? Is it that operator() is called n times on the object it receives, where n is defined by the template parameter? 2.3 What could use improvement: - Is there any way you can include something that takes a function pointer of an existing function and makes a function object from it? // Not sure off the top of my head this would work, but something along these // lines could be nice #include <cmath> filter<double (double), unfused> my_filter = make_filter_unfused(&sin); ***3.0 Sample program*** I tried to make a sample program, but ran into problems. gcc threw errors when I attempted to connect() two components, saying "error: invalid use of undefined type 'struct boost::dataflow::extension::signals::get_slot<(void ()(const std::string&), ....>". I'm not going to ask you to debug it, and I got a pretty good feel for everything by writing the code. Overall, I felt that the experience was a little cumbersome, but that for complicated networks the benefits would far outweigh the extra time it takes to define individual components. I merely attempted to do some string processing, which could have easily been dealt with in C++ through more conventional means, but I can see how the plug-and-chug methodology makes algorithm design much easier, were one to have many pre-connected components. Good work so far, Jake