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.
