220 25844 article Path: news.gmane.org!not-for-mail From: Morwenn Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Fixed-size views and spans Date: Sun, 8 May 2016 02:45:14 -0700 (PDT) Lines: 85 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/mixed; boundary="----=_Part_2056_1605771060.1462700714171" X-Trace: ger.gmane.org 1462700774 18470 80.91.229.3 (8 May 2016 09:46:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 May 2016 09:46:14 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC2ZP4V74IFBBK4VXS4QKGQEGA2W2JI@isocpp.org Sun May 08 11:46:08 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f198.google.com ([209.85.220.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1azLH3-0004qi-F2 for gclcip-std-proposals@m.gmane.org; Sun, 08 May 2016 11:45:17 +0200 Original-Received: by mail-qk0-f198.google.com with SMTP id s68sf227484547qkb.0 for ; Sun, 08 May 2016 02:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=tAYLot36ImrbCdRq2n1ND5qNkin6+/uocIq0IUGwgK8=; b=qZKAXRj4W6G5Aw0eQ7+4ALl5e7JlGAkC4Z774jxhFA2DOs/nOzQRv5kT+gkdSj8w7m JF1y9DbV+rHz3hK/yV4xiFEjpSVKzYO96sWrWrpR/4NUa2g2jcs9/ZZWeBiUtLRlm6c/ +0oc+BTQCZOotLrcKAB/yz87nkGBd7bs3c+GmfanSeJQEpqPTfxE4uxIMFC0wnt/T3O8 qa3xYwPiTH0Re8X5eWidGu3ujxFczSC1lZTvWH6AEPZzimflS0KrWxxBkMW6lmiRIybu iYmYHl5V9Ezvx+6/WP7WEMZEe5q6aZf7+CmX+TiBHEuWdL3FQfDrvHUHXTelbGwzG9a6 sFvg== 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:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=tAYLot36ImrbCdRq2n1ND5qNkin6+/uocIq0IUGwgK8=; b=cM9AEd8kcXq4RsPC9kVf7oh6mSvltmgO7Oatkvrmq46GU96BzK5PX1RyPTQNi4YgOY iPhT0ex5X+bZwEn0bYBiGlC3SvEHtjA3kF7oUfk/VIN088y0wOXzympt/oJNLOVqxNK0 7xgO5P4eW3VGafTVboHb/NZQ7ALj7c5WDgBh5iNKGScAbDUHfKXIzLxz+7U8Kunc3B2m K8kWOpXfF6/v+SwDCDTB3ghGpNOZbGOIINZzO0Qo7juA5vBWLiV3b27RF4x8YoINZqQU WdqHb27zxVhsbqKaAIWP5m8A0cZzIAdWsYD9ihcBOhaXPfYXli66Xd4RZLlRfK7eZZbM v+Zw== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=tAYLot36ImrbCdRq2n1ND5qNkin6+/uocIq0IUGwgK8=; b=EIlKqVhO+a7MiZcmXCL43t9NrDm1cXnL4vLAHdYfn2UAZmbh/1jUA//tlcX8U/qQzp kmDyCRvtzvgKYpU35CUzS2bZLpuTb90fhyQvqQoWS2Il0GtGOkEw/L0amOwFa2rN9+Rx Io6nZll7M5r+brVy9IvpCPuU0QdMcfyJPNdKcsDqDaldwtv12sKQGM+CIeJNzyefeN8J aADcIoNQhyh2zgIdUVi+r1LRcT5PoEUT5eFYcpPXSZ1JT5qAIxJ52hgegglqnNy4YyRC pg5ZM8DNW4mBZ22fPj+IzcFtFaMppuRGNnunksL0hLlU+39n73aVttf5m0wzBG6ydl56 +a8A== X-Gm-Message-State: AOPr4FVMWHiZ7jUHTQc5ZgZRgLid69+T213gZKQca5P5IupDCk8XOXHLECND5MkTcozU5A== X-Received: by 10.140.179.23 with SMTP id z23mr18768158qhz.21.1462700716475; Sun, 08 May 2016 02:45:16 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.130.205 with SMTP id m74ls1569104ioi.9.gmail; Sun, 08 May 2016 02:45:15 -0700 (PDT) X-Received: by 10.50.182.7 with SMTP id ea7mr65490igc.2.1462700715267; Sun, 08 May 2016 02:45:15 -0700 (PDT) X-Original-Sender: morwenn29@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:25844 Archived-At: ------=_Part_2056_1605771060.1462700714171 Content-Type: multipart/alternative; boundary="----=_Part_2057_1137107448.1462700714171" ------=_Part_2057_1137107448.1462700714171 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Another quick idea: sometimes we know that we will perform an operation on= =20 the next N element of an iterable, where N is known at compile-time. It=20 might be the case for what we could call =C2=AB bottom-up divide-and-conque= r =C2=BB=20 algorithms. For example, WikiSort=20 starts by dividing the=20 collection to sort in chunks of 8 elements and sorting them before=20 proceeding with soe smart merging operations. We know how to speed up some= =20 operations when the number of elements is small and known at compile-time:= =20 sorting networks are an excellent tool to sort integers when the size of=20 the collection to sort is known at compile-time. However there is no simple way to tell to the standard library's algorithms= =20 that they will work with a small number of elements known at compile-time.= =20 A solution would be to add span and view classes that take an integer=20 template parameter for their size, and let library implementers add=20 overloads to algorithms for such utility classes when they think it is=20 useful (it could still fit the Ranges TS design). Any thoughts about the usefulness of such fixed-size span and view classes? --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/dc128d7b-df5a-4a2f-a21b-136029ae3a84%40isocpp.or= g. ------=_Part_2057_1137107448.1462700714171 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Another quick idea: sometimes we know that we will perform= an operation on the next N element of an iterable, where N is known at com= pile-time. It might be the case for what we could call =C2=AB bottom-up div= ide-and-conquer =C2=BB algorithms. For example, WikiSort starts by dividing the collectio= n to sort in chunks of 8 elements and sorting them before proceeding with s= oe smart merging operations. We know how to speed up some operations when t= he number of elements is small and known at compile-time: sorting networks = are an excellent tool to sort integers when the size of the collection to s= ort is known at compile-time.

However there is no simple way to tell= to the standard library's algorithms that they will work with a small = number of elements known at compile-time. A solution would be to add span a= nd view classes that take an integer template parameter for their size, and= let library implementers add overloads to algorithms for such utility clas= ses when they think it is useful (it could still fit the Ranges TS design).=

Any thoughts about the usefulness of such fixed-size span and view = classes?

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/dc128d7b-df5a-4a2f-a21b-136029ae3a84= %40isocpp.org.
------=_Part_2057_1137107448.1462700714171-- ------=_Part_2056_1605771060.1462700714171-- .