Return size_t instead of u32 for size() ops in contaniers

[Mel]

I've been coding lately a bit on 64 bits and i've seen something many people does that is actually incorrect, and it is to think that the size of a container is always an unsigned 32 bits integer. The STL handles this well, and returns always size_t types when it needs it, but in many places, this is not the thing to do. While it is still true on 32 bits, because the size_t type is just a typedef of an unsigned integer, and on the practice, it is useful, it isn't really correct anymore when you switch to 64 bit, and is kind of bothersome when you're doing comparisons and suddenly you get tons of warnings when they tell you you might be losing some precision because of comparing 32 bit to 64 bit, when you didn't get that kind of errors just because both types were actually the same thing.

Wouldn't it be more portable to use the size_t type to handle containers size? (and iterators...) after all, its exactly the meaning this type has, to signify a "size" I know this can be really a small matter, but i have the impression that sooner than later, people would realize just this. It isn't that long since we have 4GB of RAM available, so who knows?...

[devsh]

This is amongst the many reason why I'm replacing irrtypes (u16,u32,s16,s32) with stdint

[CuteAlien]

Using size_t would have been my first choice. But changing it at this time means breaking the interface :-(
And it kinda doesn't matter generally - just use u32 when working with core::array. If you really have data-structures which don't fit in there, I'd recommend using std::vector instead there.

There are other places (file-functions) where I want to switch to size_t (thought there had been some troubles with that as well I think, I remember I stopped converting at some point last time when I thought it would be a 5 minute job and it turned out not to be that). But for containers... not sure... maybe - it's kinda nice, but just being slightly nicer is generally a bad reason for modifying an interface in libraries (completely different inside applications where being nice is generally worth it).

[Mel]

Yeah, i am aware that this is interface breaking in many cases and that it might just cause unnecesary problems, but i can't help but fear that not keeping this in mind can cause problems in the future so elemental that are overlooked. After all, it isn't that long since the programming in 64 bit has become "mainstream" Anyway, just a small reminder. Also, eficiency wise 32 bit would still behave faster right?

[CuteAlien]

Well, if we switch to STL then that problem is solved automatically.
Don't know about efficiency - always hard to tell :-) (I think floats are for example sometimes slower than double because they are converted internally to double by the processor - not sure if something similar happens with 32/64 bit integers).

[chronologicaldot]

It was probably just meant for consistency and avoid casting and whatnot on the part of the user. Most things seem to use u32 or s32, even when they don't literally mean 32-bit, which bugs me.

[Mel]

Of course it is that, and on the practical side 32 extra bits really add very little because 16 exabytes (if i am not mistaken... ) is still something extremely large. But it is like you're somehow underestimating what 64 bits are when you're fitting them into 32 bit variables

It is like the discussion about having 32 bit or 16 bit indices in a meshbuffer, save the 16 bit choice is completely intentional and it didn't slip there just out of accustomed usage, perhaps sticking to 32 bits indexing variables should be, from now on, a design choice, and should be always regarded like that and taken into consideration. 32 bits are safer after all, a failed memory reservation in 32 bit may mean 4GB at most, while it can be disastrous in 64bits