220 7433 article Path: news.gmane.org!not-for-mail From: "Billy O'Neal" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: To add the method append for all sequential containers that have method push_back Date: Tue, 22 Oct 2013 15:56:04 -0700 Lines: 643 Approved: news@gmane.org Message-ID: References: <4167b82e-a3cc-44ce-9825-b52514bc1531@isocpp.org> <357325b0-cec5-4d22-ad56-9bb66f76b458@isocpp.org> <983ff074-5d8c-488a-b06c-49d53d5b7a5b@isocpp.org> <369298d9-3f8b-405a-8bfe-ae209372a26f@isocpp.org> <4ceba2fe-c45d-4eba-ba2e-59f1a0892393@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1133073a8f07f404e95c5023 X-Trace: ger.gmane.org 1382482600 6621 80.91.229.3 (22 Oct 2013 22:56:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Oct 2013 22:56:40 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBDKLBLVE6ADBBLMFTSJQKGQECLOF4FQ@isocpp.org Wed Oct 23 00:56:46 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f197.google.com ([209.85.216.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VYksY-0004Ty-9m for gclcip-std-proposals@m.gmane.org; Wed, 23 Oct 2013 00:56:46 +0200 Original-Received: by mail-qc0-f197.google.com with SMTP id x19sf33974qcw.0 for ; Tue, 22 Oct 2013 15:56:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=sieI+T3rm0JvC47uw6fqyj224PxbSUOa51oOq5p3xRE=; b=ilitpK5uTRgTwfYuqhiLFiDt4FHNUjuYHQt3UWVQb4velh7gN5Q0qjwLuCEEq2CXMD sftv9EtkOTL5bl1ZdCbKN6cune/v/5rbRnXpmsJBEyInIshnnCmIOcR3gORO/nkjmqG9 jqQaJ1H7oa+fmEg65bb6xTnfrZobLq6Ryccx856P2R6uJWg5IVZohwN9Tk8hANWo/uZW YljPSlIm6ZrEGV4nAX1L1H18D/LDw6n+zz1pp4+kMH/3RrSjcI7HwsOFg5wCwGPMN5n7 RkoSBrUReys4yGPr8ZO+22KZd7cTVvOgiV9IXGpW/JJ9EBFxgIGK+7mQ4bLen9wHFQva iyQg== X-Received: by 10.236.20.114 with SMTP id o78mr22440592yho.8.1382482605505; Tue, 22 Oct 2013 15:56:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.52.136 with SMTP id t8ls187116obo.60.gmail; Tue, 22 Oct 2013 15:56:44 -0700 (PDT) X-Received: by 10.60.52.1 with SMTP id p1mr3968100oeo.41.1382482604931; Tue, 22 Oct 2013 15:56:44 -0700 (PDT) Original-Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [2607:f8b0:4003:c02::22a]) by mx.google.com with ESMTPS id q1si2861207oev.75.2013.10.22.15.56.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 15:56:44 -0700 (PDT) Received-SPF: pass (google.com: domain of billy.oneal@gmail.com designates 2607:f8b0:4003:c02::22a as permitted sender) client-ip=2607:f8b0:4003:c02::22a; Original-Received: by mail-oa0-f42.google.com with SMTP id k14so11612oag.15 for ; Tue, 22 Oct 2013 15:56:44 -0700 (PDT) X-Received: by 10.60.52.81 with SMTP id r17mr4055709oeo.3.1382482604654; Tue, 22 Oct 2013 15:56:44 -0700 (PDT) Original-Received: by 10.182.87.37 with HTTP; Tue, 22 Oct 2013 15:56:04 -0700 (PDT) In-Reply-To: <4ceba2fe-c45d-4eba-ba2e-59f1a0892393@isocpp.org> X-Original-Sender: billy.oneal@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of billy.oneal@gmail.com designates 2607:f8b0:4003:c02::22a as permitted sender) smtp.mail=billy.oneal@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:7433 Archived-At: --001a1133073a8f07f404e95c5023 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable > if such a function is declared as a non-member function it usually returns a new object. I disagree with that. Example: std::swap. Billy O'Neal https://github.com/BillyONeal/ http://stackoverflow.com/users/82320/billy-oneal Malware Response Instructor - BleepingComputer.com On Tue, Oct 22, 2013 at 1:52 PM, Vlad from Moscow wrot= e: > At least because as a general rule if a function that deals with > two objects and is declared as a member function it usually > returns reference to "this" object. On the other hand, if such a function > is declared as a non-member function it usually returns a new object. > Moreover this call > > append( v, { a, 2, 3, 4 } ); > > looks like two containers are used so any reader can not exclude that the > function is declared as > > std::vector append( const std::vector &v1, const > std::vector &v2 ); > > A non-member function append looks like operator overloading in C# where > overloaded operators are declared as static member functions and return a > new object. > > =D3=D2=C5=C4=C1, 23 =CF=CB=D4=D1=C2=D2=D1 2013 =C7., 0:18:42 UTC+4 =D0=CF= =CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Billy O'Neal =CE=C1=D0=C9=D3=C1=CC: > >> I don't see why >> append( v, { 1, 2, 3, 4 } ) >> raises any more question about what is actually returned when compared >> with >> v.append( { 1, 2, 3, 4 } ) >> >> Billy O'Neal >> https://github.com/BillyONeal/ >> http://stackoverflow.com/**users/82320/billy-oneal >> Malware Response Instructor - BleepingComputer.com >> >> >> On Tue, Oct 22, 2013 at 1:17 PM, Vlad from Moscow wrot= e: >> >>> If v.append( /*...*/ ) indeed will not return the vector itself then I >>> could agree with you that a non-member function can be introduced. But = in >>> my opinion only this call >>> >>> append( v, { 1, 2, 3, 4 } ) >>> >>> can arise a question what is actually returned. >>> >>> =D3=D2=C5=C4=C1, 23 =CF=CB=D4=D1=C2=D2=D1 2013 =C7., 0:09:59 UTC+4 =D0= =CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Billy O'Neal >>> =CE=C1=D0=C9=D3=C1=CC: >>> >>>> >From the second call it is not clear what is outputed whether it is a >>>> new vector or it is the original vector. >>>> >>>> I disagree. You can use nonmember append with basic_string, and the >>>> name "append" implies modifying the original vector. There's nothing a= bout >>>> the syntactical difference between member and nommember functions whic= h >>>> clearly indicates "this modifies" or "this does not modify". >>>> >>>> That is, there's no reason "v.append(xyz)" doesn't return a different >>>> vector either, by this logic. >>>> >>>> Billy O'Neal >>>> https://github.com/BillyONeal/ >>>> http://stackoverflow.com/**users**/82320/billy-oneal >>>> Malware Response Instructor - BleepingComputer.com >>>> >>>> >>>> On Tue, Oct 22, 2013 at 1:03 PM, Vlad from Moscow wr= ote: >>>> >>>>> >>>>> In this case you can not substituted a call of the method for >>>>> std::basic_string with a call for a vector. So the interface will not= be >>>>> consistent. >>>>> >>>>> Apart from this the call >>>>> >>>>> std::cout << v.append( { 1, 2, 3, 4, 5 } ); >>>>> >>>>> looks semantically more clear than >>>>> >>>>> std::cout << append( v, { 1, 2, 3, 4, 5 } ); >>>>> >>>>> From the second call it is not clear what is outputed whether it is a >>>>> new vector or it is the original vector. >>>>> >>>>> =D7=D4=CF=D2=CE=C9=CB, 22 =CF=CB=D4=D1=C2=D2=D1 2013 =C7., 21:37:19 U= TC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Billy O'Neal >>>>> =CE=C1=D0=C9=D3=C1=CC: >>>>> >>>>>> I suppose I understand why there's no append here -- append on >>>>>> basic_string is the same thing effectively as operator+=3D -- but th= ere's no >>>>>> such semantic operation that makes sense for vector. >>>>>> >>>>>> I suppose there's no reason for someone who wants this semantic not >>>>>> to do: >>>>>> >>>>>> template >>>>>> T& append(T& container, InputIterator first, InputIterator last) >>>>>> { >>>>>> container.insert(container.**end****(), first, last); >>>>>> return container; >>>>>> } >>>>>> >>>>>> Billy O'Neal >>>>>> https://github.com/BillyONeal/ >>>>>> http://stackoverflow.com/**users****/82320/billy-oneal >>>>>> Malware Response Instructor - BleepingComputer.com >>>>>> >>>>>> >>>>>> On Tue, Oct 22, 2013 at 5:04 AM, Vlad from Moscow = wrote: >>>>>> >>>>>>> Taking into account method append of std::basic_string it is not a >>>>>>> new name. append and insert will have differenct semantic. append w= ill >>>>>>> return reference to the container itself. So you can use it for exa= mple the >>>>>>> follwoing way >>>>>>> >>>>>>> std::vector v =3D { 1, 2, 3, 4, 5 }; >>>>>>> >>>>>>> for ( int x : v.append( { 4, 3, 2, 1 } ) ) std::cout << x << ' '; >>>>>>> >>>>>>> insert is used then you need the position after inserting new >>>>>>> elements. For example >>>>>>> >>>>>>> auto pos =3D v.end(); >>>>>>> >>>>>>> pos =3D v.insert( pos, { 4, 3, 2, 1 } ); >>>>>>> v.insert( pos, 5 ); >>>>>>> >>>>>>> =D7=D4=CF=D2=CE=C9=CB, 22 =CF=CB=D4=D1=C2=D2=D1 2013 =C7., 11:56:50= UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Bengt >>>>>>> Gustafsson =CE=C1=D0=C9=D3=C1=CC: >>>>>>> >>>>>>>> I think the idea is good, this use case appears quite often. But >>>>>>>> why not overload push_back with more signatures instead of introdu= cing a >>>>>>>> new name? The signatures available would then be exactly parallel = to >>>>>>>> insert(), with the difference that the first parameter is absent. >>>>>>>> >>>>>>>> >>>>>>>> Den tisdagen den 22:e oktober 2013 kl. 01:20:59 UTC+2 skrev Evgeny >>>>>>>> Panasyuk: >>>>>>>>> >>>>>>>>> >>>>>>>>> No, I do not think so. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Why not? >>>>>>>>> >>>>>>>>> >>>>>>>>>> It is common interface of all sequential containers including an= d >>>>>>>>>> together with std::basic_string. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Just read GotW #84. >>>>>>>>> std::string has many controversial design decisions. We should no= t >>>>>>>>> uglify STL by borrowing bad stuff from std::string. >>>>>>>>> >>>>>>>> -- >>>>>>> >>>>>>> --- >>>>>>> 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/**iso**** >>>>>>> cpp.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, sen= d >>>>> 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/**iso** >>>>> cpp.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-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/. > --=20 ---=20 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 e= mail 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-proposa= ls/. --001a1133073a8f07f404e95c5023 Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: quoted-printable
> if=9Asuch a function is declared as a non-member= function it usually returns a new object.

I disag= ree with that. Example: std::swap.
Billy O'Neal
Malware Response Instructor - BleepingComputer.com


On Tue, Oct 22, 2013 at 1:52 PM, Vlad fr= om Moscow <vlad.moscow@mail.ru> wrote:
At least because=9Aas a general rule if a function th= at=9A=9Adeals with two=9Aobjects=9Aand is=9Adeclared as a member function i= t usually returns=9Areference to=9A"this" object. On the other ha= nd, if=9Asuch a function is declared as a non-member function it usually re= turns a new object.=9A
Moreover this call
=9A
append( v, { a, 2, 3, 4 } )= ;
=9A
looks like two containers are used so any reader = can not exclude that the function is=9Adeclared as
=9A
= std::vector<int> append( const std::vector<int> &v1, const = std::vector<int> &v2 );
=9A
A non-member function append looks like=9Aoperator overl= oading in C# where overloaded operators are declared as static member funct= ions and return a new object.

=D3=D2=C5=C4=C1, 23 =CF=CB=D4= =D1=C2=D2=D1 2013=9A=C7., 0:18:42 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC= =D8 Billy O'Neal =CE=C1=D0=C9=D3=C1=CC:
I don't see wh= y
append( v, { 1, 2, 3, 4 } )
raises any more question about w= hat is actually returned when compared with
v.append( { 1, 2, 3, = 4 } )

Billy O'Neal
Malware Response Instructor - BleepingComputer.com


On Tue, Oct= 22, 2013 at 1:17 PM, Vlad from Moscow <vlad....@ma= il.ru> wrote:
If v.append( /*...*/ ) indeed will not return the vec= tor itself then I could agree with you that a non-member function can be in= troduced. But in my opinion only this call
=9A
append( = v, { 1, 2, 3, 4 } )
=9A
can arise a question what is actually returned.

=D3=D2=C5=C4=C1, 23 =CF=CB=D4=D1=C2=D2=D1 2013=9A=C7., 0:09:59 UTC+4 = =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Billy O'Neal =CE=C1=D0=C9=D3=C1=CC= :
>From the second call it is not clear what is= outputed whether it is a new vector or it is the original vector.

I disagree. You can use nonmember append with basic_string= , and the name "append" implies modifying the original vector. Th= ere's nothing about the syntactical difference between member and nomme= mber functions which clearly indicates "this modifies" or "t= his does not modify".

That is, there's no reason "v.append(xyz)"= ; doesn't return a different vector either, by this logic.
<= /div>

Billy O'Nea= l
Malware Response Instructor - BleepingComputer.com


On Tue, Oct 22, 2013 at = 1:03 PM, Vlad from Moscow <vlad....@mail.ru>= wrote:
=9A
In this case you can not substituted a = call of the method for std::basic_string with a call for=9Aa vector. So the= interface will not be consistent.
=9A
Apart from this= the call
=9A
std::cout << v.append( { 1, 2, 3, 4, 5 } );
<= div>=9A
looks semantically more clear than
=9A
std::cout << append( v, { 1, 2, 3, 4, 5 } );
=9A
From the second call it is not clear what is outputed whether it is a new= vector or it is the original vector.

=D7=D4=CF=D2=CE=C9=CB, 22 =CF=CB=D4=D1=C2=D2=D1 2013=9A=C7., 21:37= :19 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Billy O'Neal =CE=C1=D0= =C9=D3=C1=CC:
I suppose I understand why there's no append here= -- append on basic_string is the same thing effectively as operator+=3D --= but there's no such semantic operation that makes sense for vector.
I suppose there's no reason for someone who wants this seman= tic not to do:

template <typename T, typename I= nputIterator>
T& append(T& container, InputIterator fi= rst, InputIterator last)
{
=9A =9A container.insert(container.end(), first, last);
=9A =9A return container;
}
Taking into account method append of std::basic_strin= g it is not a new name. append and insert will have differenct semantic. ap= pend will return reference to the container itself. So you can use it for e= xample the follwoing way
=9A
std::vector<int> v =3D { 1, 2, 3, 4, 5 };
=9A
for ( int x=9A: v.append( { 4, 3, 2, 1 } ) ) std::cout <= < x << ' ';
=9A
insert is used then yo= u need the position after inserting new elements. For example
=9A
auto pos =3D v.end();
=9A
pos =3D v.= insert( pos, { 4, 3, 2, 1 } );
v.insert( pos,=9A5 );
=D7=D4=CF=D2=CE=C9=CB, 22 =CF=CB=D4=D1=C2=D2=D1 2013=9A=C7., 11:56:50 UTC= +4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Bengt Gustafsson =CE=C1=D0=C9=D3=C1= =CC:
I think the idea is good, this = use case appears quite often. But why not overload push_back with more sign= atures instead of introducing a new name? The signatures available would th= en be exactly parallel to insert(), with the difference that the first para= meter is absent.


Den tisdagen den 22:e oktober 2013 kl. 01:20:59 UTC+2 skrev Evgeny = Panasyuk:

No, I do not th= ink so.

Why not?
=9A
It is common interface of all sequential containers=9Aincluding=9Aand = together with std::basic_string.

Just read= GotW #84.
std::string has many controversial design decisions. We shoul= d not uglify STL by borrowing bad stuff from std::string.
<= div>

--
=9A
---
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

--
=9A
---
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/iso<= /u>cpp.org/group/std-proposals/.

--
=9A
---
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-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/.

--
=9A
---
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-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/gro= up/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-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/<= /a>.
--001a1133073a8f07f404e95c5023-- .