Re: short pointers (32 bit) in 64 bit apps

["John S. Fine" <johnsfine at verizon dot net>]

Reza Roboubi wrote:
> Trust me, doing this in the compiler is a _much_ more sane, easy to 
> implement, and clean solution.
Trust me instead.  Using C++ and a templated type for the short pointer 
is easy.  Modifying the compiler is hard.   They aren't anywhere close 
to a scale where you might reach the opposite conclusion.

If this were a common requirement (both to save that space despite the 
complications and restrictions, and to do so for programs written in C, 
not C++) then there might be a case to do a difficult project in the 
compiler instead of many people doing simpler projects in their own 
code.  But I doubt you will convince any experienced GCC maintainer that 
this will be a common requirement.
> If you use C++ templates, it can get crazy very quickly:  imagine 
> trying to reference this template based object (using a void short **) 
> (for passing to a generic function like memcpy.)
The template would obviously have a conversion operator to the correct 
type of ordinary pointer, which you might further cast to void* if you 
wanted to use it with memcpy etc.  But I can't think of any reason you 
might want anything like void short** to ever exist.

> It's an awful mess!  The more you try to "fix" it, the more you 
> realize it's broken.  The reason is that this 
> "type-first-logic-second" mentality of C++ is just WRONG at a 
> fundamental level, and that cannot be fixed.
I won't try further to fix your bias against C++, I assume that wouldn't 
be possible.