Array Indexing

[kris]

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.
>