Date: Mon, 9 Oct 2017 09:53:45 -0700
On 9 Oct 2017 09:36, "Nelson, Clark" <clark.nelson_at_[hidden]> wrote:
> > After a while pondering, the best example I've got to
> demonstrate a
> > need for the feature test macro is something like this:
> >
> > #ifdef __cpp_mandatory_copy_elision
> >
> > NoCopyNoMove indirectFactory() {
> > return factory(1); // ill-formed prior to C++17
> > }
> > #endif
>
> Should SD-6 contain an example like this one? It seems to me
> that there ought to be a different definition of indirectFactory
> under an #else, but I don't know what it should look like.
>
>
> For this example, depending on the intent of the library author it
> may be impossible to provide an alternate definition. The feature
> test macro allows this portion of the interface to be omitted if it's
> nonessential.
I just want to be sure I understand what you're thinking, which (I think)
is this:
"indirectFactory", which is a library function, should be available only
when copy elision is guaranteed. Code that doesn't need guaranteed copy
elision will just use "factory" instead.
I think I would say: code that wants to be compilable with older
implementations will just use "factory" instead (and auto&& when needed).
Code that does depend on guaranteed copy elision will just (try to) use
"indirectFactory", and get an error if compiled on an implementation
doesn't provide guaranteed copy elision.
Code that really needs to use indirectFactory, or wants to use it and
doesn't care about supporting older compilers, will just use it and get an
error on older compilers.
So there's no need for uses of "indirectFactory" to be conditioned on the
macro: using it implies that guaranteed copy elision is required.
Right.
Is that right?
Clark
> > After a while pondering, the best example I've got to
> demonstrate a
> > need for the feature test macro is something like this:
> >
> > #ifdef __cpp_mandatory_copy_elision
> >
> > NoCopyNoMove indirectFactory() {
> > return factory(1); // ill-formed prior to C++17
> > }
> > #endif
>
> Should SD-6 contain an example like this one? It seems to me
> that there ought to be a different definition of indirectFactory
> under an #else, but I don't know what it should look like.
>
>
> For this example, depending on the intent of the library author it
> may be impossible to provide an alternate definition. The feature
> test macro allows this portion of the interface to be omitted if it's
> nonessential.
I just want to be sure I understand what you're thinking, which (I think)
is this:
"indirectFactory", which is a library function, should be available only
when copy elision is guaranteed. Code that doesn't need guaranteed copy
elision will just use "factory" instead.
I think I would say: code that wants to be compilable with older
implementations will just use "factory" instead (and auto&& when needed).
Code that does depend on guaranteed copy elision will just (try to) use
"indirectFactory", and get an error if compiled on an implementation
doesn't provide guaranteed copy elision.
Code that really needs to use indirectFactory, or wants to use it and
doesn't care about supporting older compilers, will just use it and get an
error on older compilers.
So there's no need for uses of "indirectFactory" to be conditioned on the
macro: using it implies that guaranteed copy elision is required.
Right.
Is that right?
Clark
Received on 2017-10-09 18:53:50