Reconsider EIGEN_DEFAULT_TO_ROW_MAJOR
Submitted by Hordur Johannsson
Assigned to Nobody
Link to original bugzilla bug (#422)
Version: 3.0
Description
Created attachment 254
Example that fails linking
I recently came across a potential problem caused by providing the EIGEN_DEFAULT_TO_ROW_MAJOR define.
The problem is when you are using libraries built with different options then there can be problems during linking because MatrixXd will have a different types depending on whether -DEIGEN_DEFAULT_TO_ROW_MAJOR was used or not.
This makes it hard to use libraries compiled with different options in the
same programs. Because when you include headers with MatrixXd, the type
doesn't reflect the type when the library was built.
I've attached a minimal example with program c.cpp that uses libraries a.cpp and b.cpp that are compiled with and without -DEIGEN_DEFAULT_TO_ROW_MAJOR. This causes c.cpp failing to compile, because Eigen::MatrixXd isn't the same type in a.o and b.o.
If someone runs into this problem there are few options:
- Re-compile library b.cpp with the -DEIGEN_DEFAULT_TO_ROW_MAJOR
- Modify the header files for library b to
void b(Matrix<double, Dynamic, Dynamic, ColMajor> M); - Re-organize my code so that I do not include a.h and b.h
in the same compilation unit.
Option 1. is probably easiest but sometimes one uses pre-packaged libraries, e.g. Ubuntu packages.
Option 2. would be good, if library developers ensured to be explicit on
ordering on their public interfaces. By not providing
EIGEN_DEFAULT_TO_ROW_MAJOR means that MatrixXd has an explicit ColMajor
ordering.
I see the usefulness with having the EIGEN_DEFAULT_TO_ROW_MAJOR, but I'm worried that it can lead to incompatibilities.
Is there some better way to handle this?
Attachment 254, "Example that fails linking":
eigen_ordering.tar.gz