Subject: Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-26 17:05:58
>>> Maybe no-one uses expected<T> as function parameter, but consider this:
>>> expected<vector<T>> g()
>>> vector<T> v;
>>> // try to populate v;
>>> return v; // are you expecting a copy elision here?
>> This is definitely a concern for C++ 14 (not 17).
> Are you sure copy elision in C++17 takes this case into account?
I am not up to date with C++ 17 yet. But assuming
http://en.cppreference.com/w/cpp/language/return#Notes is correct:
"If expression is an lvalue expression and the conditions for copy
elision are met, or would be met, except that expression names a
function parameter, then overload resolution to select the constructor
to use for initialization of the returned value is performed twice:
first as if expression were an rvalue expression (thus it may select the
move constructor or a copy constructor taking reference to const), and
if no suitable conversion is available, overload resolution is performed
the second time, with lvalue expression (so it may select the copy
constructor taking a reference to non-const).
The above rule applies even if the function return type is different
from the type of expression (copy elision requires same type)"
... then yes, copy elision in C++ 17 takes this case into account.
>> But I think end users
>> get this problem with implicit conversion - it helps that recent clangs
>> have a rich set of warnings when you do an inefficient return of a stack
>> allocated object. So I don't think it as much a problem as others think.
> It will be great if you added in the documentation how do you solve the
> reported warnings ;-)
I don't think the right place for telling people how to write
warnings-free C++ is Boost documentation.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk