[Dune-devel] [Dune-Bugs][#683] Requesting value_type and unary operator-() in FieldVector.
Jö Fahlke
jorrit at jorrit.de
Mon Jun 29 15:56:07 CEST 2015
Am Mon, 29. Jun 2015, 10:07:01 +0200 schrieb Christian Engwer:
> Date: Mon, 29 Jun 2015 10:07:01 +0200
> From: Christian Engwer <christian.engwer at uni-muenster.de>
> To: Oliver Sander <sander at igpm.rwth-aachen.de>
> Cc: "dune-devel at dune-project.org" <dune-devel at dune-project.org>
> Subject: Re: [Dune-devel] [Dune-Bugs][#683] Requesting value_type and unary
> operator-() in FieldVector.
> > What's so bad about C++11? We use that all over the place. And did you measure the impact
> > of those "expensive temporaries"? I wouldn't be surprised if you had a hard time seeing their
> > effect at all. :-)
>
> for 2.4 we decided on compiler compatibilities which prohibit the use
> of std::move _in_ the core modules. If you want to measure the impact
> feel free, but std::move was introduced exactly to avoid these
> temporaries, as (in many cases) the compiler can't do this for you.
I have to agree with Oli here.
1. std::move has nothing to do with it. Not for FieldVector, which keeps all
its data within the class, so moves would be just as expensive as copies.
(And possibly even more expensive, because I've seen compilers that don't
do copy constructor elision any more if you explicitly specify std::move,
but that situation has hopefully improved since.)
2. I doubt that after optimization there would be much left of a temporary in
the assembler code (for FieldVector; it depends on the class, of course).
Regards,
Jö.
--
Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics,
University of Münster, Orleans-Ring 10, D-48149 Münster
Tel: +49 251 83 35146 Fax: +49 251 83 32729
featured product: Debian GNU/Linux - http://www.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20150629/00c45825/attachment.sig>
More information about the Dune-devel
mailing list