🚀 go-pugleaf

dag@bellman.control.lth.se (Dag Bruck) writes:

>In the recent discussion on pointer comparisons, Fergus Hendersson
>suggested adding a standard library function ptrcmp() instead of
>extending the definitions of "<" and ">" for pointers.  I think we
>also agreed on a reasonable relationship between ptrcmp() and the
>relational operators.
>
>While I think ptrcmp() is better than nothing, I still think extending
>the definition of the relational operators is far better.
[...]
>3.  The programmer using class Tree must remember to use a different
>class for pointers.  There is no type checking that prevents the user
>from using Tree<Foo*> -- it will compile fine but produce the wrong
>results on some machines.
[...]
>I regard (3) is biggest problem, in particular as there is no way (as
>far as I know) to diagnose the problem.   It may work fine on some
>machines, and then break when you port the code to a new machine or a
>new memory model on the same machine.

The problem is that there are two different sorts of "ordering" operations
that are useful in different circumstances. The first is comparing
pointers to objects in the same array, the second is comparing arbitrary
pointers. On some architectures, the former is much faster than the latter.

Extending the definition of the relational operators would make many programs
considerably less efficient, break some conformant but not strictly conformant
programs, and would create more problems than it would solve, IMHO.

Although ptrcmp() is not a perfect solution as far as template data-structures
go, the alternative would also have difficulties -- what if I want a Tree
of pointers all of which _are_ in the same array, and efficiency is
very important? In that case, Tree<Foo*> is exactly what I want.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!