Re: [eigen] Issues regarding Quaternion-alignment and const Maps

[ Thread Index | Date Index | More Archives ]

On Wed, Jul 7, 2010 at 10:26 AM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> On Wed, Jul 7, 2010 at 9:56 AM, Christoph Hertzberg
> <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> The second issue is a bit more complicated:
>> Eigen::Map severely violates const-correctness. I.e., it is possible to
>> create a non-const Map from a (const double*).
>> If you still accept API-changes, I would suggest having a Map and a ConstMap
>> (similar to iterators in STL).
> yes, that's not very nice. The only advantage of our current approach
> is that keep the number of type instantiation to a minimum. The user
> can still manually enforce constness by declaring the Map object
> const:
> const double* data= ...;
> const Map<MatrixXf&> map(data,....);
> But, sure, this is far to be satisfactory, for many reasons.
> This issue also exists with named Block objects:
> foo(const MatrixXf& m) {
>  Block<MatrixXf> bl(mat,0,0,,4,4);
>  bl.setZero();
> }
> API-wise, what about const qualifying the matrix type to enforce constness:
> // here data can be a double* or a const double*
> Map<const MatrixXf> mat(data,...);
> // here data must be a double*
> Map<MatrixXf> mat(data,...);
> and we would do the same for Block. (Block and Map are based on the
> same implementation).
> Again the drawback is that we are artificially increasing the number
> of types, and consequently compilation time and binary sizes....

This issue was also bugging me. I am voting for this option but I
think it requires some new macros because our traits are only
specialized for clean types.

But then it seems to be working out of the box though I did not check
everything - at least this example works (and only with const

#include <iostream>

#include <Eigen/Eigen>

using namespace Eigen;

void main()
  MatrixXd m = MatrixXd::Random(50,50);
  Map<const MatrixXd> mymap(, m.rows(), m.cols());
  const double* data_ptr =;

I cannot push anything because I used tr1 traits like
std::remove_const but that one is easily implemented.

A general cleanup of our traits/template helpers would be nice so they
are conforming with the standard - just an idea, I could even do it.

Regarding Gael's comment about the increased types and build times, I
think const correctness should be preferred over shorter build times.

- Hauke

Mail converted by MHonArc 2.6.19+