This page documents the Eigen2 support modes, a powerful tool to help migrating your project from Eigen 2 to Eigen 3. Don't miss our page on API changes between Eigen 2 and Eigen 3.

Table of contents

The quick way: define EIGEN2_SUPPORT

By defining EIGEN2_SUPPORT before including any Eigen 3 header, you get back a large part of the Eigen 2 API, while keeping the Eigen 3 API and ABI unchanged.

This defaults to the stage 30 described below.

The rest of this page describes an optional, more powerful staged migration path.

Overview of the staged migration path

The primary reason why EIGEN2_SUPPORT alone may not be enough to migrate a large project from Eigen 2 to Eigen 3 is that some of the Eigen 2 API is inherently incompatible with the Eigen 3 API. This happens when the same identifier is used in Eigen 2 and in Eigen 3 with different meanings. To help migrate projects that rely on such API, we provide a staged migration path allowing to perform the migration incrementally.

It goes as follows:

Step 0: start with a project using Eigen 2.
Step 1: build your project against Eigen 3 with Eigen 2 support stage 10. This mode enables maximum compatibility with the Eigen 2 API, with just a few exceptions.
Step 2: build your project against Eigen 3 with Eigen 2 support stage 20. This mode forces you to add eigen2_ prefixes to the Eigen2 identifiers that conflict with Eigen 3 API.
Step 3: build your project against Eigen 3 with Eigen 2 support stage 30. This mode enables the full Eigen 3 API.
Step 4: build your project against Eigen 3 with Eigen 2 support stage 40. This mode enables the full Eigen 3 strictness on matters, such as const-correctness, where Eigen 2 was looser.
Step 5: build your project against Eigen 3 without any Eigen 2 support mode.

Stage 10: define EIGEN2_SUPPORT_STAGE10_FULL_EIGEN2_API

Enable this mode by defining the EIGEN2_SUPPORT_STAGE10_FULL_EIGEN2_API preprocessor macro before including any Eigen 3 header.

This mode maximizes support for the Eigen 2 API. As a result, it does not offer the full Eigen 3 API. Also, it doesn't offer quite 100% of the Eigen 2 API.

The part of the Eigen 3 API that is not present in this mode, is Eigen 3's Geometry module. Indeed, this mode completely replaces it by a copy of Eigen 2's Geometry module.

The parts of the API that are still not 100% Eigen 2 compatible in this mode are:

Dot products over complex numbers. Eigen 2's dot product was linear in the first variable. Eigen 3's dot product is linear in the second variable. In other words, the Eigen 2 code
x.dot(y)

is equivalent to the Eigen 3 code
y.dot(x)

In yet other words, dot products are complex-conjugated in Eigen 3 compared to Eigen 2. The switch to the new convention was commanded by common usage, especially with the notation for dot products of column-vectors.
The Sparse module.
Certain fine details of linear algebraic decompositions. For example, LDLT decomposition is now pivoting in Eigen 3 whereas it wasn't in Eigen 2, so code that was relying on its underlying matrix structure will break.
Usage of Eigen types in STL containers, as explained on this page.

Stage 20: define EIGEN2_SUPPORT_STAGE20_RESOLVE_API_CONFLICTS

Enable this mode by defining the EIGEN2_SUPPORT_STAGE10_FULL_EIGEN2_API preprocessor macro before including any Eigen 3 header.

This mode removes the Eigen 2 API that is directly conflicting with Eigen 3 API. Instead, these bits of Eigen 2 API remain available with eigen2_ prefixes. The main examples of such API are:

the whole Geometry module. For example, replace Quaternion by eigen2_Quaternion, replace Transform3f by eigen2_Transform3f, etc.
the lu() method to obtain a LU decomposition. Replace by eigen2_lu().

There is also one more eigen2_-prefixed identifier that you should know about, even though its use is not checked at compile time by this mode: the dot() method. As was discussed above, over complex numbers, its meaning is different between Eigen 2 and Eigen 3. You can use eigen2_dot() to get the Eigen 2 behavior.

Stage 30: define EIGEN2_SUPPORT_STAGE30_FULL_EIGEN3_API

Enable this mode by defining the EIGEN2_SUPPORT_STAGE30_FULL_EIGEN3_API preprocessor macro before including any Eigen 3 header. Also, this mode is what you get by default when you just define EIGEN2_SUPPORT.

This mode gives you the full unaltered Eigen 3 API, while still keeping as much support as possible for the Eigen 2 API.

The eigen2_-prefixed identifiers are still available, but at this stage you should now replace them by Eigen 3 identifiers. Have a look at our page on API changes between Eigen 2 and Eigen 3.

Stage 40: define EIGEN2_SUPPORT_STAGE40_FULL_EIGEN3_STRICTNESS

Enable this mode by defining the EIGEN2_SUPPORT_STAGE40_FULL_EIGEN3_STRICTNESS preprocessor macro before including any Eigen 3 header.

This mode tightens the last bits of strictness, especially const-correctness, that had to be loosened to support what Eigen 2 allowed. For example, this code compiled in Eigen 2:

const float array[4];

x = Map<Vector4f>(array);

That allowed to circumvent constness. This is no longer allowed in Eigen 3. If you have to map const data in Eigen 3, map it as a const-qualified type. However, rather than explictly constructing Map objects, we strongly encourage you to use the static Map methods instead, as they take care of all of this for you:

const float array[4];

x = Vector4f::Map(array);

This lets Eigen do the right thing for you and works equally well in Eigen 2 and in Eigen 3.

Finally drop all Eigen 2 support

Stage 40 is the first where it's "comfortable" to stay for a little longer period, since it preserves 100% Eigen 3 compatibility. However, we still encourage you to complete your migration as quickly as possible. While we do run the Eigen 2 test suite against Eigen 3's stage 10 support mode, we can't guarantee the same level of support and quality assurance for Eigen 2 support as we do for Eigen 3 itself, especially not in the long term. This page describes a large part of the changes that you may need to perform.

What about ABI compatibility?

It goes as follows:

Stage 10 already is ABI compatible with Eigen 3 for the basic (Matrix, Array, SparseMatrix...) types. However, since this stage uses a copy of Eigen 2's Geometry module instead of Eigen 3's own Geometry module, the ABI in the Geometry module is not Eigen 3 compatible.
Stage 20 removes the Eigen 3-incompatible Eigen 2 Geometry module (it remains available with eigen2_ prefix). So at this stage, all the identifiers that exist in Eigen 3 have the Eigen 3 ABI (and API).
Stage 30 introduces the remaining Eigen 3 identifiers. So at this stage, you have the full Eigen 3 ABI.
Stage 40 is no different than Stage 30 in these matters.