From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by sourceware.org (Postfix) with ESMTPS id 1F5AE385840B; Mon, 4 Oct 2021 20:30:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1F5AE385840B Received: by mail-wm1-x32a.google.com with SMTP id t16-20020a1c7710000000b003049690d882so504334wmi.5; Mon, 04 Oct 2021 13:30:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WwzcIgUo63pvQrcBGCZD6k9o3rf5oQqgdGpHSfyiAZo=; b=8FHFse8G4h0kOa2l5RFZV+CssQcnBoyE4uD4rmUERlQ0sLmWhmPRH5SkcCLKn0HyRC gtJJsXm2Y/fLljBvEOyVxdLJnhKxfbohP6wE7i5moZy1xRbGFp8Ki3B5U6jo/BL66Nqo uUOsbfOlVdq1V0KHpeT2yNN1UAUA3r+nLF9BXiHYqL5UMVG1Mr9tCl2e4Gyp01HjabMx C9oo/DJKPxlGcH7/1SD65hOtJQvN/2msy2GUnSFj0EM2DLQZZOIy2PB99Ekh+kZ12cGn ChgbsU3UhqIJ7QW7i+2k4tM6Ijf/eAyou0v+4J0bdEkIkUKJesOiJJxSYvJLq9L5Xj/g HYwA== X-Gm-Message-State: AOAM533YA54Ig0ZgMaYfTWTVz6cYyNNMxgXtMqQQ+c3kAZ1DaX9nTIrU e9i2vtXyb6fC+MqG/bH02jdqcFWZsBHd2ioVD4I= X-Google-Smtp-Source: ABdhPJyZPsYxL4bF66Rj3pDE5YntJCx7diE3QqCCt2lyOhlerQydqghm0t305RbGv/u84/QROJOi+y9WdTe6hGe0BZM= X-Received: by 2002:a1c:2002:: with SMTP id g2mr20147003wmg.169.1633379415210; Mon, 04 Oct 2021 13:30:15 -0700 (PDT) MIME-Version: 1.0 References: <57b54891-59ba-394d-3d53-218f5061b8ef@gmail.com> <9ea0770a-54fb-2c17-b527-2797b5fd3b50@gmail.com> <34b34b00-8c96-68c1-e436-ab0f64291c2f@gmail.com> In-Reply-To: <34b34b00-8c96-68c1-e436-ab0f64291c2f@gmail.com> From: Jonathan Wakely Date: Mon, 4 Oct 2021 21:30:02 +0100 Message-ID: Subject: Re: [committed] libstdc++: Specialize std::pointer_traits<__normal_iterator> To: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= Cc: Jonathan Wakely , "libstdc++" , gcc-patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 20:30:17 -0000 On Mon, 4 Oct 2021 at 21:28, Fran=C3=A7ois Dumont via Libstdc++ wrote: > > On 04/10/21 10:05 pm, Fran=C3=A7ois Dumont wrote: > > On 02/10/21 10:24 pm, Jonathan Wakely wrote: > >> On Sat, 2 Oct 2021 at 18:27, Fran=C3=A7ois Dumont wrote: > >>> I would like to propose this alternative approach. > >>> > >>> In this patch I make __normal_iterator and random iterator > >>> _Safe_iterator compatible for pointer_traits primary template. > >>> > >>> Regarding pointer_traits I wonder if it shouldn't check for the > >>> to_pointer method availability and use per default: return { > >>> std::addressof(__e) }; otherwise. This way we wouldn't have to > >>> provide a > >>> pointer_to method on __normal_iterator. > >> But I would rather not have these members present in vector::iterator > >> and string::iterator, in case users accidentally start to rely on them > >> being present. > > > > Making pointer_traits friends would help but I do not like it neither. > > > > > >> > >> Another option would be to overload std::__to_address so it knows how > >> to get the address from __normal_iterator and _Safe_iterator. > >> > >> . > > > > I start thinking that rather than proposing not-useful and even > > incorrect code in the case of the _Safe_iterator<> it might be a > > better approach. > > > > Even the rebind for __normal_iterator is a little strange because when > > doing rebind on std::vector::iterator for long it produces > > __normal_iterator>, quite inconsistent even if > > useless. > > > > But there's something that I'm missing, what is the relation between > > __addressof and std::pointer_traits ? Is it that __builtin_addressof > > is using it ? > > > Ignore this last question, I realized that we are talking about > __to_address, not __addressof. Yes, see the definition of std::__to_address in and also PR 96416.