www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Array Indexing

reply "DigitalMars D compiler News" <lugaidster gmail.com> writes:
I have another problem (I'm kinda a newbie in D, I come from a .NET 
background) when I index an array with a byte. I have this function that 
returns a byte I use for index on an array. The thing is that whan that byte 
value is over 0x7F where it would be negative if it was a char the runtime 
raises an array bounds exception, I know a workaround and that is to and the 
value with 0xFF but I shouldn't have to (and if I perform an explicit cast 
it doesn't help it) since it is already a byte. Anyone knows if this is 
correct behavior?

--
Regards,
Alberto Simon 
Apr 25 2006
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
DigitalMars D compiler News wrote:
 I have another problem (I'm kinda a newbie in D, I come from a .NET 
 background) when I index an array with a byte. I have this function that 
 returns a byte I use for index on an array. The thing is that whan that byte 
 value is over 0x7F where it would be negative if it was a char the runtime 
 raises an array bounds exception, I know a workaround and that is to and the 
 value with 0xFF but I shouldn't have to (and if I perform an explicit cast 
 it doesn't help it) since it is already a byte. Anyone knows if this is 
 correct behavior?

'byte' is a signed 8-bit integer. Try ubyte instead, that's the unsigned variant.
Apr 25 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Frits van Bommel wrote:
 DigitalMars D compiler News wrote:
 I have another problem (I'm kinda a newbie in D, I come from a .NET 
 background) when I index an array with a byte. I have this function 
 that returns a byte I use for index on an array. The thing is that 
 whan that byte value is over 0x7F where it would be negative if it was 
 a char the runtime raises an array bounds exception, I know a 
 workaround and that is to and the value with 0xFF but I shouldn't have 
 to (and if I perform an explicit cast it doesn't help it) since it is 
 already a byte. Anyone knows if this is correct behavior?

'byte' is a signed 8-bit integer. Try ubyte instead, that's the unsigned variant.

This one has also bitten me a couple of times. "byte" just feels unsigned to me. All the "byte"-like typedefs I've encountered in C were always "unsigned char". L.
Apr 26 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
Lionello Lunesu wrote:
 Frits van Bommel wrote:
 
 DigitalMars D compiler News wrote:

 I have another problem (I'm kinda a newbie in D, I come from a .NET 
 background) when I index an array with a byte. I have this function 
 that returns a byte I use for index on an array. The thing is that 
 whan that byte value is over 0x7F where it would be negative if it 
 was a char the runtime raises an array bounds exception, I know a 
 workaround and that is to and the value with 0xFF but I shouldn't 
 have to (and if I perform an explicit cast it doesn't help it) since 
 it is already a byte. Anyone knows if this is correct behavior?

'byte' is a signed 8-bit integer. Try ubyte instead, that's the unsigned variant.

This one has also bitten me a couple of times. "byte" just feels unsigned to me. All the "byte"-like typedefs I've encountered in C were always "unsigned char". L.

Agreed. Byte isn't really an integer, it's more for storage. Storage should not care about signedness, it should just be used for read, write, comparison, and bit-flipping operations. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M-- V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++ ------END GEEK CODE BLOCK------ James Dunne
May 01 2006
next sibling parent reply kris <foo bar.com> writes:
James Dunne wrote:

 Agreed.  Byte isn't really an integer, it's more for storage.  Storage 
 should not care about signedness, it should just be used for read, 
 write, comparison, and bit-flipping operations.

Woah ... byte isn't really an integer? I guess long is not really an integer either, and should only be used for bit flipping too :)
May 01 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
kris wrote:
 James Dunne wrote:
 
 Agreed.  Byte isn't really an integer, it's more for storage.  Storage 
 should not care about signedness, it should just be used for read, 
 write, comparison, and bit-flipping operations.

Woah ... byte isn't really an integer? I guess long is not really an integer either, and should only be used for bit flipping too :)

Of course not. I simply meant that bytes shouldn't be used for calculations. None of our integral types are literal mathematical types if that's what you're trying to point out. I meant the word 'byte' implies storage. Would you prefer octet instead? -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M-- V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++ ------END GEEK CODE BLOCK------ James Dunne
May 01 2006
parent reply kris <foo bar.com> writes:
James Dunne wrote:
 kris wrote:
 
 James Dunne wrote:

 Agreed.  Byte isn't really an integer, it's more for storage.  
 Storage should not care about signedness, it should just be used for 
 read, write, comparison, and bit-flipping operations.

Woah ... byte isn't really an integer? I guess long is not really an integer either, and should only be used for bit flipping too :)

Of course not. I simply meant that bytes shouldn't be used for calculations. None of our integral types are literal mathematical types if that's what you're trying to point out. I meant the word 'byte' implies storage. Would you prefer octet instead?

I'm not trying to piss on your shoes, James :) But, what you noted is kinda' nonsense. Each of those common terms represent 'storage'; not just "byte". And what's this about byte "should just be used for read, write, comparison, and bit-flipping"? That's plain rubbish :) How about a "tiny int"? The point is, you /appear/ to be making a totally arbitrary distinction. Eight-bit values make perfectly good "integers" for a number of CPU designs and applications. It may not suit the type of apps you happen to be thinking of, but that's beside the point. Just because the natural comfort-spot for hardware architectures currently targeted by D happen to have 32-bit registers, that doesn't make "int" the only road to travel. Does it? What about 64-bit architectures, where the comfort-spot can be a 64-bit "long" instead? (depending on how you compile your app). At that point, does "int" get relegated to the place where "byte" used to be? For 'read', 'write', 'comparison', and 'bit flipping' only? This is daft. And I wouldn't bother to say anything other than someone might take you literally :) *shrug*
May 01 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
kris wrote:
 James Dunne wrote:
 
 kris wrote:

 James Dunne wrote:

 Agreed.  Byte isn't really an integer, it's more for storage.  
 Storage should not care about signedness, it should just be used for 
 read, write, comparison, and bit-flipping operations.

Woah ... byte isn't really an integer? I guess long is not really an integer either, and should only be used for bit flipping too :)

Of course not. I simply meant that bytes shouldn't be used for calculations. None of our integral types are literal mathematical types if that's what you're trying to point out. I meant the word 'byte' implies storage. Would you prefer octet instead?

I'm not trying to piss on your shoes, James :)

Hehehe. Didn't mean to jump to defensive mode.
 But, what you noted is kinda' nonsense. Each of those common terms 
 represent 'storage'; not just "byte". And what's this about byte "should 
 just be used for read, write, comparison, and bit-flipping"? That's 
 plain rubbish :)
 
 How about a "tiny int"?
 
 The point is, you /appear/ to be making a totally arbitrary distinction. 
 Eight-bit values make perfectly good "integers" for a number of CPU 
 designs and applications. It may not suit the type of apps you happen to 
 be thinking of, but that's beside the point.
 
 Just because the natural comfort-spot for hardware architectures 
 currently targeted by D happen to have 32-bit registers, that doesn't 
 make "int" the only road to travel. Does it? What about 64-bit 
 architectures, where the comfort-spot can be a 64-bit "long" instead? 
 (depending on how you compile your app). At that point, does "int" get 
 relegated to the place where "byte" used to be? For 'read', 'write', 
 'comparison', and 'bit flipping' only?
 
 This is daft. And I wouldn't bother to say anything other than someone 
 might take you literally :)
 
 *shrug*

Ah, I understand the confusion now. Yes I didn't make myself quite clear. However, that is a lot of words to put in my mouth when I could be (and am) talking about something completely different... My problem was with the name of the type and the confusion it causes. Don't get me wrong, I'm all about 8-bit signed/unsigned integers and of course they have their place in computation and embedded environments, but calling them 'byte' and 'ubyte' disturbs me. Summary: I'd rather they be 'int8' and 'uint8' or some derivative thereof. Perhaps even 'tiny' as you half-suggested would suit better. We don't generally talk about something taking up 3 kilo-unsigned-bytes, do we? No, it's simply an octet, not implying any signedness of the actual integer value stored within. A byte array to me should just mean an array of octets that can look like tiny integers when you want them to. Also, they may be grouped up and treated as little-endian/big-endian larger integer types. What I meant by the 'read' 'write' 'comparison' and 'bit-flipping' were the list of allowable operations on the concept of storage bytes, not necessarily the equivalently-sized integer type, 'tiny' or whatever you wish to call it. That's the distinction I'm trying to make, plain and simple. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M-- V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++ ------END GEEK CODE BLOCK------ James Dunne
May 02 2006
parent kris <foo bar.com> writes:
Ah ... right. That /is/ different :)

Thanks;



James Dunne wrote:
 kris wrote:
 
 James Dunne wrote:

 kris wrote:

 James Dunne wrote:

 Agreed.  Byte isn't really an integer, it's more for storage.  
 Storage should not care about signedness, it should just be used 
 for read, write, comparison, and bit-flipping operations.

Woah ... byte isn't really an integer? I guess long is not really an integer either, and should only be used for bit flipping too :)

Of course not. I simply meant that bytes shouldn't be used for calculations. None of our integral types are literal mathematical types if that's what you're trying to point out. I meant the word 'byte' implies storage. Would you prefer octet instead?

I'm not trying to piss on your shoes, James :)

Hehehe. Didn't mean to jump to defensive mode.
 But, what you noted is kinda' nonsense. Each of those common terms 
 represent 'storage'; not just "byte". And what's this about byte 
 "should just be used for read, write, comparison, and bit-flipping"? 
 That's plain rubbish :)

 How about a "tiny int"?

 The point is, you /appear/ to be making a totally arbitrary 
 distinction. Eight-bit values make perfectly good "integers" for a 
 number of CPU designs and applications. It may not suit the type of 
 apps you happen to be thinking of, but that's beside the point.

 Just because the natural comfort-spot for hardware architectures 
 currently targeted by D happen to have 32-bit registers, that doesn't 
 make "int" the only road to travel. Does it? What about 64-bit 
 architectures, where the comfort-spot can be a 64-bit "long" instead? 
 (depending on how you compile your app). At that point, does "int" get 
 relegated to the place where "byte" used to be? For 'read', 'write', 
 'comparison', and 'bit flipping' only?

 This is daft. And I wouldn't bother to say anything other than someone 
 might take you literally :)

 *shrug*

Ah, I understand the confusion now. Yes I didn't make myself quite clear. However, that is a lot of words to put in my mouth when I could be (and am) talking about something completely different... My problem was with the name of the type and the confusion it causes. Don't get me wrong, I'm all about 8-bit signed/unsigned integers and of course they have their place in computation and embedded environments, but calling them 'byte' and 'ubyte' disturbs me. Summary: I'd rather they be 'int8' and 'uint8' or some derivative thereof. Perhaps even 'tiny' as you half-suggested would suit better. We don't generally talk about something taking up 3 kilo-unsigned-bytes, do we? No, it's simply an octet, not implying any signedness of the actual integer value stored within. A byte array to me should just mean an array of octets that can look like tiny integers when you want them to. Also, they may be grouped up and treated as little-endian/big-endian larger integer types. What I meant by the 'read' 'write' 'comparison' and 'bit-flipping' were the list of allowable operations on the concept of storage bytes, not necessarily the equivalently-sized integer type, 'tiny' or whatever you wish to call it. That's the distinction I'm trying to make, plain and simple.

May 02 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
James Dunne wrote:
 
 Agreed.  Byte isn't really an integer, it's more for storage.  Storage 
 should not care about signedness, it should just be used for read, 
 write, comparison, and bit-flipping operations.

Just as long as 'nibble' is a numeric type I'm happy. No one really needs an entire byte anyway. Sean
May 01 2006