Hi Ville,
since you wrote the latest patches on tuple constructors, do you have an
opinion on this patch, or alternate strategies to achieve the same goal?
https://gcc.gnu.org/ml/libstdc++/2016-04/msg00041.html
On Thu, 21 Apr 2016, Marc Glisse wrote:
On Thu, 21 Apr 2016, Jonathan Wakely wrote:
On 20 April 2016 at 21:42, Marc Glisse wrote:
Hello,
does anyone remember why the move constructor of _Tuple_impl is not
defaulted? The attached patch does not cause any test to fail (whitespace
kept to avoid line number changes). Maybe something about tuples of
references?
I don't know/remember why. It's possible it was to workaround a
front-end bug that required it, or maybe just a mistake and it should
always have been defaulted.
Ok, then how about something like this? In order to suppress the move
constructor in tuple (when there is a non-movable element), we need to
either declare it with suitable constraints, or keep it defaulted and
ensure that we don't bypass a missing move constructor anywhere along
the way (_Tuple_impl, _Head_base). There is a strange mix of 2
strategies in the patch, I prefer the tag class, but I started using
enable_if before I realized how many places needed those horrors.
Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
2016-04-22 Marc Glisse <marc.gli...@inria.fr>
* include/std/tuple (__element_arg_t): New class.
(_Head_base(const _Head&), _Tuple_impl(const _Head&, const
_Tail&...):
Remove.
(_Head_base(_UHead&&)): Add __element_arg_t argument...
(_Tuple_impl): ... and adjust callers.
(_Tuple_impl(_Tuple_impl&&)): Default.
(_Tuple_impl(const _Tuple_impl<other>&),
_Tuple_impl(_Tuple_impl<other>&&), _Tuple_impl(_UHead&&): Constrain.
* testsuite/20_util/tuple/nomove.cc: New.
--
Marc Glisse
