220 11300 article Path: news.gmane.org!not-for-mail From: Jeremy Maitin-Shepard Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Comments on n3976 (array_view) Date: Fri, 13 Jun 2014 12:17:39 -0700 (PDT) Lines: 181 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_66_30456423.1402687059594" X-Trace: ger.gmane.org 1402687069 15003 80.91.229.3 (13 Jun 2014 19:17:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Jun 2014 19:17:49 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCYZZ4E5WQCRBVM45WOAKGQE3K54CVI@isocpp.org Fri Jun 13 21:17:43 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f199.google.com ([209.85.216.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WvWys-0005Uz-RS for gclcip-std-proposals@m.gmane.org; Fri, 13 Jun 2014 21:17:43 +0200 Original-Received: by mail-qc0-f199.google.com with SMTP id l6sf2188104qcy.6 for ; Fri, 13 Jun 2014 12:17:42 -0700 (PDT) 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=f4w7h4qgUnI108onX82UhBapNW5WZwNSYOCjyM1W/lE=; b=PgQCvaTNBml18T9BuulBkYrdeo/1U6hZSNfo9TqMxpISId0nL+jI3JL9VumHoukds5 cNKM2VmFUC6I3qU6CeUPfLsiPt2yY5KYwnExDuCtHKKv9esBVRonhCgoiT1yfQ80/m7L FkUcwScbNfyZYxz75SPP7qwaihGiQO9YdA3EOXT0PKBXnGFCtFUyEGBxyI4zMF6L0TNH KDsaDyv/eXE74FdC1Fdxsy0FfqEZy6IfBPtw0on8O7XEAjsvWTUkRPcXkwTpN8Tl3CmK n2It5BQaUgsXQsIy1dV3b0V047V1QXbceluXAnkrblchD1gc1rpbpU5j/4zCy4LubEMq z5AQ== X-Gm-Message-State: ALoCoQnwWr8w04i3WnqMTXKtYteAZKRT/FuzNnDWw8q1+MV/PIEtJ4AvIsVUN3ETStD0H2YNQe1K X-Received: by 10.58.237.130 with SMTP id vc2mr1356995vec.25.1402687062032; Fri, 13 Jun 2014 12:17:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.23.101 with SMTP id l5ls387736igf.9.canary; Fri, 13 Jun 2014 12:17:40 -0700 (PDT) X-Received: by 10.50.66.129 with SMTP id f1mr125777igt.13.1402687060923; Fri, 13 Jun 2014 12:17:40 -0700 (PDT) X-Original-Sender: jeremy@jeremyms.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:11300 Archived-At: ------=_Part_66_30456423.1402687059594 Content-Type: text/plain; charset=UTF-8 C++ is sorely in need of a "vocabulary type" for representing pointer ranges. It is also sorely in need of a good, standard library for multidimensional arrays/containers/ranges. While the design space for a one-dimensional, unstrided array view is fairly limited, the design space for a multidimensional array/container/range is very large. Finding the right design certainly involves numerous design iterations and very substantial user experience. While the proposed design in n3976 is a very useful starting point, it would be premature to standardize it at this point, as it is far from comprehensive and it is difficult to know how well the proposed interface could be extended to provide a larger set of functionality on par with the facilities available in many other languages. Some particular issues with the proposed design include: - No iterators are provided for array_view or strided_array_view, a clear omission in the interface. For a multidimensional array, there are two obvious types of iteration that may be desired: 1. iterating over just the first dimension; 2. iterating over a flat view of all of the elements. For a strided array, iterating over a flat view cannot be done efficiently without segmented/hierarchical iterators. Which of these should be the default (i.e. provided through begin() and end() rather than through some adaptor) is not clear, but the choice should be consistent with the definition of the size() member, for compatibility with existing ranges and containers. (1) would be consistent with operator[]. The proposal has size() returning the total number of elements, rather than the size of the first dimension, but this is not necessarily the best choice. - No data() access member for strided_array_view. This is presumably omitted because the memory is non-contiguous, but given that strided_array_view is a thin wrapper, there has to be a convenient way to get at the underlying memory. Given the definition of Viewable, the use of the name data() might be problematic as it would allow the incorrect (albeit explicit) conversion from strided_array_view to array_view. Possibly Viewable should be traits-based rather than based only on the presence of data() and size(). - Slicing is limited: it is not possible to take a slice in a dimension other than the first. - operator++ and operator-- on index seem very questionable. The semantics are rather arbitrary and not that likely to be useful except for a single dimension anyway. - It is not clear whether it is really useful to have bounds and index be separate types (though should probably at least be explicitly convertible to each other). Furthermore, bounds and index essentially represent a fixed-size discrete vector type, i.e. an augmented interface for std::array. Arguably the interface of std::array should just be extended to add component-wise operators instead. Also, a much more comprehensive set of component-wise operations should be provided. A statically-sized vector type is sorely needed in C++, but it does not make sense to standardize these limited, single-purposes types when they could be, and should be, much more general. Other omissions from index and bounds include: 1. no data() access to the components 2. no iterators over components for index or bound 3. the iterators for bounds iterate over positions, but are inefficient without segment/hierarchical iterators. This position iteration is clearly useful but the facility at present is very limited: it should likely be presented as a multidimensional range itself, and support a non-zero origin. Minor issues: - The array_view(ArrayType) constructor allows any ArrayType for which is_convertible>, pointer>::value. However, this allows conversions between base and derived types, which is incorrect. From my perspective, the only way to properly explore this design space for multidimensional arrays/containers/ranges is through an actively developed and widely used open source library. A much more reasonable target for standardization is a one-dimensional array_view. Since it would just be a thin wrapper over a pointer and a size or a pair of pointers, with no ownership, there are no obstacles to interoperability with other types. If a multi-dimensional array view is introduced later, its one-dimensional version could be implicitly convertible to and from the existing one-dimensional array_view. An array_view might likewise be redundant with iterator_range, but this is not a problem since zero-overhead implicit conversions are possible. -- --- 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_66_30456423.1402687059594 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
C++ is sorely in need of a "vocabulary type" for represent= ing pointer ranges.  It is also sorely in need of a good, standard lib= rary for multidimensional arrays/containers/ranges.  While the design = space for a one-dimensional, unstrided array view is fairly limited, the de= sign space for a multidimensional array/container/range is very large. = ; Finding the right design certainly involves numerous design iterations an= d very substantial user experience.  While the proposed design in n397= 6 is a very useful starting point, it would be premature to standardize it = at this point, as it is far from comprehensive and it is difficult to know = how well the proposed interface could be extended to provide a larger set o= f functionality on par with the facilities available in many other language= s.  Some particular issues with the proposed design include:

