On 10/27/2010 12:57 PM, Bart Janssens wrote: > So to rephrase my question: > let's say I want to evaluate proto expression "_cout << A * B * C". To > do this, I traverse the tree and the following should happen: > 1. B * C gets evaluated first, into an (Eigen) expression template > that stores a reference to B and C. This is OK, since B and C are not > temporaries.
Yes. > 2. A*(result of B*C) gets evaluated, which may produce something > that stores (result of B*C) by reference Yes. > 3. The final expression result is output using <<, and at that point > the Eigen expression templates execute, expecting that all the > referred variables still exist. Yes. And they do because all the temporary objects that have been created live until the end of the full expression, which includes the output expression. > So how can I make sure the (result of B*C) gets stored somewhere? (result of B*C) is a temporary object (X) that holds B and C by reference. A*(B*C) is a temporary object (Y) that holds the temporary object (X) by reference. This is all kosher. However, that's not what your example was doing. Your example was RETURNING the equivalent of A*(B*C) from a function. NOT GOOD. The temporary object (X) dies at the end of the full expression in which it was created. That's the return statement. By the time you try to traverse the expression to evaluate it, (X) is dead and buried. > If I > can do that, then I can use this stored data to construct the > A*(result of B*C) step, and it's safe even if it is done by reference. You should be asking yourself why you're trying to return expression templates from a function. If you really need to do that, then you can't go returning references to temporary objects. > For more complex expressions, all the steps in the tree would need to > be stored like this. Once the call to operator<< finishes, this > "temporary tree" can be discarded. > > The problem I have here appears to be general to expression template > matrix libraries, before Eigen we used our own matrix lib, and it > exhibited the same problem. Right. This problem has nothing at all to do with Proto. -- Eric Niebler BoostPro Computing http://www.boostpro.com _______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto