On 04/04/16 21:45 +0300, Ville Voutilainen wrote:
And yes, -ENOPATCH.
On 4 April 2016 at 21:42, Ville Voutilainen <ville.voutilai...@gmail.com> wrote:
Tested on Linux-PPC64.
2016-04-04 Ville Voutilainen <ville.voutilai...@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!
