On 28 Jan 2009, at 17:08, Michael Ash wrote:
On Wed, Jan 28, 2009 at 6:00 AM, Jeremy Pereira
wrote:
On 27 Jan 2009, at 23:07, Graham Cox wrote:
However, I would argue that this is the C compiler behaving in a
deliberately inconsistent way, since in C, arrays and pointers are
supposed
to
On Wed, Jan 28, 2009 at 6:00 AM, Jeremy Pereira wrote:
>
> On 27 Jan 2009, at 23:07, Graham Cox wrote:
>
>>
>> On 28 Jan 2009, at 2:24 am, Jeremy Pereira wrote:
>>
>>> Yes. That is correct, but since buffer is already a pointer to the first
>>> byte of the array and then you are taking a referenc
On 27 Jan 2009, at 23:07, Graham Cox wrote:
On 28 Jan 2009, at 2:24 am, Jeremy Pereira wrote:
Yes. That is correct, but since buffer is already a pointer to the
first byte of the array and then you are taking a reference to it,
key will end up containing the address of the buffer. You r
On Jan 27, 2009, at 8:23 AM, Adam Venturella wrote:
Will thanks for the heads up, for my purposes this time around, the
input stream will be coming in off the file system, but I did not want
to load the whole thing into an NSData object.
Have you considered NSFileHandle and its -readDataOfLeng
On Tue, Jan 27, 2009 at 6:43 PM, Jean-Daniel Dupas
wrote:
>
> Le 27 janv. 09 à 23:52, Michael Ash a écrit :
>
>> On Tue, Jan 27, 2009 at 5:15 PM, William Jon Shipley
>> wrote:
Will thanks for the heads up, for my purposes this time around, the
input stream will be coming in off the
Le 27 janv. 09 à 23:52, Michael Ash a écrit :
On Tue, Jan 27, 2009 at 5:15 PM, William Jon Shipley
wrote:
Will thanks for the heads up, for my purposes this time around, the
input stream will be coming in off the file system, but I did not
want
to load the whole thing into an NSData object
On 28 Jan 2009, at 10:23 am, Chris Suter wrote:
In which case using & later is then going to cause it to break.
Yes, you have a good point. But I did want to make clear that the
statement:
since buffer is already a pointer to the first byte of the array and
then you are taking a refere
Hi Graham,
On Wed, Jan 28, 2009 at 10:07 AM, Graham Cox wrote:
> It's a good habit IMO to always
> take the address in these cases to make it clear in your code what your
> intentions were when you wrote it.
I'm afraid I have to disagree with this approach.
In my opinion, it's more likely that
On 28 Jan 2009, at 2:24 am, Jeremy Pereira wrote:
Yes. That is correct, but since buffer is already a pointer to the
first byte of the array and then you are taking a reference to it,
key will end up containing the address of the buffer. You really
need:
uint key = *(uint*)buffer;
On Tue, Jan 27, 2009 at 5:15 PM, William Jon Shipley
wrote:
>> Will thanks for the heads up, for my purposes this time around, the
>> input stream will be coming in off the file system, but I did not want
>> to load the whole thing into an NSData object.
>
> Ah! Well, your approach will work, but
On Tue, Jan 27, 2009 at 5:15 PM, William Jon Shipley
wrote:
> In my tests "NSUncachedRead" is very, VERY fast, great if you are only going
> to use each byte once. "NSMappedRead" has a different set of constraints but
> can also be very fast.
Since he's apparently unwilling, I'll link to Wil's bl
On 27 Jan 2009, at 14:23, Adam Venturella wrote:
The file I am
reading is assured to be in little-endian, and I am checking what the
host byte ordering is first. Leopard is little endian ( at least on
the intel chips, but I have read there are other macs that are
big-endian, so I am trying to c
Will thanks for the heads up, for my purposes this time around, the
input stream will be coming in off the file system, but I did not want
to load the whole thing into an NSData object.
Ah! Well, your approach will work, but if your file is less than 4GB I
highly recommend something like:
On 1/27/09 3:24 PM, Jeremy Pereira said:
>> Leopard is little endian ( at least on
>> the intel chips, but I have read there are other macs that are
>> big-endian, so I am trying to catch and handle that accordingly)
>
>The endianness is dependent on the processor architecture, not the
>operating
On 27 Jan 2009, at 14:23, Adam Venturella wrote:
Leopard is little endian ( at least on
the intel chips, but I have read there are other macs that are
big-endian, so I am trying to catch and handle that accordingly)
The endianness is dependent on the processor architecture, not the
operat
Will thanks for the heads up, for my purposes this time around, the
input stream will be coming in off the file system, but I did not want
to load the whole thing into an NSData object.
Graham, thanks for the byte-ordering nod as well. The file I am
reading is assured to be in little-endian, and
[inputStream open];
[inputStream read: buffer maxLength:sizeof(buffer)];
...
Note that although your call to -read:maxLength: will work as you
expect most of the time, it's not guaranteed to work and is bad
practice.
The docs for NSInputStream say this method will "Return the actual
numb
Le 27 janv. 09 à 06:28, Graham Cox a écrit :
On 27 Jan 2009, at 4:17 pm, Adam Venturella wrote:
Thanks! I knew I was doing to many steps!
uint key = *(uint*)&buffer;
You will also need to consider byte-ordering if your app or the data
could be used on different architectures. If for
On 27 Jan 2009, at 4:17 pm, Adam Venturella wrote:
Thanks! I knew I was doing to many steps!
uint key = *(uint*)&buffer;
You will also need to consider byte-ordering if your app or the data
could be used on different architectures. If for example your input
data is known to be big-end
Thanks! I knew I was doing to many steps!
On Mon, Jan 26, 2009 at 8:44 PM, Graham Cox wrote:
>
> On 27 Jan 2009, at 2:09 pm, Adam Venturella wrote:
>
>> NSData * d = [NSData dataWithBytes:buffer length:sizeof(buffer)];
>> uint * key = (uint *) malloc(sizeof(uint));
>> [d getBytes:key length:sizeo
On 27 Jan 2009, at 2:09 pm, Adam Venturella wrote:
NSData * d = [NSData dataWithBytes:buffer length:sizeof(buffer)];
uint * key = (uint *) malloc(sizeof(uint));
[d getBytes:key length:sizeof(uint)];
uint key;
[d getBytes:&key length:sizeof(uint)];
but since you have merely wrapped in NSDa
Here is what I am doing now.. I just feel like I have an extra step in
converting the buffer into NSData...malloc...free
uint sample = 0x04034b50;
uint8_t buffer[sizeof(uint)];
[inputStream open];
[inputStream read: buffer maxLength:sizeof(buffer)];
NSData * d = [NSData dataWithBytes:buf
22 matches
Mail list logo
