Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > void* versus uint32*

Reply
Thread Tools

void* versus uint32*

 
 
john smith
Guest
Posts: n/a
 
      04-01-2005
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.


 
Reply With Quote
 
 
 
 
Karl Heinz Buchegger
Guest
Posts: n/a
 
      04-01-2005
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
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
Richard Herring
Guest
Posts: n/a
 
      04-01-2005
In message <(E-Mail Removed)>, Karl Heinz Buchegger
<(E-Mail Removed)> 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
 
Reply With Quote
 
Karl Heinz Buchegger
Guest
Posts: n/a
 
      04-01-2005
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
(E-Mail Removed)
 
Reply With Quote
 
Howard
Guest
Posts: n/a
 
      04-01-2005

"john smith" <(E-Mail Removed)> wrote in message
newssb3e.731$(E-Mail Removed)...
>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.





 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Mozilla versus IE versus Opera versus Safari Peter Potamus the Purple Hippo Firefox 0 05-08-2008 12:56 PM
equal? versus eql? versus == versus === verus <=> Paul Butcher Ruby 12 11-28-2007 06:06 AM
Certification - MCP versus MCSA versus MCSE =?Utf-8?B?Q2FuYWRhX0d1eU0=?= Microsoft Certification 1 08-24-2006 06:33 PM
script versus code versus ? Russ ASP .Net 1 06-10-2004 03:06 AM
HTML Client Control versus. HTML Server Control versus. Web Server Control Matthew Louden ASP .Net 1 10-11-2003 07:09 PM



Advertisments