Array and other core collections don't use size_t?


#1

Sorry if this has been asked a zillion times before, I can't exactly what I'm looking for with the search function.

 

What are the reasons for core collections such as Array not using size_t for indexing, returning the collection's size etc?  

Couple of guesses:

- They should do but it'll break (or at least, produce too many warnings in) users' applications

- Signed representation is sometimes handy

 

Not that I really want to store more than 4 billion things, but I just trialled a 64 bit build and was kind of expecting these to be the native width.


#2

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.


#3

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.


#4

Few reasons to use int vs size_t in the article from Scott Meyers (1995) linked below.

Interesting also: ( https://software.intel.com/en-us/forums/topic/534769 ).


#5

OK thanks.

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.