C++ Logo


Advanced search

Re: [ub] Justification for < not being a total order on pointers?

From: Jeffrey Yasskin <jyasskin_at_[hidden]>
Date: Mon, 26 Aug 2013 11:26:56 -0700
On Mon, Aug 26, 2013 at 11:12 AM, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> Chandler Carruth <chandlerc_at_[hidden]> writes:
> | The freedom that optimizing compilers very deeply need is that the
> | ordering be totally unspecified.
> Is that enough for what people want when they wish for operator< to be a
> total order?

Certainly some people want to guarantee:

void foo() {
  int a;
  int b;
  assert(&a < &b);

but they're wrong. ;) When I suggest that < should be a total order on
pointers, I don't mean any more than what we've already specified for
std::less<T*>. The ordering should be unspecified beyond being a total

> | So long as we keep this, I have no knowledge of significant negative
> | impacts on optimizing compilers. If you have other specific
> | optimizations, please bring them up (clearly, I'm not familiar with
> | all optimizing compilers! ;])
> See above. Note also that I've been careful making a distinction
> between "optimization" and "program transformation" -- the former appear
> to be loaded (usually with emotions both ways), while the latter
> describes a wide range of things compilers and static analysis tools do.

I think "program transformation" isn't precise enough. Certainly there
are many transformations that could rely on any piece of unspecified
behavior, but as long as they're only transformations, I have no
problem banning them. If they're also optimizations or debugging aids
or serve some other purpose, then we actually have to decide on a


Received on 2013-08-26 20:27:17