Is there any compression library for Cocoa?

  • Hi,

    Is there any compression library for Cocoa?

    I actually need a library or framework to compress/de-compress zip
    stream, I've tried so hard trying to find one in web but failed....

    Allen Dang
    <allengnr...>
  • On Thursday, November 29, 2007, at 11:56AM, "Allen Dang" <allengnr...> wrote:
    > Hi,
    >
    > Is there any compression library for Cocoa?
    >
    > I actually need a library or framework to compress/de-compress zip
    > stream, I've tried so hard trying to find one in web but failed....

    Does this help? http://www.cocoadev.com/index.pl?UsingZipFilesExamples
  • On Nov 29, 2007, at 17:55, Allen Dang wrote:

    > Is there any compression library for Cocoa?
    >
    > I actually need a library or framework to compress/de-compress zip
    > stream, I've tried so hard trying to find one in web but failed....

    Try this one:
    http://www.winimage.com/zLibDll/minizip.html

    It's C, but I've been able to write an Objective-C wrapper for the
    unzip part. If you want I can send it to you.

    andy
  • Thanks for your advise, I decide to use zlib to implement compression.

    ÔÚ 2007-11-30£¬ÉÏÎç9:22£¬ Shawn Erickson дµÀ£º

    > On Nov 29, 2007 8:55 AM, Allen Dang <allengnr...> wrote:
    >> Hi,
    >>
    >> Is there any compression library for Cocoa?
    >
    > man zlib

    Allen Dang
    <allengnr...>
  • There's a handy NSData-Compression class in Dustin Mierau's NetSocket
    0.9 sample code available here:

    http://blackholemedia.com/code/

    Here's a snippet from the header file.

    @interface NSData (Compression)
    - (NSData*)compressedData;
    - (NSData*)compressedDataWithLevel:(int)inLevel;
    - (NSData*)uncompressedData;
    @end

    @interface NSMutableData (Compression)
    - (BOOL)compress;
    - (BOOL)uncompress;
    @end
  • > There's a handy NSData-Compression class in Dustin Mierau's NetSocket
    > 0.9 sample code available here:
    >
    > http://blackholemedia.com/code/
    >
    > Here's a snippet from the header file.
    >
    > @interface NSData (Compression)
    > - (NSData*)compressedData;
    > - (NSData*)compressedDataWithLevel:(int)inLevel;
    > - (NSData*)uncompressedData;
    > @end
    >
    > @interface NSMutableData (Compression)
    > - (BOOL)compress;
    > - (BOOL)uncompress;
    > @end

    This code (from above) appears to leak:

    - (NSData*)compressedDataWithLevel:(int)inLevel
    {
        Bytef*    data = (Bytef*)[self bytes];
        uLongf    originalLength = [self length];
        uLongf    bufferLength = ( [self length] * 1.1 ) + 16;
        Bytef*    buffer;
        int        err;

        if( inLevel > NSDataCompressionBest )
            inLevel = NSDataCompressionBest;

        if( inLevel < Z_DEFAULT_COMPRESSION )
            inLevel = NSDataCompressionNone;

        buffer = (Bytef*)malloc( (uInt)bufferLength );
        err = compress2( buffer, &bufferLength, (const Bytef*)data, [self
    length], inLevel );
        if( err != Z_OK )
        {
            free( buffer );
            return nil;
        }

        bcopy( buffer, buffer + sizeof( uLongf ), bufferLength );
        bcopy( (void*)&originalLength, buffer, sizeof( uLongf ) );

        return [NSData dataWithBytesNoCopy:buffer length:bufferLength + sizeof(
    uLongf )];
    }

    If the compression is successful, and I later release the (compressed)
    NSData, buffer is still around, right?

    Is there an update to this code?

    How could I add buffer to a pool of sorts to be released when the object is
    released as it is just malloc'd.

    Thanks,

    Trygve
  • On 30 avr. 08, at 11:24, Trygve Inda wrote:

    > How could I add buffer to a pool of sorts to be released when the
    > object is
    > released as it is just malloc'd.

    I believe that this would do the trick:

    return [NSData dataWithBytesNoCopy:buffer length:bufferLength
    +sizeof(uLongf) freeWhenDone:YES];

    --
    Luc Heinrich - <luc...>
  • On 30 Apr 2008, at 11:24, Trygve Inda wrote:

    > If the compression is successful, and I later release the (compressed)
    > NSData, buffer is still around, right?

    No, from the documentation for + (id)dataWithBytes: length:
    "The returned object takes ownership of the bytes pointer and frees it
    on deallocation. Therefore, bytes must point to a memory block
    allocated with malloc."

    Matt
  • >
    > On 30 Apr 2008, at 11:24, Trygve Inda wrote:
    >
    >> If the compression is successful, and I later release the (compressed)
    >> NSData, buffer is still around, right?
    >
    > No, from the documentation for + (id)dataWithBytes: length:
    > "The returned object takes ownership of the bytes pointer and frees it
    > on deallocation. Therefore, bytes must point to a memory block
    > allocated with malloc."
    >
    > Matt
    >

    So why the need for + dataWithBytesNoCopy:length:freeWhenDone: ?

    It would seem that if freeWhenDone is YES, these are identical calls?

    Trygve
  • On 30 Apr 2008, at 12:35, Trygve Inda wrote:

    > So why the need for + dataWithBytesNoCopy:length:freeWhenDone: ?
    >
    > It would seem that if freeWhenDone is YES, these are identical calls?

    Because sometimes you might want to use NO. i.e maybe its a non-
    malloced buffer that you want to treat as NSData, or maybe just a
    malloced buffer that you need to pass to some method that expects an
    NSData, but you don't want to have to duplicate the entire buffer.

    Matt
  • >
    > On 30 Apr 2008, at 12:35, Trygve Inda wrote:
    >
    >> So why the need for + dataWithBytesNoCopy:length:freeWhenDone: ?
    >>
    >> It would seem that if freeWhenDone is YES, these are identical calls?
    >
    > Because sometimes you might want to use NO. i.e maybe its a non-
    > malloced buffer that you want to treat as NSData, or maybe just a
    > malloced buffer that you need to pass to some method that expects an
    > NSData, but you don't want to have to duplicate the entire buffer.

    I guess the freeWhenDone is a newer call then, otherwise it'd make more
    sense to only have the freeWhenDone variant.

    Thanks,

    Trygve
  • On Apr 30, 2008, at 4:40 AM, Trygve Inda wrote:

    >> On 30 Apr 2008, at 12:35, Trygve Inda wrote:
    >>
    >>> So why the need for + dataWithBytesNoCopy:length:freeWhenDone: ?
    >>>
    >>> It would seem that if freeWhenDone is YES, these are identical
    >>> calls?
    >>
    >> Because sometimes you might want to use NO. i.e maybe its a non-
    >> malloced buffer that you want to treat as NSData, or maybe just a
    >> malloced buffer that you need to pass to some method that expects
    >> an NSData, but you don't want to have to duplicate the entire buffer.
    >
    > I guess the freeWhenDone is a newer call then, otherwise it'd make
    > more sense to only have the freeWhenDone variant.

    -[NSData dataWithBytesNoCopy:length:freeWhenDone] was introduced in
    10.2, but it wouldn't necessarily be out of line to have both calls
    even if they were the same age.  There are lots of methods that are
    convenience wrappers for longer methods, such as the the factory
    methods on many classes or the -[NSString rangeOfString:] variants.

    --Chris Nebel
previous month november 2007 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    
Go to today