This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3 PATCH] PR libstdc++/70437
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 5 Apr 2016 11:53:06 +0100
- Subject: Re: [v3 PATCH] PR libstdc++/70437
- Authentication-results: sourceware.org; auth=none
- References: <CAFk2RUb+RBM7oK+33pMvz5VNhcPo+7eVpZJOyX8VyecPj0puvg at mail dot gmail dot com> <CAFk2RUaMgb6g3wULKZQFNtdsYVN1y94c_SzkJVCFW29wzLHz7A at mail dot gmail dot com>
On 04/04/16 21:45 +0300, Ville Voutilainen wrote:
And yes, -ENOPATCH.
On 4 April 2016 at 21:42, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
Tested on Linux-PPC64.
2016-04-04 Ville Voutilainen <ville.voutilainen@gmail.com>
PR libstdc++/70437
* include/bits/stl_pair.h (_ConstructiblePair,
_ImplicitlyConvertiblePair, _MoveConstructiblePair,
_ImplicitlyMoveConvertiblePair): Add shortcut conditions
for same-type cases.
* testsuite/20_util/pair/70437.cc: New.
Thanks for the fix.
diff --git a/libstdc++-v3/include/bits/stl_pair.h b/libstdc++-v3/include/bits/stl_pair.h
index 7057030..206553a 100644
--- a/libstdc++-v3/include/bits/stl_pair.h
+++ b/libstdc++-v3/include/bits/stl_pair.h
@@ -90,29 +90,45 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template <typename _T1, typename _T2, typename _U1, typename _U2>
constexpr bool _ConstructiblePair()
{
- return __and_<is_constructible<_T1, const _U1&>,
- is_constructible<_T2, const _U2&>>::value;
+ return __and_<__or_<is_same<typename decay<_T1>::type,
+ typename decay<_U1>::type>,
+ is_constructible<_T1, const _U1&>>,
+ __or_<is_same<typename decay<_T2>::type,
+ typename decay<_U2>::type>,
+ is_constructible<_T2, const _U2&>>>::value;
}
I wonder if we want an __is_samey trait that checks if two decayed
types are the same.
More seriously, a comment might be useful to explain that although
these "concepts" return true for samey types, that is just to prevent
is_constructible from getting into a mess with incomplete types, and
actually for samey types one of the special member functions might end
up being chosen by overload resolution instead.
Did I get that right? If so, I definitely think it's worth a comment,
as I for one won't remember the details in a few months!