--000000000000d5d307056ef085f9
Content-Type: text/plain; charset="UTF-8"

Forgive me, I'm sure this has been asked before.

A well-known fact is that the result of comparing pointers is unspecified
unless they point into the same array or into the same complete object, but
std::less<T*> is nonetheless guaranteed to provide a strict total order
even if the built-in < operator for T* does not.

Why can't we just change the standard so that the built-in < operator for
T* also provides a strict total order? It would take about 5 minutes to
write up a paper, which is why I'm sure it would have been done by now if
there wasn't a good reason not to.

--
*Brian Bi*

--
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/CAMmfjbM%2Bpopqk-49hc%2BwbyZCMbqc%3DmBKnAkL%3DV3Yz_bB2-UhpQ%40mail.gmail.com.

--000000000000d5d307056ef085f9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Forgive me, I&#39;m sure this has been asked bef=
ore.<br><br></div>A well-known fact is that the result of comparing pointer=
s is unspecified unless they point into the same array or into the same com=
plete object, but std::less&lt;T*&gt; is nonetheless guaranteed to provide =
a strict total order even if the built-in &lt; operator for T* does not.<br=
><br></div>Why can&#39;t we just change the standard so that the built-in &=
lt; operator for T* also provides a strict total order? It would take about=
 5 minutes to write up a paper, which is why I&#39;m sure it would have bee=
n done by now if there wasn&#39;t a good reason not to.<br clear=3D"all"><d=
iv><div><div><div><br>-- <br><div class=3D"gmail_signature" data-smartmail=
=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><font color=3D"=
#c0c0c0"><i>Brian Bi</i></font><br><div></div><div></div><div></div></div><=
/div></div></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&quot; 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/CAMmfjbM%2Bpopqk-49hc%2BwbyZCMbqc%3Dm=
BKnAkL%3DV3Yz_bB2-UhpQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbM%=
2Bpopqk-49hc%2BwbyZCMbqc%3DmBKnAkL%3DV3Yz_bB2-UhpQ%40mail.gmail.com</a>.<br=
 />

--000000000000d5d307056ef085f9--

.

On Monday, 18 June 2018 13:36:39 PDT Brian Bi wrote:
> Why can't we just change the standard so that the built-in < operator for
> T* also provides a strict total order? It would take about 5 minutes to
> write up a paper, which is why I'm sure it would have been done by now if
> there wasn't a good reason not to.

The reason is that you're not *supposed* to order pointers for different
arrays. And the reason for that is that on some systems only a portion of the
pointer representation needs to be compared to determine the ordering, if it
is in the same array.

Think of 16-bit segmented DOS builds, with 32-bit far pointers. Aside from the
Huge Memory Model, all objects (including arrays) are limited to 64kB in size,
so the segment portion of the pointer remains the same for any pointer.
Iteration only requires modifying the offset portion.

Ordering in that system requires only to compare the 16-bit offsets, not the
entire 32-bit representation. Considering it's a build for a 16-bit platform
with 16-bit CMP instructions, a 32-bit comparison would mean an extra jump,
something you don't want in the general case. That logic is only required in
std::less, so it's kept there.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/3889234.yOr8yHXb3L%40tjmaciei-mobl1.

.

--0000000000006f0008056ef12219
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 18, 2018 at 3:53 PM Thiago Macieira <thiago@macieira.org> wrote:

> On Monday, 18 June 2018 13:36:39 PDT Brian Bi wrote:
> > Why can't we just change the standard so that the built-in < operator for
> > T* also provides a strict total order? It would take about 5 minutes to
> > write up a paper, which is why I'm sure it would have been done by now if
> > there wasn't a good reason not to.
>
> The reason is that you're not *supposed* to order pointers for different
> arrays. And the reason for that is that on some systems only a portion of
> the
> pointer representation needs to be compared to determine the ordering, if
> it
> is in the same array.
>
> Think of 16-bit segmented DOS builds, with 32-bit far pointers. Aside from
> the
> Huge Memory Model, all objects (including arrays) are limited to 64kB in
> size,
> so the segment portion of the pointer remains the same for any pointer.
> Iteration only requires modifying the offset portion.
>
> Ordering in that system requires only to compare the 16-bit offsets, not
> the
> entire 32-bit representation. Considering it's a build for a 16-bit
> platform
> with 16-bit CMP instructions, a 32-bit comparison would mean an extra
> jump,
> something you don't want in the general case. That logic is only required
> in
> std::less, so it's kept there.
>

