From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by sourceware.org (Postfix) with ESMTPS id C53E83858D28; Mon, 4 Oct 2021 20:27:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C53E83858D28 Received: by mail-wm1-x329.google.com with SMTP id z2so14433215wmc.3; Mon, 04 Oct 2021 13:27:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ZNryIoZPvParPK+E09yedrqT85/Fz/jIQ9TQ3H4K/OY=; b=5NNBFSaBu7IqaH1hyyXoD5NxPC0vJUehBS9iIWtEF2myWn8B8PBWdRC92lDlmMOrsn K5YYwITjYy7j/yn+30KkKVpjyB6ir6x3HcBHSGCiuUE9VqbO743odw77WGVvHB0BCd7F NW9SDzA2e86+JVuvnBs8BFvT7ZMHD50hQ86X7bXk5Vy1TAwAz13jg4R370xDnBAW0Os+ XSTn4Qr4xgeCmaU4hTuXIPnk/8akSVAZX7aNo+nfQ/a8ebQJeMPGMZ3e562ZkSIw6Iuh K9pav7WZhHoWdqQH4CUR5cjU7CA8zqJm3TJir8BF8zzAcMmE/rl/Tx3W4/pF4lMV5i0V GE/w== X-Gm-Message-State: AOAM5324j++AU8zX77R3x6NUKRR7Km5gVdyO9uWrZt2CnayQG0E+aO/M 3uN+5Hm9lYKrYPKZwMFnNoPTP1yEl7Kbag== X-Google-Smtp-Source: ABdhPJyham2tNVSF+w4qonn/viz+149XmjsoeyQ1DoloouVU1TsP/R7BIvyWunf0+Mahl7/xivRrGw== X-Received: by 2002:a7b:cbc2:: with SMTP id n2mr101197wmi.2.1633379220627; Mon, 04 Oct 2021 13:27:00 -0700 (PDT) Received: from ?IPv6:2a01:e0a:1dc:b1c0:e5de:4d6e:565b:8a5e? ([2a01:e0a:1dc:b1c0:e5de:4d6e:565b:8a5e]) by smtp.googlemail.com with ESMTPSA id o1sm15511625wru.91.2021.10.04.13.27.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Oct 2021 13:27:00 -0700 (PDT) Subject: Re: [committed] libstdc++: Specialize std::pointer_traits<__normal_iterator> From: =?UTF-8?Q?Fran=c3=a7ois_Dumont?= To: Jonathan Wakely Cc: libstdc++ , gcc-patches References: <57b54891-59ba-394d-3d53-218f5061b8ef@gmail.com> <9ea0770a-54fb-2c17-b527-2797b5fd3b50@gmail.com> Message-ID: <34b34b00-8c96-68c1-e436-ab0f64291c2f@gmail.com> Date: Mon, 4 Oct 2021 22:26:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <9ea0770a-54fb-2c17-b527-2797b5fd3b50@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, 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:27:03 -0000 On 04/10/21 10:05 pm, François Dumont wrote: > On 02/10/21 10:24 pm, Jonathan Wakely wrote: >> On Sat, 2 Oct 2021 at 18:27, François 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.