Not all implementation-defined behavior are created equal;
I am unsure what the implementation-defined nature of char
signed a signed type or not has to do with this.

I do confess that I don't believe that piece of code is what
should be driving the decision. Why array, and not containers
which are general and more widespread? Is it just because the
novice is using array? If yes, then the answer to that particular question
is: don't use array - which is a sound advice to novices anyway.

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>