This bugzilla service is closed. All entries have been migrated to https://gitlab.com/libeigen/eigen

Bug 1087

Summary: Returning by const value prohibits r-value optimizations.
Product: Eigen Reporter: Emily <el>
Component: Core - generalAssignee: Nobody <eigen.nobody>
Status: NEW ---    
Severity: Optimization CC: chtz, gael.guennebaud, jacob.benoit.1
Priority: Normal    
Version: 3.2   
Hardware: All   
OS: All   
Whiteboard:

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: http://stackoverflow.com/questions/16834937/isnt-the-const-modifier-here-unnecessary 

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 gitlab.com'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: https://gitlab.com/libeigen/eigen/issues/1087.