|Re: [eigen] Matrix::RowXpr::Nested is a reference...|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Matrix::RowXpr::Nested is a reference...
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Fri, 2 Oct 2009 08:13:02 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Ew3p1XvBkwzWiJt1+xU63oKMyrWVG+YOoD4mhphpQX8=; b=M4EWByhWbxIk60G4NPHwLTpEJ/uhLY4O+ToPX1dLQjpJ1p5kiOoDQcu+lNbG7jkhZy MAtZg/Rz8e4Zx62PgZDbjtHJ2akzlVmH+fKAuMqsRFVoAkcmcui6jmCJhoqVH+yEuKgH dcnkc3wZ1/GOVkPzpzVdhndEA9yJWdCPr6k5A=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=IqALxGMsLnPn5SxAWPzFBqK/SL/IDBrFRiJkGnqZMSz+nu6mTC2dERYX/7mTZ86VmF qJQQviDR86MUlCuuAaZmSNWsrqpABlo+bFhaauCrLiO8tCkat3OXW58hqi+ameAYDGIb L4yZZeW+LTRhudXutF8Maj+A+GW45Aa86kA3Q=
2009/10/1 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> Is that correct as is?
Yes. Check in Core/util/XprHelper.h:
template< blabla > struct ei_nested
typedef typename ei_meta_if<
(int(ei_traits<T>::Flags) & EvalBeforeNestingBit)
|| ( int(CostEval) <= int(CostNoEval) ),
See the const T& above ? That's the solution used when doing
ei_nested<RowXpr> by default.
> In the following case
> it means that it fails since matrix.row(0) returns a temporary to which a
> reference is stored in Replicate.
Yes, this is true.
In most cases this is OK as the temporary is alive long enough.
There are some corner cases where this is NOT OK for example if you
want to write a function that returns such a Replicate object.
For these corner cases, we have .nestByValue() which allows you to
force that the row() object is nested by value.
Now I don't remember for sure the exact reasons why we nest by
reference by default, as indeed these are lightweight objects. I think
that was just to avoid useless copying of objects which we feared
would confuse the compiler. It's crucial that the compiler understands
that it can inline all these objects and not actually construct them
So it's that's only that, then, feel free with replacing const T& by T
here and checking if the compiler still generates good code. If yes,
then that sounds like great news, as we would then be able to get rid
> I used this piece of code to verify my assumption:
> #include "Eigen/Core"
> #include "boost/type_traits/is_reference.hpp"
> void main()
> typedef Eigen::MatrixXd::RowXpr::Nested type;
> std::cout << typeid(type).name();
> if (boost::is_reference<type>::type::value == true) std::cout << "&";
> std::cout << std::endl;