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

[Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>]

Gael Guennebaud schrieb:
> [...]
> 
> With Eigen3 you can map unaligned data as a Quaternion, but that's
> less convenient. So you would like a DontAlign option, e.g.:
> 
> Quaternion<double,DontAlign>
> 
> Then we should also add such an option to Translation and Transform.

Yes, that would be nice.

>> 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,...);

Yes, looks even nicer than introducing a new type.

>> Ok, and actually a third very minor issue regarding Maps:
>> Maps of fixed sizes should boil down to a single pointer, but they don't due
>> to the ei_variable_if_dynamic-object, which is not allowed to have size 0,
>> even if it contains no members.
>> One possible solution (without to much code-rewriting) would be to combine
>> the sizes and the m_data pointer to a single object, providing
>> getter-functions for rows and cols, and some template-specializations if
>> sizes are Dynamic (similar to how ei_matrix_storage is implemented)
> 
> Indeed, we had to introduce a separated ei_matrix_storage class for
> that precise purpose. Actually, we did not thought that, e.g.,
> sizeof(Map<Matrix4f>) would matter... but again, why not :)

As I said, this is a minor issue (for me). I guess, when using a Map as
temporary (as in most cases) all overhead should get optimized away
(didn't actually check this, though)

Christoph

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

Tel: (+49) 421-218-64252
----------------------------------------------