220 33174 <6e2d133b-1c0a-49a9-ae2b-98d82d3a40d3@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Add a few missing things from the iterator library Date: Tue, 11 Jul 2017 07:36:05 -0700 (PDT) Lines: 146 Approved: news@gmane.org Message-ID: <6e2d133b-1c0a-49a9-ae2b-98d82d3a40d3@isocpp.org> References: <9434787.nHRs7m2U1a@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7290_1864966793.1499783765653" X-Trace: blaine.gmane.org 1499783768 30813 195.159.176.226 (11 Jul 2017 14:36:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Jul 2017 14:36:08 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBVWESPFQKGQEGU3VNYY@isocpp.org Tue Jul 11 16:36:04 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f71.google.com ([74.125.83.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dUwGi-0007ig-5r for gclcip-std-proposals@m.gmane.org; Tue, 11 Jul 2017 16:36:04 +0200 Original-Received: by mail-pg0-f71.google.com with SMTP id u5sf1310799pgq.14 for ; Tue, 11 Jul 2017 07:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=jyTtenyacn21GiVy74Pjop3KeK1SLYcK79bYPRUC3AM=; b=mKOnqj0yJ1eU9rXPe5Y9CEVSTm3ORu36Z7/2Ocbg2gRZtwG5OSOhE3Pfj4ag4oCOqA b0rY2RT1C0r1J5gZIuifLEy0nl6YOhx1gV0hOw9vbo92od+QK7J9JemJsXRkx2iKBamk NZRh/6+gARWdpa9wVOdv70/IYFCLSXl+d0kboy4PRYWdR9VQioTuM53dKi8HdGQLtnoj FBJFexCERrI9cCcLa/XFuXFb4HRM5eDblEZ3OTQ4m1wPPJHOXq0F1kAbUmgc9av5pC+j giRolbgYNcOFxXBJRpZmUXJRCcCO+7iTfksq6eFKBB+pup+Zm4OIrngdQwOQFZUawzmd l7Hg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=jyTtenyacn21GiVy74Pjop3KeK1SLYcK79bYPRUC3AM=; b=OKAJ+rNT5qyO5nmWVjicX6TRaU+75nnCJeGpo7s1te2uwnLMpdYqRCxNCm4uXLCx84 TNxETsNXgLTbQ2KqUu+QXgIspivAsxhRZ3eMjJJSqOPwJ9Wm38JUk0qLoHPRxuR/YMAO h0L5A7SZShuPSkT53sh/WfxGn7EWbdc+k39JNPISUd4cCmv6XiuZF6xLJI82bmiJvdEZ dZ1ct0fhvlxTJ0b0KY3jl5f1O+NQApL9grsJT05v3rjCeRW8j3v9VxMF1qipHogJp2yS 7EGxrJuVkWzXVdi5PWc8nWL3twqom9BOl5Mu0Cib1xP2b/lWwLYlIdrN/j9sV3QR+QCL AuXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version: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=jyTtenyacn21GiVy74Pjop3KeK1SLYcK79bYPRUC3AM=; b=po7dM2oC1AZE8zZorqWOHzkuOnjfvTvtH8lJvkXiv7FTH8oSGBvaTFrQcamHj5sp9c bbr5fzwMEL4rwC3A6WdiDg5TeF40bL2A/HKAqkrcws/BjRQMn7eCUE84al1pt3KtBdt1 9XUSAA6ULiLilqgpfAHDGwiKHyMAyH50qDHBALnjByii9nIaFqcSCz3WTstUdhwtg9wZ FhRHSly7NijPGkb7MzffENxOeW4rKpaEPySLZFNn8PDrQNQnJkkak43Gbw1Y/Nb+YE/2 CcSM4t3qhGrqQcL5zhTE34tuAJbRyXGgO2BTBlroCDdLqGIUruK4whHIhd44KY3J8NVY pNEg== X-Gm-Message-State: AIVw112ZgSYIWKF7RchmUdoR1SlU30mI0XyykGKvXgC+dowy8A6RzHI3 JwPd+XYZHfM5yUL4 X-Received: by 10.99.123.10 with SMTP id w10mr156034pgc.81.1499783767900; Tue, 11 Jul 2017 07:36:07 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.83.2 with SMTP id n2ls7242714itb.3.canary-gmail; Tue, 11 Jul 2017 07:36:06 -0700 (PDT) X-Received: by 10.36.34.209 with SMTP id o200mr684433ito.0.1499783766342; Tue, 11 Jul 2017 07:36:06 -0700 (PDT) In-Reply-To: <9434787.nHRs7m2U1a@tjmaciei-mobl1> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:33174 Archived-At: ------=_Part_7290_1864966793.1499783765653 Content-Type: multipart/alternative; boundary="----=_Part_7291_1964673315.1499783765653" ------=_Part_7291_1964673315.1499783765653 Content-Type: text/plain; charset="UTF-8" On Tuesday, July 11, 2017 at 2:14:08 AM UTC-4, Thiago Macieira wrote: > > On segunda-feira, 10 de julho de 2017 22:21:10 PDT Giovanni Funchal wrote: > > I agree with Daniel's point that the 1:1 relation between container and > > iterator types is not currently mandated. However: > > - I believe it only affects (3). > > Strictly speaking, yes. But (2) is also difficult to achieve. You're > asking for > a way to transform an iterator to const_iterator, but those types are > often > unrelated. For example, for libstdc++'s std::unordered_map, the two > iterator > classes are just aliases to std::__detail::_Node_const_iterator and > std::__detail::_Node_iterator. > > A const iterator is not the same as a const_iterator. > > > - Due to std::iterator_traits, iterators know something about > > their container (iterator_category) so there is already limited scope > for > > an iterator to be used in multiple containers. BTW, perhaps > > std::iterator_traits::iterator_container would be a better > place > > for (3). > > First, the category is the category of the iterator, not of the container. > Second, you cannot have a link back to the container, period. (3) is > simply > unachievable. Just think of this, what should this be > > std::iterator_traits::container > > choose: > std::vector > std::string > std::basic_string > really... > std::array > QVector > QByteArray > Even better, what about iterators that do not have containers? Things like iterator wrappers and mutators. No algorithm has any right to query anything about the iterator's container. That's the whole point of iterators: to be the intermediary between the container of the data and the algorithm that acts on the data. If there is something lacking in our iterator interfaces which algorithms genuinely need, then *that* is what needs to be fixed. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6e2d133b-1c0a-49a9-ae2b-98d82d3a40d3%40isocpp.org. ------=_Part_7291_1964673315.1499783765653 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, July 11, 2017 at 2:14:08 AM UTC-4, Thiago Maci= eira wrote:
On segunda-feira, 1= 0 de julho de 2017 22:21:10 PDT Giovanni Funchal wrote:
> I agree with Daniel's point that the 1:1 relation between cont= ainer and
> iterator types is not currently mandated. However:
> - I believe it only affects (3).

