From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38900 invoked by alias); 1 Aug 2019 12:52:28 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 38293 invoked by uid 89); 1 Aug 2019 12:52:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Aug 2019 12:52:26 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 932BC882EA; Thu, 1 Aug 2019 12:52:25 +0000 (UTC) Received: from localhost (unknown [10.33.36.86]) by smtp.corp.redhat.com (Postfix) with ESMTP id 23C2E600C4; Thu, 1 Aug 2019 12:52:24 +0000 (UTC) Date: Thu, 01 Aug 2019 12:52:00 -0000 From: Jonathan Wakely To: Daniel =?iso-8859-1?Q?Kr=FCgler?= Cc: =?iso-8859-1?Q?Fran=E7ois?= Dumont , "libstdc++@gcc.gnu.org" , gcc-patches Subject: Re: PR 90409 Deque fiil/copy/move/copy_backward/move_backward/equal overloads Message-ID: <20190801125224.GQ9487@redhat.com> References: <9357e741-9a71-6783-2ce9-24ba8a3939ba@gmail.com> <84aa6517-1f06-e751-e3ef-dcaea779806e@gmail.com> <20190801095726.GA28280@redhat.com> <20190801110102.GP9487@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.12.0 (2019-05-25) X-SW-Source: 2019-08/txt/msg00028.txt.bz2 On 01/08/19 13:31 +0200, Daniel Krügler wrote: >Am Do., 1. Aug. 2019 um 13:01 Uhr schrieb Jonathan Wakely : >> >> On 01/08/19 12:36 +0200, Daniel Krügler wrote: >> >Am Do., 1. Aug. 2019 um 11:57 Uhr schrieb Jonathan Wakely : >> >> >> >> More comments inline below ... >> >[..] >> >> >> >> >François >> >> > >> >> >On 6/19/19 7:32 PM, François Dumont wrote: >> >> >>I wanted to implement Debug overloads for those already existing >> >> >>overloads but then realized that those algos could be generalized. >> >> >>This way we will benefit from the memmove replacement when operating >> >> >>with C array or std::array or std::vector iterators. >> >> >> >> >> >>I might do the same for lexicographical_compare one day. >> >> >> >> >> >>The ChangeLog below is quite huge so I attached it. I wonder if I >> >> >>could use deque::iterator and deque::const_iterator in place of the >> >> >>_Deque_iterator<> to reduce it ? >> >> >> >> >> >>Tested under Linux x86_64 normal and debug modes, ok to commit ? >> >> >> >> >> >>François >> >> >> >> >> > >> >> >> >> >diff --git a/libstdc++-v3/include/bits/deque.tcc b/libstdc++-v3/include/bits/deque.tcc >> >> >index 3f77b4f079c..9db869fb666 100644 >> >> >--- a/libstdc++-v3/include/bits/deque.tcc >> >> >+++ b/libstdc++-v3/include/bits/deque.tcc >> >> >@@ -967,155 +967,507 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER >> >> > this->_M_impl._M_finish._M_set_node(__new_nstart + __old_num_nodes - 1); >> >> > } >> >> > >> >[..] >> >> >> >> And anyway, isn't _Deque_iterator::_Self just the same type as >> >> _Deque_iterator ? It should be something like: >> >> >> >> typedef typename _GLIBCXX_STD_C::_Deque_iterator<_Tp, _Tp&, _Tp*> _Iter; >> >> >> >> >+ template >> >> >+ typename enable_if< >> >> >+ is_same::iterator_category, >> >> >+ std::random_access_iterator_tag>::value, >> >> >> >> Use is_base_of so >> >> it works for types derived from random_access_iterator_tag too. >> > >> >Interesting. Traditional type tag dispatching approaches (as function >> >parameters) do have more in a manner that would be equivalent to an >> >implicit conversion (Being used as "by-value-parameters"), so I'm >> >wondering whether this should not instead refer to is_convertible? I >> >also found examples where this trait is currently used in >> >such as >> > >> > static_assert( >> > __or_, >> > is_convertible<__samp_cat, random_access_iterator_tag>>::value, >> > "output range must use a RandomAccessIterator when input range" >> > " does not meet the ForwardIterator requirements"); >> > >> >Should possibly this trait be preferred? >> >> Hmm, I don't know why I did it that way in sample. >> >> The standard requires derivation in a couple of places today, see >> [reverse.iterator] bullet 2.1 and [move.iterator] bullet 1.1 which use >> DerivedFrom to check whether the base >> iterator is random access or not. > >If you want to mimic DerivedFrom you also need to include >is_convertible in some way, because is_base_of does not care about >access. Ah yes, that's probably why I used is_convertible :-) >Maybe introduce __is_derived_from? Whatever we do, we should make it work for C++98 too, as that's needed for François's patch. I wonder if it's good enough to just check if iterator_traits::iterator_category* converts to random_access_iterator_tag*. So rather than a generic is_derived_from, just a check for is_random_access, as that's all we need here.