220 25854 article Path: news.gmane.org!not-for-mail From: Morwenn Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Fixed-size views and spans Date: Sun, 8 May 2016 09:54:02 -0700 (PDT) Lines: 137 Approved: news@gmane.org Message-ID: References: <09bfdbe7-70d9-4d25-9f51-4b79cecfb79f@isocpp.org> <1f37ba85-fbfe-4a00-97fd-ac9125111bea@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_31_767047886.1462726442590" X-Trace: ger.gmane.org 1462726485 25989 80.91.229.3 (8 May 2016 16:54:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 May 2016 16:54:45 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC2ZP4V74IFBBK66XW4QKGQEKAGNS4Y@isocpp.org Sun May 08 18:54:44 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f198.google.com ([209.85.192.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1azRy1-0001YW-HG for gclcip-std-proposals@m.gmane.org; Sun, 08 May 2016 18:54:05 +0200 Original-Received: by mail-pf0-f198.google.com with SMTP id 203sf335357651pfy.2 for ; Sun, 08 May 2016 09:54:05 -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:in-reply-to:references: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=YB2GK22R7DnuRG1kORQyAkEKzxcVTLoxoUEY8D3TQpw=; b=n/2v98jRnZOe/HbgLrK53pZ/rZuhpTRRRB/KyON9oq7ywR72FpkWj1y0ngaRB5Hlz6 mq+mwmUVVIFz8732vOuFwe/NycRKluknHnKJsf6HStOZbocsYi1gwIQLGtXAJpRzeSNz P5L1UoCkBS8iPXj8crDgRofs7KL4Mug3qVtkjLRbN6GkX6lZdA0uRzQqElckJFfhKxpB eA2rOulz85Be2w6In7nU/WuC9fHRfUISK253eB1gFg8zvpylkrtlj33ofhmeIJYJoZmf +ls63QMR9psJRHRX/x65t7T38zuXsbz6FdOOENO823ecbrhdPYVAKrEjbmKRTl7BGLXX rSAA== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=YB2GK22R7DnuRG1kORQyAkEKzxcVTLoxoUEY8D3TQpw=; b=C42esOxHXaMAT0czAkeZ2z65DxkRU2o1ky7yxA4VczvtBU1w+J0lj1TZvh3KffOzF6 hYIIRUuvVAza2+w+5nnfM75eQmfMpbMDu1W7GGADWYPQFsA/3MGSjqMGuGTK2b5cOc17 HxsUSdx6WqNl3EAIGAwh1tJTiyDu+mTHrEFqVqC0WBR9Y2RDAYkJEMqC+6fPAAQT0Vd2 cE9wWHgFv1lZTyRNLVi2W4MLSvIP+QDrNnHe8IoQsNVopXkHf7DnGnJZgYm2BEiBgIi8 FGktFUaGY1v9vU961tIdta+a4YsalX1ZuCE8M0RKylf5UNU/SdioMrefAlB/AsOsnbpj rh6g== 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:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=YB2GK22R7DnuRG1kORQyAkEKzxcVTLoxoUEY8D3TQpw=; b=KH5xvfyQwM4h4Cdkt7xGmaY1BWN37IFduH9jCpATqmTD7a90zVo3qZmTY6KJ8AHrH7 U6SRUOL7Kdqi8ge0ncYBLkeWU/wHVj5zi2j1BrjWLHfdgzqkCNrSj97ChUKqWPZsulUR cWNkoF5APm7w+rn+nuBiArkKz+d4a9WDnwy6+YF0qZMXY/W0PneKBgRWKOQKTQgpE7qG PcN+VJhOuu0c3H6DOO8rfOsDhwdnE5WRP2RBbFhuBhX5CdN+t6/rbWrbT80AMhcvLX7h +q6XVZV2/aaufy4gSM1Hiwaj34ix4LUM/ScLhDBTH/L/bsuVlgtKIqjlZBHdtJnJifsE 35hg== X-Gm-Message-State: AOPr4FUYcoGAY527RaawYPvKgtn0diIcdOLwmOUkiTuRQbbDBmDPjDOg9n4YoyEY6OVOyg== X-Received: by 10.66.187.209 with SMTP id fu17mr19842800pac.24.1462726444478; Sun, 08 May 2016 09:54:04 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.7.40 with SMTP id 40ls1692273ioh.40.gmail; Sun, 08 May 2016 09:54:03 -0700 (PDT) X-Received: by 10.50.172.73 with SMTP id ba9mr76989igc.6.1462726443600; Sun, 08 May 2016 09:54:03 -0700 (PDT) In-Reply-To: <1f37ba85-fbfe-4a00-97fd-ac9125111bea@isocpp.org> 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:25854 Archived-At: ------=_Part_31_767047886.1462726442590 Content-Type: multipart/alternative; boundary="----=_Part_32_1038504208.1462726442591" ------=_Part_32_1038504208.1462726442591 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le dimanche 8 mai 2016 15:40:38 UTC+2, Nicol Bolas a =C3=A9crit : > > The GSL `span` type already supports being compile-time sized. Being=20 > dynamically sized is simply a specialization. > =20 Woops, useless topic then, sorry. =20 > > As for specializations in standard library algorithms... I don't much car= e=20 > for that. Sure, they can be *allowed*, but we shouldn't expect them. > > First, WikiSort seems to be able to work based solely on random-access=20 > iterators. So it's not clear why we would need specializations for that.= =20 > Also WikiSort appears to have an implicit requirement of `value_type` bei= ng=20 > default constructible (for the cache), which is not something that=20 > `stable_sort` requires. So it could not be a general replacement in the= =20 > library (though this requirement may merely be lazy programming, not a=20 > requirement of the algorithm). > > Second, if I have a need for the properties of WikiSort, it would be sill= y=20 > of me to just use `stable_sort` and hope that the implementation provides= =20 > this specializations. Yes, quality-of-implementation matters, but that is= =20 > simply expecting way too much from your implementation. The standard=20 > library is a general tool for general uses; if you need such specific=20 > algorithms, then you *need* specific algorithms. > > I wouldn't be against having a few of these newer sorting algorithms adde= d=20 > to the standard library. But they should be new functions which have the= =20 > explicit behavior of their particular algorithms. > =20 You're totally missing the point :p I was just looking for an example of an algorithm that splits a range into= =20 fixed-size range is known at compile-time and performs a well-known=20 operations (in this case sorting) on these fixed-size subranges to=20 highlight the fact that *allowing* standard algorithms to recognize a=20 fixed-size span or view might sometimes be useful. I'm not proposing to=20 standardize any specific sorting algorithm or anything, that would be=20 ~useless at best. Anyway, I only saw the standard view proposals and didn't notice that=20 gsl::span already provided the feature. I don't think I need anything more= =20 then. --=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/c225b7f4-8ae3-4d67-aed0-b5233e180bfe%40isocpp.or= g. ------=_Part_32_1038504208.1462726442591 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Le dimanche 8 mai 2016 15:40:38 UTC+2, Nicol Bolas= a =C3=A9crit=C2=A0:
The GSL `span` type already supports being compile-time sized. Bei= ng dynamically sized is simply a specialization.
=C2=A0
Woops, useless topic then, sorry.
=C2=A0