Strictly speaking, yes. But (2) is also difficult to achieve. You'r= e asking for=20
a way to transform an iterator to const_iterator, but those types are o= ften=20
unrelated. For example, for libstdc++'s std::unordered_map, the two= iterator=20
classes are just aliases to std::__detail::_Node_const_iterator an= d=20
std::__detail::_Node_iterator.

A const iterator is not the same as a const_iterator.

> - Due to std::iterator_traits<iterator>, iterators know= something about
> their container (iterator_category) so there is already limited sc= ope for
> an iterator to be used in multiple containers. BTW, perhaps
> std::iterator_traits<iterator>::iterator_container woul= d be a better place
> for (3).

First, the category is the category of the iterator, not of the contain= er.=20
Second, you cannot have a link back to the container, period. (3) is si= mply=20
unachievable. Just think of this, what should this be

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std::iterator_traits<= ;char *>::container

choose:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std::vector<char>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std::string
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0std::basic_string<char, any trait, any a= llocator> really...
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std::array<char, N&g= t;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0QVector<char>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0QByteArray

Even better, what about iterators that do not hav= e containers? Things like iterator wrappers and mutators.

No algorit= hm has any right to query anything about the iterator's container. That= 's the whole point of iterators: to be the intermediary between the con= tainer of the data and the algorithm that acts on the data. If there is som= ething lacking in our iterator interfaces which algorithms genuinely need, = then that is what needs to be fixed.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/6e2d133b-1c0a-49a9-ae2b-98d82d3a40d3= %40isocpp.org.
------=_Part_7291_1964673315.1499783765653-- ------=_Part_7290_1864966793.1499783765653-- .