220 19278 <2538311b-63f0-4242-b826-3d115439de78@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: Sat, 25 Jul 2015 07:10:18 -0700 (PDT) Lines: 516 Approved: news@gmane.org Message-ID: <2538311b-63f0-4242-b826-3d115439de78@isocpp.org> 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_34_418058296.1437833418851" X-Trace: ger.gmane.org 1437833424 21716 80.91.229.3 (25 Jul 2015 14:10:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Jul 2015 14:10:24 +0000 (UTC) Cc: sasha2048@gmail.com, inkwizytoryankes@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCXLLRHD7IDRBS5RZ2WQKGQEMEV4JFI@isocpp.org Sat Jul 25 16:10:24 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZJ09e-0000SK-Qt for gclcip-std-proposals@m.gmane.org; Sat, 25 Jul 2015 16:10:23 +0200 Original-Received: by oiho132 with SMTP id o132sf84741517oih.1 for ; Sat, 25 Jul 2015 07:10:21 -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=1zZePfm+RkRQbSMmUmSrPQGP2qxJ6CWqGu5uN4RhspU=; b=IqFu1SnaQb47puHwfbtdOrN/3RF3W+SEMvOa1gLed3uAGPTwnt1Nuq/Ag6vp0eub4n GoB4vWqHb5pmxe/refg86unzcpsf5OYYKXo9NTIelarhevwYmoahDv9F/qM6sq/K4Bzd CeqGJ/IHd/AjGcf/MzVfA8RXK+dx5bcMQOr3orHFNrk1YGA7cjnVvgTjCBUVb9lbx7hC g65zH06Y1Y15mtRXG1jDoqlzohj2VV71E22k9na9lCkgO94uIuX2H01IOnV5OOL7vGz3 PLVHTTDbqslTU5h4vFM8Z3p8WcINvi163bzuO2LW6yCjtWfAZg0AA9fwwMhphgbOrug9 uz4A== X-Gm-Message-State: ALoCoQnItgbu8ctkYPSqBVXDUwcBKL8nO/JCoyN60t58JdQmpddNQtVueZcTf1i99VU783BSFzO+ X-Received: by 10.107.38.11 with SMTP id m11mr18754121iom.15.1437833421785; Sat, 25 Jul 2015 07:10:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.23.231 with SMTP id 94ls1978615qgp.24.gmail; Sat, 25 Jul 2015 07:10:19 -0700 (PDT) X-Received: by 10.140.96.47 with SMTP id j44mr385900qge.19.1437833419523; Sat, 25 Jul 2015 07:10:19 -0700 (PDT) In-Reply-To: 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:19278 Archived-At: ------=_Part_34_418058296.1437833418851 Content-Type: multipart/alternative; boundary="----=_Part_35_2038876857.1437833418852" ------=_Part_35_2038876857.1437833418852 Content-Type: text/plain; charset=UTF-8 On Saturday, July 25, 2015 at 12:13:39 AM UTC+3, inkwizyt...@gmail.com wrote: > > > Pointers can made range, but they have `begin` and `end`? no. Because most > of them don't made any range. Can you point me std class that have `begin` > and `end` but they don't made range? > > Neither pointers nor arrays have begin and end. It is only user-defined classes can have begin and end. You can write any class that will provide begin and end and these begin and end will not make up a range. So in any case it is only the user responsibility to provide a valid range. The range-base for loop does not bother whether it has a valid range or not. Moreover you can write a user class such a way that operators ++ and * will have nothing common with ranges and the for-range loop will have well-defined behaviour. Relative to the range based for loop begin and end are not properties of a container as you think. It is own interface of the range-based for loop. Simply the names of the interface of the range-based for loop and names of member functions of some containers can coincide. That is containers can provide its own implementation of this interface of the range-based for loop. It is similar to interfaces in C#. That is in fact it is a demonstration of the C# notion of the interface in C++. Used by the range-based for statement functions begin and end and defined in some class member functions begin and end are two different entities. The range-based for loop provides an interface for the client code. How the client code will use this interface (for example a class can define member functions with the same name or you can define a non-class function) is not important for the range-based for loop. The only thing you have to guarantee that the work of the range-based for loop using your implementation of its open interface would be well-defined. Standard containers and standard algorithms already use std::pair to specify a valid range. It is a basic type of the algorithms and containers. And for this basic type basic operations should be provided including using it the range-based for loop. Consider an example. There are character arrays in C that can contain strings. You are going to write a class named string that will substitute im the most situations using of the character arrays. I am going to write a function named strlen that will define the length of a string stored in a character array. And you say me: "Do not write the function because I will write class string that will have member function size or length that will return the size of a string" And implementing your class string you are using the function that I was going to write. :) A similar situation takes place with std::pair. There is a basic type that is used to store valid ranges. And you say me: "Do not write begin and end for std:; pair because I will write a suoerconstruction that will return the same range as std::pair. Only I am sorry I also deform several algorithms.":) I do not see a great sense in this. Of course you may write a superconstruction for ranges but I am sure that the basic type that is used to store valid ranges should have also basic operations that will be used where your suoerconstruction is btotally useless and all what it does is forse the programmer to pay for what he does not use. Over all what do you want is implicit conversation form pair to range. This > is exactly same situation that conversation form int to enum. > I know usage is right when why I need use cast every time? Its for making > you remember that not every int can map to enum. > > Another approach, do pair have invariants of range? No. You should test > before each use as range if is range. Who you inform other people that you > use pair as range? > Using comments? C++ have lot better tools for this. Special classes that > will enforce it. > > int b; > int a; > > foo0(&a, &b); > foo1(std::make_pair(&a, &b)); > foo2(std::make_range(&a, &b)); > With of this functions are call incorrectly? I know that last one for sure > is broken because I beak invariants of range constructor. > I don't even need to read comments or look on implementation. This is why > we have `shared_ptr` and `unique_ptr` instead of `T*`. > This classes help us maintaining invariants, you can follow couple of > simple rules and you will never have problems with memory leaks again. > > But with `std::pair` as range is impossible, you can have valid usage of > pair that aren't ranges in your program. How do you reliable separate both > usage? > Again use different types for different concepts. > > > > > > > On Friday, July 24, 2015 at 10:06:21 PM UTC+2, Vlad from Moscow wrote: >> >> >> >> 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; >>> >>> -- --- 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_35_2038876857.1437833418852 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Saturday, July 25, 2015 at 12:13:39 AM UTC+3, i= nkwizyt...@gmail.com wrote:

Pointers can made range, but they have `begin` and `end`?= no. Because most of them don't made any range. Can you point me std cl= ass that have `begin` and `end` but they don't made range?

Neither pointers nor arrays have begin and end. It= is only user-defined classes can have begin and end.

<= div>You can write any class that will provide begin and end and these begin= and end will not make up a range.

So in any case = it is only the user responsibility to provide a valid range.

=
=C2=A0The range-base for=C2=A0loop does not bother whether it ha= s a valid range or not. Moreover you can write a user class such a way that= operators ++ and * will have nothing common with ranges and the for-range = loop will have well-defined behaviour.

Relative to= the range based for loop begin and end=C2=A0are not=C2=A0properties of a c= ontainer as you think.

=C2=A0It is=C2=A0own interf= ace of the range-based for loop. Simply the names of the interface of the r= ange-based for loop and names of member functions of=C2=A0some containers c= an coincide. That is=C2=A0containers can provide its own implementation of = this interface of the range-based for loop.

It is = similar to interfaces in C#. That is in fact it is a demonstration of the C= # notion of the interface=C2=A0 in C++.

Used by th= e range-based for statement functions begin and end and defined in some cla= ss member functions begin and end=C2=A0are=C2=A0two different entities. The= =C2=A0range-based for loop provides an interface for the client code. How t= he client code will use this interface (for example a class=C2=A0can define= =C2=A0member=C2=A0functions with the same name or you can define a non-clas= s=C2=A0function) is not important for the range-based for loop.=C2=A0=C2=A0=
=C2=A0
The only thing you have to guarantee that the= =C2=A0work of the range-based for loop using your implementation of its ope= n interface=C2=A0would be well-defined.

Standard c= ontainers and standard algorithms already use std::pair to specify a valid = range. It is a basic type of the algorithms and containers. And for this ba= sic type basic operations should be provided=C2=A0 including using it the r= ange-based for loop.

Consider an example. There ar= e character arrays in C that can contain strings. You are going to write a = class named string that will substitute im the most situations using of the= character arrays. I am going to write a function named strlen that will de= fine the length of a string stored in a character array. And you say me: &q= uot;Do not write the function because I will write class string that will h= ave member function size or length that will return the size of a string&qu= ot; And implementing your class string you are using the function that I wa= s going to write. :)

A similar situation takes pla= ce with std::pair. There is a basic type that is used to store valid ranges= .. And you say me: "Do not write begin and end for std:; pair because I= will write a suoerconstruction that will return the same range as std::pai= r. Only I am sorry I also deform several algorithms.":)

=
I do not see a great sense in this. Of course you may write a su= perconstruction for ranges but I am sure that the basic type that is used t= o store valid ranges should have also basic operations that will be used wh= ere your suoerconstruction is btotally useless and all what it does is fors= e the programmer to pay for what he does not use.

Over all what do you want is = implicit conversation form pair to range. This is exactly same situation th= at conversation form int to enum.
I know usage is right when why I need = use cast every time? Its for making you remember that not every int can map= to enum.

Another approach, do pair have invariants of range? No. Yo= u should test before each use as range if is range. Who you inform other pe= ople that you use pair as range?
Using comments? C++ have lot better too= ls for this. Special classes that will enforce it.

int= b;
int a;

foo0(&a, &b);
foo1<= span style=3D"color: rgb(102, 102, 0);">(std::make_pair(&a, &b));
foo2(std::make_range(&a, &b= ));
With of this functions are call incorrectly? I= know that last one for sure is broken because I beak invariants of range c= onstructor.
I don't even need to read comments or look on implementa= tion. This is why we have `shared_ptr` and `unique_ptr` instead of `T*`.This classes help us maintaining invariants, you can follow couple of simp= le rules and you will never have problems with memory leaks again.

B= ut with `std::pair` as range is impossible, you can have valid usage of pai= r that aren't ranges in your program. How do you reliable separate both= usage?
Again use different types for different concepts.





On Friday, July 24, 2015 at 10:06:21 PM UTC+2, Vlad from= Moscow wrote:


On Frid= ay, July 24, 2015 at 9:59:16 PM UTC+3, inkwizyt...@gmail.com wrote:<= blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddin= g-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px;= border-left-style: solid;">
If some object have `begin` an= d `end` then its range. Most pair aren't ranges then they should not ha= ve this functions.

Most pointers = are not ranges. Does it mean that pointers can not make up a range?
<= div>
Consider for example a dynamically allocated array. Does= it has a range?

<= div dir=3D"ltr">
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=C2=A0a then pair=C2=A0a and=C2=A0a + n set a valid ra= nge. 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_p= air( a, a + n );


So if you have a p= air that specifiers a valid range then you expect this range can be used in= for example the for range statement

So it is natu= ral and locgically consistent for example to write

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

It is a valid record. Why? Because=C2=A0object range d= efines a valid range. It already exists. There is no need to invent some su= perconstructions 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 ret= urn a valid range do not they?

Thus std::pair is a= n integral part of algorithms and ranges. It is already used to specify a v= alid range. There is nothing to invent. All you need is to have an access t= o elements of the ranges they make up. To have an access means that you nee= d 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 =3D p.first, end =3D p.second; begin !=3D e= nd; ++begin ) { /*...*/ }

There is no any need to = deform algorithms.=C2=A0All you need you already have in your disposal.=C2= =A0

Only instead of

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

it is better to write

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

However accordi= ng 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? Becau= se your argument is that std::pair does not set a range.:) It is funny.:)= =C2=A0

I am sorry I do not see any logic in your w= ords.

Of course you can create a class that will = be named something=C2=A0like ranges.=C2=A0 You can even to build a hierarch= y 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 co= de that I showed in this thread I wrote literally in 5-10 minutes without i= nventing any classes. Because it is natural way of using std::pair having a= range.

On the other hand your hierarchy of classe= s of ranges has been created if I am not mistaken already several years. An= d in the examples I showed their usage is no more than the usage of soap bu= bbles.

=C2=A0
If some objects don't give you guarantees = about something but you know in some cases it true then proper way of use i= s EXPLICITLY show that it hold true.
In our case `std::make_range` fulfi= ll this requirements.

Probably solution for this problem are tagged = pairs and tuples (IIRC they are form range proposition).
It look somethi= ng like that:

extern int tab<= /span>[10];

std::pai= r<std::= begin_tag<int*>, std::end_tag<int*>> a;
std::pair<std::ptr_tag<int*>, std::success_tag<= span style=3D"color: rgb(0, 136, 0);"><bool>> b;

a.<= /span>begin() =3D tab;= //equal a.first =3D tab;.end() =3D tab= + 10; //equal a.secon= d =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() <= span style=3D"color: rgb(102, 102, 0);">=3D true;
=C2=A0 =C2=A0 }
}
= return b;

--

---
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_35_2038876857.1437833418852-- ------=_Part_34_418058296.1437833418851-- .