Please list the C++17 compilers and standard libraries which target such a
system.  I'd love to see how std::less, especially std::less<void>, is
implemented.  Actual implementations and not hypotheticals, please.


While I am strongly in favor of such a change, the shorter answer is that
there are a number of committee members who are adamantly against such a
change, and trying to do so is a battle not worth fighting.
--
 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%2BPq_ur-c8RyHRp9y%2B9H%3DOvvizMtL8rkLdxA4XJGOGwX%3DA%40mail.gmail.com.

--0000000000006f0008056ef12219
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Jun 18, 2018 at 3:53 PM Thiago Macieira &lt;<a hre=
f=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>&gt; 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">On Monday, 18 June 20=
18 13:36:39 PDT Brian Bi wrote:<br>
&gt; Why can&#39;t we just change the standard so that the built-in &lt; op=
erator for<br>
&gt; T* also provides a strict total order? It would take about 5 minutes t=
o<br>
&gt; write up a paper, which is why I&#39;m sure it would have been done by=
 now if<br>
&gt; there wasn&#39;t a good reason not to.<br>
<br>
The reason is that you&#39;re not *supposed* to order pointers for differen=
t <br>
arrays. And the reason for that is that on some systems only a portion of t=
he <br>
pointer representation needs to be compared to determine the ordering, if i=
t <br>
is in the same array.<br>
<br>
Think of 16-bit segmented DOS builds, with 32-bit far pointers. Aside from =
the <br>
Huge Memory Model, all objects (including arrays) are limited to 64kB in si=
ze, <br>
so the segment portion of the pointer remains the same for any pointer. <br=
>
Iteration only requires modifying the offset portion.<br>
<br>
Ordering in that system requires only to compare the 16-bit offsets, not th=
e <br>
entire 32-bit representation. Considering it&#39;s a build for a 16-bit pla=
tform <br>
with 16-bit CMP instructions, a 32-bit comparison would mean an extra jump,=
 <br>
something you don&#39;t want in the general case. That logic is only requir=
ed in <br>
std::less, so it&#39;s kept there.<br></blockquote><div><br></div><div>Plea=
se list the C++17 compilers and standard libraries which target such a syst=
em.=C2=A0 I&#39;d love to see how std::less, especially std::less&lt;void&g=
t;, is implemented.=C2=A0 Actual implementations and not hypotheticals, ple=
ase.</div><div><br></div><div><br></div><div>While I am strongly in favor o=
f such a change, the shorter answer is that there are a number of committee=
 members who are adamantly against such a change, and trying to do so is a =
battle not worth fighting.</div><div>--=C2=A0<br></div></div><div dir=3D"lt=
r" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D=
"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &l=
t;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@=
eviloverlord.com</a>&gt; =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&quot; 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%2BPq_ur-c8RyHRp9y%2B9H%3DOvviz=
MtL8rkLdxA4XJGOGwX%3DA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
Pq_ur-c8RyHRp9y%2B9H%3DOvvizMtL8rkLdxA4XJGOGwX%3DA%40mail.gmail.com</a>.<br=
 />

--0000000000006f0008056ef12219--

.

On Monday, 18 June 2018 14:19:50 PDT Nevin Liber wrote:
> Please list the C++17 compilers and standard libraries which target such a
> system.  I'd love to see how std::less, especially std::less<void>, is
> implemented.  Actual implementations and not hypotheticals, please.

I can't. It's all in the past and I really don't expect anyone to think of
supporting 16-bit DOS in the future.

I could give hypotheticals of systems with persistent memory (see [1][2][3],
just the top three Google results). Since we've only just begun to have NVRAM
as useful storage, we don't know where the technology will lead and it's not
unthinkable to have a 128-bit-wide pointer to contain a control block. For
now, see [4] for what the team was thinking of in order to enable persistent
memory Standard Library containers.

See also [5], for a product that was reported to need pointers wider than 64-
bit. sorry, I can't find the slides that said that and that may not have
survived to the actual product.

[1] https://www.techrepublic.com/article/how-intel-optane-dc-persistent-memory-could-up-capacity-lower-cost-of-in-memory-databases/
[2] https://arstechnica.com/gadgets/2018/05/intel-finally-announces-ddr4-memory-made-from-persistent-3d-xpoint/
[3] https://www.forbes.com/sites/marcochiappetta/2018/05/30/intel-could-revolutionize-datacenters-with-optane-dc-persistent-memory/
[4] https://events.static.linuxfound.org/sites/events/files/slides/
NVML_Cpp_linuxcon_0.pdf
[5] https://www.labs.hpe.com/the-machine

