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