[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] nesting
- From: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>
- Date: Fri, 5 Feb 2010 10:46:30 +0100
- 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=ApKjTXIkjSRen+Yk7jftAKvnw2/u9K0XqNKmg9XDwGA=; b=hMC+CheaQ1dfp1/mcZeb6HR8K7dEU6UCA7SdWPUw3QVZjxGmAUZRTsRbU9qOVe+5kq fsMDoKQkhPnM2fRvgplxBRI6TsokXCF4NXD24ceoZxvFTMIO8TCfpsAbGjA0NVgWzNv5 J4KzhJslCxhZ2JqD3nxVn67K+IJh7vi/DzP+8=
- 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=M/HpgWsS9hggmmN0iUdfv1GZvkKuNimyYRARBU60ANee26/jy0jhu1gfVn2ss1RydT 57ssehDi4QNR0HwxUSAhnA8mtC6GGGgikyEUssgNKfXJrj+LlNXJpFVniGpUo/z84TfR hLEnXM6cZdo5Wut5fgZZojhl/LjETeg668MYk=
On Fri, Feb 5, 2010 at 10:22 AM, Gael Guennebaud
> Let's first consider dynamic sized matrices only. For them we could create a
> Temporary class inheriting DenseMatrixBase which would behave like a shared
> pointer with automatic deletion. So instead of copying the whole matrix
> data, you would only copy the sizes, the pointer and increment a counter.
> Get it?
Funny since I've also been considering shared_ptrs for the product
> Now, of course this concept does not work with fixed size objetcs. For them
> you would have to nest them in a kind of shared-pointer-expression, and so
> create the matrix objects using operator new... that is even worse :(
.... but I did not see this problem.
> So unless someone see how to solve this latter issue, what Hauke is trying
> to do could work. But instead of specialzing ei_ref_selector for all
> expressions I would suggest a different approach using new bit Flags. The
> rules would be as follow:
> - if the expr has the NestByReference flag, then nest by reference,
> otherwise nest by value
> - by default, only Matrix and Array would have the NestByReference flag
> - the NestByReference flag is not inherited
> - an expression nesting a temporary would have the NestParentByReference
> - the NestParentByReference flag is not inherited, but if one of the
> children of an expression has the NestParentByReference flag, then the
> current expression will have the NestByReference flag. If we make sure that
> NestParentByReferenceBit == NestByReference>>1, then we simply have to do:
> Flags = ... | ((Lhs::Flags|Rhs::Flags)&NestParentByReference) << 1), or we
> could also use a macro: Flags = ... |
> As an implication, we could get rid of ei_ref_selector. Everything will be
> done by ei_nesting and the ei_traits, so fewer template instanciations.
> To detect if a child generates a temporary, ei_nesting could expose an
> Evaluate boolean.
To me this sounds very good. If I understand this correctly, you don't
even need to touch every expression but only those nesting temporaries
and as you said, it will even reduce compile time.