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

[Reza Roboubi <reza@parvan.net>]

Andrew Haley wrote:
>> Essentially, you would want a pointer type modifier:
>>
>> struct list {
>>   struct list short * next;
>> };
>>
>>> Then you can add the top 32-bits to pointer addresses within your data
>>> structure before you attempt to dereference them.
>> That's the point:  not having to do this manually.
> 
> I don't see the point of changing the language.  Define a custom allocator
> and store the pointers in uint32_t variables.  C++ makes this very easy:
> see below.
> 
> Andrew.
> 
> #include <cstdint>
> #include <cstdio>
> 
> template<class T> class shortptr
> {
 > [...]

---------------------------------------
Two more quotes from Linus Torvalds:
"C++ leads to really really bad design choices [...]"
"the whole C++ exception handling thing is fundamentally broken. It's
    _especially_ broken for kernels"
---------------------------------------

Trust me, doing this in the compiler is a _much_ more sane, easy to 
implement, and clean solution.  As Ian Taylor said, you just need some 
tweaking of loads and stores.  That, and the "short" language keyword.
(The problem is that gcc is huge and complex for getting started.)

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.)  Now suddenly, you must 
write another template to represent that (assuming C++ even allows that, 
and the g++ implementation of "void **" or "char **" templates is bug 
free.)  You must then make your generic function("memcpy") aware of 
these types, which wasn't part of the original design plan (it's really 
crazy!)  Then, you'll have to write type converters (say what!) to go 
back and forth between all these templates.

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.

C++ _might_ be useful for something like KDE, but then again GUI people 
don't need things like "short pointers" in the first place.

Reza.