C ++ Eigen Matrix澄清

Question

I have only recently started exploring C++ Eigen library and a little puzzled with some of the documentation. It would be great if someone can clarify this.

1. In the common pitfalls ( https://eigen.tuxfamily.org/dox-devel/TopicPitfalls.html ) Alignment Issues section, it says " Indeed, since C++17, C++ does not have quite good enough support for explicit data alignment.".

   The page on how to get rid of alignment issues ( https://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html#getrid ), the documentation says, "If you can target [c++17] only with a recent compiler (eg, GCC>=7, clang>=5, MSVC>=19.12), then you're lucky: enabling c++17 should be enough" .

   So is alignment not an issue with Eigen Matrix if I am using c++ 17 with gcc>=7.0? Have I understood this right? And that the macro EIGEN_MAKE_ALIGNED_OPERATOR_NEW won't be needed? And if this is correct, what is different between c++14/c++17 which takes care of the alignment issues?

2. The second question is regarding the pass-by-value section ( https://eigen.tuxfamily.org/dox-devel/group__TopicPassingByValue.html ). The documentation claims that pass-by-value could be illegal and could crash the program. This is very puzzling to me. Wouldn't pass-by-value just invoke a copy constructor? As an example.

Eigen::Vector3f veca = ComputeVecA();
Eigen::Vector3f vecb = veca; //< If pass-by-value is unsafe, is this operation safe?

3. And lastly, can I rely on RVO/NRVO for Eigen fixed sized matrix class? I suspect the answer to this is yes.

Answer 1

In the common pitfalls ( https://eigen.tuxfamily.org/dox-devel/TopicPitfalls.html ) Alignment Issues section, it says "Indeed, since C++17, C++ does not have quite good enough support for explicit data alignment."

This seems to be a typo. It should say "until C++17" instead of "since C++17" because C++17 actually added support for allocation with extraordinary alignment restrictions. Two comments agree with me.

The page on how to get rid of alignment issues ( https://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html#getrid ), the documentation says, "If you can target [C++17] only with a recent compiler (eg, GCC >= 7, Clang >= 5, MSVC >= 19.12), then you're lucky: enabling C++17 should be enough."

So is alignment not an issue with Eigen Matrix if I am using C++17 with gcc >= 7.0? Have I understood this right? And that the macro EIGEN_MAKE_ALIGNED_OPERATOR_NEW won't be needed?

Yes.

And if this is correct, what is different between C++14/C++17 which takes care of the alignment issues?

C++17 supports Dynamic memory allocation for over-aligned data . operator new now properly allocates over-aligned memory with the align_val_t argument.

The second question is regarding the pass-by-value section ( https://eigen.tuxfamily.org/dox-devel/group__TopicPassingByValue.html ). The documentation claims that pass-by-value could be illegal and could crash the program. This is very puzzling to me. Wouldn't pass-by-value just invoke a copy constructor?

If the variable is a local variable (as vecb in your example), then the compiler and the library take care to ensure that vecb meets the special alignment restriction required by Eigen. However, if the variable is a function parameter, this alignment restriction is not respected, meaning the program may operate on ill-aligned memory, thus crash. (This has little to do with the copy constructor.)

And lastly, can I rely on RVO/NRVO for Eigen fixed sized matrix class? I suspect the answer to this is yes.

The answer is pretty much the same for Eigen classes and other classes: try and see. Usually the answer is yes.

Answer 2

• Q1: as already commented, this was a typo when updating this paragraph for c++17. This is already fixed.

• Q2: I don't remember all the details about this one but it is related to two technical issues.

  1. Some compilers failed to properly align the stack, in this case it is hopeless to get aligned function parameters.
  2. Old ABI specifications did not allowed overalignment of function parameters. I would expect that since c++11 and the usage of the standardized alignas keyword this is not an issue anymore, but maybe this is still a problem on some exotic compiler-OS combinations.

• Q3: there is nothing preventing RVO/NRVO, and from my experience when it can apply it does apply.