> why you would not use that alternative in all cases if you want your code to be portable across compilers
Because he wants to use the new better features on those compilers that support them.
This is important because it’s the only clear motivating use case I’ve heard so far for feature test macros: To encourage aggressive new C++ feature adoption for third-party libraries that do not control their customers’ compiler choice, so that they can adopt a new C++ feature on the compilers that support it, while still working on downlevel (down to C++98) compilers they also have to support.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Richard Smith
Sent: Thursday, October 5, 2017 4:34 PM
To: Ville Voutilainen <firstname.lastname@example.org>
Cc: email@example.com <Features@open-std.org>
Subject: Re: [SG10] A feature macro for mandatory copy elision
On 5 October 2017 at 15:08, Ville Voutilainen <firstname.lastname@example.org> wrote:
On 6 October 2017 at 01:04, Richard Smith <email@example.com> wrote:
>> 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.
I can avoid compiling that when I know it won't work, for which I can
use the macro. I can compile that when I know
it'll work, for which the macro tells me that it'll work.
The thing I'm missing is what alternative you use when the feature is not available, and why you would not use that alternative in all cases if you want your code to be portable across compilers. Your original example is not that, because you can just use the version with __cpp_guaranteed_copy_elision not defined, with no loss of functionality.
>> 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
> 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.
That would be wrapping the whole type in #ifdef
__cpp_mandatory_copy_elision, and providing
a different type that doesn't rely on copy elision, like a type that
is movable and has a different name.
This sounds promising. Can you give an example?