This bugzilla service is closed. All entries have been migrated to https://gitlab.com/libeigen/eigen
Bug 1209 - No conversion from Eigen::Translation or Eigen::Rotation2D to Eigen::Transform
Summary: No conversion from Eigen::Translation or Eigen::Rotation2D to Eigen::Transform
Status: DECISIONNEEDED
Alias: None
Product: Eigen
Classification: Unclassified
Component: Geometry (show other bugs)
Version: 3.2
Hardware: All All
: Normal Compilation Problem
Assignee: Nobody
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 3.4
  Show dependency treegraph
 
Reported: 2016-04-22 15:31 UTC by sogartary
Modified: 2019-12-04 15:43 UTC (History)
4 users (show)



Attachments
A short example reproducing the bug (606 bytes, text/x-c++src)
2016-04-22 15:31 UTC, sogartary
no flags Details

Description sogartary 2016-04-22 15:31:05 UTC
Created attachment 700 [details]
A short example reproducing the bug

The documentation https://eigen.tuxfamily.org/dox/group__TutorialGeometry.html states:

"Any of the above transformation types can be converted to any other types of the same nature, or to a more generic type."

It seems there is no conversion from
Translation<float, 2> or Eigen::Rotation2D<float> to
Transform<float, 2, Eigen::Affine>

Attached is a file with a short code piece illustrating the problem.

The expected behavior is the program to compile without errors.

I have not checked for other types.
Comment 1 Christoph Hertzberg 2016-04-25 10:59:42 UTC
The documentation says that you need to convert from Rotation/Translation to Transform explicitly or by assignment, i.e.
  Eigen::Transform<float, 2, Eigen::Affine> t2 (Eigen::Rotation2D<float>(0));
or
  Eigen::Transform<float, 2, Eigen::Affine> t2; t2 = Eigen::Rotation2D<float>(0);

I don't know the rational why we prohibit implicit conversion at this point? 
IMO, if a class (such as Rotation) is conceptually a subclass of another (in this case Transform), I would expect that they can be converted implicitly. Generally, if there is an assignment operator from A to B, I'd usually expect to have an implicit constructor as well (unless the assigned object is some sort of delegate, such as an Eigen::Map, of course).

The behaviour is the same in 3.2 and 3.3 at the moment.
Comment 2 Gael Guennebaud 2016-04-25 13:44:30 UTC
This issue is reported over and over (like the missing template keyword in method calls).

I guess the main reason is to prevent costly conversion/temporary to occur silently in function calls.

The fact that in c++ T a = b; involves an explicit conversion from type of b to T is really annoying and an unwelcomed side effect.
Comment 3 Christoph Hertzberg 2016-04-25 14:17:18 UTC
I just dug out the discussion we had on that half a decade ago:
http://thread.gmane.org/gmane.comp.lib.eigen/2192

Basically, the question is whether explicit constructors shall only prevent programming errors (e.g., prohibit implicit conversion from size_t to VectorXd), or also help against introducing overhead. I do remember the motivation now -- and there actually is an easy workaround for users who do want to have explicit conversion. I'm still not entirely convinced that this necessarily makes sense (from a user's point of view). E.g.:

void foo(const Transform2d&);
void bar(){
  foo(Translation2d() * Rotation2d()); // works.
  foo(Translation2d());                // does not work!
  foo(Transform2d(Translation2d()) );  // unnecessarily verbose ...
}


Also, in other cases we have no problem with implicit conversion, e.g.:

void foo(const MatrixXd& mat) { }
void bar() {
   ArrayXXd arr;
   foo(arr); // expensive copy of arr into a MatrixXd;
}
Comment 4 Nobody 2019-12-04 15:43:35 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/1209.

Note You need to log in before you can comment on or make changes to this bug.