> While I am strongly in favor of such a change, the shorter answer is that
> there are a number of committee members who are adamantly against such a
> change, and trying to do so is a battle not worth fighting.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/1975911.jZbo21u2Sj%40tjmaciei-mobl1.

.

------=_Part_8600_578363881.1529390149675
Content-Type: multipart/alternative;
 boundary="----=_Part_8601_892482667.1529390149675"

------=_Part_8601_892482667.1529390149675
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Il giorno luned=C3=AC 18 giugno 2018 22:36:42 UTC+2, Brian Bi ha scritto:
>
> Why can't we just change the standard so that the built-in < operator for=
=20
> T* also provides a strict total order? It would take about 5 minutes to=
=20
> write up a paper, which is why I'm sure it would have been done by now if=
=20
> there wasn't a good reason not to.
>

By making it UB you allow an implementation to put diagnostic runtime traps=
=20
on pointer misuse. If you would make such operations well formed the only=
=20
effect would be to ban the only weapon against this kind of objectionable=
=20
code. The good reason is that there is actually nothing to gain and much to=
=20
lose.

--=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/df39a324-fcc1-4d2f-9daf-c4ce67c3d85a%40isocpp.or=
g.

------=_Part_8601_892482667.1529390149675
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>Il giorno luned=C3=AC 18 giugno 2018 22:36:42 UTC+2, B=
rian Bi ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div></div>Why can&#39;t we just change the standard so that the buil=
t-in &lt; operator for T* also provides a strict total order? It would take=
 about 5 minutes to write up a paper, which is why I&#39;m sure it would ha=
ve been done by now if there wasn&#39;t a good reason not to.<br></div></bl=
ockquote><div><br></div><div>By making it UB you allow an implementation to=
 put diagnostic runtime traps on pointer misuse. If you would make such ope=
rations well formed the only effect would be to ban the only weapon against=
 this kind of objectionable code. The good reason is that there is actually=
 nothing to gain and much to lose.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/df39a324-fcc1-4d2f-9daf-c4ce67c3d85a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/df39a324-fcc1-4d2f-9daf-c4ce67c3d85a=
%40isocpp.org</a>.<br />

------=_Part_8601_892482667.1529390149675--

------=_Part_8600_578363881.1529390149675--

.

------=_Part_22671_1119990475.1529394314022
Content-Type: multipart/alternative;
 boundary="----=_Part_22672_941885013.1529394314022"

------=_Part_22672_941885013.1529394314022
Content-Type: text/plain; charset="UTF-8"

Except it's not Undefined Behavior, but Unspecified Result. Which is
completely different.

Unspecified result means: the language doesn't tell you anything about the
result, but guarantee somehow that the result will be fully determined. So
you cannot expect if the it will return true or false, but you can expect
nothing more complicated than that will happen.

However, accessing a out-of-bound pointer is Undefined Behavior, and tools
can be put here for misuse check.

--
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/7bf5acb7-7abb-44dd-9899-c8177c38c243%40isocpp.org.

------=_Part_22672_941885013.1529394314022
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Except it&#39;s not Undefined Behavior, but Unspecified Re=
sult. Which is completely different.<br><br>Unspecified result means: the l=
anguage doesn&#39;t tell you anything about the result, but guarantee someh=
ow that the result will be fully determined. So you cannot expect if the it=
 will return true or false, but you can expect nothing more complicated tha=
n that will happen.<br><br>However, accessing a out-of-bound pointer is Und=
efined Behavior, and tools can be put here for misuse check.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/7bf5acb7-7abb-44dd-9899-c8177c38c243%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7bf5acb7-7abb-44dd-9899-c8177c38c243=
%40isocpp.org</a>.<br />

------=_Part_22672_941885013.1529394314022--

------=_Part_22671_1119990475.1529394314022--

.

On Tuesday, 19 June 2018 00:45:13 PDT florian.csdt@gmail.com wrote:
> Except it's not Undefined Behavior, but Unspecified Result. Which is
> completely different.
>
> Unspecified result means: the language doesn't tell you anything about the
> result, but guarantee somehow that the result will be fully determined. So
> you cannot expect if the it will return true or false, but you can expect
> nothing more complicated than that will happen.

