Subject: Re: [ub] Canonical ordering
From: Christopher Jefferson (chris_at_[hidden])
Date: 2013-10-18 01:46:42
Here is a suggestion. How about we make the result of comparing pointers
from different allocations into implementation-defined behaviour?
Implementations can still have pointers p and q from different blocks of
memory where p == q, they just cannot invoke undefined behaviour, the
result must be repeatable. Also, if some user finds all the platforms he or
she cares about define a total ordering, they are also happy.
All we are removing now (I think) is the ability to optimise based on
On 11 Oct 2013 02:57, "Gabriel Dos Reis" <gdr_at_[hidden]> wrote:
> Nevin Liber <nevin_at_[hidden]> writes:
> | And in a simpler world, both the novice solution and the expert solution
> | to match...
> Well, "experts" would not be "experts" if they are undistinguishable
> from novices. <g>
> We may be on a side track here. If your argument is that putting stuff
> in ordered associative containers requires an ordering, then the natural
> thing to do is to have a mechanism to automatically generate a default
> "natural" ordering.
> Making operator< on pointers a total order does not solve that. It
> isn't a strech of imagination that they would want to put
> std::complex<T> in associative containers too. Novices would still have
> to write codes with subtle deficienties.
> Note: I am trying to make sure that we understand changes with potentially
> reaching consequences, and not just focus on a possibly incomplete patch
> with narrow justification. At the end of the day, someone is going to
> stand in front of SG12 and WG21 and get stoned forever, and that is
> likely to be me :-) So if you argue one side, I would argue the other
> for the purpose understanding and documentation of design choice --
> there is no One Right Answer; it is engineering.
> -- Gaby
> ub mailing list
SG12 list run by herb.sutter at gmail.com