On Mon, Aug 26, 2013 at 9:12 AM, Nevin Liber <nevin_at_[hidden]> wrote:
> On 26 August 2013 11:00, Jeffrey Yasskin <jyasskin_at_[hidden]> wrote:
>>
>>
>> Could someone explain why we need to allow operator<(T*) to be a
>> non-order?
>
>
> It comes from C.

Yeah, C11 still makes it undefined behavior, not just unspecified: 6.5.8p5

> I believe it comes from the days of segmented
> architectures.
>
> I do not know of any modern machines that have such architectures and have
> C++11 compilers for them. Whenever it comes up for discussion on various
> reflectors, no one has mentioned one either.

Now that you mention it, GPUs might be an example. Olivier, do you
depend on this restriction? (Rest of thread at
http://www.open-std.org/pipermail/ub/2013-August/000095.html)

I had assumed that it was an optimization thing nowadays, as Gaby
said, and maybe if the optimizations aren't that significant we could
drop them.

> I for one would like to see
> this restriction go away.
>
> Armchair thought: maybe we should propose a total ordering for pointers
> (for C++17 at this point) and see if anyone objects?
>
>
> All that being said, I believe Library is inconsistent in its use of
> operator< vs. std::less<T>, and that needs to be addressed separately.
> Pointers are the current poster child for the issue but user code might be
> specializing std::less as well.
> --
> Nevin ":-)" Liber <mailto:nevin_at_[hidden]> (847) 691-1404
>
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>