Boost logo

Boost :

From: Eric Niebler (eric_at_[hidden])
Date: 2008-03-26 11:55:23

Noah Stein wrote:
> Eric,
> I spent a few hours the other week trying to convert my last matrix-vector
> class library over to proto. It implemented expression trees, but I’d never
> gotten around to adding some features that proto should make much, much
> easier to implement such as expression optimization. I figured it would be a
> good way to experiment with the library to review. I eventually gave up on
> refactoring my class towards proto and instead tried refactoring your
> lazy_vector example towards my class. It's raised some questions/points.
> I'll illustrate with questions that are based on your lazy_vector example.
> 1) lazy_vector seemed like it could derive from lazy_vector_expr in CRTP
> fashion. I figured your use of std::vector<T> as the terminal type was just
> to make initialization easier;

??? It's a lazy_vector. My use of std::vector<> has nothing to do with
initialization. It's to hold a vector of elements.

> however, using CRTP fails to compile. Did I
> miss this in the documentation or is it not explicitly mentioned?

What failed to compile? Can you show me the code?

> 2) How can I handle scalar values transparently? My attempts to accept
> "v1=v2*5" have failed. I can't get the 5 to implicitly construct into a
> scalar_vector type I have defined. I had that working in my old one, but I
> can't seem to figure out the correct way of setting that up in proto.

In proto, literals like 5 are converted to terminal<int>::type by
default. It sounds like what you want is for int terminals to be treated
as a vector of scalars. There are a couple of ways to approach this.

1) At some point, you'll need to evaluate the expression, perhaps with
proto::eval() and a custom context class. In your context, you can add a
handler for int terminals and treat them like scalar vectors. This is
what I would do.

2) Before you evaluate an expression that may contain int terminals, you
can apply a proto transform that replaces all int terminals with scalar
vectors. This is probably not the ideal solution for you, unless you
need to do other transforms, too (like expression optimization).

3) You can cause int terminals to be converted into scalar vectors on
expression construction by using a custom generator. Think of a
generator as a very simple transform that is applied to every new
expression that proto creates for you. In the lazy_vector example, the
lazy_vector_domain is defined like this:

// Tell proto that in the lazy_vector_domain, all
// expressions should be wrapped in laxy_vector_expr<>
struct lazy_vector_domain
   : proto::domain<
       , LazyVectorGrammar

proto::generator<> is a simple generator that takes any expression type
and wraps it in lazy_vector_expr<>. You could write one that first turns
scalar terminals into scalar vectors, and then wraps them in

(3) is workable, but I would discourage it (see below). (2) is the Proto
Way (tm), but might be tricky for someone who doesn't yet know
transforms. (1) is also the Proto Way (tm) and might be the simplest
thing to do.

> 3) My vector class' signature is very simple: template<typename T> class
> Vector : VectorExpr<terminal<T> > .

You probably mean VectorExpr<terminal<T>::type>, right?

> The type T contains a number of traits
> defining the vector: the type of the elements, the dimension, how the data
> is stored. I can't figure out how to specify the terminals in my grammar. In
> your example, you use terminal<std::vector<_> > as your terminal. The
> std::vector part is unknown to me. That's my point of variation in my vector
> concept thus I can't know all the different types that could be used in the
> terminal. I tried deriving my storage classes from a common base class;
> however, that failed. Is there any way to encode some sort of restriction
> in the grammar for this situation? Right now, I'm using _, but that's
> clearly not a great solution.

If you have derived your storage classes from a common base, then try
this to match your terminals:

     , proto::if_< is_base_and_derived< common_base, _arg >() >

> Proto looks very interesting. I was quite excited the first I saw it
> mentioned. There seems to be a lot of power there. I just need to figure out
> how to use it. You have a lot of documentation, but it seems to be attacking
> the problem from the opposite direction I'm approaching from, so it's been a
> little slow going. I hate asking questions about something I can investigate
> on my own, but I'd like to get far enough along that I can properly review
> it.

Yes, Proto comes at the problem differently than other expression
template libraries, because it's not really an expression template
library. It's a library for building domain-specific languages. In
Proto, the expression template itself, and the operator overloads that
build it, are rather incidental. The focus of Proto is what you *do*
with the expression once you have it. So rather than asking, "How can I
get Proto to build the type I want," you might ask, "How can I get the
behavior I want from the types Proto builds." The answer for that is
usually either: (a) write a context, or (b) write a transform.

While you can certainly get Proto to build you the type that you want,
that's not Proto's natural mode of operation. By default, Proto builds
an abstract tree representing the expression, with little or no
domain-specific information in it. All the domain-specific knowledge is
centralized in your domain's contexts or transforms. The reason I did it
this way was to facilitate cross-domain interoperability. The same
expression can mean one thing in one domain and something else in a
different one. That allows expressions from different domains to be
intermingled freely, as with semantic actions (lambda domain) in a
grammar (parser domain). Or consider the placeholder terminal _1. You
would like that to mean different things to bind, lambda, spirit, karma,
phoenix, xpressive, etc. If it were a proto terminal, all these
libraries could use the same terminal -- it's just syntax -- and the
semantics could vary by library.

I hope this gets you a little farther along.

Eric Niebler
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at