Re: [eigen] Issues regarding Quaternion-alignment and const Maps |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Issues regarding Quaternion-alignment and const Maps
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Wed, 7 Jul 2010 11:20:32 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=5Nyc6c/bVkStC+pRz7qVGWI7jphOAnCHkSyd+TTYPQU=; b=tnYMDM+SOeua89LOrwDseMjiaBjnwKoRGoOVaKeH0Q7ho+l4ktsKB18Y2K5aap3FEV mkvpni1y6MjL8VyrdvublbOy4t2lg8eYqePiIoyYABc24UGXModb8Licvr9a4qbkkx9d eYticnft7qKalnPYawxpJN2F3R/WzaMYXLCgg=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=YKdzBcR8C0sj27zxxBKt+8Bq87pxzpLbcNT1iZAsdGgolakM87EZLdVYzjypcHgcxr 0RgcvASytfMek6Ao9To/CYnDpB28yIdM9fvBp/aEhdAhlY05NG7qjFIZ7pRNECUzsw5J wwxt9zgp9wi2vm1E04wBAueTdX2zM8B+hNnVU=
On Wed, Jul 7, 2010 at 10:53 AM, Hauke Heibel
<hauke.heibel@xxxxxxxxxxxxxx> wrote:
> 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
> double*):
>
> #include <iostream>
>
> #include <Eigen/Eigen>
>
> using namespace Eigen;
>
> void main()
> {
> MatrixXd m = MatrixXd::Random(50,50);
> Map<const MatrixXd> mymap(m.data(), m.rows(), m.cols());
> const double* data_ptr = mymap.data();
> }
>
> I cannot push anything because I used tr1 traits like
> std::remove_const but that one is easily implemented.
we already have it:
ei_unconst<type>::type
> 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.
would be nice.
gael
> Regarding Gael's comment about the increased types and build times, I
> think const correctness should be preferred over shorter build times.
>
> - Hauke
>
>
>