220 4834 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: Mon, 3 Jun 2013 13:24:54 -0700 (PDT) Lines: 130 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_4336_17924660.1370291094024" X-Trace: ger.gmane.org 1370291096 3090 80.91.229.3 (3 Jun 2013 20:24:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Jun 2013 20:24:56 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDQ2R4E5RIKBBFXXWOGQKGQE4HKZD2Q@isocpp.org Mon Jun 03 22:24:57 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f69.google.com ([209.85.216.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UjbJH-0008KR-T4 for gclcip-std-proposals@m.gmane.org; Mon, 03 Jun 2013 22:24:56 +0200 Original-Received: by mail-qa0-f69.google.com with SMTP id j11sf5074977qag.8 for ; Mon, 03 Jun 2013 13:24:55 -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=LgYH1L8qYbAxHOZlOpBdW6ElKw9UHYZTLq+w3ULlN6s=; b=fZ1PFy/zekcU2a4l2vhfFKtnFAtW/JY3Exvfwgxj8px6NKGTGnQxCH+3FT0ZUvQs92 fncJpgFvK7VBgsQoPA5O3pGMEayU1Y2h1BezWXSGPYgaSWVvkYtUip6AVU6mR+WxEudt ieNlLbZzu4xGl5RLKs6WJus/m5VMcsZF1yCNL0xPH+ziGcKIjUBJmy4B5rCpaPtsq0HI Hxh9pzHjAEBntLUsOv/RYbViT3QM6SOQKyOYdcFx7CcIWF+i0hr9on3oZBScrm0heT8p U7hMlGwjfZupjtl8ov0d39emahAXEpxGfXcMx08o4m5p6SLeLnaVsTMMuH56WjS4YMad fW1w== X-Received: by 10.236.93.116 with SMTP id k80mr13523606yhf.32.1370291094993; Mon, 03 Jun 2013 13:24:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.74.169 with SMTP id u9ls440045qev.32.gmail; Mon, 03 Jun 2013 13:24:54 -0700 (PDT) X-Received: by 10.49.103.202 with SMTP id fy10mr1763961qeb.32.1370291094365; Mon, 03 Jun 2013 13:24:54 -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:4834 Archived-At: ------=_Part_4336_17924660.1370291094024 Content-Type: text/plain; charset=ISO-8859-1 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. Making it assignable and shrinkable introduces complexity to the type (e.g. more error detection, more methods, more code paths, more to test). 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. The other issue in giving sequence the ability to be shrunk in combination with permitting access to mutable elements is that mutability to both the size and the elements is passed. Suppose you pass a character sequence to be capitalized -- the capitalize implementation can capitalize the string and accidentally shrink your sequence because mutability of the container and its elements are mutual. When the members are const, you could always pass a sequence by value. If they are not const, passing sequences becomes more complex. Why should we use yours instead of theirs (ie: array_ref)? I did a side-by-side comparison before you asked. To answer the question: Even if you took both proposals as-is, I would favor sequence because the option to have mutable array elements is more useful than assignment and shrinking. Again, I can be convinced those are necessities. -- --- 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_4336_17924660.1370291094024 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 as= signable and adjustable in size.

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

Mo= st of us would answer "Yes" to the following questions: Are there times whe= n 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 gre= ater scope to people. Not everyone will misuse that, but some will. I see i= t as being quite similar to SBRM and favoring local types. The sequence sho= uld be a dependency of the array/allocation it references. If you expand th= e scope and increase the sequence's lifetime, then the likelihood that some= body uses a dangling pointer increases (as one example).

re Lightweight: The smallest array_ref could be the same size as a s= equence. Because array_ref's members are not const, it could result in larg= er and slower code. Making it assignable and shrinkable introduces complexi= ty to the type (e.g. more error detection, more methods, more code paths, m= ore to test).

Shrinking did not exist in my propos= al because I never needed that functionality. I was content with the guaran= tees the type provided and its simplicity. The type did not attempt to be a= n iterator, range, or scanner as well. I've found slicing quite effective.<= /div>

The other issue in giving sequence the abilit= y to be shrunk in combination with permitting access to mutable elements is= that mutability to both the size and the elements is passed. Suppose you p= ass a character sequence to be capitalized -- the capitalize implementation= can capitalize the string and accidentally shrink your sequence because mu= tability of the container and its elements are mutual. When the members are= const, you could always pass a sequence by value. If they are not const, p= assing sequences becomes more complex.


<= /div>

Why should we use yo= urs instead of theirs (ie: array_ref)?

I di= d a side-by-side comparison before you asked. To answer the question: Even = if you took both proposals as-is, I would favor sequence because the option= to have mutable array elements is more useful than assignment and shrinkin= g. Again, I can be convinced those are necessities.


--
 
---
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_4336_17924660.1370291094024-- .