Christopher Jefferson <chris_at_[hidden]> writes:

| 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
| undefinedf behaviour?

Indeed.

At the Chicago meeting, Matt Austern and I had conversations over
two days on this issue, and I believe we came to a conclusion that I
think would satisfy the concerns I've, it would also satisfy some of the
conerns he had. It would be to form a wording that restrict the
behavior -- but it wasn't 'implementation-defined' which is a much
stronger requirement, I believe. The avenue still needs investigations
but I am relatively confident about it.

At one evening, I believe Jeffrey was explaining to me that would be one
possible solution, but it wouldn't solve the real problems they were
having in library, which is that they need an ordering; defining
operator< on pointers while useful for many cases still does not solves
what happens for std::complex<T>, etc.

-- Gaby

|
| 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
| ought
| | 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
| far
| 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
| ub_at_[hidden]
| http://www.open-std.org/mailman/listinfo/ub