220 19235 <15e678b3-9b6b-4966-a7a5-1d37495fda5e@isocpp.org> article Path: news.gmane.org!not-for-mail From: Vlad from Moscow Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Overloading std::begin and std::end for std::pair Date: Fri, 24 Jul 2015 00:36:04 -0700 (PDT) Lines: 211 Approved: news@gmane.org Message-ID: <15e678b3-9b6b-4966-a7a5-1d37495fda5e@isocpp.org> References: <012fd35d-96fd-4775-835e-2105176c4f97@isocpp.org> <792fab39-5af7-4d95-b9ba-a5cc4aed8544@isocpp.org> <8100167.A1Y3soRlXn@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_318_1054327731.1437723364615" X-Trace: ger.gmane.org 1437723373 22113 80.91.229.3 (24 Jul 2015 07:36:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jul 2015 07:36:13 +0000 (UTC) Cc: thiago@macieira.org To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCXLLRHD7IDRBZOVY6WQKGQE7QEFKNY@isocpp.org Fri Jul 24 09:36:07 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 1ZIXWZ-0005ZA-B4 for gclcip-std-proposals@m.gmane.org; Fri, 24 Jul 2015 09:36:07 +0200 Original-Received: by qkcb2 with SMTP id b2sf24737760qkc.3 for ; Fri, 24 Jul 2015 00:36:06 -0700 (PDT) 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:cc:message-id:in-reply-to :references: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=VfptZbNgWPCGOanYisAb+zIqTwPk1i+9orsbiIIgSLM=; b=Itx3efx2Qh6lOqs6ohLsiEnIRYSc8jvXriGfO6od5CCsXJSpdMhCyQZiXtA8zX4QkN Ky0+kCanztE3tlbd3FiAc7ACJaMGFrq4ziEM4hWw54yYUFIIIzGtWDBq5CFHN887pi3c 9Y5ByHYQOSmIg+YgCW963httR9zVI+I6zn63mayEn+ZsulCKg/Qv35fyFzIKC0igd4+I 5iv/b2v3Q4f8SIrazofvDwZkJ/UzB7+EgYKetnSN76FkWCUw/+ONzWwTiG6JtqW2sVE4 bw649qKqqorRHJcJd/QudD4CLGXmSrvNZNLG0nFCueC9f68HAybQxwZ/7JX+5cSFUfY1 8A6Q== X-Gm-Message-State: ALoCoQlRiWVurOx79zRTIQZE+D23e5PJBHt2jbswfcTji+6kYkL8FoOdEF3XgLxZWPr0HnRoGmYh X-Received: by 10.140.232.13 with SMTP id d13mr12632781qhc.2.1437723366388; Fri, 24 Jul 2015 00:36:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.28.74 with SMTP id 68ls1378869qgy.28.gmail; Fri, 24 Jul 2015 00:36:05 -0700 (PDT) X-Received: by 10.140.81.149 with SMTP id f21mr258023qgd.8.1437723365251; Fri, 24 Jul 2015 00:36:05 -0700 (PDT) In-Reply-To: <8100167.A1Y3soRlXn@tjmaciei-mobl4> X-Original-Sender: vlad.moscow@mail.ru 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:19235 Archived-At: ------=_Part_318_1054327731.1437723364615 Content-Type: multipart/alternative; boundary="----=_Part_319_849222971.1437723364615" ------=_Part_319_849222971.1437723364615 Content-Type: text/plain; charset=UTF-8 On Friday, July 24, 2015 at 1:58:22 AM UTC+3, Thiago Macieira wrote: > > On Thursday 23 July 2015 12:31:59 Vlad from Moscow wrote: > > Could you explain why do I need some ranges when this program looks > clear > > and nice without any ranges? > > Because you made it so that std::pair is always a range, but that > isn't > the case. In fact, I'd argue that most people who think of "iterating" > over a > pair expect it to behave as an array of two elements: the first and the > second. > > There is a serious logical mistake. If for example two pointers can make up a range this does not mean that any two pointers is a range or that any range is two pointers. Even two iterators of the same container or two pointers of the same array might not make a range. std::pair is simply a media that can store iterators. It is used in algorithm std::mismatch where iterators does not make up a range or in the algorithm or class methods equal_range where pointers make up a range. It is a responsibility of the programmer to use appropriate iterators that are stored in the media. So you and Sean Middleditch attempts to substitute the meaning of std::pair for the role like just ranges are false and confuse programmers. It is responsibility of the programmer to correctly use std::pair in different situations. With the same success you can use any valid C++ construction incorrectly. For example you can return a reference to a local variable of a function. Does it mean that something wrong with references and the programmers shall not declare function return types as references? According to your false logic it follows that the programmers indeed shall not declare function return types as references The ptoblem is why should the programmer pay for the means that he totally need not? I showed already an example with std::multimap where the code looks clear and nice. But you are saying: "Stop! Programs must not be so clear and nice. You have to declare a class hierarchy and use these additional classes to do a simple and entirely correct thing." Why do the programmer have to use a suoerstructure when he already has a range that he stored on such a media like std::pair? And moreover now Sean Middleditch is even going to deform standard algorithms with the only purpose that all programmers used his useless superstructures where all can be done simply and clear without them. I'd expect: > > template const T* begin(const pair &p) > { return &p.first; } > > template const T *end(const pair &p) > { return &p.second + 1; } > > Which allows me to run: > > int main() > { > for (auto i : std::make_pair(1, 2)) > cout << i << ' '; > cout << endl; > } > > output: 1 2 > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > > -- --- 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_319_849222971.1437723364615 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, July 24, 2015 at 1:58:22 AM UTC+3, Thia= go Macieira wrote:
On Thursday 23 July 2015 12:= 31:59 Vlad from Moscow wrote:
> Could you explain why do I need some ranges when this program look= s clear=20
> and nice without any ranges?

Because you made it so that std::pair<T, T> is always a range, bu= t that isn't=20
the case. In fact, I'd argue that most people who think of "it= erating" over a=20
pair expect it to behave as an array of two elements: the first and the= second.


There is a serious logical mistake. If for exampl= e two pointers can make up a range this does not mean that any two pointers= is a range or that any range is two pointers. Even two iterators of the sa= me container or two pointers of the same array might not make a range.

std::pair is simply a media that can store iterators. = It is used in algorithm std::mismatch where iterators does not make up a ra= nge or in the algorithm or class methods=C2=A0 equal_range where pointers m= ake up a range.

It is a responsibility of the prog= rammer to use appropriate iterators that are stored in the media.

So you and Sean Middleditch attempts to substitute the mean= ing of=C2=A0 std::pair for the role like just ranges are false and confuse = programmers.
It is responsibility of the programmer to correctly = use std::pair in different situations.
=C2=A0
With the = same success you can use any valid C++ construction incorrectly. For exampl= e you can return a reference to a local variable of a function. Does it mea= n that something wrong with references and the programmers shall not declar= e function return types as references?

According = to your false logic it follows that the programmers indeed shall not declar= e function return types as references

The ptoblem = is why should the programmer pay for the means that he totally need not?

I showed already an example with std::multimap where= the code looks clear and nice. But you are saying: "Stop! Programs mu= st not be so clear and nice. You have to declare a class hierarchy and use = these additional classes to do a simple and entirely correct thing."

Why do the programmer have to use a suoerstructure = when he already has a range that he stored on such a media like std::pair?<= /div>

And moreover now Sean Middleditch is even going to= deform standard algorithms with the only purpose that all programmers used= his useless superstructures where all can be done simply and clear without= them.


I&#= 39;d expect:

template<typename T> const T* begin(const pair<T, T> &p= )
{ return &p.first; }

template<typename T> const T *end(const pair<T, T> &p)
{ return &p.second + 1; }

Which allows me to run:

int main()
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0for (auto i : std::make= _pair(1, 2))
=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=A0cout << i << ' ';
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cout << endl;
}

output: 1 2
--=20
Thiago Macieira - thiago (AT) macieira= ..info - thiago (AT) kde.org
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4= 5358

--

---
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_319_849222971.1437723364615-- ------=_Part_318_1054327731.1437723364615-- .