autorelease CGImageRef?

  • Given a CGImageRef, how can I autorelease it?

    Perhaps this is obvious, or perhaps its impossible, but googling
    hasn't found me the answer yet except for a tantalizing comment in
    the docs for NSBitmapImageRep:

    - (CGImageRef)CGImage (added in 10.5)
    "Returns an autoreleased CGImage object (an opaque type) from the
    receiver's current bitmap data."

    For CFStringRef, I know I can cast it to an NSString* and then
    autorelease it, but is there an equivalent for CGImageRef?

    Thanks,
        Peter.

    --
                  Keyboard Maestro 3 Now Available!
                    Now With Status Menu triggers!

    Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your Mac
    <>          <<A href="http://download.stairways.com/">http://download.stairways.com/>
  • Since CGImage is derived from CFType you can just do:

    [(id)aCGImageRef autorelease]

    The reason being that CFType knows how to handle a -release message,
    and autorelease is just a way of deferring that message.

    On 6 Aug 2008, at 09:29, Peter N Lewis wrote:

    > Given a CGImageRef, how can I autorelease it?
    >
    > Perhaps this is obvious, or perhaps its impossible, but googling
    > hasn't found me the answer yet except for a tantalizing comment in
    > the docs for NSBitmapImageRep:
    >
    > - (CGImageRef)CGImage (added in 10.5)
    > "Returns an autoreleased CGImage object (an opaque type) from the
    > receiver's current bitmap data."
    >
    > For CFStringRef, I know I can cast it to an NSString* and then
    > autorelease it, but is there an equivalent for CGImageRef?
    >
    > Thanks,
    > Peter.
    >
    > --
    > Keyboard Maestro 3 Now Available!
    > Now With Status Menu triggers!
    >
    > Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your Mac
    > <>          <<A href="http://download.stairways.com/">http://download.stairways.com/
  • Be carefull when you mix CFType memory management, and obj-c memory
    management.
    It works well when you do not use GC, but may become problematic if
    you do not take special care with GC code.

    If I'm not wrong, it should be something like this:

    [NSMakeCollectable(aCGImageRef) autorelease];

    Le 6 août 08 à 12:16, Mike Abdullah a écrit :

    > Since CGImage is derived from CFType you can just do:
    >
    > [(id)aCGImageRef autorelease]
    >
    > The reason being that CFType knows how to handle a -release message,
    > and autorelease is just a way of deferring that message.
    >
    > On 6 Aug 2008, at 09:29, Peter N Lewis wrote:
    >
    >> Given a CGImageRef, how can I autorelease it?
    >>
    >> Perhaps this is obvious, or perhaps its impossible, but googling
    >> hasn't found me the answer yet except for a tantalizing comment in
    >> the docs for NSBitmapImageRep:
    >>
    >> - (CGImageRef)CGImage (added in 10.5)
    >> "Returns an autoreleased CGImage object (an opaque type) from the
    >> receiver's current bitmap data."
    >>
    >> For CFStringRef, I know I can cast it to an NSString* and then
    >> autorelease it, but is there an equivalent for CGImageRef?
    >>
    >> Thanks,
    >> Peter.
    >>
    >> --
    >> Keyboard Maestro 3 Now Available!
    >> Now With Status Menu triggers!
    >>
    >> Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your
    >> Mac
    >> <http://www.stairways.com/>          <http://
    >> download.stairways.com/

    >
  • Am Mi,06.08.2008 um 14:26 schrieb Jean-Daniel Dupas:

    > Be carefull when you mix CFType memory management, and obj-c memory
    > management.
    > It works well when you do not use GC, but may become problematic if
    > you do not take special care with GC code.
    IIRC, there are some rules:
    1 GC respects reference counting. That means, that GC will not
    deallocate any instance with an RC greater than 0.
    2 RC methods of objective-C (-retain, -release) are "dead". That means
    that no change of the RC is applied.
    3 (1+2) Using GC and -retain, -release leads to the situation, that
    the RC is never greater than 0. So GC behaves as intended: GC respects
    the RC, but there is no RC to respect. (Even it works: You should not
    mix up GC and RC methods.)
    4 RC functions of CF are still working. That means, that they do
    change the RC.
    5 (1+4) Using CF-RC leads to the situation, that (by CF) referenced
    instances are not collected by the GC.

    5 is a feature, because you can hold instances in memory without
    having a reference to it.

    Amin

    >
    >
    > If I'm not wrong, it should be something like this:
    >
    > [NSMakeCollectable(aCGImageRef) autorelease];
    >
    >
    > Le 6 août 08 à 12:16, Mike Abdullah a écrit :
    >
    >> Since CGImage is derived from CFType you can just do:
    >>
    >> [(id)aCGImageRef autorelease]
    >>
    >> The reason being that CFType knows how to handle a -release
    >> message, and autorelease is just a way of deferring that message.
    >>
    >> On 6 Aug 2008, at 09:29, Peter N Lewis wrote:
    >>
    >>> Given a CGImageRef, how can I autorelease it?
    >>>
    >>> Perhaps this is obvious, or perhaps its impossible, but googling
    >>> hasn't found me the answer yet except for a tantalizing comment in
    >>> the docs for NSBitmapImageRep:
    >>>
    >>> - (CGImageRef)CGImage (added in 10.5)
    >>> "Returns an autoreleased CGImage object (an opaque type) from the
    >>> receiver's current bitmap data."
    >>>
    >>> For CFStringRef, I know I can cast it to an NSString* and then
    >>> autorelease it, but is there an equivalent for CGImageRef?
    >>>
    >>> Thanks,
    >>> Peter.
    >>>
    >>> --
    >>> Keyboard Maestro 3 Now Available!
    >>> Now With Status Menu triggers!
    >>>
    >>> Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your
    >>> Mac
    >>> <>          <<A href="http://download.stairways.com/">http://download.stairways.com/
    >>> >


    >>


    Amin Negm-Awad
    <negm-awad...>
  • On Wed, Aug 6, 2008 at 6:08 AM, Negm-Awad Amin <negm-awad...> wrote:
    >
    > Am Mi,06.08.2008 um 14:26 schrieb Jean-Daniel Dupas:
    >
    >> Be carefull when you mix CFType memory management, and obj-c memory
    >> management.
    >> It works well when you do not use GC, but may become problematic if you do
    >> not take special care with GC code.
    >
    > IIRC, there are some rules:

    Likely best to point folks at the documentation...

    <http://developer.apple.com/documentation/Cocoa/Conceptual/GarbageCollection
    /Articles/gcCoreFoundation.html
    >

    -Shawn
  • At 7:48 AM -0700 6/8/08, Shawn Erickson wrote:

    Yes, that is quite helpful (except that the imagined implementation
    of CFMakeCollectable omits the fact that it is a no-op in managed
    memory mode).

    This email sent to <peter...> 2:26 PM +0200 6/8/08,
    Jean-Daniel Dupas wrote:
    > If I'm not wrong, it should be something like this:
    >
    > [NSMakeCollectable(aCGImageRef) autorelease];

    This appears correct, except for the fact that, for reasons known
    only to Apple, although CFMakeCollectable is available in 10.4, the
    trivial NSMakeCollectable macro is available only in 10.5.  So
    expanding the NSMakeCollectable macro gives:

    return [(id)CFMakeCollectable(aCGImageRef) autorelease];

    However, the working of this line of code is rather subtle.

    In memory managed mode CFMakeCollectable is a no-op and autorelease
    works, so the code is equivalent to

    return [(id)aCGImageRef autorelease];

    while in garbage collected mode, CFMakeCollectable is equivalent to
    CFRelease, and autorelease is a no-op, so the code is equivalent to:

    CFRelease(aCGImageRef);
    return (id)aCGImageRef

    The documentation is well worth readings because it is quite tricky
    the way CFRetain/CFRelease always work, even in garbage collection
    mode, and CFRetainCount > 0 stops garbage collection from happening
    on the object, while retain/release/autorelease work only in memory
    managed mode and are no-ops in garbage collection mode (that part is
    well known I think).

    Thanks for the enlightenment!
        Peter.
    --
                  Keyboard Maestro 3 Now Available!
                    Now With Status Menu triggers!

    Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your Mac
    <>          <<A href="http://download.stairways.com/">http://download.stairways.com/>
  • The hope is that most people are either writing GC code, in which case
    CFMakeCollectable is a less scary looking version of CFRelease, or
    non-GC code in which case they aren't using the function at all.

    However, for people who are writing code that needs to work both ways,
    here's how I think of it:

    (1) You need to balance the NS reference count and the CF reference
    count separately.
    (2) NSMakeCollectable transfers one reference from the CF column to
    the NS column.

    Ken Ferry
    Cocoa Frameworks

    On Wed, Aug 6, 2008 at 7:44 PM, Peter N Lewis <peter...> wrote:
    > At 7:48 AM -0700 6/8/08, Shawn Erickson wrote:
    >>
    >> Likely best to point folks at the documentation...
    >>
    >>
    >> <http://developer.apple.com/documentation/Cocoa/Conceptual/GarbageCollection
    /Articles/gcCoreFoundation.html
    >
    >
    > Yes, that is quite helpful (except that the imagined implementation of
    > CFMakeCollectable omits the fact that it is a no-op in managed memory mode).
    >
    > This email sent to <peter...> 2:26 PM +0200 6/8/08,
    > Jean-Daniel Dupas wrote:
    >>
    >> If I'm not wrong, it should be something like this:
    >>
    >> [NSMakeCollectable(aCGImageRef) autorelease];
    >
    > This appears correct, except for the fact that, for reasons known only to
    > Apple, although CFMakeCollectable is available in 10.4, the trivial
    > NSMakeCollectable macro is available only in 10.5.  So expanding the
    > NSMakeCollectable macro gives:
    >
    > return [(id)CFMakeCollectable(aCGImageRef) autorelease];
    >
    > However, the working of this line of code is rather subtle.
    >
    > In memory managed mode CFMakeCollectable is a no-op and autorelease works,
    > so the code is equivalent to
    >
    > return [(id)aCGImageRef autorelease];
    >
    > while in garbage collected mode, CFMakeCollectable is equivalent to
    > CFRelease, and autorelease is a no-op, so the code is equivalent to:
    >
    > CFRelease(aCGImageRef);
    > return (id)aCGImageRef
    >
    > The documentation is well worth readings because it is quite tricky the way
    > CFRetain/CFRelease always work, even in garbage collection mode, and
    > CFRetainCount > 0 stops garbage collection from happening on the object,
    > while retain/release/autorelease work only in memory managed mode and are
    > no-ops in garbage collection mode (that part is well known I think).
    >
    > Thanks for the enlightenment!
    > Peter.
    > --
    > Keyboard Maestro 3 Now Available!
    > Now With Status Menu triggers!
    >
    > Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your Mac
    > <>          <<A href="http://download.stairways.com/">http://download.stairways.com/
    >
  • On 8/7/08 10:44 AM, Peter N Lewis said:

    >> [NSMakeCollectable(aCGImageRef) autorelease];
    >
    > This appears correct, except for the fact that, for reasons known
    > only to Apple, although CFMakeCollectable is available in 10.4, the
    > trivial NSMakeCollectable macro is available only in 10.5.

    Yes, quite annoying.

    > So expanding the NSMakeCollectable macro gives:
    >
    > return [(id)CFMakeCollectable(aCGImageRef) autorelease];

    True, but that cast can cause warnings, and so having it in a system
    header is nice.  If you can, use the NS version.  Consider:

    --------
    #import <Cocoa/Cocoa.h>

    int main (void)
    {
    CFStringRef foo = nil;

    [NSMakeCollectable(foo) autorelease];
    [(id)CFMakeCollectable(foo) autorelease]; //line 8

    return 0;
    }
    --------

    $ gcc-4.2 -Wcast-qual /Users/sean/Desktop/test.m
    /Users/sean/Desktop/test.m: In function 'main':
    /Users/sean/Desktop/test.m:8: warning: cast discards qualifiers from
    pointer target type

    I suspect that's why the NS version was later added.

    --
    ____________________________________________________________
    Sean McBride, B. Eng                <sean...>
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
  • On Aug 6, 2008, at 7:44 PM, Peter N Lewis wrote:

    > This email sent to <peter...> 2:26 PM +0200 6/8/08,
    > Jean-Daniel Dupas wrote:
    >> If I'm not wrong, it should be something like this:
    >>
    >> [NSMakeCollectable(aCGImageRef) autorelease];
    >
    > This appears correct, except for the fact that, for reasons known
    > only to Apple, although CFMakeCollectable is available in 10.4, the
    > trivial NSMakeCollectable macro is available only in 10.5.

    If you build with the Mac OS X 10.5 SDK, you should be able to use
    NSMakeCollectable since it's declared as an inline function.

    The earliest release of Mac OS X you're targeting is a function of the
    Mac OS X Deployment Target build setting, not the SDK.

      -- Chris
  • At 8:24 AM -0700 7/8/08, Chris Hanson wrote:
    > If you build with the Mac OS X 10.5 SDK, you should be able to use
    > NSMakeCollectable since it's declared as an inline function.
    >
    > The earliest release of Mac OS X you're targeting is a function of
    > the Mac OS X Deployment Target build setting, not the SDK.

    That's true, but its not safe to do so.

    For example, that will allow kCGBlendModeCopy to be used, even though
    its not available in 10.4.

    Thanks,
        Peter.

    --
                  Keyboard Maestro 3 Now Available!
                    Now With Status Menu triggers!

    Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your Mac
    <>          <<A href="http://download.stairways.com/">http://download.stairways.com/>
  • Am 07.08.2008 um 17:24 schrieb Chris Hanson:

    >> This appears correct, except for the fact that, for reasons known
    >> only to Apple, although CFMakeCollectable is available in 10.4, the
    >> trivial NSMakeCollectable macro is available only in 10.5.
    >
    > If you build with the Mac OS X 10.5 SDK, you should be able to use
    > NSMakeCollectable since it's declared as an inline function.
    >
    > The earliest release of Mac OS X you're targeting is a function of
    > the Mac OS X Deployment Target build setting, not the SDK.

    In theory:
    - The Xcode 2.4  10.4 SDK allows deployment on ANY 10.4 version,
    - The Xcode 2.5 / 3.x  SDKs for  10.4 and 10.5 SDKs allow deployment
    on recently updated 10.4 versions:

    < http://www.tom-e.org/2008/04/pimp-my-xcode-sdk/>

    These differences are AFAIK not covered in any release notes.

    Regards,
    Tom_E
  • Le 8 août 08 à 16:17, Thomas Engelmeier a écrit :

    >
    > Am 07.08.2008 um 17:24 schrieb Chris Hanson:
    >
    >>> This appears correct, except for the fact that, for reasons known
    >>> only to Apple, although CFMakeCollectable is available in 10.4,
    >>> the trivial NSMakeCollectable macro is available only in 10.5.
    >>
    >> If you build with the Mac OS X 10.5 SDK, you should be able to use
    >> NSMakeCollectable since it's declared as an inline function.
    >>
    >> The earliest release of Mac OS X you're targeting is a function of
    >> the Mac OS X Deployment Target build setting, not the SDK.
    >
    >
    > In theory:
    > - The Xcode 2.4  10.4 SDK allows deployment on ANY 10.4 version,
    > - The Xcode 2.5 / 3.x  SDKs for  10.4 and 10.5 SDKs allow deployment
    > on recently updated 10.4 versions:
    >
    > < http://www.tom-e.org/2008/04/pimp-my-xcode-sdk/>

    Only as long as you set the deployment target to 10.4 of course.
    An application compiled using 10.5 SDK and deployment target sets to
    10.5 will not run on 10.4.
  • Am 08.08.2008 um 16:23 schrieb Jean-Daniel Dupas:

    >> In theory:
    >> - The Xcode 2.4  10.4 SDK allows deployment on ANY 10.4 version,
    >> - The Xcode 2.5 / 3.x  SDKs for  10.4 and 10.5 SDKs allow
    >> deployment on recently updated 10.4 versions:
    >>
    >> < http://www.tom-e.org/2008/04/pimp-my-xcode-sdk/>
    >
    >
    > Only as long as you set the deployment target to 10.4 of course.
    > An application compiled using 10.5 SDK and deployment target sets to
    > 10.5 will not run on 10.4.

    Well, personally I'd expect an app linked against the 10.4 SDK  from
    Xcode 3 / 2.5 to run on any version of 10.4, otherwise I'd expect it's
    name to be like 10.3.9 SDK.

    Regards,
    Tom_E
  • On Aug 7, 2008, at 7:07 PM, Peter N Lewis wrote:

    > At 8:24 AM -0700 7/8/08, Chris Hanson wrote:
    >> If you build with the Mac OS X 10.5 SDK, you should be able to use
    >> NSMakeCollectable since it's declared as an inline function.
    >>
    >> The earliest release of Mac OS X you're targeting is a function of
    >> the Mac OS X Deployment Target build setting, not the SDK.
    >
    > That's true, but its not safe to do so.
    >
    > For example, that will allow kCGBlendModeCopy to be used, even
    > though its not available in 10.4.

    It is as safe as it ever was.  You just need to put in checks for what
    OS you're running on around places you use functionality from the
    newer release(s).

    Where it gets complex is trying to message or (even more so) subclass
    new 10.5 classes in code that also needs to run on 10.4.

      -- Chris
  • At 3:19 PM -0700 8/8/08, Chris Hanson wrote:
    > On Aug 7, 2008, at 7:07 PM, Peter N Lewis wrote:
    >
    >> At 8:24 AM -0700 7/8/08, Chris Hanson wrote:
    >>> If you build with the Mac OS X 10.5 SDK, you should be able to use
    >>> NSMakeCollectable since it's declared as an inline function.
    >>>
    >>> The earliest release of Mac OS X you're targeting is a function of
    >>> the Mac OS X Deployment Target build setting, not the SDK.
    >>
    >> That's true, but its not safe to do so.
    >>
    >> For example, that will allow kCGBlendModeCopy to be used, even
    >> though its not available in 10.4.
    >
    > It is as safe as it ever was.  You just need to put in checks for
    > what OS you're running on around places you use functionality from
    > the newer release(s).

    My point is, the compiler will not tell you that you are using a
    constant like kCGBlendModeCopy that is not supported in 10.4 if you
    use the 10.5 SDK with Deployment Target 10.4.  On the other hand, the
    compiler will tell you if you try to use kCGBlendModeCopy with the
    10.4 SDK because it's not defined.  You can still manually define it
    and use it, but you have to go out of your way to do it - as you
    should if you want your code to work on 10.4 first time instead of
    after a lot of beta testing.

    So I'll stick with the 10.4 SDK until I really have to use something
    difficult from 10.5, by which time I will hopefully be able to drop
    10.4 entirely.

    Thanks,
        Peter.

    --
                  Keyboard Maestro 3 Now Available!
                    Now With Status Menu triggers!

    Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your Mac
    <>          <<A href="http://download.stairways.com/">http://download.stairways.com/>
previous month august 2008 next month
MTWTFSS
        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
Go to today