Topic: Add qualifier flags or tags to std::sort to
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 22 May 2018 10:42:43 -0500
Raw View
--00000000000015bfb0056ccd47d0
Content-Type: text/plain; charset="UTF-8"
On Tue, May 22, 2018 at 10:31 AM <jrmarsha@mtu.edu> wrote:
> I generally prefer the approach of hiding complexity by default, but keep
> everything available. In this instance, it makes more intuitive sense to
> get an idea of what the user wants, then select the best algorithm for the
> given constraints. This would make sense over adding a unique function
> declaration for each combination of constraints a user would specify. It
> is a cleaner and more flexible interface for users and gives implementers
> significant flexibility in implementation.
>
Why would I want to make this choice at run time? When I sort data, they I
want any extra runtime overhead in the main loop, so at best this is only a
thin veneer for picking a particular algorithm. I'd rather just call an
appropriately named function to guarantee that I'm getting the sort
behavior I expect w/o unnecessary overhead.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMhPpc5%2BY379Gj2uo5S%2BXtG-t5O7EXvxU5WEWHSA5xRsw%40mail.gmail.com.
--00000000000015bfb0056ccd47d0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, May 22, 2018 at 10:31 AM <<a href=3D"mailto:jrm=
arsha@mtu.edu">jrmarsha@mtu.edu</a>> wrote:<br><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I generally prefer the ap=
proach of hiding complexity by default, but keep everything available.=C2=
=A0 In this instance, it makes more intuitive sense to get an idea of what =
the user wants, then select the best algorithm for the given constraints.=
=C2=A0 This would make sense over adding a unique function declaration for =
each combination of constraints a user would specify.=C2=A0 It is a cleaner=
and more flexible interface for users and gives implementers significant f=
lexibility in implementation.<br></div></blockquote><div><br></div><div>Why=
would I want to make this choice at run time?=C2=A0 When I sort data, they=
I want any extra runtime overhead in the main loop, so at best this is onl=
y a thin veneer for picking a particular algorithm.=C2=A0 I'd rather ju=
st call an appropriately named function to guarantee that I'm getting t=
he sort behavior I expect w/o unnecessary overhead. =C2=A0</div></div>-- <b=
r><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signat=
ure"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)"=
; Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div=
></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMhPpc5%2BY379Gj2uo5S%2BXtG-t=
5O7EXvxU5WEWHSA5xRsw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMh=
Ppc5%2BY379Gj2uo5S%2BXtG-t5O7EXvxU5WEWHSA5xRsw%40mail.gmail.com</a>.<br />
--00000000000015bfb0056ccd47d0--
.
Author: jrmarsha@mtu.edu
Date: Tue, 22 May 2018 09:26:14 -0700 (PDT)
Raw View
------=_Part_35837_1591244955.1527006375037
Content-Type: multipart/alternative;
boundary="----=_Part_35838_1863222894.1527006375037"
------=_Part_35838_1863222894.1527006375037
Content-Type: text/plain; charset="UTF-8"
Part of what I changed was from a runtime evaluation to a constexpr, so
that isn't a problem.
On Tuesday, May 22, 2018 at 11:43:22 AM UTC-4, Nevin ":-)" Liber wrote:
>
> On Tue, May 22, 2018 at 10:31 AM <jrma...@mtu.edu <javascript:>> wrote:
>
>> I generally prefer the approach of hiding complexity by default, but keep
>> everything available. In this instance, it makes more intuitive sense to
>> get an idea of what the user wants, then select the best algorithm for the
>> given constraints. This would make sense over adding a unique function
>> declaration for each combination of constraints a user would specify. It
>> is a cleaner and more flexible interface for users and gives implementers
>> significant flexibility in implementation.
>>
>
> Why would I want to make this choice at run time? When I sort data, they
> I want any extra runtime overhead in the main loop, so at best this is only
> a thin veneer for picking a particular algorithm. I'd rather just call an
> appropriately named function to guarantee that I'm getting the sort
> behavior I expect w/o unnecessary overhead.
> --
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>>
> +1-847-691-1404
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51017340-e001-4bd7-a3f4-ea40e1b2d7bb%40isocpp.org.
------=_Part_35838_1863222894.1527006375037
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Part of what I changed was from a runtime evaluation to a =
constexpr, so that isn't a problem.<br><br>On Tuesday, May 22, 2018 at =
11:43:22 AM UTC-4, Nevin ":-)" Liber wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr">On Tue, May 22, 2018 at 10:31 AM &l=
t;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"T-BtYN=
7hBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';r=
eturn true;" onclick=3D"this.href=3D'javascript:';return true;">jrm=
a...@mtu.edu</a>> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">I generally prefer the approach of hiding co=
mplexity by default, but keep everything available.=C2=A0 In this instance,=
it makes more intuitive sense to get an idea of what the user wants, then =
select the best algorithm for the given constraints.=C2=A0 This would make =
sense over adding a unique function declaration for each combination of con=
straints a user would specify.=C2=A0 It is a cleaner and more flexible inte=
rface for users and gives implementers significant flexibility in implement=
ation.<br></div></blockquote><div><br></div><div>Why would I want to make t=
his choice at run time?=C2=A0 When I sort data, they I want any extra runti=
me overhead in the main loop, so at best this is only a thin veneer for pic=
king a particular algorithm.=C2=A0 I'd rather just call an appropriatel=
y named function to guarantee that I'm getting the sort behavior I expe=
ct w/o unnecessary overhead. =C2=A0</div></div>-- <br><div dir=3D"ltr"><div=
dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=
=C2=A0 <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"T-BtYN7hBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">ne...@eviloverlord.com</a><wbr>> =C2=A0+1-847-691-1404</div=
></div></div></div></div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/51017340-e001-4bd7-a3f4-ea40e1b2d7bb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/51017340-e001-4bd7-a3f4-ea40e1b2d7bb=
%40isocpp.org</a>.<br />
------=_Part_35838_1863222894.1527006375037--
------=_Part_35837_1591244955.1527006375037--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Wed, 23 May 2018 07:48:37 +0200
Raw View
On Tue, May 22, 2018 at 09:26:14AM -0700, jrmarsha@mtu.edu wrote:
> Part of what I changed was from a runtime evaluation to a constexpr, so
> that isn't a problem.
I do not understand that comment but I too woul like to know the answer to
why
constexpr void sort (T begin, T end, int flags)
{
if (flags & 1)
sort_variant_1(begin, end);
else
sort_variant_2(begin, end);
}
is a better interface than exposing
sort_variant_1 and sort_variant_2
to the user.
The only thing your proposed interface allows is greater variation in between
various vendor implementations of sort and I do not see that as an advantage.
/MF
> On Tuesday, May 22, 2018 at 11:43:22 AM UTC-4, Nevin ":-)" Liber wrote:
> >
> > On Tue, May 22, 2018 at 10:31 AM <jrma...@mtu.edu <javascript:>> wrote:
> >
> >> I generally prefer the approach of hiding complexity by default, but keep
> >> everything available. In this instance, it makes more intuitive sense to
> >> get an idea of what the user wants, then select the best algorithm for the
> >> given constraints. This would make sense over adding a unique function
> >> declaration for each combination of constraints a user would specify. It
> >> is a cleaner and more flexible interface for users and gives implementers
> >> significant flexibility in implementation.
> >>
> >
> > Why would I want to make this choice at run time? When I sort data, they
> > I want any extra runtime overhead in the main loop, so at best this is only
> > a thin veneer for picking a particular algorithm. I'd rather just call an
> > appropriately named function to guarantee that I'm getting the sort
> > behavior I expect w/o unnecessary overhead.
> > --
> > Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>>
> > +1-847-691-1404
> >
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51017340-e001-4bd7-a3f4-ea40e1b2d7bb%40isocpp.org.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20180523054837.GA20640%40noemi.bahnhof.se.
.
Author: joshua.r.marshall.1991@gmail.com
Date: Wed, 23 May 2018 04:35:45 -0700 (PDT)
Raw View
------=_Part_41395_1225927864.1527075345602
Content-Type: multipart/alternative;
boundary="----=_Part_41396_1468394318.1527075345602"
------=_Part_41396_1468394318.1527075345602
Content-Type: text/plain; charset="UTF-8"
The idea is that users aren't interested in figuring out a particular sort
to use, but the execution traits of the sort. From what I know off the top
of my head, there are unique best choices for each of the following:
Suffix Array constant workspace linear time unparallelizable (SACA-K)
Suffix Array log workspace linear time unparallelizable (divsufsort)
stable sort constant workspace n log time unparallelizable (block sort)
stable sort constant workspace n log n time parallelizabe (I think a
different variant of block sort with more overhead)
stable linear workspace n log n time unparallelizable (timsort)
stable linear workspace n log n time parallelizable (a timsort variant I'm
working on)
unstable log workspace unparallelizable (introsort)
unstable log workspace parallelizable (introsort with greater overhead)
There is also Ska Sort, spreadsort, pdqsort, spinsort, flat_stable_sort,
block_indirect_sort, sample_sort, and parallel_stable_sort. All but the
first of these appear in Boost as they've found instances where users meed
to pick a different sort for a different application. (
https://www.boost.org/doc/libs/1_67_0/libs/sort/doc/html/index.html )
So rather than having so many unique functions, one function for each work
case, or sacrificing the general ability of stdlib to perform in a wide
variety of environments, extending the std::sort() interface to allow
characterization of execution properties seems most practical. Instead of
having to pick exactly how to sort, just pick the characteristics.
On Wednesday, May 23, 2018 at 1:48:41 AM UTC-4, Magnus Fromreide wrote:
>
> On Tue, May 22, 2018 at 09:26:14AM -0700, jrma...@mtu.edu <javascript:>
> wrote:
> > Part of what I changed was from a runtime evaluation to a constexpr, so
> > that isn't a problem.
>
> I do not understand that comment but I too woul like to know the answer to
> why
>
> constexpr void sort (T begin, T end, int flags)
> {
> if (flags & 1)
> sort_variant_1(begin, end);
> else
> sort_variant_2(begin, end);
> }
>
> is a better interface than exposing
>
> sort_variant_1 and sort_variant_2
>
> to the user.
>
> The only thing your proposed interface allows is greater variation in
> between
> various vendor implementations of sort and I do not see that as an
> advantage.
>
> /MF
>
> > On Tuesday, May 22, 2018 at 11:43:22 AM UTC-4, Nevin ":-)" Liber wrote:
> > >
> > > On Tue, May 22, 2018 at 10:31 AM <jrma...@mtu.edu <javascript:>>
> wrote:
> > >
> > >> I generally prefer the approach of hiding complexity by default, but
> keep
> > >> everything available. In this instance, it makes more intuitive
> sense to
> > >> get an idea of what the user wants, then select the best algorithm
> for the
> > >> given constraints. This would make sense over adding a unique
> function
> > >> declaration for each combination of constraints a user would specify.
> It
> > >> is a cleaner and more flexible interface for users and gives
> implementers
> > >> significant flexibility in implementation.
> > >>
> > >
> > > Why would I want to make this choice at run time? When I sort data,
> they
> > > I want any extra runtime overhead in the main loop, so at best this is
> only
> > > a thin veneer for picking a particular algorithm. I'd rather just
> call an
> > > appropriately named function to guarantee that I'm getting the sort
> > > behavior I expect w/o unnecessary overhead.
> > > --
> > > Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>>
> > > +1-847-691-1404
> > >
> >
> > --
> > 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-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>
> > To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/51017340-e001-4bd7-a3f4-ea40e1b2d7bb%40isocpp.org.
>
>
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f67009af-54e3-46c5-a98a-fee1cfabab36%40isocpp.org.
------=_Part_41396_1468394318.1527075345602
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The idea is that users aren't interested in figur=
ing out a particular sort to use, but the execution traits of the sort.=C2=
=A0 From what I know off the top of my head, there are unique best choices =
for each of the following:</div><div>Suffix Array constant workspace linear=
time unparallelizable (SACA-K)<br></div><div>Suffix Array log workspace li=
near time unparallelizable (divsufsort)<br></div><div>stable sort constant =
workspace n log time unparallelizable (block sort)<br>stable sort constant =
workspace n log n time parallelizabe (I think a different variant of block =
sort with more overhead)<br>stable linear workspace n log n time unparallel=
izable (timsort)<br>stable linear workspace n log n time parallelizable (a =
timsort variant I'm working on)<br>unstable log workspace unparalleliza=
ble (introsort)<br>unstable log workspace parallelizable (introsort with gr=
eater overhead)</div><div><font size=3D"2"><span style=3D"font-family: aria=
l, sans-serif;"><br></span></font></div><div><font size=3D"2"><span style=
=3D"font-family: arial, sans-serif;">There is also Ska Sort,</span></font><=
font size=3D"2"><span style=3D"font-family: arial, sans-serif;"> spreadsort=
, pdqsort, spinsort, flat_stable_sort, block_indirect_sort, sample_sort, an=
d parallel_stable_sort.=C2=A0 All but the first of these appear in Boost as=
they've found instances where users meed to pick a different sort for =
a different application. ( https://www.boost.org/doc/libs/1_67_0/libs/sort/=
doc/html/index.html )</span></font></div><div><font size=3D"2"><span style=
=3D"font-family: arial, sans-serif;"><br></span></font></div><div><font siz=
e=3D"2"><span style=3D"font-family: arial, sans-serif;">So rather than havi=
ng so many unique functions, one function for each work case, or sacrificin=
g the general ability of stdlib to perform in a wide variety of environment=
s, extending the std::sort() interface to allow characterization of executi=
on properties seems most practical.=C2=A0 Instead of having to pick exactly=
how to sort, just pick the characteristics.<br></span></font></div><div><b=
r></div><br>On Wednesday, May 23, 2018 at 1:48:41 AM UTC-4, Magnus Fromreid=
e wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, May 22, 2018 a=
t 09:26:14AM -0700, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"evRb_C7pBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">jrma...@mtu.edu</a> wrote:
<br>> Part of what I changed was from a runtime evaluation to a constexp=
r, so=20
<br>> that isn't a problem.
<br>
<br>I do not understand that comment but I too woul like to know the answer=
to
<br>why
<br>
<br>constexpr void sort (T begin, T end, int flags)
<br>{
<br>=C2=A0 if (flags & 1)
<br>=C2=A0 =C2=A0 sort_variant_1(begin, end);
<br>=C2=A0 else
<br>=C2=A0 =C2=A0 sort_variant_2(begin, end);
<br>}
<br>
<br>is a better interface than exposing
<br>
<br>sort_variant_1 and sort_variant_2
<br>
<br>to the user.
<br>
<br>The only thing your proposed interface allows is greater variation in b=
etween
<br>various vendor implementations of sort and I do not see that as an adva=
ntage.
<br>
<br>/MF
<br>
<br>> On Tuesday, May 22, 2018 at 11:43:22 AM UTC-4, Nevin ":-)&quo=
t; Liber wrote:
<br>> >
<br>> > On Tue, May 22, 2018 at 10:31 AM <<a>jrma...@mtu.edu</a> &=
lt;javascript:>> wrote:
<br>> >
<br>> >> I generally prefer the approach of hiding complexity by d=
efault, but keep=20
<br>> >> everything available. =C2=A0In this instance, it makes mo=
re intuitive sense to=20
<br>> >> get an idea of what the user wants, then select the best =
algorithm for the=20
<br>> >> given constraints. =C2=A0This would make sense over addin=
g a unique function=20
<br>> >> declaration for each combination of constraints a user wo=
uld specify. =C2=A0It=20
<br>> >> is a cleaner and more flexible interface for users and gi=
ves implementers=20
<br>> >> significant flexibility in implementation.
<br>> >>
<br>> >
<br>> > Why would I want to make this choice at run time? =C2=A0When =
I sort data, they=20
<br>> > I want any extra runtime overhead in the main loop, so at bes=
t this is only=20
<br>> > a thin veneer for picking a particular algorithm. =C2=A0I'=
;d rather just call an=20
<br>> > appropriately named function to guarantee that I'm gettin=
g the sort=20
<br>> > behavior I expect w/o unnecessary overhead. =C2=A0
<br>> > --=20
<br>> > =C2=A0Nevin ":-)" Liber =C2=A0<mailto:<a>ne...@e=
viloverlord.<wbr>com</a> <javascript:>>=20
<br>> > =C2=A0+1-847-691-1404
<br>> >
<br>>=20
<br>> --=20
<br>> You received this message because you are subscribed to the Google=
Groups "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"evRb_C7pBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">std-proposal...@<wbr>isocpp.org</a>.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"evRb_C7pBAAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hr=
ef=3D'javascript:';return true;">std-pr...@isocpp.org</a>.
<br>> To view this discussion on the web visit <a href=3D"https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/51017340-e001-4bd7-a3f4-ea40=
e1b2d7bb%40isocpp.org" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-proposals=
/51017340-e001-4bd7-a3f4-ea40e1b2d7bb%40isocpp.org';return true;" oncli=
ck=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/51017340-e001-4bd7-a3f4-ea40e1b2d7bb%40isocpp.org';return true=
;">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/5=
1017340-e001-4bd7-<wbr>a3f4-ea40e1b2d7bb%40isocpp.org</a><wbr>.
<br>
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f67009af-54e3-46c5-a98a-fee1cfabab36%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f67009af-54e3-46c5-a98a-fee1cfabab36=
%40isocpp.org</a>.<br />
------=_Part_41396_1468394318.1527075345602--
------=_Part_41395_1225927864.1527075345602--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Wed, 23 May 2018 14:31:04 +0100
Raw View
--00000000000079b7b7056cdf8cd7
Content-Type: text/plain; charset="UTF-8"
I'm not convinced that extending the sort interface in such a manner is
appropriate. If anything, a new parameter (or template argument) should
define exactly which approach to use (when you say users "aren't
interested" in choosing the right method, this is far from a general
statement, and I have doubts that all approaches can be uniquely described
with a set of meaningful flags in this way without significant redundancy).
Something this fundamental shouldn't open itself up to frequent changes as
different approaches come along.
One idea is as follows. First, let sort accept an optional template
argument, e.g. a struct or function which handles the sorting logic itself
(this allows users to create their own sorting approach, or otherwise
choose a specific approach manually). Then, create your own constexpr
library to determine an appropriate choice of S, and use the return type to
plug into sort.
This provides considerably more flexibility IMO.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPd%3DzTEiJ8xKLgE1g64z%2B1Hk%3DCDwGoZy3G1QZ7PvA-Xnw%40mail.gmail.com.
--00000000000079b7b7056cdf8cd7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">I'm not convinced that extending the sort interface i=
n such a manner is appropriate. If anything, a new parameter (or template a=
rgument) should define exactly which approach to use (when you say users &q=
uot;aren't interested" in choosing the right method, this is far f=
rom a general statement, and I have doubts that all approaches can be uniqu=
ely described with a set of meaningful flags in this way without significan=
t redundancy). Something this fundamental shouldn't open itself up to f=
requent changes as different approaches come along.<div dir=3D"auto"><br></=
div><div dir=3D"auto">One idea is as follows. First, let sort accept an opt=
ional template argument, e.g. a struct or function which handles the sortin=
g logic itself (this allows users to create their own sorting approach, or =
otherwise choose a specific approach manually). Then, create your own const=
expr library to determine an appropriate choice of S, and use the return ty=
pe to plug into sort.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Th=
is provides considerably more flexibility IMO.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPd%3DzTEiJ8xKLgE1g64z%2B1Hk%=
3DCDwGoZy3G1QZ7PvA-Xnw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CC=
Pd%3DzTEiJ8xKLgE1g64z%2B1Hk%3DCDwGoZy3G1QZ7PvA-Xnw%40mail.gmail.com</a>.<br=
/>
--00000000000079b7b7056cdf8cd7--
.
Author: jrmarsha@mtu.edu
Date: Wed, 23 May 2018 06:36:18 -0700 (PDT)
Raw View
------=_Part_41249_1838690899.1527082578272
Content-Type: multipart/alternative;
boundary="----=_Part_41250_301228892.1527082578272"
------=_Part_41250_301228892.1527082578272
Content-Type: text/plain; charset="UTF-8"
That could be a better approach. Could you give some kind of boiler plate
example?
On Wednesday, May 23, 2018 at 9:31:19 AM UTC-4, Jake Arkinstall wrote:
>
> I'm not convinced that extending the sort interface in such a manner is
> appropriate. If anything, a new parameter (or template argument) should
> define exactly which approach to use (when you say users "aren't
> interested" in choosing the right method, this is far from a general
> statement, and I have doubts that all approaches can be uniquely described
> with a set of meaningful flags in this way without significant redundancy).
> Something this fundamental shouldn't open itself up to frequent changes as
> different approaches come along.
>
> One idea is as follows. First, let sort accept an optional template
> argument, e.g. a struct or function which handles the sorting logic itself
> (this allows users to create their own sorting approach, or otherwise
> choose a specific approach manually). Then, create your own constexpr
> library to determine an appropriate choice of S, and use the return type to
> plug into sort.
>
> This provides considerably more flexibility IMO.
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e3d2b39b-3fd4-453c-b77b-312d76959c29%40isocpp.org.
------=_Part_41250_301228892.1527082578272
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">That could be a better approach.=C2=A0 Could you give some=
kind of boiler plate example?<br><br>On Wednesday, May 23, 2018 at 9:31:19=
AM UTC-4, Jake Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"auto">I'm not convinced that extending the sort interfac=
e in such a manner is appropriate. If anything, a new parameter (or templat=
e argument) should define exactly which approach to use (when you say users=
"aren't interested" in choosing the right method, this is fa=
r from a general statement, and I have doubts that all approaches can be un=
iquely described with a set of meaningful flags in this way without signifi=
cant redundancy). Something this fundamental shouldn't open itself up t=
o frequent changes as different approaches come along.<div dir=3D"auto"><br=
></div><div dir=3D"auto">One idea is as follows. First, let sort accept an =
optional template argument, e.g. a struct or function which handles the sor=
ting logic itself (this allows users to create their own sorting approach, =
or otherwise choose a specific approach manually). Then, create your own co=
nstexpr library to determine an appropriate choice of S, and use the return=
type to plug into sort.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>This provides considerably more flexibility IMO.</div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e3d2b39b-3fd4-453c-b77b-312d76959c29%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e3d2b39b-3fd4-453c-b77b-312d76959c29=
%40isocpp.org</a>.<br />
------=_Part_41250_301228892.1527082578272--
------=_Part_41249_1838690899.1527082578272--
.