Professional Web Applications Themes

When to use a Ptr vs a Handle? - Mac Programming

Can someone explain, or point me to an explanation of, the difference between Ptrs vs Handles. I've gathered from the docs I've been able to find for functions like NewPtrClear and NewHandleClear that Ptrs are not relocatable and Handles are. But it's not clear to me what the consequences of that are. I.e. when should I use which one? I ask because in the QuickTime examples I've been playing around with the code builds up a TunePlayer which has two parts a header and a queue of note events. In the example the header is a chunk of memory allocated ...

  1. #1

    Default When to use a Ptr vs a Handle?

    Can someone explain, or point me to an explanation of, the difference
    between Ptrs vs Handles. I've gathered from the docs I've been able to
    find for functions like NewPtrClear and NewHandleClear that Ptrs are
    not relocatable and Handles are. But it's not clear to me what the
    consequences of that are. I.e. when should I use which one?

    I ask because in the QuickTime examples I've been playing around with
    the code builds up a TunePlayer which has two parts a header and a
    queue of note events. In the example the header is a chunk of memory
    allocated as a Ptr while the queue is allocated as a Handle. But the
    function prototype for both TuneSetHeader and TuneQueue has the two
    arguments both as "unsigned long*". How does one know which to use or
    does it not matter?

    -Peter

    --
    Peter Seibel com

    Lisp is the red pill. -- John Fraser, comp.lang.lisp
    Peter Guest

  2. #2

    Default Re: When to use a Ptr vs a Handle?

    In article <com>,
    Peter Seibel <com> wrote:
     

    http://developer.apple.com/doentation/mac/Memory/Memory-11.html
    David Guest

  3. #3

    Default Re: When to use a Ptr vs a Handle?

    In article <com>,
    Peter Seibel <com> wrote:
     

    Pointers are references to blocks of memory. Handles are references to
    pointers. The idea was that on machines with relatively little memory
    and no MMU it would be entirely possible to rapidly end up in a
    situation where you wanted memory and you had enough free but it wasn't
    contiguous. With a Handle, the system can move the chunk of memory
    behind your back, updating the pointer to which your handle points so
    you can still get at it via double indirection.

     

    Something of an art. The simple answer is that usually you can decide
    which way to go because the API will actually budge or even force you
    down one path. When you're writing your own stuff, or the API doesn't
    demand a particular course of action, it's kind of on your own
    recognizance. I tend(ed) to favor Handles for pre-OS X development. I
    think that would be more true for things that are kept around for a
    while, and less true for things that were transient.

    G
    Gregory Guest

  4. #4

    Default Re: When to use a Ptr vs a Handle?

    In article <comcast.net>,
    Gregory Weston <com> wrote:
     

    When it doesn't matter for the toolbox, I would suggest that the more
    important considerations than how long it is going to hang around is a)
    will you need to resize the block; if so a handle is usually
    preferable, b) how early can you allocate the block; if you can
    allocate it on system startup along with your other pointer blocks,
    then they can be efficiently allocated and organized, c) (this goes
    along with b)) how long will the block be around; I don't like using
    pointers for transients because it causes "holes" that the OS can't
    fix, and d) how big is the block; really big blocks are more expensive
    in overhead to move around and less likely to create non-reusable
    holes.

    Note that my point c) is contrary to Greg's view in that he is more
    likely to use handles for things that hang around and pointers for
    transients. The problem with this is that if you allocate a transient
    pointer and then then another pointer gets allocated and then you
    dispose of your transient pointer, you have created a hole that the OS
    can't fix. Thus, I use pointers when the block is going to hang around
    forever, particularly if it is large.

    Spence

    --
    James P. Spencer
    Rochester, MN

    "Badges?? We don't need no stinkin badges!"
    James Guest

  5. #5

    Default Re: When to use a Ptr vs a Handle?

    Peter Seibel <com> wrote in message news:<com>... 

    I could write a lot on this subject if you're interested, but briefly,
    pointers a single-dereferenced and are not movable. I can think of
    four kinds of pointers, 1) pointers allocated from the heap such as
    the ones that you are talking about 2) pointers to global variables
    gGlobalVar and 3) pointers to local variables, myLocalVar. 4) master
    pointers which are pointed to by a handle.

    Sometimes, it doesn't matter which kind of pointer that you use. For
    example, if you call BlockMove, you can use any kind of pointer type

    Handles are always allocated from the heap. One of the original ten
    commandments of Mac programming is "Don't be a fakir". Handles are
    doubly-dereferenced, but they have to reference a block allocated from
    the heap with NewHandle, NewHandleClear, etc.

    For your own use, for dynamically allocated objects, you can use
    either pointers or handles. The difference is that pointers cannot be
    moved, but in pre-OS X, they could fragment the heap. That's why
    handles were invented. They are doubly-dereferenced. You application
    keeps track of the handle which points to a "master-pointer". If the
    OS needs to move memory around to make room for an allocation, it can
    move the block referenced by your handle and update the master pointer
    so that you you doubly dereference your handle, you get back to the
    same block.

    Working correctly with handles can be tricky though. Are you
    programming 68K, Power PC, pre-OS X, or OS X?

    Kaydell
    Kaydell Guest

  6. #6

    Default Re: When to use a Ptr vs a Handle?

    com (Kaydell) writes:
     

    OS X. At the moment I'm just observing that in the example code I
    found for the QTMA they use a Ptr for the header argument to
    TuneSetHeader[1] and a Handle for the tune argument to TuneQueue[2],
    both of which are doented as being unsigned long*. The header
    argument is doented as:

    header
    A pointer to a list of instruments that will be used in subsequent
    calls to the TuneQueue function. ... The list is terminated by a
    marker event of subtype kMarkerEventEnd.

    while the tune argument is doented as:

    tune
    A pointer to an array of events, terminated by a marker event of
    subtype kMarkerEventEnd.

    I don't see anything in that doentation that tells me one should be
    a Handle and the other a Ptr unless there's a distinction between a
    pointer to a list and a pointer to an array. But to the extent I
    understand Handles it seems it would matter. It seems if you pass a
    Handle the reciever is going to have to do one more layer of
    indirection than they would if you gave them a Ptr and they have no
    way of knowing which you gave them. Isn't that basically right?

    -Peter

    [1] <http://developer.apple.com/doentation/QuickTime/APIREF/SOURCESIII/tunesetheader.htm>

    [2] <http://developer.apple.com/doentation/QuickTime/APIREF/SOURCESIII/tunequeue.htm>
    --
    Peter Seibel com

    Lisp is the red pill. -- John Fraser, comp.lang.lisp
    Peter Guest

  7. #7

    Default Re: When to use a Ptr vs a Handle?

    In article <300120042237023091%net>,
    James Spencer <net> wrote:
     
    > ...
    > Note that my point c) is contrary to Greg's view in that he is more
    > likely to use handles for things that hang around and pointers for
    > transients. The problem with this is that if you allocate a transient
    > pointer and then then another pointer gets allocated and then you
    > dispose of your transient pointer, you have created a hole that the OS
    > can't fix. Thus, I use pointers when the block is going to hang around
    > forever, particularly if it is large.[/ref]

    Possibly I have used the word transient differently than you read it,
    and I accept responsibility for the ambiguity. When I said transient,
    what I was actually talking about were allocations that didn't tend to
    stick around past the completion of the current pass through the event
    loop. As a result, they don't cause for me the fragmentation that you
    suggested.
    Gregory Guest

  8. #8

    Default Re: When to use a Ptr vs a Handle?

    In article <com>, Peter Seibel <com>
    wrote:
     

    The short answer is that on Mac OS X you should never use a handle unless you
    have to, and you should never create pointers with NewPtr unless you have to.
    Use malloc (and new, in C++), and you will be able to resize your blocks,
    without taking either the performance or the complexity hit of using handles.

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  9. #9

    Default Re: When to use a Ptr vs a Handle?

    Miro Jurisic <org> writes:
     
    >
    > The short answer is that on Mac OS X you should never use a handle
    > unless you have to, and you should never create pointers with NewPtr
    > unless you have to. Use malloc (and new, in C++), and you will be
    > able to resize your blocks, without taking either the performance or
    > the complexity hit of using handles.[/ref]

    Okay, so my question is how do I know when I *have to* use either a
    pointer created with NewPtr or a handle? Unless I'm missing something,
    they're can't be interchangable since one is a pointer to some data
    and the other is a pointer to a pointer to some data. Is there some
    convention in the API doentation that indicates when an unsigned
    long* means a Ptr and when it means a Handle?

    -Peter

    --
    Peter Seibel com

    Lisp is the red pill. -- John Fraser, comp.lang.lisp
    Peter Guest

  10. #10

    Default Re: When to use a Ptr vs a Handle?

    In article <com>, Peter Seibel
    <com> wrote:
     

    You are correct in that they are certainly NOT interchangeable.

    A pointer to a long is NEVER a handle, it is not even a Ptr; it is a
    pointer to to an unsigned long.

    A Handle is very specific: it must be allocated by the Mac memory
    manager. It is technically defined as a pointer to a Ptr (Ptr *) and
    in turn a Ptr is defined as a pointer to a char (char *) but the
    toolbox will not call it a char **; it will call it a Handle when it
    expects a handle. And when it calls it a handle, it expects a handle,
    i.e. specifically a pointer to a pointer to a block of memory allocated
    by the toolbox as a handle, either directly with NewHandle() or through
    a toolbox routine such as GetResource(). When the blocks are created
    this way, the toolbox does its own clerical work. If you try creating
    your own say by mallocing a block and then sticking the resulting
    pointer in some location and then passing a pointer to that location,
    it WILL crash because the toolbox will try to do things to the block
    which it can't do.

    There are some cirstances where the toolbox calls for a data type
    other than Handle but expects a handle but in these cases the defined
    type that will usually include the word "Handle" in it. Thus, some
    Menu Manager functions call for say a MenuBarHandle which if you check
    it's definition you will learn is simply a Handle. The use of the
    specialized data type simply reminds you that the handle needs to be an
    indirect reference to a particular type of data structure.

    Spence

    --
    James P. Spencer
    Rochester, MN

    "Badges?? We don't need no stinkin badges!"
    James Guest

  11. #11

    Default Re: When to use a Ptr vs a Handle?

    James Spencer <net> writes:
     
    >
    > You are correct in that they are certainly NOT interchangeable.
    >
    > A pointer to a long is NEVER a handle, it is not even a Ptr; it is a
    > pointer to to an unsigned long.[/ref]

    Okay. I think I see where I got confused. In the example code they
    make a Handle and then later dereference it and cast that to unsigned
    long*. I though before that they were passing the handle to the
    function that expected an unsigned long*, but missed the dereference.

    So since the QuickTime music functions I care about are written in
    terms of unsigned long*, can I get rid of all this Ptr and Handle
    stuff and use malloc, as another poster suggested?

    -Peter

    --
    Peter Seibel com

    Lisp is the red pill. -- John Fraser, comp.lang.lisp
    Peter Guest

  12. #12

    Default Re: When to use a Ptr vs a Handle?

    In article <com>, Peter Seibel
    <com> wrote:
     

    Can you give a specific example of such a function?

    Generally, you won't need malloc if a function is looking for you to
    pass a pointer to a long; you will allocate the long statically and
    simply pass &myLong. The function calling for a pointer implies that
    the function needs a place to store a long on return. It doesn't mean
    that the memory has to be dynamically allocated.

    Having said that, yes, if the function calls for a unsigned long *,
    then you don't need a Ptr or a Handle and you don't have to use the Mac
    memory manager.

    Spence

    --
    James P. Spencer
    Rochester, MN

    "Badges?? We don't need no stinkin badges!"
    James Guest

  13. #13

    Default Re: When to use a Ptr vs a Handle?

    James Spencer <net> writes:
     
    >
    > Can you give a specific example of such a function?
    >
    > Generally, you won't need malloc if a function is looking for you to
    > pass a pointer to a long; you will allocate the long statically and
    > simply pass &myLong. The function calling for a pointer implies that
    > the function needs a place to store a long on return. It doesn't mean
    > that the memory has to be dynamically allocated.[/ref]

    I think in these functions it's a pointer to a long which is really
    the beginning of an array of longs which is terminated by a specific
    value. Here are the API docs for the two functions in question:

    <http://developer.apple.com/doentation/QuickTime/APIREF/SOURCESIII/tunesetheader.htm>

    <http://developer.apple.com/doentation/QuickTime/APIREF/SOURCESIII/tunequeue.htm>

    -Peter

    --
    Peter Seibel com

    Lisp is the red pill. -- John Fraser, comp.lang.lisp
    Peter Guest

  14. #14

    Default Re: When to use a Ptr vs a Handle?

    In article <com>,
    Peter Seibel <com> wrote:
     

    NewPtr and malloc() give basically the same results, and are nearly
    interchangeable. The exception is that it's bad form (and may crash) to
    use DisposePtr on something you malloc'd, and likewise to free()
    something you got from NewPtr.
    Michael Guest

  15. #15

    Default Re: When to use a Ptr vs a Handle?

    In article <com>, Peter Seibel
    <com> wrote:
     
    > >
    > > Can you give a specific example of such a function?
    > >
    > > Generally, you won't need malloc if a function is looking for you to
    > > pass a pointer to a long; you will allocate the long statically and
    > > simply pass &myLong. The function calling for a pointer implies that
    > > the function needs a place to store a long on return. It doesn't mean
    > > that the memory has to be dynamically allocated.[/ref]
    >
    > I think in these functions it's a pointer to a long which is really
    > the beginning of an array of longs which is terminated by a specific
    > value. Here are the API docs for the two functions in question:
    >
    >
    > <http://developer.apple.com/doentation/QuickTime/APIREF/SOURCESIII/tuneseth
    > eader.htm>
    >
    > <http://developer.apple.com/doentation/QuickTime/APIREF/SOURCESIII/tunequeue.htm>[/ref]

    This was helpful to understand your needs. In this context you can use
    malloc to create your block and then just pass the pointer it creates
    to your function after you have created the data structures in the
    block.

    --
    James P. Spencer
    Rochester, MN

    "Badges?? We don't need no stinkin badges!"
    James Guest

  16. #16

    Default Re: When to use a Ptr vs a Handle?

    In article <mail-9139AF.12342301022004localhost>,
    Michael Ash <com> wrote:
     
    >
    > NewPtr and malloc() give basically the same results, and are nearly
    > interchangeable. The exception is that it's bad form (and may crash) to
    > use DisposePtr on something you malloc'd, and likewise to free()
    > something you got from NewPtr.[/ref]

    Actually, I think you've watered it down a bit. I'd consider
    malloc()/DisposePtr() or NewPtr()/free() to be coding errors and I'd be
    surprised if there wasn't a crash attributable to the mixup.

    G
    Gregory Guest

  17. #17

    Default Re: When to use a Ptr vs a Handle?

    In article <comcast.net>,
    Gregory Weston <com> wrote:
     
    > >
    > > NewPtr and malloc() give basically the same results, and are nearly
    > > interchangeable. The exception is that it's bad form (and may crash) to
    > > use DisposePtr on something you malloc'd, and likewise to free()
    > > something you got from NewPtr.[/ref]
    >
    > Actually, I think you've watered it down a bit. I'd consider
    > malloc()/DisposePtr() or NewPtr()/free() to be coding errors and I'd be
    > surprised if there wasn't a crash attributable to the mixup.[/ref]

    For me, "may crash" is enough of a warning, and a big "Don't Do This"
    sign. I agree that you should never do this. However, I'm on the other
    side of the fence with the "surprise" factor. I entirely expect NewPtr
    to simply call malloc on OS X, and I'd be surprised if anything bad
    happened from mixing the two up. But I do agree that you should never
    never do it anyway.
    Michael Guest

  18. #18

    Default Re: When to use a Ptr vs a Handle?

    In article <mail-795A98.23344901022004localhost>,
    Michael Ash <com> wrote:
     

    It looks like NewPtr does some extra bookkeeping beyond just calling
    malloc. If you disassemble NewPtr on Panther, you'll see that it calls
    CSNewMemPtr, which validates the size that you pass it and calls both
    malloc and malloc_size.

    -Eric

    --
    Eric Albert stanford.edu
    http://rescomp.stanford.edu/~ejalbert/
    Eric Guest

  19. #19

    Default Re: When to use a Ptr vs a Handle?

    Eric Albert <stanford.edu> writes:
     
    >
    > It looks like NewPtr does some extra bookkeeping beyond just calling
    > malloc. If you disassemble NewPtr on Panther, you'll see that it calls
    > CSNewMemPtr, which validates the size that you pass it and calls both
    > malloc and malloc_size.[/ref]

    So does the extra work it does add some benefit? I.e. is there a
    reason to prefer either malloc or NewPtr, assuming one is writing only
    for OS X?

    -Peter

    --
    Peter Seibel com

    Lisp is the red pill. -- John Fraser, comp.lang.lisp
    Peter Guest

  20. #20

    Default Re: When to use a Ptr vs a Handle?

    In article <com>,
    Peter Seibel <com> wrote:
     

    When you resize a NewPtr-allocated pointer, it stays at the same
    position. realloc() doesn't give you that guarantee. So, if you're
    referring to the same pointer in various places, NewPtr() saves you from
    having to update all of them each time.

    Of course, when there isn't enough room to resize the pointer in place,
    NewPtr() fails with memFulErr while realloc() simply gives you a larger
    pointer elsewhere.

    -- Uli
    http://www.zathras.de
    Uli Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. Tie::Handle::CSV Help...
    By onlineviewer in forum PERL Modules
    Replies: 5
    Last Post: July 24th, 10:09 PM
  2. how much XML can Flash handle?
    By Mark.P. in forum Macromedia Flash Data Integration
    Replies: 1
    Last Post: August 26th, 06:02 PM
  3. CFIF - too new to handle this...
    By sjhf in forum Macromedia ColdFusion
    Replies: 1
    Last Post: May 5th, 08:25 PM
  4. handle the IE.
    By Mr. x in forum Macromedia Flash
    Replies: 1
    Last Post: October 8th, 09:33 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139