Am 15.02.2011 23:29, schrieb Nick Sabalausky: > "Daniel Gibson" <metalcae...@gmail.com> wrote in message > news:ijett7$1ie$5...@digitalmars.com... >> Am 15.02.2011 23:00, schrieb Nick Sabalausky: >>> "so" <s...@so.so> wrote in message news:op.vqyk3emumpw3zg@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
