void* versus uint32*

Discussion in 'C++' started by john smith, Apr 1, 2005.

  1. john smith

    john smith Guest

    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.
    john smith, Apr 1, 2005
    #1
    1. Advertising

  2. 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
    Karl Heinz Buchegger, Apr 1, 2005
    #2
    1. Advertising

  3. In message <>, Karl Heinz Buchegger
    <> 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
    Richard Herring, Apr 1, 2005
    #3
  4. 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
    Karl Heinz Buchegger, Apr 1, 2005
    #4
  5. john smith

    Howard Guest

    "john smith" <> wrote in message
    news:psb3e.731$...
    >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.
    Howard, Apr 1, 2005
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ollej Reemt
    Replies:
    7
    Views:
    501
    Jack Klein
    Apr 22, 2005
  2. Stig Brautaset

    `void **' revisited: void *pop(void **root)

    Stig Brautaset, Oct 25, 2003, in forum: C Programming
    Replies:
    15
    Views:
    778
    The Real OS/2 Guy
    Oct 28, 2003
  3. Andrew Markebo
    Replies:
    1
    Views:
    752
    Peter Hansen
    Nov 17, 2004
  4. Replies:
    5
    Views:
    815
    S.Tobias
    Jul 22, 2005
  5. Paul Butcher
    Replies:
    12
    Views:
    693
    Gary Wright
    Nov 28, 2007
Loading...

Share This Page