🚀 go-pugleaf

In article <1992Dec14.075853.3399@lth.se> dag@bellman.control.lth.se (Dag Bruck) writes:
|		if (element < root->element)
|			return InsertElement(root->left, element);
|		if (root->element < element)
|			return InsertElement(root->right, element);
|		return root->element;
|	}
|
|Note that a copy of the element argument is inserted into the tree,
|and that InsertElement() always returns a reference to this copy.
|
|Now, here's the problem: this implementation works fine for all
|element types that have an "operator < ()" including plain built-in
|types and many user-defined types.  However, it is not guaranteed to
|work with pointer elements for reasons we have discussed before.

I disagree.  Consider an implementation that fully implements a "strict"
interpretation of IEEE doubles.  Such an implementation fails to "work"
for exactly the same reason as the pointer implementations in question.
Namely your implementation assumes "<" always returns an ordering, 
but neither IEEE doubles, PC pointers, nor user implemented classes
may interpret "<" in such a manner.  In the case of PC pointers all
pointers must be to the same array for your code to work.  In the
case of a strict implementation of IEEE numbers there better not be
any NANs presented to this code.  In the case of user implemented
classes, god only knows what "<" might mean -- I/O an element up
the wazoo, for all we know!

This is not an issue of "<" at all, rather it is an issue of templates.
Templates in C++ are the equivalent to "accidental reuse" in Smalltalk.
If the syntax fits, you've got a template class, no matter that the
semantics don't work.  No matter how slow you make pointers, you still
are left with this template "accidental reuse" problem.

======

"Trust the programmer."

"Make it fast, even if it is not guaranteed to be portable."

-- The ANSI-C Rationale