As for specia= lizations in standard library algorithms... I don't much care for that.= Sure, they can be allowed, but we shouldn't expect them.
First, WikiSort seems to be able to work based solely on random-access ite= rators. So it's not clear why we would need specializations for that. A= lso WikiSort appears to have an implicit requirement of `value_type` being = default constructible (for the cache), which is not something that `stable_= sort` requires. So it could not be a general replacement in the library (th= ough this requirement may merely be lazy programming, not a requirement of = the algorithm).

Second, if I have a need for the properties of WikiS= ort, it would be silly of me to just use `stable_sort` and hope that the im= plementation provides this specializations. Yes, quality-of-implementation = matters, but that is simply expecting way too much from your implementation= .. The standard library is a general tool for general uses; if you need such= specific algorithms, then you need specific algorithms.

I wo= uldn't be against having a few of these newer sorting algorithms added = to the standard library. But they should be new functions which have the ex= plicit behavior of their particular algorithms.
= =C2=A0
You're totally missing the point :p

I was just looking= for an example of an algorithm that splits a range into fixed-size range i= s known at compile-time and performs a well-known operations (in this case = sorting) on these fixed-size subranges to highlight the fact that allowi= ng standard algorithms to recognize a fixed-size span or view might som= etimes be useful. I'm not proposing to standardize any specific sorting= algorithm or anything, that would be ~useless at best.

Anyway, I on= ly saw the standard view proposals and didn't notice that gsl::span already provided = the feature. I don't think I need anything more then.

--
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/c225b7f4-8ae3-4d67-aed0-b5233e180bfe= %40isocpp.org.
------=_Part_32_1038504208.1462726442591-- ------=_Part_31_767047886.1462726442590-- .