220 22108 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: basic_string, vector, and array iterators: required to be pointers? Date: Thu, 29 Oct 2015 10:27:51 -0700 (PDT) Lines: 96 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_731_73963453.1446139671222" X-Trace: ger.gmane.org 1446139683 14874 80.91.229.3 (29 Oct 2015 17:28:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Oct 2015 17:28:03 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBF5OZGYQKGQEQ2D4QOI@isocpp.org Thu Oct 29 18:28:01 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f197.google.com ([209.85.220.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZrqzY-00034f-9j for gclcip-std-proposals@m.gmane.org; Thu, 29 Oct 2015 18:28:00 +0100 Original-Received: by qkgc186 with SMTP id c186sf57428651qkg.3 for ; Thu, 29 Oct 2015 10:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:content-type :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Z3eShzELz0cT0djFiKH7lIUImY/taC+QeobKRcpGk0M=; b=e9ihR5oIwg6TxptJ20p1Ue3Tt4OswVcfzkPEhy0n94wyUA3KnY2NhA1aBlY1CIKlqD mDJYyXT+8M5GSRfyQt5SCk7xu6Z4JnA9FPzgEy19FOG3o72g9lgcJaXZjTEVqz0hjP+0 IrrhqhjYy7dI+McFT7MMenJJSHZx29bKDIoPlCS4dQGK9I9NXrrrpKKr8G7V82+1UI+n 1pG4q0+MUui2dOg+Abh3kEvU5xMV3rk1sy5TWizj7LqZYk+5uq2VVaiOwCPxiFU4KF0q 2ooAYclhe1tQKJU5IZZicRWboGf5/DmL0U7XHwjry9ex7LLjo/LYvmKCoT9YILNcJvd4 MGLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Z3eShzELz0cT0djFiKH7lIUImY/taC+QeobKRcpGk0M=; b=JNS0Iwgz3fRA9ZBqIxIH51ontGBEwbzRT+lBhtqOXrJ963Yq9HSPjI8ljOOfU9h8WJ EYD+XE1K3IWxqw15etNfklYpv1MHNm8nJ7hJUnyG3mUZ5OaVtYS4cCCDlOYHyTebChay k3wpjsQgYCAvgIptkBepnIsyjbe2I8KTw/Y8/TuFMMKBJRNzkd6Q13MSnHSDTzwpssib w/TR8ri2KTd9lrKVyq0UDOpKQwUMK9COUr4i0uSiGl86NRdJNpOIZdl9coMK2EcLkTJS r0VBnU8tSqu0O9m4xNDcSsnVmq6fYCWUMuxxCa+mnlJZBT/Cpqd6/gcHxHAxHsLQ7bKM QrVw== X-Gm-Message-State: ALoCoQkGKlAcRZqqSC3x7kTXvlpZgmK4BBqN2n2nmZYKxvuSkKmD3MO1sRgvuLs8jit0xYcZ28a3 X-Received: by 10.13.248.68 with SMTP id i65mr2335614ywf.39.1446139679634; Thu, 29 Oct 2015 10:27:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.26.72 with SMTP id a69ls360679ioa.108.gmail; Thu, 29 Oct 2015 10:27:51 -0700 (PDT) X-Received: by 10.50.77.70 with SMTP id q6mr310055igw.4.1446139671706; Thu, 29 Oct 2015 10:27:51 -0700 (PDT) X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:22108 Archived-At: ------=_Part_731_73963453.1446139671222 Content-Type: multipart/alternative; boundary="----=_Part_732_1452777140.1446139671222" ------=_Part_732_1452777140.1446139671222 Content-Type: text/plain; charset=UTF-8 That's the question: should the standard explicitly *require* that `basic_string`, `vector`, and `array` iterators are pointers? Along with any similar types we get (there's been some talk about `stack_array` or whatever). Let's break down the use cases. That is, why do we want them to be pointers? 1) Performance. 2) The ability to use such iterators in pointer-based interfaces without having to do `&*` on them. 3) The ability to get pointers back from pointer-based interfaces and use them easily. I've always felt that #1 should always be considered a question of the implementation. I *want* the ability for debug builds to be able to do range checking for me. I also want those checks to vanish in release builds. But I think we can achieve #2 and #3 without needing to make them explicitly pointers. We simply need two changes: A) Allow these iterators of these types to be *implicitly convertible* to pointers. That solves #2 neatly. B) Allow users to convert a pointer to some element into an iterator. That solves #3 neatly. B should be a (possibly non-member) function of the *container*. That is, you shouldn't be able to implicitly construct an iterator from a pointer. The container ought to verify that the pointer is actually within the range before doing so. And as a non-member function, it can be specialized/ADL'd for different types. Are these good ideas? -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_732_1452777140.1446139671222 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's the question: should the standard explicitly require that `basic_string`, `vector`, and `array` iterators are point= ers? Along with any similar types we get (there's been some talk about = `stack_array` or whatever).

Let's break down the use cases. That= is, why do we want them to be pointers?

1) Performance.

2) T= he ability to use such iterators in pointer-based interfaces without having= to do `&*` on them.

3) The ability to get pointers back from po= inter-based interfaces and use them easily.

I've always felt tha= t #1 should always be considered a question of the implementation. I wan= t the ability for debug builds to be able to do range checking for me. = I also want those checks to vanish in release builds.

But I think we= can achieve #2 and #3 without needing to make them explicitly pointers. We= simply need two changes:

A) Allow these iterators of these types to= be implicitly convertible to pointers. That solves #2 neatly.
B) Allow users to convert a pointer to some element into an iterator. Tha= t solves #3 neatly.

B should be a (possibly non-member) function of = the container. That is, you shouldn't be able to implicitly cons= truct an iterator from a pointer. The container ought to verify that the po= inter is actually within the range before doing so. And as a non-member fun= ction, it can be specialized/ADL'd for different types.

Are thes= e good ideas?

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_732_1452777140.1446139671222-- ------=_Part_731_73963453.1446139671222-- .