Take the 2-minute tour ×

Pointers in C++ may in general only be compared for equality. By contrast, less-than comparison is only allowed for two pointers that point to subobjects of the same complete object (e.g. array elements).

So given T * p, * q, it is illegal in general to evaluate p < q.

The standard library contains functor class templates std::less<T> etc. which wrap the built-in operator <. However, the standard has this to say about pointer types (20.8.5/8):


How can this be realised? Is it even possible to implement this?

I took a look at GCC 4.7.2 and Clang 3.2, which don't contain any specialization for pointer types at all. They seem to depend on < being valid unconditionally on all their supported platforms.

share|improve this question
Isn't it that this simply works because of the linear space of addresses provided by virtual memory? –  jogojapan Nov 14 '12 at 13:50
Huh, I had no idea that it was illegal to compare pointers in that way. –  Rook Nov 14 '12 at 13:51
@R.MartinhoFernandes: Fair enough. If you want a more concrete question, consider this variation: "Is it possible to implement the standard library on targets where pointers do not form a global, total order?" –  Kerrek SB Nov 14 '12 at 13:57
@harold, segmented architectures, 16-bit 80x86, for example. One can imagine that compiler uses only the offset part of a far pointer in <, >, etc. assuming no object crosses segment boundary, but less<T>, etc. could well use the full 20-bit seg:offset. –  chill Nov 14 '12 at 14:12
@Rook: imho comparing pointers is not in general illegal, but in general undefined. –  Zane Nov 16 '12 at 9:37

4 Answers 4

up vote 16 down vote accepted

Can pointers be totally ordered? Not in portable, standard C++. That's why the standard requires the implementation to solve the problem, not you. For any given representation of a pointer, it should be possible to define an arbitrary total ordering, but how you do it will depend on the the representation of a pointer.

For machines with a flat address space and byte addressing, just treating the pointer as if it were a similarly sized integer or unsigned integer is usually enough; this is how most compilers will handle comparison within an object as well, so on such machines, there's no need for the library to specialize std::less et al. The "unspecified" behavior just happens to do the right thing.

For word addressed machines (and there is at least one still in production), it may be necessary to convert the pointers to void* before the compiler native comparison will work.

For machines with segmented architectures, more work may be necessary. It's typical on such machines to require an array to be entirely in one segment, and just compare the offset in the segment; this means that if a and b are two arbitrary pointers, you may end up with !(a < b) && !(b < a) but not a == b. In this case, the compiler must provide specializations of std::less<> et al for pointers, which (probably) extract the segment and the offset from the pointer, and do some sort of manipulation of them.


On other thing worth mentionning, perhaps: the guarantees in the C++ standard only apply to standard C++, or in this case, pointers obtained from standard C++. On most modern systems, it's rather easy to mmap the same file to two different address ranges, and have two pointers p and q which compare unequal, but which point to the same object.

share|improve this answer
I think we have a winner :-) –  Kerrek SB Nov 14 '12 at 14:53
For the "do some sort of manipulation of them" I'd guess it's sufficient to have some ordering on the segments. If two pointers are in the same segment, compare addresses. If they are not, then p1 < p2 if segment(p1) < segment(p2). –  Zane Nov 14 '12 at 14:54
I forgot about the power of converting to void * -- so here's a tangential question: When I convert a pointer to uintptr_t, is that in general not the same as if I first convert to void * and then to uintptr_t? –  Kerrek SB Nov 14 '12 at 15:16
@Zane Maybe, if the compiler can guarantee that it always uses the same segment::offset for any specific object. At least on the old Intels, it was possible to access a given address with quite a number of different segment:offset combinations, and the most rigorous solution was to compare segment*16+offset (calculated using long). –  James Kanze Nov 14 '12 at 15:43
@KerrekSB Good question. I don't know that it's guaranteed, but I can't conceive of a case where you would get something different. On machines where some pointers are smaller than void*, I suspect that the way the compiler would do the conversion would be to first convert to void*, then take the resulting bits. –  James Kanze Nov 14 '12 at 15:45


Yes. Given any finite set you can always define an arbitrary total order over it.

Consider a simple example where you have only five possible distinct pointer values. Let's call these O (for nullptr), γ, ζ, χ, ψ1.

Let's say that no pair of two distinct pointers from the four non-null pointers can be compared with <. We can simply arbitrarily say that std::less gives us this order: O ζ γ ψ χ, even if < doesn't.

Of course, implementing this arbitrary ordering in an efficient manner is a matter of quality of implementation.

1 I am using Greek letters to remove subconscious notion of order that would arise due to familiarity with the latin alphabet; my apologies to readers that know the Greek alphabet order

share|improve this answer
Haha, sneaky. But true :-) –  Kerrek SB Nov 14 '12 at 14:01
OK, then the question is: can this arbitrary total order be made compatible with the subobject ordering of <? Would this actually be a requirement by the standard? –  Kerrek SB Nov 14 '12 at 14:08
@Kerrek no, I have never seen such requirement (I joked on the chat before that the hypothetical Hell++ implementation could have std::less for pointers implemented with p > q and std::greater for pointers just delegate to std::less). –  R. Martinho Fernandes Nov 14 '12 at 14:11
@KerrekSB less<>( p, q ) must be equal to p < q when p < q is defined. Otherwise, all bets are off. –  James Kanze Nov 14 '12 at 14:50
@JamesKanze -- I'm just looking at the draft standard, and I'm not certain that is strictly required. It would be asinine to not do that, I admit. Does the full standard have more strict wording? The draft standard either has 8 overriding 4, or 8 and 4 are inconsistent, or 8 tells you what must happen when 4s behavior is undefined: it does not specify which of these 3 options is true. (presuming consistent interpretations when there is ambiguity seems reasonable... but presuming reasonableness seems a stretch!) –  Yakk Nov 14 '12 at 16:44

On most platforms with a flat address space, they can simply do a numerical comparison between the pointers. On platforms where this isn't possible, the implementer has to come up with some other method of establishing a total order to use in std::less, but they can potentially use a more efficient method for <, since it has a weaker guarantee.

In the case of GCC and Clang, they can implement std::less as < as long as they provide the stronger guarantee for <. Since they are the ones implementing the behavior for <, they can rely on this behavior, but their users can't, since it might change in the future.

share|improve this answer

The problem is segmented architectures, where a memory address has two parts: a segment and an offset. It's "easy enough" to turn those pieces into some sort of linear form, but that takes extra code, and the decision was to not impose that overhead for operator<. For segmented architectures, operator< can simply compare the offsets. This issue was present for earlier versions of Windows.

Note that "easy enough" is a systems programmer's perspective. Different segment selectors can refer to the same memory block, so producing a canonical ordering requires pawing through details of segment mapping, which is platform-dependent and may well be slow.

share|improve this answer

Your Answer


