On Nov 6, 2013, at 2:18 PM, Richard Smith <[email protected]> wrote:
> On Wed, Nov 6, 2013 at 9:45 AM, Howard Hinnant <[email protected]> wrote: > Author: hhinnant > Date: Wed Nov 6 11:45:43 2013 > New Revision: 194154 > > URL: http://llvm.org/viewvc/llvm-project?rev=194154&view=rev > Log: > Fix several tuple bugs that were exposed by clang's implementation of CWG > 1402. This fixes http://llvm.org/bugs/show_bug.cgi?id=17798. > > Modified: > libcxx/trunk/include/tuple > > Modified: libcxx/trunk/include/tuple > URL: > http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/tuple?rev=194154&r1=194153&r2=194154&view=diff > ============================================================================== > --- libcxx/trunk/include/tuple (original) > +++ libcxx/trunk/include/tuple Wed Nov 6 11:45:43 2013 > @@ -270,7 +270,7 @@ public: > _LIBCPP_INLINE_VISIBILITY > _LIBCPP_CONSTEXPR_AFTER_CXX11 > __tuple_leaf(__tuple_leaf&& __t) > _NOEXCEPT_(is_nothrow_move_constructible<_Hp>::value) > - : value(_VSTD::move(__t.get())) > + : value(_VSTD::forward<_Hp>(__t.get())) > {} > > template <class _Tp> > @@ -457,13 +457,24 @@ struct __tuple_impl<__tuple_indices<_Ind > return *this; > } > > - _LIBCPP_INLINE_VISIBILITY > - __tuple_impl& > - operator=(const __tuple_impl& __t) > _NOEXCEPT_((__all<is_nothrow_copy_assignable<_Tp>::value...>::value)) > - { > - __swallow(__tuple_leaf<_Indx, _Tp>::operator=(static_cast<const > __tuple_leaf<_Indx, _Tp>&>(__t).get())...); > - return *this; > - } > + __tuple_impl(const __tuple_impl&) = default; > + __tuple_impl(__tuple_impl&&) = default; > + > + _LIBCPP_INLINE_VISIBILITY > + __tuple_impl& > + operator=(const __tuple_impl& __t) > _NOEXCEPT_((__all<is_nothrow_copy_assignable<_Tp>::value...>::value)) > + { > + __swallow(__tuple_leaf<_Indx, _Tp>::operator=(static_cast<const > __tuple_leaf<_Indx, _Tp>&>(__t).get())...); > + return *this; > + } > + > + _LIBCPP_INLINE_VISIBILITY > + __tuple_impl& > + operator=(__tuple_impl&& __t) > _NOEXCEPT_((__all<is_nothrow_move_assignable<_Tp>::value...>::value)) > + { > + __swallow(__tuple_leaf<_Indx, > _Tp>::operator=(_VSTD::forward<_Tp>(static_cast<__tuple_leaf<_Indx, > _Tp>&>(__t).get()))...); > + return *this; > + } > > Hmm, could you give __tuple_leaf a copy / move assignment operator and > default these too? Perhaps. I'm sure I explored that issue when I wrote this years ago. But back then I did not have nice things like defaulted special functions. And it is quite possible I would come to a different conclusion if I were to re-explore the design today. I did not do so today because of time constraints. > Also, is it intentional that the tuple elements are assigned in an > indeterminate order? That is certainly a disadvantage of the current design, though a conforming disadvantage. Some implementations of tuple (not libc++) will even store the members in reverse order. Howard _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
