C++ Logo


Advanced search

Re: [SG10] A feature macro for mandatory copy elision

From: Richard Smith <richard_at_[hidden]>
Date: Thu, 5 Oct 2017 15:04:05 -0700
On 5 Oct 2017 14:54, "Ville Voutilainen" <ville.voutilainen_at_[hidden]>

On 6 October 2017 at 00:48, Richard Smith <richard_at_[hidden]> wrote:
> On 5 Oct 2017 14:20, "Ville Voutilainen" <ville.voutilainen_at_[hidden]>
> wrote:
> On 5 October 2017 at 23:50, Richard Smith <richard_at_[hidden]> wrote:
>> What benefit does the feature-test macro give you over using the
>> non-guaranteed-copy-elision implementation in all cases?
> I can let users store the thing returned by the factory function as
> they would store any object,
> rather than force them to use lifetime-extending references.
> One of us is missing something. Why does that not work with
> the non-guaranteed-copy-elision implementation?

I can't write
NoCopyNorMove x = factory();
in C++14. It's ill-formed. Same goes for
auto x = factory();

The macro does not help you with that. It does not magically make a C++17
feature appear in C++14 mode.

> Furthermore, if I decide that I really
> hate having to use those references, I will disable the whole type if
> guaranteed copy elision is not available.
> Do you anticipate actually wanting to do that? It seems like an odd choice
> to permit the reference declaration only if guaranteed copy elision is
> available.

The choice is that rather than performing tricks with having to
befriend every possible factory function
and forcing users to use lifetime-extending references, such RAII
handles are provided only when copy
elision is available, and otherwise completely different tools need to be

I think we're still missing an example of that.

This discussion generalizes to the following: mandatory copy elision
allows doing things that were not doable
before. That provides ample reason to have a feature macro for it, as
far as I'm concerned.

Received on 2017-10-06 00:04:18