220 13628 article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: The view concept Date: Fri, 3 Oct 2014 11:14:07 -0700 (PDT) Lines: 135 Approved: news@gmane.org Message-ID: References: <428c47bd-67f2-47d1-98c0-e5ca85698076@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_745_896418672.1412360047112" X-Trace: ger.gmane.org 1412360057 2431 80.91.229.3 (3 Oct 2014 18:14:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Oct 2014 18:14:17 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRB36OXOQQKGQEC22AIEI@isocpp.org Fri Oct 03 20:14:10 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f199.google.com ([209.85.192.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xa7Mn-0005Ku-Be for gclcip-std-proposals@m.gmane.org; Fri, 03 Oct 2014 20:14:09 +0200 Original-Received: by mail-pd0-f199.google.com with SMTP id g10sf129918pdj.6 for ; Fri, 03 Oct 2014 11:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=vJF7jw9JjdJcaQS6MFqwJGpmWuqpmsPJIY4Ex2O/03o=; b=EdF2fLZFcEtDlNhDXJn8Toah2ka8/AR2TjnkymN9eUPL50YKIuNe94yJlUVjklaqT8 +J6wXLv7zVttlKIHVz57dK6aYUBpsi8VdzU5We+BE1VvNIZ9Rn6lBEO4bF/bPdg0l0Gz BSTJspqH3SB/tau6o362xyVBYMC1RIi/x4RKxivv9uDf0nrCPSZusdvkgLW7bQ5yk71q yNdWGI+prDLdtnImE4XKkUR/SxnsWrmc7TgIEnHxhdqyr2MV6A58wZoLm9vEuiwQCfX7 mCNfuWSpePhZZugdJOrgF/5r+xuuP882BpldQsGp/tPOES0w79HRxkOyG8XmOI4jpdmm ZgoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=vJF7jw9JjdJcaQS6MFqwJGpmWuqpmsPJIY4Ex2O/03o=; b=Pw3QVFzcP9fiug1CIc0fYSDUEMQDDvkDBBsN8CmwnE8vbEgXuTaLE/XYWQlZOskEBD IUV7faOlWHc2GA2OqbJEKr21cu4InpbGBSbOU3x6RcrfKX3ASRCwhRZNqpAD8gVGvppf Rxwp5tDIn0irPZD3MizgXBa2ZUJ65zY5lw+NcE1lhNkj6eh6JHWFxCEda5qnmUev8Zow YOwlVWZsrEd8ZnXld0z5H/Sz5uXm5cfCAssi6wXXEzpe8LPXQLDUj6NfJ8E8XZs6dlOq W5Ak5f6tIssWrXtJi7aiYoJba04CYreao4z2ws1VkcMCSegrF5cWiBBm9wKD4EobNax5 PY0Q== X-Gm-Message-State: ALoCoQkOwcmfMcgSKLo7188OpkXxUKXXWLUrVt1lMdoFP8Xml09PQ5+UjiFPjcKnpTxhBzu9lrq2 X-Received: by 10.66.219.36 with SMTP id pl4mr5849460pac.2.1412360048298; Fri, 03 Oct 2014 11:14:08 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.102.237 with SMTP id w100ls1335287qge.35.gmail; Fri, 03 Oct 2014 11:14:07 -0700 (PDT) X-Received: by 10.140.100.162 with SMTP id s31mr23893qge.17.1412360047407; Fri, 03 Oct 2014 11:14:07 -0700 (PDT) In-Reply-To: X-Original-Sender: fmatthew5876@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:13628 Archived-At: ------=_Part_745_896418672.1412360047112 Content-Type: text/plain; charset=UTF-8 On Friday, October 3, 2014 1:44:04 PM UTC-4, Tony V E wrote: > > > Of course we are still arguing whether a container is a range... > Maybe its better not to call a container a range but instead say that container is implicitly convertible to a range. If a container itself is range, then it has to conform to whatever the range specification is. This could be problematic and limiting in the future. An iterator is an entirely separate entity from its parent container. The container only has to specify a few methods (begin / end) to generate an iterator. The iterator type itself satisfies the iterator concept. Why not treat the range of a container in the same way? If a container is not a range itself, we can define a range in terms of a container. A range is defined as an object which represents a subset of a container. For generic algorithms such as sort, any container is easily convertible to a range which represents the full subset. Maybe you can't call std::sort(vec), but std::sort(vec.range()) is not too bad. You can also easily create ranges over strict subsets of the container and process that, (e.g. std::sort(vec.range(0, 3));) The only concern for a range is to iterate over the subset and read / write the members of the set. A view can be used for iteration but in addition it has its own semantic meaning. Similar to a view, you can shrink a range but the range can't do anything extra other than iteration, read, and write. You can also construct new ranges by taking subsets of the original range. A view on the other hand is a container. It doesn't own the underlying data but the crucial difference is that the view has its own meaning as a value type. Consider the difference between a generic range of characters and a string_view. The first is just a dumb collection, the second has a special concept of "string". The first can just iterate, read, and write character bytes. The latter can be formatted, printed, parsed, etc.. Whats interesting from all of this is that string_view and bitset_view seem to fit the view concept. array_view on the other hand really is a range. All of the splicing, sectioning, and multi-dimensional chunking are only ways of specifying how to do iteration on a contiguous buffer. In the end, the array_view is just a dumb collection of objects which are laid out contiguously in memory. It doesn't add any new semantics to the collection like string_view and bitset_view. > The biggest issue, in my mind, is that, IIUC, both Range and Container are > Regular. View is not. ie View is a mix of deep and shallow, whereas both > Range and Container are consistent in their deep/shallow-ness. > > Tony > > > -- --- 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/. ------=_Part_745_896418672.1412360047112 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, October 3, 2014 1:44:04 PM UTC-4, Tony = V E wrote:
Of course we are still arguing whethe= r a container is a range...
Maybe its better not to call a container a range but instead say that con= tainer is implicitly convertible to a range. If a container itself is range= , then it has to conform to whatever the range specification is. This could= be problematic and limiting in the future. An iterator is an entirely sepa= rate entity from its parent container. The container only has to specify a = few methods (begin / end) to generate an iterator. The iterator type itself= satisfies the iterator concept. Why not treat the range of a container in = the same way?

