From be5e2ecc21b5ea22d692d80377301003654789db Mon Sep 17 00:00:00 2001 From: Gael Guennebaud Date: Wed, 2 Sep 2015 13:04:30 +0200 Subject: bug #505: add more examples of bad and correct usages of auto and eval(). --- doc/Pitfalls.dox | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'doc/Pitfalls.dox') diff --git a/doc/Pitfalls.dox b/doc/Pitfalls.dox index 203843ca7..cf42effef 100644 --- a/doc/Pitfalls.dox +++ b/doc/Pitfalls.dox @@ -18,5 +18,21 @@ for(...) { ... w = C * v; ...} In this example, the type of C is not a MatrixXd but an abstract expression representing a matrix product and storing references to A and B. Therefore, the product of A*B will be carried out multiple times, once per iteration of the for loop. Moreover, if the coefficients of A or B change during the iteration, then C will evaluate to different values. +Here is another example leading to a segfault: +\code +auto C = ((A+B).eval()).transpose(); +// do something with C +\endcode +The problem is that eval() returns a temporary object (in this case a MatrixXd) which is then referenced by the Transpose<> expression. However, this temporary is deleted right after the first line, and there the C expression reference a dead object. The same issue might occur when sub expressions are automatically evaluated by Eigen as in the following example: +\code +VectorXd u, v; +auto C = u + (A*v).normalized(); +// do something with C +\endcode +where the normalized() method has to evaluate the expensive product A*v to avoid evaluating it twice. On the other hand, the following example is perfectly fine: +\code +auto C = (u + (A*v).normalized()).eval(); +\endcode +In this case, C will be a regular VectorXd object. */ } -- cgit v1.2.3