<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 26 August 2013 22:01, Daniel Krügler <span dir="ltr"><<a href="mailto:daniel.kruegler@gmail.com" target="_blank">daniel.kruegler@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2013/8/26 Ville Voutilainen <<a href="mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>>:<br>
<div><div class="h5">> On 26 August 2013 19:00, Jeffrey Yasskin <<a href="mailto:jyasskin@google.com">jyasskin@google.com</a>> wrote:<br>
>><br>
>> The library's running into problems because < is unspecified on<br>
>> pointers that don't point to the same object. (C++14CD[expr.rel]p4)<br>
>> Naively, this restriction makes a bit of sense, since we can't give a<br>
>> particular answer for any two pointers, but it's causing problems for<br>
>> some generic library components. Specifically:<br>
>><br>
>> std::map<T*> works because std::less has a special case for pointers.<br>
>> ([comparisons]p14)<br>
>><br>
>> std::map<std::tuple<T*>> gives undefined behavior because<br>
>> std::less<tuple> uses tuple's operator<, which uses T*'s operator<.<br>
>><br>
>> std::map<std::optional<T*>> goes back to defined behavior because we<br>
>> special-cased optional's operator< to use std::less:<br>
>> [optional.relops]p4<br>
><br>
> I have strong reasons to believe we'll see an NB comment proposing std::less<br>
> to be specialized for tuple<T*> and containers.<br>
<br>
</div></div>I don't understand why there should be different specializations<br>
instead of a single specialization:<br>
<br>
less<tuple<T...>><br>
<br>
which defines the operator() overload in terms of std::less<T> for<br>
each T in order. Same thing for pair and optional and containers.<br>
<span class="HOEnZb"><font color="#888888"><br><br></font></span></blockquote><div><br></div><div>Sounds like a reasonable approach to me. <br></div></div><br></div></div>