Re: NSData questions (including Altivec)
Re: NSData questions (including Altivec)
- Subject: Re: NSData questions (including Altivec)
- From: Timo Naroska <email@hidden>
- Date: Tue, 21 Sep 2004 12:04:18 +0200
Hi,
there's also the possibility of allocating the data buffer yourself via malloc()
and creating the NSData object with a no-copy initializer like:
+ (id)dataWithBytesNoCopy:(void *)bytes length:(unsigned)length
or
+ (id)dataWithBytesNoCopy:(void *)bytes length:(unsigned)length freeWhenDone:(BOOL)freeWhenDone;
Also, be aware that NSData is toll-free bridged with its CoreFoundation counterpart CFData
which gives you even more custom functionality using CFAllocators:
CFDataRef CFDataCreateWithBytesNoCopy (
CFAllocatorRef allocator,
const UInt8 *bytes,
CFIndex length,
CFAllocatorRef bytesDeallocator
);
-Timo
Nicko van Someren wrote:
On 21 Sep 2004, at 1:32, Sean McBride wrote:
Nicko van Someren (email@hidden) on Mon, Sep 20, 2004 11:08 said:
1) Does anybody know whether NSData guarantees to allocate memory for
it's buffer with 16-byte alignment so that altivec code can be used on
it? I'm assuming it uses malloc() for it's allocation, and malloc()
appears to guarantee this.
There is no such guarantee in the documentation so I would suggest that
even if it appears to do the right thing that you don't count on it.
man malloc says:
"The malloc(), calloc(), valloc(), and realloc() functions allocate
memory. The allocated memory is aligned such that it can be used for any
data type, including AltiVec-related types." I believe the OP is right.
True, but I can't see guarantee that NSObject uses, or will use in the
future, malloc() and related functions for its memory allocation. The
current implementation may well have desirable properties but as long as
the behaviour is not documented there is nothing to stop it being
changed in the future, so I stand by my suggestion not to count on it.
If you do choose to rely on it in your code then leaving in an assertion
check will save some debugging time in the future if it does change.
Nicko
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden