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

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
Post Reply
Mel
Competition winner
Posts: 2292
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

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

Post by 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?...
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
devsh
Competition winner
Posts: 2057
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK
Contact:

Re: Return size_t instead of u32 for size() ops in contanier

Post by devsh »

This is amongst the many reason why I'm replacing irrtypes (u16,u32,s16,s32) with stdint
CuteAlien
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: Return size_t instead of u32 for size() ops in contanier

Post by 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).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Mel
Competition winner
Posts: 2292
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: Return size_t instead of u32 for size() ops in contanier

Post by 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?
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
CuteAlien
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: Return size_t instead of u32 for size() ops in contanier

Post by 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).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
chronologicaldot
Competition winner
Posts: 684
Joined: Mon Sep 10, 2012 8:51 am

Re: Return size_t instead of u32 for size() ops in contanier

Post by 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
Competition winner
Posts: 2292
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: Return size_t instead of u32 for size() ops in contanier

Post by 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 :)
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Post Reply