220 13607 <428c47bd-67f2-47d1-98c0-e5ca85698076@isocpp.org> article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: The view concept Date: Thu, 2 Oct 2014 22:40:01 -0700 (PDT) Lines: 128 Approved: news@gmane.org Message-ID: <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_1457_1336283053.1412314801958" X-Trace: ger.gmane.org 1412314813 3033 80.91.229.3 (3 Oct 2014 05:40:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Oct 2014 05:40:13 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBMXNXCQQKGQEFTQZEYY@isocpp.org Fri Oct 03 07:40:06 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XZvb2-0005Vg-Hd for gclcip-std-proposals@m.gmane.org; Fri, 03 Oct 2014 07:40:04 +0200 Original-Received: by mail-pa0-f70.google.com with SMTP id et14sf5673311pad.1 for ; Thu, 02 Oct 2014 22:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id: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=6dLX2bXskOYVohSlA7dqfZPQvcJOQ7jO8SrnexDWgvQ=; b=fBwMj1FiFmhRAt3U5D8IbncB83V4/9RyhAogv8InqQ19Z8vCLKJ+eMh79+/QTkiZpU fGCzFHRuBi/UtHlEBvO7rQzZ74U0VFYMZTRTQuGQBtAOKSFQTJFlHdArw5RUjTfUDJdR nkFurFTdbOdzTrGlMWBKNKWrkiiwqGesIja5tFA4yxo2Cw8LHAK6nseDq7G+UVb7vQw4 qQY+VE5cfDphRBzXxGM7aOhxCkyUp2YLEOzb9GG3xYNT6/lu6VmhYn7i18OHYksbYKIS +ACqC51gc4cVcQSxyhYGLFfq+1V9bz4ewdxRfe8mIxiQNPkvqUvQOUZpm6HtYOkU8RAZ B2bg== 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: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=6dLX2bXskOYVohSlA7dqfZPQvcJOQ7jO8SrnexDWgvQ=; b=arKTbSO/D/EpvC8oasrPrKsbu5BJ33SRhpm4DpKf9rlojDAVcxHtSmroBYiaVRthik UisDKnq6TZMU62fpyzzIr5grXZJ42KYkW8uC8DxNkczBBvxsC/GootoWWajGiVvBZbYG WMa6ITShMXi1UPxfEeWZSRzIz0LuX+Q9UgzZg0Ckb3Iw2WBnyEkZNpLKz5eUlyWpKMNS ttwfHOYuXszfDfybCdCpcCyiJnhNM9/++NPm3AJyhaBsqMTs2EhuahSGzPB8D4253KEp 2jNwia0Z2rbrrGrbY+9j/rQz3QFzorTMsnP3W6TPyJYxkMMg7U7kz8LgQuLRpRbv9OfG Tjhg== X-Gm-Message-State: ALoCoQlUMwVFGdzQqZGMg8GjyOxX6UuuSi8KuYEIoSRn09Piveb2kaxBXtA7TFWcGSkn0fyqsChy X-Received: by 10.66.193.161 with SMTP id hp1mr3395944pac.40.1412314803232; Thu, 02 Oct 2014 22:40:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.96.42 with SMTP id j39ls1181125qge.89.gmail; Thu, 02 Oct 2014 22:40:02 -0700 (PDT) X-Received: by 10.140.30.36 with SMTP id c33mr6487qgc.2.1412314802447; Thu, 02 Oct 2014 22:40:02 -0700 (PDT) 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:13607 Archived-At: ------=_Part_1457_1336283053.1412314801958 Content-Type: text/plain; charset=UTF-8 With array_view, string_view, and now possibly bitset_view, this view thing is becoming contagious. I think at this stage it makes sense to precisely define exactly what a view is and how it behaves as a concept. Any kind of view type that is invented now or in the future should adhere to a set of rules so that they all have a uniform interface. First, what exactly is a view? I would define it as an adapter over a fixed size contiguous range of memory. How does a view behave with respect to common operations? Let's compare a view, to a T, and T* and see how they behave. These rules are derived from string_view and array_view. T = T: copy the value (deep copy) T* = T*: reassign the pointer (shallow copy) view = view: reassign the view (shallow copy) T == T: compare 2 values (deep compare) T* == T*: compare whether 2 pointers point to the same thing (shallow compare) view == view: compare the values (deep compare) T.foo(): direct member invocation of T (T*)->foo(): indirect member invocation of T view.foo(): direct member invocation of the view type methods Questions: 1) How do we shallow compare 2 views? 2) How do we deep copy a view? What are the common operations for any view? 1) We can iterate over a view with begin()/end() 2) We can access an element using operator[] / at() / front() / back() / data() 3) We can ask for the size() and whether or not the view is empty() 4) We can shrink the view by removing front or back elements, but not make it larger. Once you chop off the front or back of the view, you can never recover it. 5) We can reassign the view to another source array 6) We can compare 2 views The array_view proposal also gets into multi-dimensional views and striding, but I'm not going to go there yet. If there are a certain set of operations that apply to any kind of view, then perhaps it makes sense to define and mandate them for all of the view classes. This could even be done with inheritance. Have a basic_view base class which implements the above methods and have array_view (striding / sectioning / dimensions), string_view (string class), bitset_view (bit manipulation) build on top of that. -- --- 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_1457_1336283053.1412314801958 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
With array_view, string_view, and now possibly bitset_view= , this view thing is becoming contagious.

I think at thi= s stage it makes sense to precisely define exactly what a view is and how i= t behaves as a concept. Any kind of view type that is invented now or in th= e future should adhere to a set of rules so that they all have a uniform in= terface.

First, what exactly is a view?
=
I would define it as an adapter over a fixed size contiguous= range of memory.

How does a view behave with resp= ect to common operations?

Let's compare a view<= T>, to a T, and T* and see how they behave. These rules are derived from= string_view and array_view.

T =3D T: copy the val= ue (deep copy)
T* =3D T*: reassign the pointer (shallow copy)
view<T> =3D view<T>: reassign the view (shallow copy)

T =3D=3D T: compare 2 values (deep compare)
T* =3D=3D T*: compare whether 2 pointers point to the same thing (shallow= compare)
view<T> =3D=3D view<T>: compare the values = (deep compare)

T.foo(): direct member invocation o= f T
(T*)->foo(): indirect member invocation of T
vie= w<T>.foo(): direct member invocation of the view type methods

Questions:
1) How do we shallow compare 2 views= ?
2) How do we deep copy a view?

What ar= e the common operations for any view?

1) We can it= erate over a view with begin()/end()
2) We can access an element = using operator[] / at() / front() / back() / data()
3) We can ask= for the size() and whether or not the view is empty()
4) We can = shrink the view by removing front or back elements, but not make it larger.= Once you chop off the front or back of the view, you can never recover it.=
5) We can reassign the view to another source array
6)= We can compare 2 views

The array_view proposal al= so gets into multi-dimensional views and striding, but I'm not going to go = there yet.

If there are a certain set of operation= s that apply to any kind of view, then perhaps it makes sense to define and= mandate them for all of the view classes. This could even be done with inh= eritance. Have a basic_view<T> base class which implements the above = methods and have array_view (striding / sectioning / dimensions), string_vi= ew (string class), bitset_view (bit manipulation) build on top of that.

--

---
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_1457_1336283053.1412314801958-- .