Re: [eigen] RotationBase times DiagonalMatrix

[ Thread Index | Date Index | More Archives ]

On 23.09.2011 19:31, Gael Guennebaud wrote:

sorry for not being very responsive. First we all agree that C++ not
being able to make use of an explicit constructor when you write T a =
b; is very stupid, but that's not the real question here. The real

Actually I would not agree on that. If I have a class, which happens to have a constructor like this:

class MyUberClass {
  // ...
  explicit MyUberClass(const double& someImportantInitialValue);

Then I would expect that
  MyUberClass a = 0.0;
does not work (and it does work that way), while
  MyUberClass a(0.0);
does work. The first case would look as if MyUberClass could represent a double, which it does not can (it just happens to need one for construction).

Also -- maybe more important -- if I have a function which expects a MyUberClass and I accidentally pass a double I expect that not to work. This, I would say, is again a case I would expect to work for Eigen::Transform/Eigen::Translation (passing a Translation to a class which expects a Transform), because a Transform *is a* Translation.

I would rather say that it does not make sense to have a

class A {
  A(const B&);
  A& operator=(const B&);

where operator= does essentially the same as the constructor, but declare the constructor as explicit. Here, conceptually, I would say that class B *is a* class A, thus B can be assigned to A and A can be (implicitly) constructed from B.

question is do we want that Translation to Transform conversion
happens being the scene. At a first glance I would say no, and that
why I put these explicit keywords. I remember that was suggested by
another user, so I'm not the only one who thought like that.

That said, I also acknowledge that writing
Transform<...>(Translation<..>(v)) is not very convenient. Moreover, I
see that the conversion ctor from Transform to Transform of different
kinds (e.g., Affine to Projective) is not explicit. Since we cannot
make it explicit anymore (backward compatibility), it would then make
sense to also remove the other explicit keywords for transformation
like objects. I'd still keep it for the ctor from EigenBase. We could
add a non explicit one from DiagonalMatrix then.

+1 agree on that.



Dipl.-Inf. Christoph Hertzberg
Cartesium 0.051
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen

Tel: (+49) 421-218-64252

Mail converted by MHonArc 2.6.19+