|Re: [eigen] Eigen2 to Eigen3 Migration Path|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
On Thu, Jan 20, 2011 at 8:00 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> OK here's a proposal:
> we split the EIGEN2_SUPPORT mode into two separate modes:
> EIGEN2_SUPPORT and EIGEN2_FULL_SUPPORT_BREAKING_EIGEN3.
> EIGEN2_FULL_SUPPORT_BREAKING_EIGEN3 means that we guarantee 100% API
> compatibility with Eigen2, which in the case of complex dot products
> means we break the Eigen3 API (x.dot(y) giving a different result in
> the complex case).
> EIGEN2_SUPPORT means that we support Eigen2 API as much as possible,
> while still guaranteeing 100% compatibility with Eigen3.
> To the migration path would be:
> 1. Start with a Eigen2 project
> 2. Replace Eigen2 by Eigen3 + EIGEN2_FULL_SUPPORT_BREAKING_EIGEN3
> (this gives you the Eigen2 API with the Eigen3 ABI, so at this
> stage you can recompile everything).
> 3. Then take care of your complex dot products, i.e. x.dot(y) becomes
> y.dot(x), and replace EIGEN2_FULL_SUPPORT_BREAKING_EIGEN3 by
> EIGEN2_SUPPORT. At this stage, you have the Eigen3 API with just
> convenience support for the rest of your Eigen2 code.
> 4. Now you can work incrementally to remove EIGEN2_SUPPORT file by file.
> Of course it may sound crazy to do all this for a complex dot products
> convention, but really it's not limited to that. There are other
> places where the Eigen2 and EIgen3 APIs depart. Think of Transform for
Wouldn't you still have a problem when including a library that uses
Eigen 2 and another that uses Eigen 3?
For example, in this .cpp file:
In this scenario, where would I put
EIGEN2_FULL_SUPPORT_BREAKING_EIGEN3? If I put it in
lib_using_eigen_2.h then it would be defined when I include
sglaser -at- willowgarage -dot- com