Nevin Liber <nevin_at_[hidden]> writes:

| 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. I believe it comes from the days of segmented architectures.

You're right. Historically, it came from segmented architectures.

However, because it has been in the standard for that long, some
implementations may have taken advantage of that semantics restriction
even if they are not targeting segmented architecture. So, it is not
the case that because we don't have wide spread architecture anymore
means that removing that restriction is a breeze. It will invalidate
implementations that use compilation and program transformations based
on that.

If you make operator< a total order for all valid pointers (and
including the usual one-past-the-end pointers), I suspect you might also
as a by-product impose a stronger requirement on operator== on pointers.

-- Gaby

|
| 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. 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