This bugzilla service is closed. All entries have been migrated to
Bug 1087 - Returning by const value prohibits r-value optimizations.
Summary: Returning by const value prohibits r-value optimizations.
Status: NEW
Alias: None
Product: Eigen
Classification: Unclassified
Component: Core - general (show other bugs)
Version: 3.2
Hardware: All All
: Normal Optimization
Assignee: Nobody
Depends on:
Reported: 2015-10-13 09:53 UTC by Emily
Modified: 2019-12-04 15:02 UTC (History)
3 users (show)


Description Emily 2015-10-13 09:53:20 UTC
It seems to be a consistent style in Eigen to return non-POD types by const value. Which was correct and recommended style for ISO C++98 and given as advice by S. Meyers in Effective C++. However, since C++11 the advice is to return by plain value (without const).

The rationale being that returning by const value prevents the compiler from applying move semantics and thus misses out on an optimization opportunities (you can't move from a const value, as you can't modify it). See here: 

Now AFAICT Eigen isn't written using the C++11 standard, but when compiled with a modern compiler, which by now has to be considered more likely than not. The compiler can, and will, in some cases generate a default move constructor and move assignment operator to take use of move semantics.

I believe it would be good to consistently remove const from value return types. This shouldn't change behaviour nor API usage.
Comment 1 Gael Guennebaud 2015-10-13 13:40:35 UTC
Actually, most Eigen's functions return proxy objects (aka expressions), for which move semantic does not apply anyway. So this would only concern a few functions, like normalized(), and some in the Geometry modules... and for them, it would be better to return an expression too. In the meantime, we could still change the constness with respect to the enabled C++ standard.
Comment 2 Nobody 2019-12-04 15:02:48 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance:

Note You need to log in before you can comment on or make changes to this bug.