- = No iterators are provided for array_view or strided_array_view, a clear omi= ssion in the interface.  For a multidimensional array, there are two o= bvious types of iteration that may be desired:
  1. iterating over = just the first dimension;
  2. iterating over a flat view of all of= the elements.  For a strided array, iterating over a flat view cannot= be done efficiently without segmented/hierarchical iterators.
  Wh= ich of these should be the default (i.e. provided through begin() and end()= rather than through some adaptor) is not clear, but the choice should be c= onsistent with the definition of the size() member, for compatibility with = existing ranges and containers.  (1) would be consistent with operator= [].  The proposal has size() returning the total number of elements, r= ather than the size of the first dimension, but this is not necessarily the= best choice.

- No data() access member for strided_array_view. = ; This is presumably omitted because the memory is non-contiguous, but give= n that strided_array_view is a thin wrapper, there has to be a convenient w= ay to get at the underlying memory.  Given the definition of Viewable,= the use of the name data() might be problematic as it would allow the inco= rrect (albeit explicit) conversion from strided_array_view to array_view.&n= bsp; Possibly Viewable should be traits-based rather than based only on the= presence of data() and size().

- Slicing is limited: it is not poss= ible to take a slice in a dimension other than the first.

- operator= ++ and operator-- on index seem very questionable.  The semantics are = rather arbitrary and not that likely to be useful except for a single dimen= sion anyway.

- It is not clear whether it is really useful to have b= ounds and index be separate types (though should probably at least be expli= citly convertible to each other).    Furthermore, bounds and= index essentially represent a fixed-size discrete vector type, i.e. an aug= mented interface for std::array.  Arguably the interface of std::array= should just be extended to add component-wise operators instead.  Als= o, a much more comprehensive set of component-wise operations should be pro= vided.  A statically-sized vector type is sorely needed in C++, but it= does not make sense to standardize these limited, single-purposes types wh= en they could be, and should be, much more general.  Other omissions f= rom index and bounds include:
 1. no data() access to the component= s
 2. no iterators over components for index or bound
 3. t= he iterators for bounds iterate over positions, but are inefficient without= segment/hierarchical iterators.  This position iteration is clearly u= seful but the facility at present is very limited: it should likely be pres= ented as a multidimensional range itself, and support a non-zero origin.
Minor issues:
- The array_view(ArrayType) constructor allows any Ar= rayType for which is_convertible<add_pointer_t<remove_all_extents_t&l= t;ArrayType>>, pointer>::value.  However, this allows convers= ions between base and derived types, which is incorrect.

From my per= spective, the only way to properly explore this design space for multidimen= sional arrays/containers/ranges is through an actively developed and widely= used open source library.

A much more reasonable target for standar= dization is a one-dimensional array_view.  Since it would just be a th= in wrapper over a pointer and a size or a pair of pointers, with no ownersh= ip, there are no obstacles to interoperability with other types.  If a= multi-dimensional array view is introduced later, its one-dimensional vers= ion could be implicitly convertible to and from the existing one-dimensiona= l array_view.  An array_view might likewise be redundant with iterator= _range<pointer>, but this is not a problem since zero-overhead implic= it conversions are possible.

--

---
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_66_30456423.1402687059594-- .