220 4848 <1c991e6e-6bc3-4822-9ffd-7f2508e63974@isocpp.org> article Path: news.gmane.org!not-for-mail From: carrierandoperator@yahoo.co.uk Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: std::sequence Date: Tue, 4 Jun 2013 07:27:59 -0700 (PDT) Lines: 175 Approved: news@gmane.org Message-ID: <1c991e6e-6bc3-4822-9ffd-7f2508e63974@isocpp.org> References: <4551abbc-43aa-4520-a91a-f8eb25a90588@isocpp.org> <2c8e6079-9c87-425a-93e2-39251df57cd8@isocpp.org> <9f1cace3-0503-4a3c-a8ce-d7546564b3ef@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_177_18976384.1370356079480" X-Trace: ger.gmane.org 1370356085 24624 80.91.229.3 (4 Jun 2013 14:28:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Jun 2013 14:28:05 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDQ2R4E5RIKBB4HSW6GQKGQEUTIAH4A@isocpp.org Tue Jun 04 16:28:06 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ve0-f200.google.com ([209.85.128.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UjsDS-0003Sw-AY for gclcip-std-proposals@m.gmane.org; Tue, 04 Jun 2013 16:28:02 +0200 Original-Received: by mail-ve0-f200.google.com with SMTP id m1sf333334ves.3 for ; Tue, 04 Jun 2013 07:28:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=0VcRHs7MTfN8pjF++61FvvehypzEpICjXAay6O4KJdg=; b=LUdVpGmLuF4JkQrZc7WVIAifZBTK33lDGEEKA9KXfaD4l2jGZtLo8gdPj9sOsWXFNX hgCOUoAQedOQZm3HQt7Crw1VSQ4+KbiMLE5gnIvp+YiC12OStgetxNFHiICB+W5uTN9A WICDgasyZE6CyyrYDXykTmTWkIcrOFRHLbs+X0dREnlAGmoyJPuY4HauWVC3bPq6X/N3 SoWA9l2bMErjrcJn/y5+JqMV6gPmRRQHRkWN8t324gDBDY9nLnVcFcgBKHNUec/l9GXn AeiB/b9U780REBJvkN+LIuCdMpDRlzRh36hR3S+1heOQZIz5lqC5eV9SXGef7FXDO6KP GE7A== X-Received: by 10.236.119.106 with SMTP id m70mr15392599yhh.52.1370356081377; Tue, 04 Jun 2013 07:28:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.0.78 with SMTP id 14ls279955qec.10.gmail; Tue, 04 Jun 2013 07:27:59 -0700 (PDT) X-Received: by 10.49.71.135 with SMTP id v7mr1964362qeu.22.1370356079878; Tue, 04 Jun 2013 07:27:59 -0700 (PDT) In-Reply-To: X-Original-Sender: carrierandoperator@yahoo.co.uk 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:4848 Archived-At: ------=_Part_177_18976384.1370356079480 Content-Type: text/plain; charset=ISO-8859-1 On Monday, June 3, 2013 6:39:35 PM UTC-4, Nicol Bolas wrote: > > On Monday, June 3, 2013 1:24:54 PM UTC-7, carrieran...@yahoo.co.uk wrote: >> >> On Monday, June 3, 2013 1:53:20 PM UTC-4, Nicol Bolas wrote: >>> >>> And LLVM and Google have gotten by with types that are equally >>> lightweight and shortlived, yet *theirs* are assignable and adjustable >>> in size. >>> >> >> I chose to use const members because restrictions, guarantees, and >> focusing on the essence of the problem are good things. >> >> Most of us would answer "Yes" to the following questions: Are there times >> when a reference can be used rather than a pointer? Are there times when it >> is a good idea to favor a reference? Are there times when const could be >> used? And are there times when it is a good idea to favor using const? >> >> re Short lived: Making the type assignable affords greater scope to >> people. Not everyone will misuse that, but some will. I see it as being >> quite similar to SBRM and favoring local types. The sequence should be a >> dependency of the array/allocation it references. If you expand the scope >> and increase the sequence's lifetime, then the likelihood that somebody >> uses a dangling pointer increases (as one example). >> > > > > re Lightweight: The smallest array_ref could be the same size as a >> sequence. Because array_ref's members are not const, it could result in >> larger and slower code. >> > > ... how? They'll just be a pair of pointers or a pointer+size either way. > So you have checked my math. What exactly is your question? > Making it assignable and shrinkable introduces complexity to the type >> (e.g. more error detection, more methods, more code paths, more to test). >> > > More code paths of *what* to test? If your particular function won't be > changing the array_ref, then it should be a `const array_ref`. > These aren't real questions. It seems you're just trying to start an argument. I've the assumption that if you are hanging out in a C++ standard proposal group, you have some understanding of software complexity. > Shrinking did not exist in my proposal because I never needed that >> functionality. I was content with the guarantees the type provided and its >> simplicity. The type did not attempt to be an iterator, range, or scanner >> as well. I've found slicing quite effective. >> > > I don't really see how that's an argument, especially considering again > that Google and LLVM *do* need this functionality. They didn't write > those functions just because they could. Does your class get as much usage > as all internal Google and LLVM C++ projects? If not, then I would rather > defer to the guys who have the usage experience. > Since explaining this to you, endorsement comes out as the heart of your objection? You need to realize that there is a call for library proposals and that this is the forum for such proposals: "The door is open for submissions of features to be added to the standard library, and we would love to see them not only from existing community libraries like Boost, Poco, and Qt, but from *you*.". Proposals don't need your endorsement watchdogging. Let's stay squarely on topic. -- --- 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/?hl=en. ------=_Part_177_18976384.1370356079480 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Monday, June 3, 2013 6:39:35 PM UTC-4, Nicol Bolas wrote:On Monday, June 3, 2013 1:24:54 PM UT= C-7, carrieran...@yahoo.co.uk wrote:
On Monday, June 3, 2013 1:53:20 PM UTC-4, Nicol Bolas wrote:
And LLVM and Google have gotten by wi= th types that are equally lightweight and shortlived, yet theirs are= assignable and adjustable in size.

I chose to use const members because restrictions, guarantees, and focus= ing on the essence of the problem are good things.

Most of us would answer "Yes" to the following questions: Are there times = when a reference can be used rather than a pointer? Are there times when it= is a good idea to favor a reference? Are there times when const could be u= sed? And are there times when it is a good idea to favor using const?

re Short lived: Making the type assignable affords = greater scope to people. Not everyone will misuse that, but some will. I se= e it as being quite similar to SBRM and favoring local types. The sequence = should be a dependency of the array/allocation it references. If you expand= the scope and increase the sequence's lifetime, then the likelihood that s= omebody uses a dangling pointer increases (as one example).



re L= ightweight: The smallest array_ref could be the same size as a sequence. Be= cause array_ref's members are not const, it could result in larger and slow= er code.

... how? They'll just be a pair of poin= ters or a pointer+size either way.

So you have checked my math. What exactly is your question?
 
Making it assignable and shrinkable = introduces complexity to the type (e.g. more error detection, more methods,= more code paths, more to test).

More code paths= of what to test? If your particular function won't be changing= the array_ref, then it should be a `const array_ref`.

These aren't real questions. It seems you're just trying = to start an argument. I've the assumption that if you are hanging out in a = C++ standard proposal group, you have some understanding of software comple= xity.
 
 
Shrinking did n= ot exist in my proposal because I never needed that functionality. I was co= ntent with the guarantees the type provided and its simplicity. The type di= d not attempt to be an iterator, range, or scanner as well. I've found slic= ing quite effective.

I don't really see how that= 's an argument, especially considering again that Google and LLVM do= need this functionality. They didn't write those functions just because th= ey could. Does your class get as much usage as all internal Google and LLVM= C++ projects? If not, then I would rather defer to the guys who have the u= sage experience.

Since explaining= this to you, endorsement comes out as the heart of your objection? You nee= d to realize that there is a call for library proposals and that this is th= e forum for such proposals: "The door is open for submissions of features to be added to the stand= ard library, and we would love to see them not only from existing community= libraries like Boost, Poco, and Qt, but from you.". Propos= als don't need your endorsement watchdogging. Let's stay squarely on topic.=

--
 
---
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-pro= posals/?hl=3Den.
 
 
------=_Part_177_18976384.1370356079480-- .