|
Boost : |
From: Jake Voytko (jakevoytko_at_[hidden])
Date: 2007-08-12 15:37:15
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk