220 19249 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 13:06:21 -0700 (PDT) Lines: 647 Approved: news@gmane.org Message-ID: References: <012fd35d-96fd-4775-835e-2105176c4f97@isocpp.org> <792fab39-5af7-4d95-b9ba-a5cc4aed8544@isocpp.org> <8100167.A1Y3soRlXn@tjmaciei-mobl4> <15e678b3-9b6b-4966-a7a5-1d37495fda5e@isocpp.org> <9c360e55-9315-4585-9402-a813a4765e8d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1082_1582433338.1437768381872" X-Trace: ger.gmane.org 1437768404 17207 80.91.229.3 (24 Jul 2015 20:06:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jul 2015 20:06:44 +0000 (UTC) Cc: sasha2048@gmail.com, inkwizytoryankes@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCXLLRHD7IDRBPVVZKWQKGQE3FO3S4Q@isocpp.org Fri Jul 24 22:06:29 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZIjEf-0002ek-Ni for gclcip-std-proposals@m.gmane.org; Fri, 24 Jul 2015 22:06:26 +0200 Original-Received: by iebyd10 with SMTP id yd10sf55468367ieb.2 for ; Fri, 24 Jul 2015 13:06:25 -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=DhDF8QtmoOvYK1Hn7S5MLynreIr66CvAeAQURc6YRb8=; b=FzOLccdDd+TflbBlrHoja6DVK0CvmeyW7ZDETXkQIYyKdJalT1N/S2HusXd8Kdy01N AvCaMqMMG2N2+C64hjNjizHV/Lhs09/WQwDueKwfpnZEfBRT9Lg5NoHbdEKDr0Lkug0A H31LQrost1cxsnIdT3FZyZk+Lbb97nNzx5OqIA1hdtRhythN0e3sQPpxl935EzYk1aCV pIR+O4iIXke1TQRdSwQdqXhUp8mskpAH5C0I4UtGsUnYvX8F7ryHVi8FXYGcPMr+z2c5 X325lKb00BqMc9jw9sWxPLLY/mxh6onog9HGSO9XzQgdtBqkRVmT18oHpI1WRLftzOh8 MBcA== X-Gm-Message-State: ALoCoQmSbwX9xt4XoPfwuM+XUf2Ml+4hmri1Z+5Nm4v7YI9g+XnH6TUJ2s2bf31++VGX7xejIGUh X-Received: by 10.107.7.220 with SMTP id g89mr14718847ioi.2.1437768384976; Fri, 24 Jul 2015 13:06:24 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.17.170 with SMTP id 39ls1743055qgd.6.gmail; Fri, 24 Jul 2015 13:06:22 -0700 (PDT) X-Received: by 10.140.91.182 with SMTP id z51mr321692qgd.5.1437768382554; Fri, 24 Jul 2015 13:06:22 -0700 (PDT) In-Reply-To: <9c360e55-9315-4585-9402-a813a4765e8d@isocpp.org> 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:19249 Archived-At: ------=_Part_1082_1582433338.1437768381872 Content-Type: multipart/alternative; boundary="----=_Part_1083_1495154463.1437768381873" ------=_Part_1083_1495154463.1437768381873 Content-Type: text/plain; charset=UTF-8 On Friday, July 24, 2015 at 9:59:16 PM UTC+3, inkwizyt...@gmail.com wrote: > > If some object have `begin` and `end` then its range. Most pair aren't > ranges then they should not have this functions. > Most pointers are not ranges. Does it mean that pointers can not make up a range? Consider for example a dynamically allocated array. Does it has a range? How will you specify its range? I think you will specify it as a pair of pointers will not you? So for example if you allocated an integer array of size n and the address of the allocated area was stored in pointer a then pair a and a + n set a valid range. How do you specify pairs in C++? I suspect that you use std::pair. std::pair range( a, a + n ); or auto range = std::make_pair( a, a + n ); So if you have a pair that specifiers a valid range then you expect this range can be used in for example the for range statement So it is natural and locgically consistent for example to write for ( int x : range ) std::cout << x << ' '; It is a valid record. Why? Because object range defines a valid range. It already exists. There is no need to invent some superconstructions that to convert this valid range in the same valid range, You already have it. Another example that I showed early is using either algorithm or class methods equal_range. They all return a valid range do not they? Thus std::pair is an integral part of algorithms and ranges. It is already used to specify a valid range. There is nothing to invent. All you need is to have an access to elements of the ranges they make up. To have an access means that you need to get accfess to the beginning of the range and to the end of the range. You have such an access simply writing for ( auto begin = p.first, end = p.second; begin != end; ++begin ) { /*...*/ } There is no any need to deform algorithms. All you need you already have in your disposal. Only instead of for ( auto begin = p.first, end = p.second; begin != end; ++begin ) { /*...*/ } it is better to write for ( x : p ) { /(...*/ } However according to your logic you prefer to use only this record of the loop for ( auto begin = p.first, end = p.second; begin != end; ++begin ) { /*...*/ } Why? Because your argument is that std::pair does not set a range.:) It is funny.:) I am sorry I do not see any logic in your words. Of course you can create a class that will be named something like ranges. You can even to build a hierarchy of such classes and numerous specializations of the classes. :) But to use the range that is held in an object of type std::pair your classes are useless. All examples of code that I showed in this thread I wrote literally in 5-10 minutes without inventing any classes. Because it is natural way of using std::pair having a range. On the other hand your hierarchy of classes of ranges has been created if I am not mistaken already several years. And in the examples I showed their usage is no more than the usage of soap bubbles. > If some objects don't give you guarantees about something but you know in > some cases it true then proper way of use is EXPLICITLY show that it hold > true. > In our case `std::make_range` fulfill this requirements. > > Probably solution for this problem are tagged pairs and tuples (IIRC they > are form range proposition). > It look something like that: > > extern int tab[10]; > > std::pair, std::end_tag> a; > std::pair, std::success_tag> b; > > a.begin() = tab; //equal a.first = tab; > a.end() = tab + 10; //equal a.second = tab + 10; > for (auto& x : a) > { > if (x == 5) > { > b.ptr() = &x; > b.success() = true; > } > } > return b; > > > > > On Friday, July 24, 2015 at 3:10:03 PM UTC+2, Vlad from Moscow wrote: >> >> >> >> On Friday, July 24, 2015 at 3:50:58 PM UTC+3, Sasha Unknown wrote: >>> >>> To T. C. and Sean Middleditch: Thank you for you patience. While I >>> don't like the this proposal of Vlad from Moscow for many reasons, I >>> appreciate patience and level of detail in your responses. At some >>> point in future these patience and detail-level may save some good but >>> ugly-looking proposal. >>> >>> To Vlad from Moscow: >>> 1. Just to satisfy my interest: Aren't you coming to C++ from some >>> dynamically-typed language? >>> 2. If n2995 and/or D4128 would be accepted, they will satisfy all your >>> requests: >>> for ( auto x : std::make_range( a + 3, a + 7 ) ) ...; >>> for ( auto p : m.equal_range( 'A' ) ) ...; >>> >>> >> It seems you do not understand. There is no any need to build a >> superconstruction or to deform algorithms that to do this in clear and >> natural way. >> >> The C++ Standard already has all needed to do the task. And if you have >> a pair of iterators that make up a range then why do you need to build a >> range from already existent valid range?! Simply write >> >> for ( auto x : p ) ...; >> >> There is such principle KISS in programming that means Keep It Simple >> Stupid. >> >> The programmer should not pay for what he totally need not. >> >> What you are suggesting looks the following way. I have a notebook. You >> come to my home take away my notebook and say: "Pay me and i will give you >> a notebook". And after I paid you return me my notebook. >> >> Excelent idea! >> >> >> >> >> On Fri, Jul 24, 2015 at 10:36 AM, Vlad from Moscow >>> wrote: >>> > >>> > >>> > 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-proposal...@isocpp.org. >>> > To post to this group, send email to std-pr...@isocpp.org. >>> > Visit this group at >>> > http://groups.google.com/a/isocpp.org/group/std-proposals/. >>> >> -- --- 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_1083_1495154463.1437768381873 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, July 24, 2015 at 9:59:16 PM UTC+3, inkw= izyt...@gmail.com wrote:
If so= me object have `begin` and `end` then its range. Most pair aren't range= s then they should not have this functions.

=
Most pointers are not ranges. Does it mean that pointers can not= make up a range?

Consider for example a dynamica= lly allocated array. Does it has a range?

How will= you specify its range? I think you will specify it as a pair of pointers w= ill not you? So for example if you allocated an integer array of size n and= the address of the allocated area was stored in pointer=C2=A0a then pair= =C2=A0a and=C2=A0a + n set a valid range. How do you specify pairs in C++? = I suspect that you use std::pair.

std::pair<int= *, int *> range( a, a + n );

or

=
auto range =3D std::make_pair( a, a + n );

<= div>
So if you have a pair that specifiers a valid range then= you expect this range can be used in for example the for range statement

So it is natural and locgically consistent for exam= ple to write

for ( int x :=C2=A0range ) std::cout = << x << ' ';

It is a valid rec= ord. Why? Because=C2=A0object range defines a valid range. It already exist= s. There is no need to invent some superconstructions that to convert this = valid range in the same valid range, You already have it.

Another example that I showed early is using either algorithm or cl= ass methods equal_range. They all return a valid range do not they?

Thus std::pair is an integral part of algorithms and rang= es. It is already used to specify a valid range. There is nothing to invent= .. All you need is to have an access to elements of the ranges they make up.= To have an access means that you need to get accfess to the beginning of t= he range and to the end of the range.

You have suc= h an access simply writing

for ( auto begin =3D p.= first, end =3D p.second; begin !=3D end; ++begin ) { /*...*/ }
There is no any need to deform algorithms.=C2=A0All you need y= ou already have in your disposal.=C2=A0

Only inste= ad of

for ( auto begin =3D p.first, end =3D = p.second; begin !=3D end; ++begin ) { /*...*/ }

it= is better to write

for ( x : p ) { /(...*/ }

However according to your logic you prefer to use only= =C2=A0this=C2=A0record of the loop

for ( auto= begin =3D p.first, end =3D p.second; begin !=3D end; ++begin ) { /*...*/ }=

Why? Because your argument is that std::pair does= not set a range.:) It is funny.:)=C2=A0

I am sorr= y I do not see any logic in your words.

Of course= you can create a class that will be named something=C2=A0like ranges.=C2= =A0 You can even to build a hierarchy of such classes and numerous speciali= zations of the classes. :)

But to use the range th= at is held in an object of type std::pair your classes are useless.

All examples of code that I showed in this thread I wrote= literally in 5-10 minutes without inventing any classes. Because it is nat= ural way of using std::pair having a range.

On the= other hand your hierarchy of classes of ranges has been created if I am no= t mistaken already several years. And in the examples I showed their usage = is no more than the usage of soap bubbles.

=C2=A0=
If some obj= ects don't give you guarantees about something but you know in some cas= es it true then proper way of use is EXPLICITLY show that it hold true.
= In our case `std::make_range` fulfill this requirements.

Probably so= lution for this problem are tagged pairs and tuples (IIRC they are form ran= ge proposition).
It look something like that:

extern int tab[10];

std::pair<std::begin_tag<int*>, std::= end_tag<int*>> a;
std::pair<std::ptr_tag<int*>, std::<= /span>success_tag<bool>> b;

