Array Indexing

[James Dunne]

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