Boost logo

Boost :

From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2008-03-28 18:32:33


Hi!

I think Proto should be accepted for inclusion into boost.
A general purpose Expression Template library is hard to write.
Proto is the most sophisticated and closest approach to
perfection available today.

- What is your evaluation of the design?

Proto is well-designed in many aspects, though I got the
impression that some beauty and purity was sacrificed
on the altar of compile-time efficiency, but that's OK.
(And yes, I hate BOOST_PP_MACROS!)

Proto catches the most important issues of a general purpose
expression template library, I especially like the way
how expression storage and expression evaluation is strictly
separated and the way I can add my own functionality.

Proto covers the most important aspects of an ET library,
sometimes in very elegant ways.

Proto's design adressed compile time issues. That's a value in itself.

OTOH: Transforms leave me with mixed feelings.
I am not very good at catching ideas without good step-by-step
documentation and I got messed up with grammars vs. transforms.
This part of proto is new and it looks like a candidate for rework.
I'd like to have an extra review in half a year only on the grammar
and transform part of proto (*)[comment below].
That's a DSEL all by itself and I guess that interface may have some
pitfalls. Larry Evans has worked that out in detail.
There may be issues in the naming convention used there,
e.g. I am unsure whether and_ is the appropriate name for what it does.

- What is your evaluation of the implementation?

None. Not enough time. Steven Watanabe did it for us all.
Code looks clean. For my taste too many levels of nested
namespaces, but that's the boost trend at the moment.
I may appreciate this style later in my life, once I understand
why you need it.

- What is your evaluation of the documentation?

The quality varies from excellent to hard to read.
I agree with all what David writes about the docs.
There is some potential for improvement, but that should not
hinder the inclusion into boost: we need a community
effort here since Eric's skill level probably is way too high
in order to have some feeling for why the unaware might have
problems with parts of the doc. The teacher should be one
step ahead, not too far ahead.

- What is your evaluation of the potential usefulness of the library?

We really, really need this. Better today than tomorrow.
The whole world is waiting for this to come.
And C++ again rocks

- Did you try to use the library?

A couple of hours, but only for some of the examples.

- With what compiler?

VC8, Intel 10.1

- Did you have any problems?

Nope. Eric-faster-than-lightning fixed those before I could
run into them ...

- How much effort did you put into your evaluation?

I read the docs three times and worked through some details.
I investigated the type representation of expressions
by reading purposely generated compiler error messages
and tried to figure out the design.

- Are you knowledgeable about the problem domain?

I had several attempts to write some kind of ET library on my own,
some parts published at daixtrose.sourceforge.net. I also
planned to write something like proto myself, but due to lack of
time and programming skills I lost the race before it began.
(rm -rf /work/markus/ideas/expresion_templates_revisited)
Eric, thanks for the time saved by the publication of proto.

Markus

P.S. This review is short, sorry. I had some unexpected tasks
to do the last week which hindered further investigation.
I'll put some more effort into this in the future.

(*) I'd like to have an extra review on _every_ boost library
in a 2-year-cycle. By this boost::multi_array could probably be forced
to model assignable like any other STL container and ::_1 from
boost::bind will move into its own namespace - just to mention
my two favourite change requests ...


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk