64 bit C++ and OS defined types

[James Kanze]

Would you ever use a signed integer to represent a memory address?

Would you ever use an integral type to represent a memory address?

 

[Bo Persson]

Would you ever use a signed integer to represent a memory address?

No, but perhaps a pointer.


Bo Persson

 

[Tony]

Would you ever use an integral type to represent a memory address?

I use an unsigned integer type, via preprocessor define, that is the
appropriate width for the target platform.

 

[Tony]

* Tony:

In other words, instead of a practical problem one has a clash with
some ideology.
For me (and I guess also for James) choosing between the two is a
no-brainer.

Bad design is bad design. If the language instigates bad design, then it's a
bad language.

 

[Bo Persson]

I use an unsigned integer type, via preprocessor define, that is the
appropriate width for the target platform.

But the question remains: Why is there such a wide demand for storing
adresses in integral type variables? What is wrong with pointers and
references?


Bo Persson

 

[peter koch]

But the question remains: Why is there such a wide demand for storing
adresses in integral type variables? What is wrong with pointers and
references?

Bo Persson

I am not sure that there is such a wide demand, but there are
legitimate reasons that one might want to look at pointeres as ints
that might creep up into many types of of programming. One such
frequent one could be for hashing, other one could be related to
special memory allocators.

/Peter

 

[Bo Persson]

I am not sure that there is such a wide demand, but there are
legitimate reasons that one might want to look at pointeres as ints
that might creep up into many types of of programming. One such
frequent one could be for hashing, other one could be related to
special memory allocators.

Agreed, but there is not much use for a general preprocessor define
here, as hashing would also need to things like how many bits are
actually used (48 out of 64?). The same for a memory alllocator.

You could just use int, or unsigned long long, or perhaps ptrdiff_t,
as appropriate for a specific system. You must know the target system
anyway.


Bo Persson

 

[James Kanze]

I use an unsigned integer type, via preprocessor define, that
is the appropriate width for the target platform.

And when such a type doesn't exist? (Admittedly unlikely today,
with long long, but I've encountered it in the past, with 48 bit
pointers and 32 bit longs, and no larger integral type.)

More to the point, of course, is why? An integer (signed or
otherwise) isn't a pointer, and a pointer isn't an integer. And
there's really not much point in trying to represent one in the
other. (There are a very few cases where I would represent a
small integral value as a pointer, but I can't think of any
where I'd represent a pointer as an integer.)

 

[James Kanze]

I am not sure that there is such a wide demand, but there are
legitimate reasons that one might want to look at pointeres as
ints that might creep up into many types of of programming.
One such frequent one could be for hashing, other one could be
related to special memory allocators.

I don't quite see the use with regards to memory allocators, but
the case of hashing is different: you need to extract an
integral value from a pointer, but you're not representing the
pointer in an integral type---the integral value is something
else, which can't necessarily be reconverted to a pointer.
(Portably hashing pointers is tricky; on many modern machines,
the simplest and best solution is just to consider it as an
array of unsigned char, and hash the array, but I've used
machines where this wouldn't work.) Similarly, it may be
interesting to view a pointer as an array of unsigned char, in
order to "dump" it.

 

[James Kanze]

peter koch wrote:

[...]

Agreed, but there is not much use for a general preprocessor
define here, as hashing would also need to things like how
many bits are actually used (48 out of 64?). The same for a
memory alllocator.

Not only how many bits, but how they are used. On segmented
architectures (IBM mainframes, Intel 16 and 32 bit processors),
you also run the risk that the results of converting to an
integer may result in different values, even when the pointers
compare equal.

For most RISC architectures (and many others: AMD/Intel 64 bits,
and Intel when compiled in small model, where only the offset is
relevant, and in some modes on a modern IBM mainframe), the
obvious solution is just to treat the pointer as an array of
unsigned char, e.g.:

unsigned
hashPtr( void* ptr )
{
unsigned result = 2166136261U ;
unsigned char* current
= reinterpret_cast< unsigned char* >( &ptr ) ;
unsigned char* end = current + sizeof( void* ) ;
while ( current != end ) {
result = 127U * result + *current ;
++ current ;
}
return result ;
}

I don't think I'd consider that "looking at a pointer as an
int".

You could just use int, or unsigned long long, or perhaps
ptrdiff_t, as appropriate for a specific system. You must know
the target system anyway.

On some of the systems I've worked on, the "appropriate" type
would be a struct.

 

[James Kanze]

This is slightly useful in a C-style interfaces which call a
user function and allow the user to pass some data along
unchanged. Rather than using a union:

union Data {
void* p;
int i;
};

void library( void (*user_func)( Data ), Data d )
{
// ...
user_func( d );
}

which involves some inconvenience on the part of the user,
they instead accept an intptr_t (or equivalent if you don't
have stdint.h):

void library( void (*user_func)( intptr_t ), intptr_t d )
{
// ...
user_func( d );
}

This allows the user to pass a plain integer without any work,
or pass a pointer via a cast at the call site and a cast
inside user_func.

If you're talking about things like the argument to
pthread_create, this isn't so much a question of storing a
pointer as an int, as of storing an int as a pointer; the system
passes a void*, with the idea that this can point to anything.
If all you need is a small integral value, of course, converting
it to a pointer to be passed, then converting it back in the
callback, avoids many of the lifetime of object issues involved
if you pass the address of an int, and dereference. Of course,
it also involves a lot of undefined behavior, but in practice,
it will probably work on most Unix machines (and if you're
invoking pthread_create, you're under Unix); the portability
risk may be deamed less a problem than the added complexity of
managing the lifetime of the int designated by the pointer if
you use a real pointer.

 

[Tony]

And when such a type doesn't exist?

I'm really only concerned about 32-bit and 64-bit platforms in my
application development (and I wish I was born a bit later so that 32-bit
would not be a concern).

(Admittedly unlikely today,
with long long, but I've encountered it in the past, with 48 bit
pointers and 32 bit longs, and no larger integral type.)

Note above.

More to the point, of course, is why? An integer (signed or
otherwise) isn't a pointer, and a pointer isn't an integer. And
there's really not much point in trying to represent one in the
other. (There are a very few cases where I would represent a
small integral value as a pointer, but I can't think of any
where I'd represent a pointer as an integer.)

I distinguish "address" from "pointer". But I admit to thinking that
conversion to integral type is OK (I think? I'd have to go look at my
codebase... I'm old and drink a lot ). It has to be, else ptr + offset
and printf of address wouldn't work. I'm not too concerned about the actual
pointer representation as long as the overloading works.

I should have curbed the discussion of pointer representations by using
OFFSET as the example instead of ADDRESS:

maddr whats_my_address; // my define thing called maddr that
// is 4 bytes wide on a 32-bit platform and 8 bytes wide on a
// 64-bit platform.

whats_my_address = (maddr)(some_ptr + some_32bit_offset);