Good question. I've got a situation where I've two derived classes, one of which is using an STL container (indexed with size_t) and the other a JUCE one (int). I'm sure there was a good reason for it, but it's not hugely pretty.
Yeah, the reasons were pretty much like you guessed - when I wrote it back in 2003, int seemed like a perfectly good idea, and when I later thought that size_t would be better, it would cause all kinds of irritating warnings for people if I changed it.
The signedness is indeed useful, so that methods like indexOf can return -1 if they fail, but ssize_t would do the job in that case.
The linked article gives some good justifications for continuing to use signed types even in cases where negative values shouldn't be necessary. I used to use unsigned types for quantities such as collection sizes on the basis that they physically can't be negative, but have mostly drifted to signed representation for the reasons mentioned.
In case anyone didn't know, Apple will be requiring 64 bit slices for new iOS apps starting in February and for updates to existing apps from June onwards, hence my investigations. I thought the swines might do it at some point but I only just found out for sure yesterday. The C/C++ side of things isn't too bad really but for chumps like me who have a lot invested in hand written ARM NEON, it's a ballache.
