<div dir="ltr">On 10 October 2013 18:24, Gabriel Dos Reis <span dir="ltr">&lt;<a href="mailto:gdr@axiomatics.org" target="_blank">gdr@axiomatics.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">Nevin Liber &lt;<a href="mailto:nevin@eviloverlord.com">nevin@eviloverlord.com</a>&gt; writes:<br>


<br>
| [Y&#39;know, I really wish replies would by default go the whole ub group...]<br>
<br>
</div>I cannot control your email software, but when you sent me the message,<br>
it wasn&#39;t addressed to the group and I replied the same way.<br></blockquote><div><br></div><div>It isn&#39;t my software (Gmail web client); it&#39;s the mailing list.  All the other reflectors default to replying to the group; this one defaults to replying only to the original author.  I&#39;m not sure who to contact to get that changed.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br></div>
<br>
As observed by Sean Parent in another discussion, std::less&lt;T*&gt; as a<br>
total order was never meant to be synonymous for operator&lt; on pointers.<br></blockquote><div><br></div><div>Sean also says in<span style="font-family:arial,sans-serif;font-size:13px;white-space:nowrap"> [c++std-lib-ext-550]</span>: <span style="font-size:13px;font-family:arial,sans-serif">The definition of </span><span class="" style="font-size:13px;font-family:arial,sans-serif">std</span><span style="font-size:13px;font-family:arial,sans-serif">::</span><span class="" style="font-size:13px;font-family:arial,sans-serif">less</span><span style="font-size:13px;font-family:arial,sans-serif"> should be &quot;a representational order if no natural total order (</span><span class="" style="font-size:13px;font-family:arial,sans-serif">operator</span><span style="font-size:13px;font-family:arial,sans-serif"> &lt;) is available, otherwise the natural total order&quot;.  He goes on: &quot;</span><span style="font-size:13px;font-family:arial,sans-serif">They are named separately, </span><span class="" style="font-size:13px;font-family:arial,sans-serif">operator</span><span style="font-size:13px;font-family:arial,sans-serif">&lt;() is the natural total order and </span><span class="" style="font-size:13px;font-family:arial,sans-serif">std</span><span style="font-size:13px;font-family:arial,sans-serif">::</span><span class="" style="font-size:13px;font-family:arial,sans-serif">less</span><span style="font-size:13px;font-family:arial,sans-serif">&lt;&gt; is the natural total order if one exists, otherwise it is a representational order.&quot;</span></div>

<div><br></div><div>Pointers clearly violate those rules.</div><div><br></div><div>Of course, C++ experts live with these contradictory rules all the time.  That&#39;s what makes them experts... :-(  Some experts even argue we should keep this contradictory behavior without providing concrete reasons why it is still necessary.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">| If someone writes:<br>
|<br>
| struct Foo<br>
| {<br>
|     X x;<br>
|     Y y;<br>
|     Z z;<br>
|<br>
|     friend bool operator&lt;(Foo const&amp; l, Foo const&amp; r)<br>
|     { return std::tie(l.x, l.y, l.z) &lt; std::tie(r.x, r.y, r.z); }<br>
<br>
</div>in my book, that someone writing this isn&#39;t a novice, but we have<br>
already disagreed on this.<br></blockquote><div><br></div><div><br></div><div>It doesn&#39;t take an expert to want to use an object as a key in a set or a map.  I was assuming that novices had access to Boost; if you don&#39;t want to make that assumption, I&#39;m fine with that too.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
| };<br>
|<br>
| If X, Y or Z are pointers, this code is broken!<br>
<br>
</div>If X, Y, and Z are pointers, I don&#39;t think he or she would have written that.<br></blockquote><div><br></div><div>Show us how you believe a novice would write this:</div><div><br></div><div>If X, Y, Z are types that can be used as keys in a set (why should it matter whether or not they are pointers?), what does the novice have to write so that a struct of them can be used as a key in a set?<br>

</div><div><br></div><div>Then show us how the expert should write this, with the additional caveat that it works with all of the relation comparators (less, greater, less_equal, greater_equal, assuming X, Y and Z can also be used correctly with those comparators) provided by the standard library.  Again, this should not be something that is hard to do.</div>

<div><br></div><div>And in a simpler world, both the novice solution and the expert solution ought to match...</div></div>-- <br> Nevin &quot;:-)&quot; Liber  &lt;mailto:<a href="mailto:nevin@eviloverlord.com" target="_blank">nevin@eviloverlord.com</a>&gt;  (847) 691-1404
</div></div>