220 11418 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?=C5=81ukasz_Mendakiewicz?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Comments on n3976 (array_view) Date: Sun, 15 Jun 2014 14:07:49 -0700 (PDT) Lines: 253 Approved: news@gmane.org Message-ID: References: <7177de96-50e1-4590-99dc-eda255203f26@isocpp.org> <5ff6c439-3147-4d5f-809a-8adf86c17dc4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12_18079856.1402866469569" X-Trace: ger.gmane.org 1402866477 3460 80.91.229.3 (15 Jun 2014 21:07:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Jun 2014 21:07:57 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC2NDJ47YMLBBJ4W7COAKGQE3XKJEHA@isocpp.org Sun Jun 15 23:07:53 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f199.google.com ([209.85.160.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WwHea-0002Y4-Sl for gclcip-std-proposals@m.gmane.org; Sun, 15 Jun 2014 23:07:53 +0200 Original-Received: by mail-yk0-f199.google.com with SMTP id q200sf12917879ykb.2 for ; Sun, 15 Jun 2014 14:07:51 -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: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=0WrfN0WCZz0TY1Txl3ORYCk+mXXVQZzsRXntAsrS7BA=; b=g7mWd/0l2r1ifJ34Kinuygi8DCIg7ux+uJV2lmASZ6SOiP6O9rTIstg8EkyM3fYjRz 6ujJxiPZMXFldzArvavxHsKV3ixaEaRhTJGFmdMcJnfQSRuMXvDvravJgvVIVL3kM4LB kyGDPGdwH1GDvHF8+7SS8usXgR69FTxpulDXf+ZS4YjXvBh5+o2iT3eqecJX+bohxTvl WyTMxNkK3Wrxmzysxqtaj0lV7IBzLOsddRXtWaV62V58tpZ2OTeTwZBWZCWsxHuZhHgQ Au0o85cyIjWT6hrZVFu4wLs+QOXJ8sFca5Hrxn2TWY4fnanabI/q6pqhb/IiKtS7ab2b c0qg== X-Gm-Message-State: ALoCoQldTv/fC6vROpIh6oFOybwOgOjPvrzvpJv0dHrsEh7g3q5a7hhfMK2Gi7kLL05cOOMFrULy X-Received: by 10.236.141.11 with SMTP id f11mr547803yhj.54.1402866471921; Sun, 15 Jun 2014 14:07:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.85.39 with SMTP id e7ls613499igz.14.canary; Sun, 15 Jun 2014 14:07:50 -0700 (PDT) X-Received: by 10.50.138.133 with SMTP id qq5mr360956igb.4.1402866470925; Sun, 15 Jun 2014 14:07:50 -0700 (PDT) In-Reply-To: X-Original-Sender: l.mendakiewicz@live.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:11418 Archived-At: ------=_Part_12_18079856.1402866469569 Content-Type: text/plain; charset=UTF-8 I have a slightly different opinion on the matter, and in my view both array_view and ranges should coexist in the library as they serve different purposes. 1. array_view guarantees a contiguous memory range. This property can be used for performance benefit (e.g. leveraged in a vectorized or GPGPU execution) or for compatibility with C. In that spirit, I also disagree with the comment below that it should be possible to create an array_view (ignoring for the moment the obvious misnomer) over deque, list, etc. as it would conflict with this basic property. Ranges are likely the proper solution for such scenarios. Please note that random_access_iterator does not guarantee contiguity in the memory. It merely gives illusion of such, and this is insufficient to fully exploit the current hardware, which is more often than in the past bound by the memory (rather than compute). This however could be partially alleviated by introducing more specialized iterator category (vide N3884). 2. array_view allows "lifting" a contiguous allocation into a multidimensional representation. Please correct me if I'm wrong, but I think ranges by definition do not address this use case. This is not only matter of indexing using multiple components, but also other convenience operations like slicing or sectioning. Having said that, given that neither ranges nor array_view are targeted at C++14, it is not impossible for ranges to grow their scope and subsume the design space covered now by the multidimensional array_view. From our perspective this is a success, as the necessary functionality is added to the standard C++. However until this happens, the two are effectively different, despite some commonality for the basic cases. On Friday, June 13, 2014 4:56:47 PM UTC-7, Sean Middleditch wrote: > Adding a bunch of cruft that is planned to be obsoleted with an update > right around the corner seems like a waste of time and needless bloat > to the library for no practical gain. It's not even clear that there's > any point in time we'd even need the interim solution: C++14 is done, > no new library additions are going to be made to it, all work going > forward is for C++17, and it's rather likely that the first version of > comprehensive ranges will either be in C++17 or a TS released around > the same time. > > On Fri, Jun 13, 2014 at 3:07 PM, Jeremy Maitin-Shepard > > wrote: > > > > > > On Friday, June 13, 2014 2:37:50 PM UTC-7, Sean Middleditch wrote: > >> > >> On Friday, June 13, 2014 12:17:40 PM UTC-7, Jeremy Maitin-Shepard > wrote: > >>> > >>> C++ is sorely in need of a "vocabulary type" for representing pointer > >>> ranges. > >> > >> > >> There's already a Ranges sub group working on this problem, and looking > at > >> even more general cases of ranges than just pairs of > iterators/pointers. > >> > >> http://www.open-std.org/mailman/listinfo/ranges > > > > > > Sure, but (pointer, size) ranges are an extremely common and important > case, > > and devising a comprehensive range library that handles all cases is > much > > harder than handling just the (pointer, size) case. Also, in the worst > > case, a one-dimensional array_view type would become redundant after a > range > > library is standardized, but it wouldn't cause any interoperability > > problems, since the types would surely be implicitly convertible. > > > > -- > > > > --- > > You received this message because you are subscribed to a topic in the > > Google Groups "ISO C++ Standard - Future Proposals" group. > > To unsubscribe from this topic, visit > > > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/xzb1d5KUxMU/unsubscribe. > > > To unsubscribe from this group and all its topics, send an email to > > std-proposal...@isocpp.org . > > To post to this group, send email to std-pr...@isocpp.org . > > > Visit this group at > > http://groups.google.com/a/isocpp.org/group/std-proposals/. > > > > -- > Sean Middleditch > http://seanmiddleditch.com > -- --- 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_12_18079856.1402866469569 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have a slightly different opinion on the matter, an= d in my view both array_view and ranges should coexist in the library as th= ey serve different purposes.

