So yes this Binary tree is one place where things will go wrong...
At some point we might need to include <stdint.h> or otherwise get uintptr_t defined.
Remember including headers is always an issue with the bootstrapping system as well...
uintptr_t can be used to define a variable the same size as a pointer (32 or 64 bits)
(The size of long is NOT reliable between different common compilers/platforms).
We could define BTNode's key as a uintptr_t, and use it for CompareKey as well, to keep it 32 bit in 32 bit mode... Or we could simply always make it 64 bit.
The problem is places where BTNode is used, it is often replaced completely by another struct, e.g.:
Code: Select all
public class Method : struct
{
public:
class_fixed
char * name;
Method parent, left, right;
int depth;But in other places the BTNode key might be used as an int...
So it would have to be mapped to either a uint64 if we decide to standardize on 64 bit, or a uintptr_t (or a pointer, so this particular case wouldn't need to change) if we decide to standardize on the pointer size. By the way, I'd like to define a new eC data type mapping to uintptr_t...
Maybe uintptr? Better suggestion?
Note that we still have the legacy (BinaryTree/BTNode) and new (AVLTree/CustomAVLTree/AVLNode) AVL binary tree implementation. The new one uses the template system, which may require some 64 bit fixes as well. However luckily I had settled on a uint64 for the template types so that it could accomodate all types up to a uint64/double, so we might be covered on there.
At some point we still need to migrate completely to the new containers, starting perhaps from the ecereCOM implementation and then working our way up to the eC compiler library (then we might not even have this problem at all =) Not sure what will get us where we want faster in this case...
