…has come to hunt me once again. Although this time it’s not because of mistakes that I did. Instead, the problem lies in something that I missed completely.
Can you spot the problem in the following code?
void SomeObject::save( Stream &s )
{
std::size_t count = getElementCount();
s.write( count );
}
Well, it turns out std::size_t is NOT PLATFORM INDEPENDENT. And here’s the twist: I knew that since, well, forever, but I never paid any attention to it. That is, until it became a problem. And the problem was EVERYWHERE in the code.
First thing first. The C++ standard has this to say about std::size_t:
typedef /*implementation-defined*/ size_t;
What’s that supposed to mean? Basically, std::size_t may have different precision depending on the platform. For example, in a 32-bit architecture, std::size_t may be represented as a 32-bit unsigned integer. Something similar happens in a 64-bit platform.
Wait.
std::size_t is supposed to help portability, right? That’s its whole purpose. And that’s true, of course. There’s nothing wrong with std::size_t itself.
Check the code above again. Go on, I’ll wait.
So, whenever we create a [binary] stream to serialize the scene, we can’t use std::size_t because it’s just plain wrong. It will be saved as a 32-bit integer in some platforms and 64-bit in others. Later, when the stream is loaded, the number of bytes read will depend on whatever the precision of the current platform is, regardless of what was used when saving. See the problem?
This means that we can’t share binary streams between different platforms because the data might be interpreted in different ways, leading to errors when generating scenes.
For the past few years, my main setup have been OS X and iOS, both 64-bit platforms. But one day I had to use streaming on 32-bit Android phones and, as you might have guessed by now, all hell break loose…
Entering crimild::types
I had to made a call here: either we can keep using std::size_t everywhere and handle the special case in the Stream class itself; or we can make use of fixed precision types for all values (specially integers) and therefore guaranteeing that the code will be platform independent.
I went for the second approach, which seems to me to be right choice. At the time of this writing, the new types are:
namespace crimild {
using Int8 = int8_t;
using Int16 = int16_t;
using Int32 = int32_t;
using Int64 = int64_t;
using UInt8 = uint8_t;
using UInt16 = uint16_t;
using UInt32 = uint32_t;
using UInt64 = uint64_t;
using Real32 = float;
using Real64 = double;
using Bool = bool;
using Size = UInt64;
}
As you can see, crimild::Size is always defined as a 64-bit unsigned integer regardless of the platform.
Yet that means I need to change every single type definition in the current code so it uses the new types. As you might have guessed, it’s a lot of work, so I’m going to do it on the fly. I think I already tackled the critical code (that is, streaming) by the time I’m writing this post, but there’s still much to be reviewed.
New code already makes use of the platform-independent types. For example, the new particle system is employing UInt32, Real64 and other new types and–
Oh, right, I haven’t talked about the new particle system yet… Well, spoiler alert: there’s a new particle system.
You want to know more? Come back next week, then 🙂
CRIMILD 