Please, help us to better know about our user community by answering the following short survey: https://forms.gle/wpyrxWi18ox9Z5ae9 Eigen  3.3.7 Common pitfalls

# Aliasing

Don't miss this page on aliasing, especially if you got wrong results in statements where the destination appears on the right hand side of the expression.

# Alignment Issues (runtime assertion)

Eigen does explicit vectorization, and while that is appreciated by many users, that also leads to some issues in special situations where data alignment is compromised. Indeed, since C++17, C++ does not have quite good enough support for explicit data alignment. In that case your program hits an assertion failure (that is, a "controlled crash") with a message that tells you to consult this page:

http://eigen.tuxfamily.org/dox/group__TopicUnalignedArrayAssert.html

Have a look at it and see for yourself if that's something that you can cope with. It contains detailed information about how to deal with each known cause for that issue.

Now what if you don't care about vectorization and so don't want to be annoyed with these alignment issues? Then read how to get rid of them .

# C++11 and the auto keyword

In short: do not use the auto keywords with Eigen's expressions, unless you are 100% sure about what you are doing. In particular, do not use the auto keyword as a replacement for a `Matrix<>` type. Here is an example:

MatrixXd A, B;
auto C = A*B;
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:

auto C = ((A+B).eval()).transpose();
// do something with C

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 then the `C` expression references a dead object. One possible fix consists in applying `eval()` on the whole expression:

auto C = (A+B).transpose().eval();

The same issue might occur when sub expressions are automatically evaluated by Eigen as in the following example:

VectorXd u, v;
auto C = u + (A*v).normalized();
// do something with C

Here the `normalized()` method has to evaluate the expensive product `A*v` to avoid evaluating it twice. Again, one possible fix is to call .eval() on the whole expression:

auto C = (u + (A*v).normalized()).eval();

In this case, `C` will be a regular `VectorXd` object. Note that DenseBase::eval() is smart enough to avoid copies when the underlying expression is already a plain `Matrix<>`.

# Header Issues (failure to compile)

With all libraries, one must check the documentation for which header to include. The same is true with Eigen, but slightly worse: with Eigen, a method in a class may require an additional `#include` over what the class itself requires! For example, if you want to use the `cross()` method on a vector (it computes a cross-product) then you need to:

#include<Eigen/Geometry>

We try to always document this, but do tell us if we forgot an occurrence.

# Ternary operator

In short: avoid the use of the ternary operator `(COND ? THEN : ELSE)` with Eigen's expressions for the `THEN` and `ELSE` statements. To see why, let's consider the following example:

Vector3f A;
A << 1, 2, 3;
Vector3f B = ((1 < 0) ? (A.reverse()) : A);

This example will return `B = 3, 2, 1`. Do you see why? The reason is that in c++ the type of the `ELSE` statement is inferred from the type of the `THEN` expression such that both match. Since `THEN` is a `Reverse<Vector3f>`, the `ELSE` statement A is converted to a `Reverse<Vector3f>`, and the compiler thus generates:

Vector3f B = ((1 < 0) ? (A.reverse()) : Reverse<Vector3f>(A));

In this very particular case, a workaround would be to call A.reverse().eval() for the `THEN` statement, but the safest and fastest is really to avoid this ternary operator with Eigen's expressions and use a if/else construct.

# Pass-by-value

Using Eigen types with other third party libraries or even the STL can present the same problem. `boost::bind` for example uses pass-by-value to store arguments in the returned functor. This will of course be a problem.