void* versus uint32*

[john smith]

I have never really understood the difference between the two notations
below.

I often run into code where they are passing in the address of some
location.

Some people do something like this:

foo( void* p_data ) // pass in a pointer to some data

while I see others do this.

foo( uint32* p_data) // pass in a pointer to some data

Can someone please explain to me why you would choose one over the other.

Someone once told me using the uin32 guarantees alignment on a 32 bit
boundary.

Any help is greatly appreciated.

[Karl Heinz Buchegger]

john smith wrote:

I have never really understood the difference between the two notations
below.

I often run into code where they are passing in the address of some
location.

Some people do something like this:

foo( void* p_data ) // pass in a pointer to some data

while I see others do this.

foo( uint32* p_data) // pass in a pointer to some data

Can someone please explain to me why you would choose one over the other.

I use void pointers only to signal to the user of some functionality:
"Here you get a pointer, but is not of your business whats behind
that pointer, leave that alone!"

Eg. I have a geometry engine (from my dark ages). On request that
engine creates an object. It gives back a pointer to that object.
If any operation on that object needs to be done, the users code
has to present that pointer again. So the pointer acts as some sort
of 'handle' to the users code. He gets one from me, he has to present
it again in operations. But he definitly should not care what data
structure is behind that handle.

--
Karl Heinz Buchegger
kb******@gascad.at

[Richard Herring]

In message <42***************@gascad.at>, Karl Heinz Buchegger
<kb******@gascad.at> writes

john smith wrote:

I have never really understood the difference between the two notations
below.

I often run into code where they are passing in the address of some
location.

Some people do something like this:

foo( void* p_data ) // pass in a pointer to some data

while I see others do this.

foo( uint32* p_data) // pass in a pointer to some data

Can someone please explain to me why you would choose one over the other.

Given the choice, use neither.

I use void pointers only to signal to the user of some functionality:
"Here you get a pointer, but is not of your business whats behind
that pointer, leave that alone!"

Eg. I have a geometry engine (from my dark ages). On request that
engine creates an object. It gives back a pointer to that object.
If any operation on that object needs to be done, the users code
has to present that pointer again. So the pointer acts as some sort
of 'handle' to the users code. He gets one from me, he has to present
it again in operations. But he definitly should not care what data
structure is behind that handle.

Ugh. Surely *you* care that what he's giving you back pointers to isn't
garbage, and if you're giving him more than one kind of object, you're
asking for trouble. You'd be far safer giving him a pointer to a
distinct but incomplete type. He still can't tell what lies behind it,
but at least he knows that different structures have different types and
the compiler helps to enforce that their pointers can't be mixed.

Unless you're stuck with a C-style third-party API that mandates it, the
only place for void * is inside library code.

Say what you mean, and mean what you say.

--
Richard Herring

[Karl Heinz Buchegger]

Richard Herring wrote:

Eg. I have a geometry engine (from my dark ages). On request that
engine creates an object. It gives back a pointer to that object.
If any operation on that object needs to be done, the users code
has to present that pointer again. So the pointer acts as some sort
of 'handle' to the users code. He gets one from me, he has to present
it again in operations. But he definitly should not care what data
structure is behind that handle.

Ugh. Surely *you* care that what he's giving you back pointers to isn't
garbage, and if you're giving him more than one kind of object, you're
asking for trouble. You'd be far safer giving him a pointer to a
distinct but incomplete type. He still can't tell what lies behind it,
but at least he knows that different structures have different types and
the compiler helps to enforce that their pointers can't be mixed.

As said: This code originated in the 'dark ages' :-)
But of course, in the debug version the pointer is stored in a map
and checked when given back. Worked reasonable well since more then
10 years with a surprising low number of pointer type mismatches ( that
is *0* in all those >10 years).

--
Karl Heinz Buchegger
kb******@gascad.at

[Howard]

"john smith" <pr**************@charter.net> wrote in message
news:Ps***************@fe08.lga...

I have never really understood the difference between the two notations
below.

I often run into code where they are passing in the address of some
location.

Some people do something like this:

foo( void* p_data ) // pass in a pointer to some data

while I see others do this.

foo( uint32* p_data) // pass in a pointer to some data

Can someone please explain to me why you would choose one over the other.

Someone once told me using the uin32 guarantees alignment on a 32 bit
boundary.

There is no standard type uint32. Apparently, it's something defined by
your compiler's library (such as Visual C++).

I'd use uint32* if I was passing the address of a uint32 variable. It has
nothing whatsoever to do with alignment. It's a pointer to an object of
some known type, and it should point to the type of object it says it points
to! To do anything else would require a cast (and could possibly cause
problems at some point).

Perhaps that person's statement about alignment had to do with choosing the
uint32 type for a variable, such as the one whose address gets passed to
this function. But you should choose variable types based on design
requirements. If the actual size isn't that vital to know, use int, because
that is defined to be the size used by the system it's being compiled for
(e.g., 64 bits for a 64-bit system).

I rarely declare any functions that take a void* pointer. Really, the only
use I have for them is to provide a place for API callbacks to store a
pointer to one of my objects (the one that registers to receive the
callback). That lets me cast the void* pointer to a pointer of the type I
*know* it really is, so that I can call a member function of that object to
actually do the callback work. This kind of trick is needed because the API
generally has no way of knowing what type of object it's going to call back
to, so it calls a free-standing function which I write, which *does* know
the type of object to make the call to.