If a container is not a range itself, we can define a = range in terms of a container. A range is defined as an object which repres= ents a subset of a container. For generic algorithms such as sort, any cont= ainer is easily convertible to a range which represents the full subset. Ma= ybe you can't call std::sort(vec), but std::sort(vec.range()) is not too ba= d. You can also easily create ranges over strict subsets of the container a= nd process that, (e.g. std::sort(vec.range(0, 3));)

The only concern= for a range is to iterate over the subset and read / write the members of = the set. A view can be used for iteration but in addition it has its own se= mantic meaning. Similar to a view, you can shrink a range but the range can= 't do anything extra other than iteration, read, and write. You can also co= nstruct new ranges by taking subsets of the original range.

A view o= n the other hand is a container. It doesn't own the underlying data but the= crucial difference is that the view has its own meaning as a value type. C= onsider the difference between a generic range of characters and a string_v= iew. The first is just a dumb collection, the second has a special concept = of "string". The first can just iterate, read, and write character bytes. T= he latter can be formatted, printed, parsed, etc..

Whats interesting= from all of this is that string_view and bitset_view seem to fit the view = concept. array_view on the other hand really is a range. All of the splicin= g, sectioning, and multi-dimensional chunking are only ways of specifying h= ow to do iteration on a contiguous buffer. In the end, the array_view is ju= st a dumb collection of objects which are laid out contiguously in memory. = It doesn't add any new semantics to the collection like string_view and bit= set_view.



The bigge= st issue, in my mind, is that, IIUC, both Range and Container are Regular.&= nbsp; View is not. ie View is a mix of deep and shallow, whereas both Range= and Container are consistent in their deep/shallow-ness.

Tony


--

---
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-proposa= ls+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>.
------=_Part_745_896418672.1412360047112-- .