220 4818 <4551abbc-43aa-4520-a91a-f8eb25a90588@isocpp.org> article Path: news.gmane.org!not-for-mail From: carrierandoperator@yahoo.co.uk Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Proposal: std::sequence Date: Mon, 3 Jun 2013 07:07:51 -0700 (PDT) Lines: 330 Approved: news@gmane.org Message-ID: <4551abbc-43aa-4520-a91a-f8eb25a90588@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_67_29128251.1370268471526" X-Trace: ger.gmane.org 1370268474 4805 80.91.229.3 (3 Jun 2013 14:07:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Jun 2013 14:07:54 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDQ2R4E5RIKBBOOGWKGQKGQESEXBCKQ@isocpp.org Mon Jun 03 16:07:54 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ye0-f197.google.com ([209.85.213.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UjVQQ-0006Ks-GJ for gclcip-std-proposals@m.gmane.org; Mon, 03 Jun 2013 16:07:54 +0200 Original-Received: by mail-ye0-f197.google.com with SMTP id q4sf1088382yen.4 for ; Mon, 03 Jun 2013 07:07:53 -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: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=nC4rzJRHwdl8kO0Lc6NHc6UQoemdcEbZYQ/jWJ3jj4M=; b=B+tXIGBAqw6y0/IHLBBgwQYxNG2kPike3myxCiqbkWy7PApfgkdPMKZAiJVui20Hbt bng7NFyvz9QPKayRyDYqslNajYfiE0Mz2CmyIVkdvYBQHG7lIf1D/YsYxRfxSVwtUIDN PIa6SuemxVOHqUm0T8FmI6rAHtvN7Ng2H4zoMU6yO9uevZVW3Tt4i7cRA3S2PIhg894k 1fy+CozWGibeZTT1cifKLdSITWqu4EfXLNsLp0bCWF1hvp0bLvsF4G3lNG7MiGB1URXT 97SaCfr5DudFGXkYfEjfcR8Fd0iczooN/PlCZF67F/wY5KLNH7nPTtxj0AOeppg9XVd/ igKQ== X-Received: by 10.236.109.227 with SMTP id s63mr12800283yhg.24.1370268473553; Mon, 03 Jun 2013 07:07:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.82.226 with SMTP id l2ls2097775qey.6.gmail; Mon, 03 Jun 2013 07:07:52 -0700 (PDT) X-Received: by 10.49.71.97 with SMTP id t1mr1616308qeu.0.1370268471964; Mon, 03 Jun 2013 07:07:51 -0700 (PDT) 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:4818 Archived-At: ------=_Part_67_29128251.1370268471526 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm proposing a type I will refer to as "std::sequence" for this discussion= .. The sequence is a primitive class I have used for years. It is a template: EX: template class sequence {...}; It can be implemented using two member variables: - A constant pointer to an element of the type specified by the template=20 parameter - and a constant size_t which represents the number of elements in the arra= y EX: T* const d_element; const size_t d_size; Like an array, the sequence represents a contiguous allocation of objects.= =20 However, the sequence is not the owner of the objects. The lifetime of the= =20 objects and the backing allocation is handled _externally_. The member functions of the proposed class would be nearly identical to=20 std::array (sizes, element access, iterators). Additionally, std::sequence= =20 would provide member functions which return slices of the array it=20 represents. Containers in the standard library which hold contiguous elements could=20 also provide member functions which return a sequence. The class is useful for combining a dynamically sized contiguous allocation= =20 with a size parameter. This can be useful to combine and reduce parameters: void foo(int* p, size_t n); void foo(std::sequence s); For abstraction: std::vector& elements() { return this->vec; } std::sequence elements() { return std::sequence(this->vec); } Unifying parameters template dependence: From: void foo(vector); void foo(iterator); void foo(int*,size_t); template<> void foo(array) {...} To: void foo(sequence); Avoiding unnecessary promotions/temporaries: void foo(int* p,size_t n) { // looks like I have to create a new vector to pass here=85 bar(vec); } As well as algorithms and general conveniences. The type requires no change to the language. I have made the distinction between mutable and immutable sequences in my= =20 implementation, but I assume the standard library would rather *not* make= =20 that distinction. Mutability in this regard refers to the elements. Fixed= =20 size and constant pointer are by design. These objects are generally very= =20 short lived, rarely member variables, and if a sequence were created using= =20 `new` it would probably be a programmer error. I'd like to hear whether or not you would like to have this type in the=20 standard library and if so, how you'd change it (and why). Thanks --=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/?hl=3Den. ------=_Part_67_29128251.1370268471526 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I'm proposing a type I will refer to as "std::sequence"= for this discussion.

The sequence is a primitive = class I have used for years. It is a template:

EX:=

 template<class T>
 class sequence {...};

It can= be implemented using two member variables:

- A constant pointer to an elem= ent of the type specified by the template parameter

- and a constant size= _t which represents the number of elements in the array

EX:

=
 T* const d_element;
 const size_t d_size;

Like a= n array, the sequence represents a contiguous allocation of objects. Howeve= r, the sequence is not the owner of the objects. The lifetime of the object= s and the backing allocation is handled _externally_.

<= div>The member functions of the proposed class would be nearly identical to= std::array (sizes, element access, iterators). Additionally, std::sequence= would provide member functions which return slices of the array it represe= nts.

Containers in the standard library which hold= contiguous elements could also provide member functions which return a seq= uence.

The class is useful for comb= ining a dynamically sized contiguous allocation with a size parameter.

This can be useful to combine and reduce parameters:

 void foo(int* p=
, size_t n=
);<=
span style=3D"color: #000;" class=3D"styled-by-prettify">
 <=
span style=3D"color: #008;" class=3D"styled-by-prettify">void foo(std::sequence<int> s);

For abstract= ion:

 std::vector<int>& elements() {
  return this->vec=
;
 =
;}<=
span style=3D"color: #000;" class=3D"styled-by-prettify">


 =
std::sequence=
<int> elements=
() {
  return std::sequence<int>(this=
->vec);
 }

Unifying parameters template dependence:

From:

=
 void foo(vector);
 void foo(=
iterator);=

 =
void foo(int*,size_t);
 template<> void f=
oo(=
array) {...}

To:

void foo(sequence);

Avoiding unnecessary promotions/temporaries:

void foo(<=
/span>int<=
span style=3D"color: #660;" class=3D"styled-by-prettify">* p,size_t n) {
 // looks like I have to create a new vector to pass here=85
 bar(vec);
}

As= well as algorithms and general conveniences.

The = type requires no change to the language.

I have ma= de the distinction between mutable and immutable sequences in my implementa= tion, but I assume the standard library would rather *not* make that distin= ction. Mutability in this regard refers to the elements. Fixed size and con= stant pointer are by design. These objects are generally very short lived, = rarely member variables, and if a sequence were created using `new` it woul= d probably be a programmer error.

I'd like to hear= whether or not you would like to have this type in the standard library an= d if so, how you'd change it (and why).

Thanks

--

---
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_67_29128251.1370268471526-- .