a.begin() =3D; //= equal a.first =3D tab;
a.end() =3D tab + 10; //equal a.second =3D tab + = 10;
for (auto& x : a)
{
=C2=A0 =C2=A0 if (x =3D=3D 5)
=C2=A0 =C2=A0 {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 b.ptr() =3D &x;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 b.success() =3D <= /span>true;
=C2= =A0 =C2=A0 }
}
return b;
<= /div>



On Friday, July 24, 2015 at 3:10:03 PM UTC+2, Vlad fro= m Moscow wrote:


On Fri= day, July 24, 2015 at 3:50:58 PM UTC+3, Sasha Unknown wrote:
To T. C. and Sean Middleditch: Thank you for you patience. Wh= ile I
don't like the this proposal of Vlad from Moscow for many reasons, = I
appreciate patience and level of detail in your responses. At some
point in future these patience and detail-level may save some good but
ugly-looking proposal.

To Vlad from Moscow:
1. Just to satisfy my interest: Aren't you coming to C++ from some
dynamically-typed language?
2. If n2995 and/or D4128 would be accepted, they will satisfy all your = requests:
=C2=A0 =C2=A0 for ( auto x : std::make_range( a + 3, a + 7 ) ) ...;
=C2=A0 =C2=A0 for ( auto p : m.equal_range( 'A' ) ) ...;


It seems you do not understand. There = is no any need to=C2=A0build a superconstruction or to deform algorithms th= at to do this in clear and natural way.

The C++ St= andard already has all=C2=A0needed to do the task.=C2=A0 And if you have a = pair of iterators that make up a range then why do you need to build a rang= e from already existent valid range?! Simply write

=C2=A0=C2=A0=C2=A0 for ( auto=C2=A0x :=C2=A0p ) ...;

=
There is such principle KISS in programming that means Keep It Simple = Stupid.

The=C2=A0programmer should not pay for wha= t he totally need not.

What you are suggesting loo= ks the following way. I have a notebook. You come to my home take away my n= otebook and say: "Pay me and i will give you a notebook". And aft= er I paid you=C2=A0return me my notebook.

Excelent= idea!




On Fri, Jul 24, 2015 at 10:36 AM, Vlad from Mosco= w <vlad....@mail.ru> wrote:
>
>
> On Friday, July 24, 2015 at 1:58:22 AM UTC+3, Thiago Macieira wrot= e:
>>
>> On Thursday 23 July 2015 12:31:59 Vlad from Moscow wrote:
>> > Could you explain why do I need some ranges when this pro= gram looks
>> > clear
>> > and nice without any ranges?
>>
>> Because you made it so that std::pair<T, T> 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 firs= t and the
>> second.
>>
>
> There is a serious logical mistake. If for example two pointers ca= n make up
> a range this does not mean that any two pointers is a range or tha= t 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 i= n
> algorithm std::mismatch where iterators does not make up a range o= r in the
> algorithm or class methods =C2=A0equal_range where pointers make u= p a range.
>
> It is a responsibility of the programmer to use appropriate iterat= ors that
> are stored in the media.
>
> So you and Sean Middleditch attempts to substitute the meaning of = =C2=A0std::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 incor= rectly.
> For example you can return a reference to a local variable of a fu= nction.
> Does it mean that something wrong with references and the programm= ers shall
> not declare function return types as references?
>
> According to your false logic it follows that the programmers inde= ed 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 look= s 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 cla= sses 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 use= less
> superstructures where all can be done simply and clear without the= m.
>
>
>> I'd expect:
>>
>> template<typename T> const T* begin(const pair<T, T&g= 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 for (auto i : std::make_pair(1, 2)= )
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cout &= lt;< i << ' ';
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 cout << endl;
>> }
>>
>> output: 1 2
>> --
>> 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
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, = send an
> email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...= @isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/= std-proposals/.

--

---
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_1083_1495154463.1437768381873-- ------=_Part_1082_1582433338.1437768381872-- .