* [v3 PATCH] Slight cleanup of tuple constraints.
@ 2017-03-27 14:49 Ville Voutilainen
2017-03-27 15:21 ` Jonathan Wakely
0 siblings, 1 reply; 2+ messages in thread
From: Ville Voutilainen @ 2017-03-27 14:49 UTC (permalink / raw)
To: libstdc++, gcc-patches, Dinka Ranns
[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]
This is not something that should go in at this stage, but I'm sending
it for review. Dinka quite astutely pointed out that the sizeof...(_Elements)>=1
tests seem unnecessary, and they are;
1) the helper aliases _TCC and _TMC already check that the incoming
pack and the element pack have the same size
2) if the element pack is empty, we wouldn't use these constructors
anyway, since we have a specialization for a zero-element tuple...
3) ...except that for the one taking const _Elements& we might, for
class template argument deduction cases, but we have a deduction
guide that deduces the zero-element specialization for 'tuple t;' so
we still won't use these constructors.
When stage1 for gcc 8 opens, I expect to clean up tuple's constraints
a bit anyway: there's no actual need to have, for instance, _ConstructibleTuple
and _MoveConstructibleTuple separately. However, that's a topic for another day,
as mentioned.
Tested on Linux-x64.
2017-03-27 Ville Voutilainen <ville.voutilainen@gmail.com>
Slight cleanup of tuple constraints.
* include/std/tuple (tuple(const _Elements&...)): Strike
the unnecessary sizeof... test.
(tuple(_UElements&&...)): Likewise.
* testsuite/20_util/tuple/element_access/get_neg.cc: Adjust.
[-- Attachment #2: tuple-sizeof-cleanup.diff --]
[-- Type: text/plain, Size: 2816 bytes --]
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 1f5365a..8af581c 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -602,8 +602,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_TCC<_Dummy>::template
_ConstructibleTuple<_Elements...>()
&& _TCC<_Dummy>::template
- _ImplicitlyConvertibleTuple<_Elements...>()
- && (sizeof...(_Elements) >= 1),
+ _ImplicitlyConvertibleTuple<_Elements...>(),
bool>::type=true>
constexpr tuple(const _Elements&... __elements)
: _Inherited(__elements...) { }
@@ -613,8 +612,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_TCC<_Dummy>::template
_ConstructibleTuple<_Elements...>()
&& !_TCC<_Dummy>::template
- _ImplicitlyConvertibleTuple<_Elements...>()
- && (sizeof...(_Elements) >= 1),
+ _ImplicitlyConvertibleTuple<_Elements...>(),
bool>::type=false>
explicit constexpr tuple(const _Elements&... __elements)
: _Inherited(__elements...) { }
@@ -640,8 +638,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_TMC<_UElements...>::template
_MoveConstructibleTuple<_UElements...>()
&& _TMC<_UElements...>::template
- _ImplicitlyMoveConvertibleTuple<_UElements...>()
- && (sizeof...(_Elements) >= 1),
+ _ImplicitlyMoveConvertibleTuple<_UElements...>(),
bool>::type=true>
constexpr tuple(_UElements&&... __elements)
: _Inherited(std::forward<_UElements>(__elements)...) { }
@@ -651,8 +648,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_TMC<_UElements...>::template
_MoveConstructibleTuple<_UElements...>()
&& !_TMC<_UElements...>::template
- _ImplicitlyMoveConvertibleTuple<_UElements...>()
- && (sizeof...(_Elements) >= 1),
+ _ImplicitlyMoveConvertibleTuple<_UElements...>(),
bool>::type=false>
explicit constexpr tuple(_UElements&&... __elements)
: _Inherited(std::forward<_UElements>(__elements)...) { }
diff --git a/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc b/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc
index 03835f4..6648d5e 100644
--- a/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/tuple/element_access/get_neg.cc
@@ -17,7 +17,7 @@
// { dg-options "-fno-show-column" }
// { dg-do compile { target c++14 } }
-// { dg-error "in range" "" { target *-*-* } 1297 }
+// { dg-error "in range" "" { target *-*-* } 1293 }
#include <tuple>
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [v3 PATCH] Slight cleanup of tuple constraints.
2017-03-27 14:49 [v3 PATCH] Slight cleanup of tuple constraints Ville Voutilainen
@ 2017-03-27 15:21 ` Jonathan Wakely
0 siblings, 0 replies; 2+ messages in thread
From: Jonathan Wakely @ 2017-03-27 15:21 UTC (permalink / raw)
To: Ville Voutilainen; +Cc: libstdc++, gcc-patches, Dinka Ranns
On 27/03/17 17:44 +0300, Ville Voutilainen wrote:
>This is not something that should go in at this stage, but I'm sending
>it for review. Dinka quite astutely pointed out that the sizeof...(_Elements)>=1
>tests seem unnecessary, and they are;
>
>1) the helper aliases _TCC and _TMC already check that the incoming
>pack and the element pack have the same size
>2) if the element pack is empty, we wouldn't use these constructors
>anyway, since we have a specialization for a zero-element tuple...
>3) ...except that for the one taking const _Elements& we might, for
>class template argument deduction cases, but we have a deduction
>guide that deduces the zero-element specialization for 'tuple t;' so
>we still won't use these constructors.
Sounds right, so this looks good for Stage 1.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-03-27 15:12 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-27 14:49 [v3 PATCH] Slight cleanup of tuple constraints Ville Voutilainen
2017-03-27 15:21 ` Jonathan Wakely
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).