Date: Mon, 26 Aug 2013 17:33:12 +0100
On 26/08/13 17:27, Gabriel Dos Reis wrote:
> 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.
Given the stronger requirements of std::less<T*>, is there any standard
library which does not implement std::less<T*> by a simple pointer
comparison?
If no implementation is making use of the difference between pointer <
and pointer std::less comparisons, perhaps we should take that leniency
away?
Chris
>
> 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
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
> 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.
Given the stronger requirements of std::less<T*>, is there any standard
library which does not implement std::less<T*> by a simple pointer
comparison?
If no implementation is making use of the difference between pointer <
and pointer std::less comparisons, perhaps we should take that leniency
away?
Chris
>
> 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
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
Received on 2013-08-26 18:33:29