Re: [eigen] Can we prevent that this compiles? |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Can we prevent that this compiles?*From*: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>*Date*: Wed, 30 Sep 2009 17:05:28 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=BALXVSc6ZvPbRhy9Q0RT34RQC3uu97v+H5EhCeT8/UU=; b=t7I42w4bIWYIvfmG8kgnbr40pOpR9s/t6E2qeRCX28tHTkFVRrl42mIx8w5jwAAiGf 7ZokorODXdU+L8ahI4naI8udCe6Sd+AHFyt32RfDrTfnvcNyorgdpVbdtG1S2Q6tSkGU 1hzzXQ0RfHDTvA527Sh1oc45qPXfl4OMmRvPI=*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; b=UZsOf8ZrLQ5dx1ns5NViV0Xpj6FZfJvq0OIIexmNoJsAf0TLSE4EHDIITsBqvsMnol rYZL3cUzz0Ni0DpsgcBamd9Eh9/6YLml28+T4LDUl+G7gIYquuSaHh1N2O2j1Ev24BXg FymKZUgDZ4Ro0ji8/mZKRoShJ2AccWwPoQxEo=

On Wed, Sep 30, 2009 at 4:52 PM, Markus Moll <markus.moll@xxxxxxxxxxxxxxxx> wrote:

In theory we could prevent implicit conversion by making the Matrix ctors explicit, i.e.

explicit Matrix(const MatrixBase<OtherDerived>& other);

explicit Matrix(const AnyMatrixBase<OtherDerived> &other);

But it is probably not really a solution since it seems that we rely on implicit conversions.

The same as you do, the additional ctor approach.

With static asserts we can make the compile error self explanatory. I preferred the ctor approach since it does not require implementing a ConstRef class.

Hauke

Hm, what was the third solution?

In theory we could prevent implicit conversion by making the Matrix ctors explicit, i.e.

explicit Matrix(const MatrixBase<OtherDerived>& other);

explicit Matrix(const AnyMatrixBase<OtherDerived> &other);

But it is probably not really a solution since it seems that we rely on implicit conversions.

Also, what solution do you refer to as the second solution?

The same as you do, the additional ctor approach.

The reason why I like the first solution better is that it does not add any

constructors. There's one major benefit, consider:

Replicate<MatrixXd::RowXpr,2,1> rep(5);

Here, the compiler won't find a suitable constructor and will probably list

the set of candidates. That might be very helpful. With the second approach, a

suitable constructor *is* found, but instantiation leads to an unusual compile

error.

With static asserts we can make the compile error self explanatory. I preferred the ctor approach since it does not require implementing a ConstRef class.

Hauke

**Follow-Ups**:**Re: [eigen] Can we prevent that this compiles?***From:*Markus Moll

**References**:**[eigen] Can we prevent that this compiles?***From:*Hauke Heibel

**Re: [eigen] Can we prevent that this compiles?***From:*Markus Moll

**Re: [eigen] Can we prevent that this compiles?***From:*Hauke Heibel

**Re: [eigen] Can we prevent that this compiles?***From:*Markus Moll

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Can we prevent that this compiles?** - Next by Date:
**Re: [eigen] Can we prevent that this compiles?** - Previous by thread:
**Re: [eigen] Can we prevent that this compiles?** - Next by thread:
**Re: [eigen] Can we prevent that this compiles?**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |