220 4843 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: std::sequence Date: Mon, 3 Jun 2013 15:39:35 -0700 (PDT) Lines: 132 Approved: news@gmane.org Message-ID: 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_3241_2880306.1370299175608" X-Trace: ger.gmane.org 1370299179 20584 80.91.229.3 (3 Jun 2013 22:39:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Jun 2013 22:39:39 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBKNWWSGQKGQE6ADZAYA@isocpp.org Tue Jun 04 00:39:40 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f70.google.com ([209.85.219.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UjdPe-0005Y9-OF for gclcip-std-proposals@m.gmane.org; Tue, 04 Jun 2013 00:39:39 +0200 Original-Received: by mail-oa0-f70.google.com with SMTP id k14sf5493109oag.5 for ; Mon, 03 Jun 2013 15:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=QFMEQVi0hREHab3hbmKE6p3Pj3lCvmC0oA5mJsJpZqk=; b=HL66lSS8fi9uUihfBPveZ25iniT7dQexfVmunDNPpFHlNAJL/oH7Nj1QfWdy8saWS+ OWV8YmWq2/oBP8hszH45+OH007BhhcBWlR7ufcoPElwEf5GYGbi0Md6KMk4dhwlb4QcD jNn1tcuCdMHakQlZB0rgchOl2BIH0eu8O4vpwd9HBWVVI8Mtu32W8TEpHLHnQ0wZsdgO Nky9SGNRRuuB5T5YDkR3OgquCI+saZopixPtYS6YIHNW3hy5OT04M9u9l4LbFKSeN4bt qRZlMbi+e/TWI0dy5OYuB+ZmyH7ooGb5dR2RvQwiGq7ewzWK/MZ7PXH0XXV/tt4rFeQl JsTA== X-Received: by 10.43.124.198 with SMTP id gp6mr18639241icc.20.1370299177504; Mon, 03 Jun 2013 15:39:37 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.11.82 with SMTP id o18ls2354320igb.14.canary; Mon, 03 Jun 2013 15:39:36 -0700 (PDT) X-Received: by 10.50.36.99 with SMTP id p3mr31479igj.4.1370299176470; Mon, 03 Jun 2013 15:39:36 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:4843 Archived-At: ------=_Part_3241_2880306.1370299175608 Content-Type: text/plain; charset=ISO-8859-1 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. > 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`. 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. -- --- 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_3241_2880306.1370299175608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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:
An= d LLVM and Google have gotten by with types that are equally lightweight an= d shortlived, yet theirs are assignable and adjustable in size.
<= /div>

I chose to use const members because = restrictions, guarantees, and focusing on the essence of the problem are go= od things.

Most of us would answer "Yes" to the fo= llowing 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? Ar= e there times when const could be used? And are there times when it is a go= od idea to favor using const?

re Short lived: = Making the type assignable affords greater scope to people. Not everyone wi= ll 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/allo= cation it references. If you expand the scope and increase the sequence's l= ifetime, then the likelihood that somebody uses a dangling pointer increase= s (as one example).



re Lightweight: The smallest array_ref = could be the same size as a sequence. Because array_ref's members are not c= onst, it could result in larger and slower code.
... how? They'll just be a pair of pointers or a pointer+size either way.<= br> 
Making it = assignable and shrinkable introduces complexity to the type (e.g. more erro= r detection, more methods, more code paths, more to test).

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

Shrinking d= id not exist in my proposal because I never needed that functionality. I wa= s content with the guarantees the type provided and its simplicity. The typ= e 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 becaus= e 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 t= he usage experience.

--
 
---
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_3241_2880306.1370299175608-- .