1. array_view guarant= ees a contiguous memory range. This property can be used for performan= ce benefit (e.g. leveraged in a vectorized or GPGPU execution) or for compa= tibility with C.
In that spirit, I also disagree with the comment= below that it should be possible to create an array_view (ignoring for the= moment the obvious misnomer) over deque, list, etc. as it would conflict w= ith this basic property. Ranges are likely the proper solution for suc= h scenarios.
Please note that random_access_iterator does not gua= rantee contiguity in the memory. It merely gives illusion of such, and this= is insufficient to fully exploit the current hardware, which is more often= than in the past bound by the memory (rather than compute). This however&n= bsp;could be partially alleviated by introducing more specialized iter= ator category (vide N3884).

2. array_view allows "= lifting" a contiguous allocation into a multidimensional representation. Pl= ease correct me if I'm wrong, but I think ranges by definition do not addre= ss this use case. This is not only matter of indexing using multiple compon= ents, but also other convenience operations like slicing or sectioning.

Having said that, given that neither ranges nor array= _view are targeted at C++14, it is not impossible for ranges to grow t= heir scope and subsume the design space covered now by the multidimensional= array_view. From our perspective this is a success, as the necessary funct= ionality is added to the standard C++. However until this happens, the two = are effectively different, despite some commonality for the basic cases.
On Friday, June 13, 2014 4:56:47 PM UTC-7, Sean Middleditch wrote:
Adding a bunch of cruft that is planned to b= e obsoleted with an update
right around the corner seems like a waste of time and needless bloat
to the library for no practical gain. It's not even clear that there's
any point in time we'd even need the interim solution: C++14 is done,
no new library additions are going to be made to it, all work going
forward is for C++17, and it's rather likely that the first version of
comprehensive ranges will either be in C++17 or a TS released around
the same time.

On Fri, Jun 13, 2014 at 3:07 PM, Jeremy Maitin-Shepard
<jer...@jeremyms.com> = wrote:
>
>
> On Friday, June 13, 2014 2:37:50 PM UTC-7, Sean Middleditch wrote:
>>
>> On Friday, June 13, 2014 12:17:40 PM UTC-7, Jeremy Maitin-Shep= ard wrote:
>>>
>>> C++ is sorely in need of a "vocabulary type" for represent= ing pointer
>>> ranges.
>>
>>
>> There's already a Ranges sub group working on this problem, an= d looking at
>> even more general cases of ranges than just pairs of iterators= /pointers.
>>
>> http://www.open-std.org/mailman/listinf= o/ranges
>
>
> Sure, but (pointer, size) ranges are an extremely common and impor= tant case,
> and devising a comprehensive range library that handles all cases = is much
> harder than handling just the (pointer, size) case.  Also, in= the worst
> case, a one-dimensional array_view type would become redundant aft= er a range
> library is standardized, but it wouldn't cause any interoperabilit= y
> problems, since the types would surely be implicitly convertible.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in= the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/xzb= 1d5KUxMU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email t= o
> std-proposal...@isocpp.= org.
> To post to this group, send email to std-pr...@isocpp.org.
> Visit this group at
> ht= tp://groups.google.com/a/isocpp.org/group/std-proposals/.



--=20
Sean Middleditch
http://seanmiddleditch.com

--

---
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_12_18079856.1402866469569-- .