Topic: Thoughts about P0100R0
Author: Morwenn <morwenn29@gmail.com>
Date: Thu, 5 Nov 2015 14:17:46 -0800 (PST)
Raw View
------=_Part_993_370600272.1446761866902
Content-Type: multipart/alternative;
boundary="----=_Part_994_2086772886.1446761866902"
------=_Part_994_2086772886.1446761866902
Content-Type: text/plain; charset=UTF-8
Among other things, P0100R0 proposes to add the following strongly-typed
enumerations to the standard library:
enum class partial_ordering { less, unordered, greater };
enum class weak_ordering { less, equivalent, greater };
enum class total_ordering { less, equal, greater };
I think that the idea is great but that these enumerations would benefit
from an explicit conversion to int where the three values would be equal to
-1, 0 and 1.
It would allow to have strong typing by default but the ability to
interface with old APIs that rely on the values -1, 0 and 1. While some of
this old APIs only check the values, other ones do some arithmetic with the
returned values (I have seen multiplications, but also additions in the
wild) and changing every API would be a bit bothersome.
Basically, I propose to change the enumerations as follows:
enum class partial_ordering: int { less = -1, unordered = 0, greater = 1 };
enum class weak_ordering: int { less = -1, equivalent = 0, greater = 1 };
enum class total_ordering: int { less = -1, equal = 0, greater = 1 };
Any opinion about that?
Morwenn.
--
---
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_994_2086772886.1446761866902
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Among other things, P0100R0 proposes to add the following =
strongly-typed enumerations to the standard library:<br><font size=3D"2"><s=
pan style=3D"font-family: courier new,monospace;"><br></span></font><pre><f=
ont size=3D"2"><span style=3D"font-family: courier new,monospace;"><code>en=
um class partial_ordering { less, unordered, greater };
enum class weak_ordering { less, equivalent, greater };
enum class total_ordering { less, equal, greater };</code></span></font></p=
re><br>I think that the idea is great but that these enumerations would ben=
efit from an explicit conversion to int where the three values would be equ=
al to -1, 0 and 1.<br>It would allow to have strong typing by default but t=
he ability to interface with old APIs that rely on the values -1, 0 and 1. =
While some of this old APIs only check the values, other ones do some arith=
metic with the returned values (I have seen multiplications, but also addit=
ions in the wild) and changing every API would be a bit bothersome.<br><br>=
Basically, I propose to change the enumerations as follows:<br><br><pre><fo=
nt size=3D"2"><span style=3D"font-family: courier new,monospace;"><code>enu=
m class partial_ordering: int { less =3D -1, unordered =3D 0, greater =3D 1=
};
enum class weak_ordering: int { less =3D -1, equivalent =3D 0, greater =3D =
1 };
enum class total_ordering: int { less =3D -1, equal =3D 0, greater =3D 1 };=
</code></span></font></pre><font size=3D"2"><span style=3D"font-family: cou=
rier new,monospace;"></span></font><br>Any opinion about that?<br><br>Morwe=
nn.<br><br></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_994_2086772886.1446761866902--
------=_Part_993_370600272.1446761866902--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 5 Nov 2015 16:00:49 -0800 (PST)
Raw View
------=_Part_1878_1428540084.1446768050014
Content-Type: multipart/alternative;
boundary="----=_Part_1879_1721758199.1446768050015"
------=_Part_1879_1721758199.1446768050015
Content-Type: text/plain; charset=UTF-8
On Thursday, November 5, 2015 at 5:17:47 PM UTC-5, Morwenn wrote:
>
> Among other things, P0100R0 proposes to add the following strongly-typed
> enumerations to the standard library:
>
> enum class partial_ordering { less, unordered, greater };
> enum class weak_ordering { less, equivalent, greater };
> enum class total_ordering { less, equal, greater };
>
>
> I think that the idea is great but that these enumerations would benefit
> from an explicit conversion to int where the three values would be equal to
> -1, 0 and 1.
> It would allow to have strong typing by default but the ability to
> interface with old APIs that rely on the values -1, 0 and 1. While some of
> this old APIs only check the values, other ones do some arithmetic with the
> returned values (I have seen multiplications, but also additions in the
> wild) and changing every API would be a bit bothersome.
>
> Basically, I propose to change the enumerations as follows:
>
> enum class partial_ordering: int { less = -1, unordered = 0, greater = 1 };
> enum class weak_ordering: int { less = -1, equivalent = 0, greater = 1 };
> enum class total_ordering: int { less = -1, equal = 0, greater = 1 };
>
>
> Any opinion about that?
>
My concern is that idiots will believe that this will work:
strcmp(...) == static_cast<int>(weak_ordering::less)
--
---
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_1879_1721758199.1446768050015
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, November 5, 2015 at 5:17:47 PM UTC-5, Morwenn wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Among other things, P01=
00R0 proposes to add the following strongly-typed enumerations to the stand=
ard library:<br><font size=3D"2"><span style=3D"font-family:courier new,mon=
ospace"><br></span></font><pre><font size=3D"2"><span style=3D"font-family:=
courier new,monospace"><code>enum class partial_ordering { less, unordered,=
greater };
enum class weak_ordering { less, equivalent, greater };
enum class total_ordering { less, equal, greater };</code></span></font></p=
re><br>I think that the idea is great but that these enumerations would ben=
efit from an explicit conversion to int where the three values would be equ=
al to -1, 0 and 1.<br>It would allow to have strong typing by default but t=
he ability to interface with old APIs that rely on the values -1, 0 and 1. =
While some of this old APIs only check the values, other ones do some arith=
metic with the returned values (I have seen multiplications, but also addit=
ions in the wild) and changing every API would be a bit bothersome.<br><br>=
Basically, I propose to change the enumerations as follows:<br><br><pre><fo=
nt size=3D"2"><span style=3D"font-family:courier new,monospace"><code>enum =
class partial_ordering: int { less =3D -1, unordered =3D 0, greater =3D 1 }=
;
enum class weak_ordering: int { less =3D -1, equivalent =3D 0, greater =3D =
1 };
enum class total_ordering: int { less =3D -1, equal =3D 0, greater =3D 1 };=
</code></span></font></pre><font size=3D"2"><span style=3D"font-family:cour=
ier new,monospace"></span></font><br>Any opinion about that?<br></div></blo=
ckquote><div dir=3D"ltr"><br>My concern is that idiots will believe that th=
is will work:<br><br>strcmp(...) =3D=3D static_cast<int>(weak_orderin=
g::less)<br><br><br></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1879_1721758199.1446768050015--
------=_Part_1878_1428540084.1446768050014--
.
Author: snk_kid <korcan.hussein@googlemail.com>
Date: Fri, 6 Nov 2015 00:53:40 -0800 (PST)
Raw View
------=_Part_1571_543864290.1446800020664
Content-Type: multipart/alternative;
boundary="----=_Part_1572_1069059296.1446800020665"
------=_Part_1572_1069059296.1446800020665
Content-Type: text/plain; charset=UTF-8
"idiots"? seriously? common man.
On Friday, November 6, 2015 at 12:00:50 AM UTC, Nicol Bolas wrote:
>
> On Thursday, November 5, 2015 at 5:17:47 PM UTC-5, Morwenn wrote:
>>
>> Among other things, P0100R0 proposes to add the following strongly-typed
>> enumerations to the standard library:
>>
>> enum class partial_ordering { less, unordered, greater };
>> enum class weak_ordering { less, equivalent, greater };
>> enum class total_ordering { less, equal, greater };
>>
>>
>> I think that the idea is great but that these enumerations would benefit
>> from an explicit conversion to int where the three values would be equal to
>> -1, 0 and 1.
>> It would allow to have strong typing by default but the ability to
>> interface with old APIs that rely on the values -1, 0 and 1. While some of
>> this old APIs only check the values, other ones do some arithmetic with the
>> returned values (I have seen multiplications, but also additions in the
>> wild) and changing every API would be a bit bothersome.
>>
>> Basically, I propose to change the enumerations as follows:
>>
>> enum class partial_ordering: int { less = -1, unordered = 0, greater = 1 };
>> enum class weak_ordering: int { less = -1, equivalent = 0, greater = 1 };
>> enum class total_ordering: int { less = -1, equal = 0, greater = 1 };
>>
>>
>> Any opinion about that?
>>
>
> My concern is that idiots will believe that this will work:
>
> strcmp(...) == static_cast<int>(weak_ordering::less)
>
>
>
--
---
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_1572_1069059296.1446800020665
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">"idiots"? seriously? common man.<br><br>On Frida=
y, November 6, 2015 at 12:00:50 AM UTC, Nicol Bolas wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">On Thursday, November 5, 2015 at 5:17:47 PM UTC=
-5, Morwenn wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
Among other things, P0100R0 proposes to add the following strongly-typed en=
umerations to the standard library:<br><font size=3D"2"><span style=3D"font=
-family:courier new,monospace"><br></span></font><pre><font size=3D"2"><spa=
n style=3D"font-family:courier new,monospace"><code>enum class partial_orde=
ring { less, unordered, greater };
enum class weak_ordering { less, equivalent, greater };
enum class total_ordering { less, equal, greater };</code></span></font></p=
re><br>I think that the idea is great but that these enumerations would ben=
efit from an explicit conversion to int where the three values would be equ=
al to -1, 0 and 1.<br>It would allow to have strong typing by default but t=
he ability to interface with old APIs that rely on the values -1, 0 and 1. =
While some of this old APIs only check the values, other ones do some arith=
metic with the returned values (I have seen multiplications, but also addit=
ions in the wild) and changing every API would be a bit bothersome.<br><br>=
Basically, I propose to change the enumerations as follows:<br><br><pre><fo=
nt size=3D"2"><span style=3D"font-family:courier new,monospace"><code>enum =
class partial_ordering: int { less =3D -1, unordered =3D 0, greater =3D 1 }=
;
enum class weak_ordering: int { less =3D -1, equivalent =3D 0, greater =3D =
1 };
enum class total_ordering: int { less =3D -1, equal =3D 0, greater =3D 1 };=
</code></span></font></pre><font size=3D"2"><span style=3D"font-family:cour=
ier new,monospace"></span></font><br>Any opinion about that?<br></div></blo=
ckquote><div dir=3D"ltr"><br>My concern is that idiots will believe that th=
is will work:<br><br>strcmp(...) =3D=3D static_cast<int>(weak_<wbr>or=
dering::less)<br><br><br></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1572_1069059296.1446800020665--
------=_Part_1571_543864290.1446800020664--
.
Author: Morwenn <morwenn29@gmail.com>
Date: Fri, 6 Nov 2015 03:14:37 -0800 (PST)
Raw View
------=_Part_269_1909922359.1446808477443
Content-Type: multipart/alternative;
boundary="----=_Part_270_1065993909.1446808477443"
------=_Part_270_1065993909.1446808477443
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le vendredi 6 novembre 2015 01:00:50 UTC+1, Nicol Bolas a =C3=A9crit :
>
> My concern is that idiots will believe that this will work:
>
> strcmp(...) =3D=3D static_cast<int>(weak_ordering::less)
>
> Well, we can't always be dragged down by people who go all their way to=
=20
misuse things.
I don't think the number of people who will know and care about=20
weak_ordering and friends will be *that* high, let alone the number of=20
people who will know about it and still manage to misuse it like that.
I mean, if one tries to write things like that, it means that they are also=
=20
still using strcmp to write things (I don't think a line like that would=20
appear while coding against a C API), so...
I understand the risk, but I don't think it's high actually.
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_270_1065993909.1446808477443
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le vendredi 6 novembre 2015 01:00:50 UTC+1, Nicol Bolas a =
=C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">My concern is=
that idiots will believe that this will work:<br><div dir=3D"ltr"><br>strc=
mp(...) =3D=3D static_cast<int>(weak_<wbr>ordering::less)<br><br></di=
v></blockquote><div>Well, we can't always be dragged down by people who=
go all their way to misuse things.<br>I don't think the number of peop=
le who will know and care about <span style=3D"font-family: courier new,mon=
ospace;">weak_ordering</span> and friends will be *that* high, let alone th=
e number of people who will know about it and still manage to misuse it lik=
e that.<br>I mean, if one tries to write things like that, it means that th=
ey are also still using strcmp to write things (I don't think a line li=
ke that would appear while coding against a C API), so...<br><br>I understa=
nd the risk, but I don't think it's high actually.<br></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_270_1065993909.1446808477443--
------=_Part_269_1909922359.1446808477443--
.
Author: Morwenn <morwenn29@gmail.com>
Date: Wed, 16 Mar 2016 12:17:06 -0700 (PDT)
Raw View
------=_Part_19_1267087225.1458155826458
Content-Type: multipart/alternative;
boundary="----=_Part_20_2113925108.1458155826458"
------=_Part_20_2113925108.1458155826458
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I started to implement P0100R1=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0100r1.html> in a=
=20
library of mine. Some parts are really smooth, but some other parts don't=
=20
fill *that* smooth; here is what I could notice while implementing the=20
proposal:
- Making customization points with the proposed functions seems to be=20
the way to go. That way it only "reserves" one name for every feature in=
=20
the standard library, and the customization points can still perform ADL=
to=20
find user-defined functions, and yet they can still be passed to functio=
ns,=20
which is a good selling point for since they are meant to be passed to=
=20
algorithms.
- Handling the trinary comparators in algorithms is a bit tedious:=20
algorithms are supposed to accept either binary predicates (at least for=
=20
backwards compatibility, sometimes for convenience) or trinary comparato=
rs.=20
However, we need to discriminate between both: predicates return a resul=
t=20
convertible to bool, but what about trinary comparators? They can *at=20
least* return a partial_ordering, a weak_ordering or a total_ordering,=
=20
but can there be extra user-defined ordering returned by user-defined=20
trinary comparators too? If so, how to generically disciminate them from=
=20
predicates?
- Moreover, in order to implement algorithms only once means that every=
=20
ordering value should be explicitly convertible to a common type and to=
=20
same values at some point (I did that with -1, 0 and 1) since the names =
of=20
the enumerators are not the same for the different orderings. One could =
say=20
that it doesn't matter since a specific algorithm should only work with =
one=20
specific ordering, but this isn't true: using std::sort with either=20
weak_order or total_order will yield either an inconsistent sort or a=20
consistent sort; both might be desirable depending on the application.
- Apparently total_less, total_equal, total_greater... exist for=20
convenience but also for optimizations purpose. If so, should we also ha=
ve=20
total_less_or_equal, total_greater_or_equal and friends to take=20
advantage of existing <=3D and >=3D operators when possible?
- Algorithms are only able to fully take advantage of orders when they=
=20
know both the trinary comparator and the corresponding (possibly optimiz=
ed)=20
binary predicates. For example, if we need to perform a simple less=20
operation on integers several times in a raw, having total_order only=20
means that we will end up performing twice as many comparisons as if we=
=20
used total_less instead. There needs to be a mechanism (or at least=20
guarantees) so that algorithms can take advantage of both a trinary=20
comparator and the corresponding predicates at the same time to avoid=20
performance losses.
- The enumerator values -1, 0 and 1 that I proposed are handy for=20
several purposes: having common values for equivalent enumerators (albei=
t=20
with different names) in different orderings, but they also allow to=20
implement a reverse function to reverse an ordering with a simple hidden=
=20
subtraction. Also it still makes it easy to forward values to legacy=20
functions with an explicit static_cast to int.
Basically, the proposal is full of good ideas, but I believe that the=20
points mentioned above should be addressed. Any additional thoughts? I=20
believe that my points are accurate, but I may miss some things; if so,=20
don't hesitate to contribute.
Also I never managed to actually get any answer from Lawrence Crowl; I=20
would be glad if someone could make sure that the points are thoroughly=20
discussed too when the proposal is discussed again for inclusion into the=
=20
standard. If I can't manage to contact anyone, I might end up wirting a=20
proposal to address those points :/
Le jeudi 5 novembre 2015 23:17:47 UTC+1, Morwenn a =C3=A9crit :
>
> Among other things, P0100R0 proposes to add the following strongly-typed=
=20
> enumerations to the standard library:
>
> enum class partial_ordering { less, unordered, greater };
> enum class weak_ordering { less, equivalent, greater };
> enum class total_ordering { less, equal, greater };
>
>
> I think that the idea is great but that these enumerations would benefit=
=20
> from an explicit conversion to int where the three values would be equal =
to=20
> -1, 0 and 1.
> It would allow to have strong typing by default but the ability to=20
> interface with old APIs that rely on the values -1, 0 and 1. While some o=
f=20
> this old APIs only check the values, other ones do some arithmetic with t=
he=20
> returned values (I have seen multiplications, but also additions in the=
=20
> wild) and changing every API would be a bit bothersome.
>
> Basically, I propose to change the enumerations as follows:
>
> enum class partial_ordering: int { less =3D -1, unordered =3D 0, greater =
=3D 1 };
> enum class weak_ordering: int { less =3D -1, equivalent =3D 0, greater =
=3D 1 };
> enum class total_ordering: int { less =3D -1, equal =3D 0, greater =3D 1 =
};
>
>
> Any opinion about that?
>
> Morwenn.
>
>
--=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/2e1fdff0-c666-4337-be82-788602c98ea8%40isocpp.or=
g.
------=_Part_20_2113925108.1458155826458
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I started to implement <a href=3D"http://www.open-std.org/=
jtc1/sc22/wg21/docs/papers/2015/p0100r1.html">P0100R1</a> in a library of m=
ine. Some parts are really smooth, but some other parts don't fill <i>t=
hat</i> smooth; here is what I could notice while implementing the proposal=
:<br><ul><li>Making customization points with the proposed functions seems =
to be the way to go. That way it only "reserves" one name for eve=
ry feature in the standard library, and the customization points can still =
perform ADL to find user-defined functions, and yet they can still be passe=
d to functions, which is a good selling point for since they are meant to b=
e passed to algorithms.</li><li>Handling the trinary comparators in algorit=
hms is a bit tedious: algorithms are supposed to accept either binary predi=
cates (at least for backwards compatibility, sometimes for convenience) or =
trinary comparators. However, we need to discriminate between both: predica=
tes return a result convertible to <span style=3D"font-family: courier new,=
monospace;">bool</span>, but what about trinary comparators? They can <i>at=
least</i> return a <span style=3D"font-family: courier new,monospace;">par=
tial_ordering</span>, a <span style=3D"font-family: courier new,monospace;"=
>weak_ordering</span> or a <span style=3D"font-family: courier new,monospac=
e;">total_ordering</span>, but can there be extra user-defined ordering ret=
urned by user-defined trinary comparators too? If so, how to generically di=
sciminate them from predicates?</li><li>Moreover, in order to implement alg=
orithms only once means that every ordering value should be explicitly conv=
ertible to a common type and to same values at some point (I did that with =
-1, 0 and 1) since the names of the enumerators are not the same for the di=
fferent orderings. One could say that it doesn't matter since a specifi=
c algorithm should only work with one specific ordering, but this isn't=
true: using <span style=3D"font-family: courier new,monospace;">std::sort<=
/span> with either <span style=3D"font-family: courier new,monospace;">weak=
_order</span> or <span style=3D"font-family: courier new,monospace;">total_=
order</span> will yield either an inconsistent sort or a consistent sort; b=
oth might be desirable depending on the application.</li><li>Apparently <sp=
an style=3D"font-family: courier new,monospace;">total_less</span>,<span st=
yle=3D"font-family: courier new,monospace;"> total_equal</span>, <span styl=
e=3D"font-family: courier new,monospace;">total_greater</span>... exist for=
convenience but also for optimizations purpose. If so, should we also have=
<span style=3D"font-family: courier new,monospace;">total_less_or_equal</s=
pan>, <span style=3D"font-family: courier new,monospace;">total_greater_or_=
equal</span> and friends to take advantage of existing <span style=3D"font-=
family: courier new,monospace;"><=3D</span> and <span style=3D"font-fami=
ly: courier new,monospace;">>=3D</span> operators when possible?</li><li=
>Algorithms are only able to fully take advantage of orders when they know =
both the trinary comparator and the corresponding (possibly optimized) bina=
ry predicates. For example, if we need to perform a simple <span style=3D"f=
ont-family: courier new,monospace;">less</span> operation on integers sever=
al times in a raw, having <span style=3D"font-family: courier new,monospace=
;">total_order</span> only means that we will end up performing twice as ma=
ny comparisons as if we used <span style=3D"font-family: courier new,monosp=
ace;">total_less</span> instead. There needs to be a mechanism (or at least=
guarantees) so that algorithms can take advantage of both a trinary compar=
ator and the corresponding predicates at the same time to avoid performance=
losses.<br></li><li>The enumerator values -1, 0 and 1 that I proposed are =
handy for several purposes: having common values for equivalent enumerators=
(albeit with different names) in different orderings, but they also allow =
to implement a <span style=3D"font-family: courier new,monospace;">reverse<=
/span> function to reverse an ordering with a simple hidden subtraction. Al=
so it still makes it easy to forward values to legacy functions with an exp=
licit <span style=3D"font-family: courier new,monospace;">static_cast</span=
> to <span style=3D"font-family: courier new,monospace;">int</span>.</li></=
ul>Basically, the proposal is full of good ideas, but I believe that the po=
ints mentioned above should be addressed. Any additional thoughts? I believ=
e that my points are accurate, but I may miss some things; if so, don't=
hesitate to contribute.<br><br>Also I never managed to actually get any an=
swer from Lawrence Crowl; I would be glad if someone could make sure that t=
he points are thoroughly discussed too when the proposal is discussed again=
for inclusion into the standard. If I can't manage to contact anyone, =
I might end up wirting a proposal to address those points :/<br><br>Le jeud=
i 5 novembre 2015 23:17:47 UTC+1, Morwenn a =C3=A9crit=C2=A0:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Among other things, P0100R0=
proposes to add the following strongly-typed enumerations to the standard =
library:<br><font size=3D"2"><span style=3D"font-family:courier new,monospa=
ce"><br></span></font><pre><font size=3D"2"><span style=3D"font-family:cour=
ier new,monospace"><code>enum class partial_ordering { less, unordered, gre=
ater };
enum class weak_ordering { less, equivalent, greater };
enum class total_ordering { less, equal, greater };</code></span></font></p=
re><br>I think that the idea is great but that these enumerations would ben=
efit from an explicit conversion to int where the three values would be equ=
al to -1, 0 and 1.<br>It would allow to have strong typing by default but t=
he ability to interface with old APIs that rely on the values -1, 0 and 1. =
While some of this old APIs only check the values, other ones do some arith=
metic with the returned values (I have seen multiplications, but also addit=
ions in the wild) and changing every API would be a bit bothersome.<br><br>=
Basically, I propose to change the enumerations as follows:<br><br><pre><fo=
nt size=3D"2"><span style=3D"font-family:courier new,monospace"><code>enum =
class partial_ordering: int { less =3D -1, unordered =3D 0, greater =3D 1 }=
;
enum class weak_ordering: int { less =3D -1, equivalent =3D 0, greater =3D =
1 };
enum class total_ordering: int { less =3D -1, equal =3D 0, greater =3D 1 };=
</code></span></font></pre><font size=3D"2"><span style=3D"font-family:cour=
ier new,monospace"></span></font><br>Any opinion about that?<br><br>Morwenn=
..<br><br></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/2e1fdff0-c666-4337-be82-788602c98ea8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2e1fdff0-c666-4337-be82-788602c98ea8=
%40isocpp.org</a>.<br />
------=_Part_20_2113925108.1458155826458--
------=_Part_19_1267087225.1458155826458--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 17 Mar 2016 19:19:56 +0100
Raw View
This is a multi-part message in MIME format.
--------------050800080105090205030003
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 16/03/2016 20:17, Morwenn a =C3=A9crit :
> I started to implement P0100R1=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0100r1.html>=20
> in a library of mine. Some parts are really smooth, but some other=20
> parts don't fill /that/ smooth; here is what I could notice while=20
> implementing the proposal:
Hi, I have just take a look at the paper so there should be a lot of=20
things I don't understand yet. The purpose on this replay is to=20
understand it better as I believe that I have not understood it as I=20
don't understand the problems you are referring to. It would help if we=20
can take a look at your implementation.
> * Making customization points with the proposed functions seems to
> be the way to go. That way it only "reserves" one name for every
> feature in the standard library, and the customization points can
> still perform ADL to find user-defined functions, and yet they can
> still be passed to functions, which is a good selling point for
> since they are meant to be passed to algorithms.
>
I have a question, how do you want to call e.g. total_less or=20
total_order? Could you show an example of an algorithm calling them?
I'm not sure the propose of these functions is to pass them to=20
algorithms, but I'm surely wrong.
>
> * Handling the trinary comparators in algorithms is a bit tedious:
> algorithms are supposed to accept either binary predicates (at
> least for backwards compatibility, sometimes for convenience) or
> trinary comparators. However, we need to discriminate between
> both: predicates return a result convertible to bool, but what
> about trinary comparators? They can /at least/ return a
> partial_ordering, a weak_ordering or a total_ordering, but can
> there be extra user-defined ordering returned by user-defined
> trinary comparators too? If so, how to generically disciminate
> them from predicates?
>
I don't think other orders could be taken in account until they are on=20
the table by the standard.
>
> * Moreover, in order to implement algorithms only once means that
> every ordering value should be explicitly convertible to a common
> type and to same values at some point (I did that with -1, 0 and
> 1) since the names of the enumerators are not the same for the
> different orderings.
>
I don't understand what you mean here. Could you give one example?
>
> * One could say that it doesn't matter since a specific algorithm
> should only work with one specific ordering,
>
Right. You implement an algorithm for a specific kind of order.
>
> * but this isn't true: using std::sort with either weak_order or
> total_order will yield either an inconsistent sort or a consistent
> sort; both might be desirable depending on the application.
>
I guess that you will implement it then with the less restrictive order=20
in this case.
>
> * Apparently total_less,total_equal, total_greater... exist for
> convenience but also for optimizations purpose. If so, should we
> also have total_less_or_equal, total_greater_or_equal and friends
> to take advantage of existing <=3D and >=3D operators when possible?
>
If there are algorithms that could take advantage of them, it could have=20
a sens. We need at least one.
>
> * Algorithms are only able to fully take advantage of orders when
> they know both the trinary comparator and the corresponding
> (possibly optimized) binary predicates. For example, if we need to
> perform a simple less operation on integers several times in a
> raw, having total_order only means that we will end up performing
> twice as many comparisons as if we used total_less instead. There
> needs to be a mechanism (or at least guarantees) so that
> algorithms can take advantage of both a trinary comparator and the
> corresponding predicates at the same time to avoid performance losses=
..
>
I don't see what problem are you seen. IMHO, the algorithm will use=20
total_order or total_less depending on his needs. If only total_less is=20
useful, I don't see why total_order will be used. I'm not sure I=20
understand the problem or how total_order and total_less should be used.
>
> * The enumerator values -1, 0 and 1 that I proposed are handy for
> several purposes: having common values for equivalent enumerators
> (albeit with different names) in different orderings,
>
This is already the case with the proposal, The values are 0, 1, 2.
>
> * but they also allow to implement a reverse function to reverse an
> ordering with a simple hidden subtraction.
>
I suspect that you could do it also with 0,1,2, isn't it?
>
> * Also it still makes it easy to forward values to legacy functions
> with an explicit static_cast to int.
>
>
You will need to add -1 to the static_cast.
Vicente
--=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/56EAF54C.4030300%40wanadoo.fr.
--------------050800080105090205030003
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">Le 16/03/2016 20:17, Morwenn a =C3=A9cri=
t=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:2e1fdff0-c666-4337-be82-788602c98ea8@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">I started to implement <a moz-do-not-send=3D"true"
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0100r1.htm=
l">P0100R1</a>
in a library of mine. Some parts are really smooth, but some
other parts don't fill <i>that</i> smooth; here is what I could
notice while implementing the proposal:<br>
</div>
</blockquote>
Hi, I have just take a look at the paper so there should be a lot of
things I don't understand yet. The purpose on this replay is to
understand it better as I believe that I have not understood it as I
don't understand the problems you are referring to. It would help if
we can take a look at your implementation.<br>
<br>
<br>
<blockquote
cite=3D"mid:2e1fdff0-c666-4337-be82-788602c98ea8@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>Making customization points with the proposed functions
seems to be the way to go. That way it only "reserves" one
name for every feature in the standard library, and the
customization points can still perform ADL to find
user-defined functions, and yet they can still be passed to
functions, which is a good selling point for since they are
meant to be passed to algorithms.</li>
</ul>
</div>
</blockquote>
I have a question, how do you want to call e.g. total_less or
total_order? Could you show an example of an algorithm calling them?<br=
>
<br>
I'm not sure the propose of these functions is to pass them to
algorithms, but I'm surely wrong.<br>
<blockquote
cite=3D"mid:2e1fdff0-c666-4337-be82-788602c98ea8@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>Handling the trinary comparators in algorithms is a bit
tedious: algorithms are supposed to accept either binary
predicates (at least for backwards compatibility, sometimes
for convenience) or trinary comparators. However, we need to
discriminate between both: predicates return a result
convertible to <span style=3D"font-family: courier
new,monospace;">bool</span>, but what about trinary
comparators? They can <i>at least</i> return a <span
style=3D"font-family: courier new,monospace;">partial_orderin=
g</span>,
a <span style=3D"font-family: courier new,monospace;">weak_orde=
ring</span>
or a <span style=3D"font-family: courier new,monospace;">total_=
ordering</span>,
but can there be extra user-defined ordering returned by
user-defined trinary comparators too? If so, how to
generically disciminate them from predicates?</li>
</ul>
</div>
</blockquote>
I don't think other orders could be taken in account until they are
on the table by the standard.<br>
<blockquote
cite=3D"mid:2e1fdff0-c666-4337-be82-788602c98ea8@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>Moreover, in order to implement algorithms only once means
that every ordering value should be explicitly convertible
to a common type and to same values at some point (I did
that with -1, 0 and 1) since the names of the enumerators
are not the same for the different orderings. </li>
</ul>
</div>
</blockquote>
I don't understand what you mean here. Could you give one example?<br>
<blockquote
cite=3D"mid:2e1fdff0-c666-4337-be82-788602c98ea8@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>One could say that it doesn't matter since a specific
algorithm should only work with one specific ordering,</li>
</ul>
</div>
</blockquote>
Right. You implement an algorithm for a specific kind of order. <br>
<blockquote
cite=3D"mid:2e1fdff0-c666-4337-be82-788602c98ea8@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<ul>
<li> but this isn't true: using <span style=3D"font-family:
courier new,monospace;">std::sort</span> with either <span
style=3D"font-family: courier new,monospace;">weak_order</spa=
n>
or <span style=3D"font-family: courier new,monospace;">total_or=
der</span>
will yield either an inconsistent sort or a consistent sort;
both might be desirable depending on the application.</li>
</ul>
</div>
</blockquote>
I guess that you will implement it then with the less restrictive
order in this case.<br>
<blockquote
cite=3D"mid:2e1fdff0-c666-4337-be82-788602c98ea8@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>Apparently <span style=3D"font-family: courier
new,monospace;">total_less</span>,<span
style=3D"font-family: courier new,monospace;"> total_equal</s=
pan>,
<span style=3D"font-family: courier new,monospace;">total_great=
er</span>...
exist for convenience but also for optimizations purpose. If
so, should we also have <span style=3D"font-family: courier
new,monospace;">total_less_or_equal</span>, <span
style=3D"font-family: courier new,monospace;">total_greater_o=
r_equal</span>
and friends to take advantage of existing <span
style=3D"font-family: courier new,monospace;"><=3D</span>
and <span style=3D"font-family: courier new,monospace;">>=3D=
</span>
operators when possible?</li>
</ul>
</div>
</blockquote>
If there are algorithms that could take advantage of them, it could
have a sens. We need at least one.<br>
<blockquote
cite=3D"mid:2e1fdff0-c666-4337-be82-788602c98ea8@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>Algorithms are only able to fully take advantage of orders
when they know both the trinary comparator and the
corresponding (possibly optimized) binary predicates. For
example, if we need to perform a simple <span
style=3D"font-family: courier new,monospace;">less</span>
operation on integers several times in a raw, having <span
style=3D"font-family: courier new,monospace;">total_order</sp=
an>
only means that we will end up performing twice as many
comparisons as if we used <span style=3D"font-family: courier
new,monospace;">total_less</span> instead. There needs to
be a mechanism (or at least guarantees) so that algorithms
can take advantage of both a trinary comparator and the
corresponding predicates at the same time to avoid
performance losses.<br>
</li>
</ul>
</div>
</blockquote>
I don't see what problem are you seen. IMHO, the algorithm will use
total_order or total_less depending on his needs. If only total_less
is useful, I don't see why total_order will be used. I'm not sure I
understand the problem or how total_order and total_less should be
used.<br>
<blockquote
cite=3D"mid:2e1fdff0-c666-4337-be82-788602c98ea8@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>The enumerator values -1, 0 and 1 that I proposed are
handy for several purposes: having common values for
equivalent enumerators (albeit with different names) in
different orderings, </li>
</ul>
</div>
</blockquote>
This is already the case with the proposal, The values are 0, 1, 2.<br>
<blockquote
cite=3D"mid:2e1fdff0-c666-4337-be82-788602c98ea8@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>but they also allow to implement a <span
style=3D"font-family: courier new,monospace;">reverse</span>
function to reverse an ordering with a simple hidden
subtraction. </li>
</ul>
</div>
</blockquote>
I suspect that you could do it also with 0,1,2, isn't it?<br>
<blockquote
cite=3D"mid:2e1fdff0-c666-4337-be82-788602c98ea8@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>Also it still makes it easy to forward values to legacy
functions with an explicit <span style=3D"font-family:
courier new,monospace;">static_cast</span> to <span
style=3D"font-family: courier new,monospace;">int</span>.</li=
>
</ul>
<br>
</div>
</blockquote>
You will need to add -1 to the static_cast. <br>
<br>
Vicente<br>
</body>
</html>
<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/56EAF54C.4030300%40wanadoo.fr?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.org/d/m=
sgid/std-proposals/56EAF54C.4030300%40wanadoo.fr</a>.<br />
--------------050800080105090205030003--
.
Author: Morwenn <morwenn29@gmail.com>
Date: Fri, 18 Mar 2016 01:49:20 -0700 (PDT)
Raw View
------=_Part_1983_1472889082.1458290960889
Content-Type: multipart/alternative;
boundary="----=_Part_1984_286525225.1458290960889"
------=_Part_1984_286525225.1458290960889
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le jeudi 17 mars 2016 19:20:00 UTC+1, Vicente J. Botet Escriba a =C3=A9crit=
:
>
> Le 16/03/2016 20:17, Morwenn a =C3=A9crit :
>
> I started to implement P0100R1=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0100r1.html> in=
=20
> a library of mine. Some parts are really smooth, but some other parts don=
't=20
> fill *that* smooth; here is what I could notice while implementing the=20
> proposal:
>
> Hi, I have just take a look at the paper so there should be a lot of=20
> things I don't understand yet. The purpose on this replay is to understan=
d=20
> it better as I believe that I have not understood it as I don't understan=
d=20
> the problems you are referring to. It would help if we can take a look at=
=20
> your implementation.
>
> I only started to push the modifications in a specific branch of my=20
> library: https://github.com/Morwenn/cpp-sort/tree/trinary-comparators, so=
=20
> there isn't much available yet but I intend to pursue the effort.
>
>
> - Making customization points with the proposed functions seems to be=
=20
> the way to go. That way it only "reserves" one name for every feature =
in=20
> the standard library, and the customization points can still perform A=
DL to=20
> find user-defined functions, and yet they can still be passed to funct=
ions,=20
> which is a good selling point for since they are meant to be passed to=
=20
> algorithms.=20
>
> I have a question, how do you want to call e.g. total_less or total_order=
?=20
> Could you show an example of an algorithm calling them?
>
If total_less and total_order are customization points, you can simply call=
std::sort(vec.begin(),=20
vec.end(), std::total_less); and std::sort(vec.begin(), vec.end(),=20
std::total_order);.
On the other hand, if they are mere functions, you'd have to wrap them into=
=20
a function object in order to pass them to an algorithm (it can be done=20
implicitly if P0119 is accepted though).
That said, even with P0119, you'd have to write the function object by hand=
=20
to use ADL.
>
> I'm not sure the propose of these functions is to pass them to algorithms=
,=20
> but I'm surely wrong.
>
I may still be the one misreading the paper, who knows? :p
>
> - Handling the trinary comparators in algorithms is a bit tedious:=20
> algorithms are supposed to accept either binary predicates (at least f=
or=20
> backwards compatibility, sometimes for convenience) or trinary compara=
tors.=20
> However, we need to discriminate between both: predicates return a res=
ult=20
> convertible to bool, but what about trinary comparators? They can *at=
=20
> least* return a partial_ordering, a weak_ordering or a total_ordering,=
=20
> but can there be extra user-defined ordering returned by user-defined=
=20
> trinary comparators too? If so, how to generically disciminate them fr=
om=20
> predicates?=20
>
> I don't think other orders could be taken in account until they are on th=
e=20
> table by the standard.
>
Yeah, that's also how I implemented the trait that checks whether a=20
function is a trinary comparator for now. I hardly see how to make that=20
more generic without having false positives.=20
>
> - Moreover, in order to implement algorithms only once means that=20
> every ordering value should be explicitly convertible to a common type=
and=20
> to same values at some point (I did that with -1, 0 and 1) since the n=
ames=20
> of the enumerators are not the same for the different orderings.=20
>
> I don't understand what you mean here. Could you give one example?
>
Imagine we want std::sort to accept either std::weak_order or=20
std::total_order depending on whether you want an inconsistent or a=20
consistent sort.
Whenever you want to check whether the result of a comparison is equal or=
=20
equivalent, you will have to check against std::weak_ordering::equivalent=
=20
or std::total_ordering::equal depending on the order, which makes for a=20
hardly generic implementation.
Now, if we know that the underlying values are -1, 0 and 1, we can check=20
with static_cast<int>(comparison_result) =3D=3D 0 through the whole algorit=
hm.
Not the cleanest thing in the world, but at least it avoids having to=20
reimplement the algorithm for every ordering.
>
> - One could say that it doesn't matter since a specific algorithm=20
> should only work with one specific ordering,=20
>
> Right. You implement an algorithm for a specific kind of order.=20
>
>
> - but this isn't true: using std::sort with either weak_order or=20
> total_order will yield either an inconsistent sort or a consistent=20
> sort; both might be desirable depending on the application.=20
>
> I guess that you will implement it then with the less restrictive order i=
n=20
> this case.
>
Well, depending on how orders are actually meant to be used with=20
algorithms, you might be right. I still might be wrong :)
Which raises another interesting point: the proposal should definitely=20
include examples of how to use the orders with algorithms to make it clear.=
=20
>
> - Apparently total_less, total_equal, total_greater... exist for=20
> convenience but also for optimizations purpose. If so, should we also =
have=20
> total_less_or_equal, total_greater_or_equal and friends to take=20
> advantage of existing <=3D and >=3D operators when possible?=20
>
> If there are algorithms that could take advantage of them, it could have =
a=20
> sens. We need at least one.
>
True. I believe that such things exist... well, I don't have an example=20
right now so maybe not.=20
>
> - Algorithms are only able to fully take advantage of orders when they=
=20
> know both the trinary comparator and the corresponding (possibly optim=
ized)=20
> binary predicates. For example, if we need to perform a simple less=20
> operation on integers several times in a raw, having total_order only=
=20
> means that we will end up performing twice as many comparisons as if w=
e=20
> used total_less instead. There needs to be a mechanism (or at least=20
> guarantees) so that algorithms can take advantage of both a trinary=20
> comparator and the corresponding predicates at the same time to avoid=
=20
> performance losses.
> =20
> I don't see what problem are you seen. IMHO, the algorithm will use=20
> total_order or total_less depending on his needs. If only total_less is=
=20
> useful, I don't see why total_order will be used. I'm not sure I understa=
nd=20
> the problem or how total_order and total_less should be used.
>
I was trying to reimplement algorithms with two overloads for comparison:=
=20
"is it a trinary comparator" or "is it a predicate" to run them as in my=20
previous example on how I think they are meant to be used.
In which case, when given a trinary comparator, the algorithm only knows=20
about the passed comparator, not about the possible optimized predicates=20
that might be associated.
Sure, the algorithms could use their knowledge of the standard when passed=
=20
a standard trinary comparator to use the associated predicates... if only=
=20
standard trinary comparators are allowed then it's not a problem.
>
> - The enumerator values -1, 0 and 1 that I proposed are handy for=20
> several purposes: having common values for equivalent enumerators (alb=
eit=20
> with different names) in different orderings,=20
>
> This is already the case with the proposal, The values are 0, 1, 2.
>
True. Less legacy-friendly though :/=20
>
> - but they also allow to implement a reverse function to reverse an=20
> ordering with a simple hidden subtraction.=20
>
> I suspect that you could do it also with 0,1,2, isn't it?
>
static_cast<total_ordering>(-(static_cast<int>(value) - 1) + 1) for=20
example? Well yeah, it works.
>
> - Also it still makes it easy to forward values to legacy functions=20
> with an explicit static_cast to int.=20
>
>
> You will need to add -1 to the static_cast.=20
>
> Vicente
>
=20
Also true, I guess that the *really* legacy-friendly argument is the only=
=20
one that holds for that specific point.
Anyway, thanks for taking the time to answer everything point per point;=20
some of the points you raise are interesting :)
--=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/a03f3682-2dc9-4b00-9e66-0a0e175d4af3%40isocpp.or=
g.
------=_Part_1984_286525225.1458290960889
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le jeudi 17 mars 2016 19:20:00 UTC+1, Vicente J. Botet Esc=
riba a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>Le 16/03/2016 20:17, Morwenn a =C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">I started to implement <a href=3D"http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2015/p0100r1.html" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\7=
5http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%=
2Fp0100r1.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEwjjUenXDpeDx0fWJpRYUo8AM=
sEg';return true;" onclick=3D"this.href=3D'http://www.google.com/ur=
l?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F=
2015%2Fp0100r1.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEwjjUenXDpeDx0fWJpRY=
Uo8AMsEg';return true;">P0100R1</a>
in a library of mine. Some parts are really smooth, but some
other parts don't fill <i>that</i> smooth; here is what I could
notice while implementing the proposal:<br>
</div>
</blockquote>
Hi, I have just take a look at the paper so there should be a lot of
things I don't understand yet. The purpose on this replay is to
understand it better as I believe that I have not understood it as I
don't understand the problems you are referring to. It would help i=
f
we can take a look at your implementation.<br>
<br>
I only started to push the modifications in a specific branch of my lib=
rary: https://github.com/Morwenn/cpp-sort/tree/trinary-comparators, so ther=
e isn't much available yet but I intend to pursue the effort.<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>Making customization points with the proposed functions
seems to be the way to go. That way it only "reserves"=
; one
name for every feature in the standard library, and the
customization points can still perform ADL to find
user-defined functions, and yet they can still be passed to
functions, which is a good selling point for since they are
meant to be passed to algorithms.</li>
</ul>
</div>
</blockquote>
I have a question, how do you want to call e.g. total_less or
total_order? Could you show an example of an algorithm calling them?<br=
></div></blockquote><div><br>If <span style=3D"font-family: courier new,mon=
ospace;">total_less</span> and <span style=3D"font-family: courier new,mono=
space;">total_order</span> are customization points, you can simply call <s=
pan style=3D"font-family: courier new,monospace;">std::sort(vec.begin(), ve=
c.end(), std::total_less);</span> and <span style=3D"font-family: courier n=
ew,monospace;">std::sort(vec.begin(), vec.end(), std::total_order);<span st=
yle=3D"font-family: arial,sans-serif;">.<br>On the other hand, if they are =
mere functions, you'd have to wrap them into a function object in order=
to pass them to an algorithm (it can be done implicitly if P0119 is accept=
ed though).<br>That said, even with P0119, you'd have to write the func=
tion object by hand to use ADL.<br></span></span></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
<br>
I'm not sure the propose of these functions is to pass them to
algorithms, but I'm surely wrong.<br></div></blockquote><div><br>I =
may still be the one misreading the paper, who knows? :p<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFF=
F">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>Handling the trinary comparators in algorithms is a bit
tedious: algorithms are supposed to accept either binary
predicates (at least for backwards compatibility, sometimes
for convenience) or trinary comparators. However, we need to
discriminate between both: predicates return a result
convertible to <span style=3D"font-family:courier new,monospace=
">bool</span>, but what about trinary
comparators? They can <i>at least</i> return a <span style=3D"f=
ont-family:courier new,monospace">partial_ordering</span>,
a <span style=3D"font-family:courier new,monospace">weak_orderi=
ng</span>
or a <span style=3D"font-family:courier new,monospace">total_or=
dering</span>,
but can there be extra user-defined ordering returned by
user-defined trinary comparators too? If so, how to
generically disciminate them from predicates?</li>
</ul>
</div>
</blockquote>
I don't think other orders could be taken in account until they are
on the table by the standard.<br></div></blockquote><div><br>Yeah, that=
's also how I implemented the trait that checks whether a function is a=
trinary comparator for now. I hardly see how to make that more generic wit=
hout having false positives. <br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>Moreover, in order to implement algorithms only once means
that every ordering value should be explicitly convertible
to a common type and to same values at some point (I did
that with -1, 0 and 1) since the names of the enumerators
are not the same for the different orderings. </li>
</ul>
</div>
</blockquote>
I don't understand what you mean here. Could you give one example?<=
br></div></blockquote><div><br>Imagine we want <span style=3D"font-family: =
courier new,monospace;">std::sort</span> to accept either <span style=3D"fo=
nt-family: courier new,monospace;">std::weak_order</span> or <span style=3D=
"font-family: courier new,monospace;">std::total_order</span> depending on =
whether you want an inconsistent or a consistent sort.<br>Whenever you want=
to check whether the result of a comparison is equal or equivalent, you wi=
ll have to check against std::weak_ordering::equivalent or std::total_order=
ing::equal depending on the order, which makes for a hardly generic impleme=
ntation.<br>Now, if we know that the underlying values are -1, 0 and 1, we =
can check with <span style=3D"font-family: courier new,monospace;">static_c=
ast<int>(comparison_result) =3D=3D 0</span> through the whole algorit=
hm.<br>Not the cleanest thing in the world, but at least it avoids having t=
o reimplement the algorithm for every ordering.<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>One could say that it doesn't matter since a specific
algorithm should only work with one specific ordering,</li>
</ul>
</div>
</blockquote>
Right. You implement an algorithm for a specific kind of order. <br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<ul>
<li> but this isn't true: using <span style=3D"font-family:co=
urier new,monospace">std::sort</span> with either <span style=3D"font-famil=
y:courier new,monospace">weak_order</span>
or <span style=3D"font-family:courier new,monospace">total_orde=
r</span>
will yield either an inconsistent sort or a consistent sort;
both might be desirable depending on the application.</li>
</ul>
</div>
</blockquote>
I guess that you will implement it then with the less restrictive
order in this case.<br></div></blockquote><div><br>Well, depending on h=
ow orders are actually meant to be used with algorithms, you might be right=
.. I still might be wrong :)<br>Which raises another interesting point: the =
proposal should definitely include examples of how to use the orders with a=
lgorithms to make it clear. <br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>Apparently <span style=3D"font-family:courier new,monospace">=
total_less</span>,<span style=3D"font-family:courier new,monospace"> total_=
equal</span>,
<span style=3D"font-family:courier new,monospace">total_greater=
</span>...
exist for convenience but also for optimizations purpose. If
so, should we also have <span style=3D"font-family:courier new,=
monospace">total_less_or_equal</span>, <span style=3D"font-family:courier n=
ew,monospace">total_greater_or_equal</span>
and friends to take advantage of existing <span style=3D"font-f=
amily:courier new,monospace"><=3D</span>
and <span style=3D"font-family:courier new,monospace">>=3D</=
span>
operators when possible?</li>
</ul>
</div>
</blockquote>
If there are algorithms that could take advantage of them, it could
have a sens. We need at least one.<br></div></blockquote><div><br>True.=
I believe that such things exist... well, I don't have an example righ=
t now so maybe not. <br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>Algorithms are only able to fully take advantage of orders
when they know both the trinary comparator and the
corresponding (possibly optimized) binary predicates. For
example, if we need to perform a simple <span style=3D"font-fam=
ily:courier new,monospace">less</span>
operation on integers several times in a raw, having <span styl=
e=3D"font-family:courier new,monospace">total_order</span>
only means that we will end up performing twice as many
comparisons as if we used <span style=3D"font-family:courier ne=
w,monospace">total_less</span> instead. There needs to
be a mechanism (or at least guarantees) so that algorithms
can take advantage of both a trinary comparator and the
corresponding predicates at the same time to avoid
performance losses.<br>
</li>
</ul>
</div>
</blockquote>
I don't see what problem are you seen. IMHO, the algorithm will use
total_order or total_less depending on his needs. If only total_less
is useful, I don't see why total_order will be used. I'm not su=
re I
understand the problem or how total_order and total_less should be
used.<br></div></blockquote><div><br>I was trying to reimplement algori=
thms with two overloads for comparison: "is it a trinary comparator&qu=
ot; or "is it a predicate" to run them as in my previous example =
on how I think they are meant to be used.<br>In which case, when given a tr=
inary comparator, the algorithm only knows about the passed comparator, not=
about the possible optimized predicates that might be associated.<br>Sure,=
the algorithms could use their knowledge of the standard when passed a sta=
ndard trinary comparator to use the associated predicates... if only standa=
rd trinary comparators are allowed then it's not a problem.<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D=
"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>The enumerator values -1, 0 and 1 that I proposed are
handy for several purposes: having common values for
equivalent enumerators (albeit with different names) in
different orderings, </li>
</ul>
</div>
</blockquote>
This is already the case with the proposal, The values are 0, 1, 2.<br>=
</div></blockquote><div><br>True. Less legacy-friendly though :/ <br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div text=3D"#000000" bgcolor=
=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>but they also allow to implement a <span style=3D"font-family=
:courier new,monospace">reverse</span>
function to reverse an ordering with a simple hidden
subtraction. </li>
</ul>
</div>
</blockquote>
I suspect that you could do it also with 0,1,2, isn't it?<br></div>=
</blockquote><div><br><span style=3D"font-family: courier new,monospace;">s=
tatic_cast<total_ordering>(-(static_cast<int>(value) - 1) + 1)<=
/span> for example? Well yeah, it works.<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<ul>
<li>Also it still makes it easy to forward values to legacy
functions with an explicit <span style=3D"font-family:courier n=
ew,monospace">static_cast</span> to <span style=3D"font-family:courier new,=
monospace">int</span>.</li>
</ul>
<br>
</div>
</blockquote>
You will need to add -1 to the static_cast. <br>
<br>
Vicente<br></div></blockquote><div>=C2=A0<br>Also true, I guess that th=
e <i>really</i> legacy-friendly argument is the only one that holds for tha=
t specific point.<br><br><br>Anyway, thanks for taking the time to answer e=
verything point per point; some of the points you raise are interesting :)<=
br></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/a03f3682-2dc9-4b00-9e66-0a0e175d4af3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a03f3682-2dc9-4b00-9e66-0a0e175d4af3=
%40isocpp.org</a>.<br />
------=_Part_1984_286525225.1458290960889--
------=_Part_1983_1472889082.1458290960889--
.