From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2000-03-13 12:23:27
> Having looked at the documentation, but not the code, I think this is
> beautiful work.
> If I thought this could have been carried to a conclusion
> anywhere nearly this satisfactory I would have pursued it myself months
I started work on this last year, it was only in January that I met up with
Jaakko and his BL library and that has made all the difference.
> The things I can find to criticize so far are:
> 1. It's a little disturbing that you can write 'obvious' things which
> compile and 'should' work, but fail only at runtime, e.g.
> > for_each(a.begin(),a.end(), cout << ", " << free1); //valid, but wrong
> > for_each(a.begin(),a.end(), cout << constant(", ") << free1); //ok
> Incidentally, wy doesn't the first one work, if your example "free1+5"
> work? How does the user know when she must write constant()?
I can see that this will need some getting used to. Expression templates
will try to do things once. For evaluating constants this is what you would
int x, y;
transform(a.begin, a.end(), x + y + free1);
will make a temporary of x+y and add the result of that to the argument of
> 2. Naming: It's best to avoid abbreviations, so I don't like 'var'. I
> 'argument' would be much more descriptive than 'free'. 'create_ptr'
> create a pointer, it creates an object on the heap (maybe 'new_object'?)
Ok, new_object would be fine with me.
var, is a little harder for me because if you have to write the fully
qualified name everywhere its going to be hard to read and understand.
for_each(a.begin(), a.end(), boost::ll::variable(x) = boost::ll::argument1,
boost::ll::argument1 = boost::ll::varible(y),
boost::ll::variable(y) = boost::ll::variable(x)
line breaks help but....
> 3. Documentation. You've done a remarkably thorough job of documenting
> especially for an alpha release,
> a. I'd like to see you qualify all names with their respective
> That will give a much better picture of how it would look in real,
> best-practices C++ code.
Ok, but I never use that style in my real work except in files which have
name collisions. IMO it makes it too hard to read.
> b. Occasionally, you reveal implementation details which only seem to
> confuse the issues, without giving the user additional expressive power:
> > int i = 0;
> > int j;
> > for_each(a.begin(),a.end(), (var(j) = free1, free1 = var(i), var(i) =
> > var(j)));
> > The delayed variables and constants can be defined outside the labmda
> > expression as well:
> > int i = 0; int j;
> > var_type<int>::type vi(var(i)), vj(var(j));
> > for_each(a.begin(),a.end(), (vj = free1, free1 = vi, vi = vj));
> > constant_type<int>::type five(constant(5));
> > for_each(a.begin(),a.end(), (vi = five, free1 = vi * constant(6) ));
> Why would anyone want to write it that way? It's much harder to read than
> the original.
> Your control-flow examples could benefit from some well-chosen line
> Incidentally, aren't there some parens missing around the suboordinate
> clauses of the while_loop?
> 4. I would think a lambda version of ?: would be more important than
> if_then_else... how 'bout it?
Sorry, can't overload ?:, in fact overloading new, delete, -> and ->* don't
work either because they have a defined return type, which is not what you
want in this case.
Thanks again for all the comments.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk