Integer conversions too pedantic in 64-bit

[Daniel Gibson]

Am 15.02.2011 23:29, schrieb Nick Sabalausky:
> "Daniel Gibson" <metalcaedes at gmail.com> wrote in message 
> news:ijett7$1ie$5 at digitalmars.com...
>> Am 15.02.2011 23:00, schrieb Nick Sabalausky:
>>> "so" <so at so.so> wrote in message news:op.vqyk3emumpw3zg at so-pc...
>>>>
>>>> Funny thing is the most important argument against size_t got the least
>>>> attention.
>>>> I will leave it as an exercise for the reader.
>>>
>>> That variables of type "size_t" are frequently used to store indicies 
>>> rather
>>> than the actual *size* of anything?
>>>
>>> That it does nothing to help with 32/64-bit portability until you 
>>> actually
>>> compile your code both ways?
>>
>> I don't understand that point.
>>
> 
> If you're writing something in 32-bit and you use size_t, it may compile 
> perfectly fine for 32-bit, but the compiler won't tell you about any 
> problems that will appear when you compile the same code for 64-bit (such as 
> "can't implicitly convert"). Presumably the same would apply to writing 
> something on 64-bit and then suddenly compiling for 32-bit.
> 
> I'm not actually asserting that this is a big issue. Maybe it is, maybe it 
> isn't, I don't know. Just making guesses at what "so" sees as "the most 
> important argument against size_t [that] got the least attention".
> 

Ok, that is right.
Probably it would be helpful if size_t was a proper type that can't be mixed
with other types in dangerous ways without explicit casting.

Cheers,
- Daniel