The language does not ensure the three-way comparison (total ordering) that if
p1 < p2 and p2 < p3, that p1 will be less than p3. You need std::less for
total ordering.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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/7411945.6xn8npGA9t%40tjmaciei-mobl1.

.

------=_Part_25236_895678977.1529429789841
Content-Type: multipart/alternative;
 boundary="----=_Part_25237_138506007.1529429789841"

------=_Part_25237_138506007.1529429789841
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tuesday, June 19, 2018 at 7:21:10 AM UTC-7, Thiago Macieira wrote:
>
> On Tuesday, 19 June 2018 00:45:13 PDT floria...@gmail.com <javascript:>=
=20
> wrote:=20
> > Except it's not Undefined Behavior, but Unspecified Result. Which is=20
> > completely different.=20
> >=20
> > Unspecified result means: the language doesn't tell you anything about=
=20
> the=20
> > result, but guarantee somehow that the result will be fully determined.=
=20
> So=20
> > you cannot expect if the it will return true or false, but you can=20
> expect=20
> > nothing more complicated than that will happen.=20
>
> The language does not ensure the three-way comparison (total ordering)=20
> that if=20
> p1 < p2 and p2 < p3, that p1 will be less than p3. You need std::less for=
=20
> total ordering.
>

Yes. And even std::less will not tell you the *actual* ordering of pointers=
=20
on your system. It is perfectly valid for the library implementor to=20
implement an "interleaved" std::less such that

    int a[10], b[10];
    int *p =3D &a[5];
    auto Less =3D std::less<int*>();
    assert( Less(a, p) && Less(p, a+10) );  // this MUST be true, according=
=20
to the standard's rules, because a < p && p < a+10
    assert( Less(b, p) && Less(p, b+10) );  // this ALSO COULD be true,=20
according to the standard's rules

=E2=80=93Arthur

--=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/ad34de57-9f06-414f-80c2-d5c0cfc2fc06%40isocpp.or=
g.

------=_Part_25237_138506007.1529429789841
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, June 19, 2018 at 7:21:10 AM UTC-7, Thiago Maci=
eira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday, 19 June=
 2018 00:45:13 PDT <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"wAP9OgEbBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;j=
avascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;=
return true;">floria...@gmail.com</a> wrote:
<br>&gt; Except it&#39;s not Undefined Behavior, but Unspecified Result. Wh=
ich is
<br>&gt; completely different.
<br>&gt;=20
<br>&gt; Unspecified result means: the language doesn&#39;t tell you anythi=
ng about the
<br>&gt; result, but guarantee somehow that the result will be fully determ=
ined. So
<br>&gt; you cannot expect if the it will return true or false, but you can=
 expect
<br>&gt; nothing more complicated than that will happen.
<br>
<br>The language does not ensure the three-way comparison (total ordering) =
that if=20
<br>p1 &lt; p2 and p2 &lt; p3, that p1 will be less than p3. You need std::=
less for=20
<br>total ordering.<br></blockquote><div><br></div><div>Yes. And even std::=
less will not tell you the <i><b>actual</b></i> ordering of pointers on you=
r system. It is perfectly valid for the library implementor to implement an=
 &quot;interleaved&quot; std::less such that</div><div><br></div><div>=C2=
=A0 =C2=A0 int a[10], b[10];</div><div>=C2=A0 =C2=A0 int *p =3D &amp;a[5];<=
br></div><div>=C2=A0 =C2=A0 auto Less =3D std::less&lt;int*&gt;();</div><di=
v>=C2=A0 =C2=A0 assert( Less(a, p) &amp;&amp; Less(p, a+10) ); =C2=A0// thi=
s MUST be true, according to the standard&#39;s rules, because a &lt; p &am=
p;&amp; p &lt; a+10</div><div><div>=C2=A0 =C2=A0 assert( Less(b, p) &amp;&a=
mp; Less(p, b+10) ); =C2=A0// this ALSO COULD be true, according to the sta=
ndard&#39;s rules</div></div><div><br></div><div>=E2=80=93Arthur</div></div=
>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/ad34de57-9f06-414f-80c2-d5c0cfc2fc06%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ad34de57-9f06-414f-80c2-d5c0cfc2fc06=
%40isocpp.org</a>.<br />

------=_Part_25237_138506007.1529429789841--

------=_Part_25236_895678977.1529429789841--

.