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: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>
- Date: Wed, 7 Jul 2010 10:53:05 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=sJLgJIW0mFZAbfxt9b75e7mpbBA0y84mMGkSHqk8l6U=; b=g0qRwtqoZObI4nugT7VWRQlmJytfG+DuQe1Kz9+C7nNu2llcXGiqs9SmTQQjdALwXa MX/TnSNAnj2oiQCeCjpkTCS1uOJc4yDL6SQgLzbJfMXGaeOpoyyYynI5U6oNR8Eo5yAb 8FuDKshRbcsPnvmlm3D3uBHigCAdw5ehDV7Q0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=AyJq33wNgHop/FpmlQ4F2fBwJkUjgnLM5w0cQ0UJYYT4m5f6lJ/4RpfdwAHAvyXNnO PMG81MQjae8l1fGDNpklrxs8mGZwCLWJmLxLX/dKSKSzIsG8K1cc2Jal+JY931ugDJN5 SxR1OlO0mmKbZlI9g9BWC4wI6j+31RIIyloTs=
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.
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