Thanks to everyone who is interested in this. Alas, I'm sure I'm not the only one who hasn't been able to keep up with the whole thread.

A request: Whenever this thread wraps up, it would be useful if a small paper (or just email to EWG) report would summarize the reasons why we should NOT require < on T* to have identical semantics to today's less<T*>. I think that summary would be helpful.

Thanks,

Herb


From: ub-bounces_at_[hidden] [mailto:ub-bounces_at_[hidden]] On Behalf Of Nevin Liber
Sent: Friday, October 18, 2013 10:13 AM
To: WG21 UB study group
Subject: Re: [ub] Canonical ordering

On 18 October 2013 01:46, Christopher Jefferson <chris_at_[hidden]<mailto:chris_at_[hidden]>> wrote:

Here is a suggestion. How about we make the result of comparing pointers from different allocations into implementation-defined behaviour?
While it gets it out of this group, I don't think that addresses the real problem.

Of course, if you think that:

bool isInArray = std::begin(a) <= p && p < std::end(a);

is an unreasonable piece of code, there are no problems. :-) If you think it is reasonable, I don't see how making it implementation-defined behavior stops the optimizer from rewriting that as:

bool isInArray = static_cast<bool>(p);

(possibly even 'isInArray = true;', but I'd have to study the rules for nullptrs to see if this is allowed)

And developers can't count on implementation-defined behavior in portable code. Look at all the pain people go through because C didn't nail down (for valid reasons at the time) the signness of char. And the implementation-defined behavior of the representation of char only has two possible outcomes...

--
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]<mailto:nevin_at_[hidden]>>  (847) 691-1404<tel:%28847%29%20691-1404>