Class members padding

[Klaim]

In Ogre::Vector3 we can see that :

Code: Select all

class _OgreExport Vector3
    {
    public:
		Real x, y, z;

But then :

Code: Select all

	inline Real operator [] ( const size_t i ) const
        {
            assert( i < 3 );

            return *(&x+i);
        }

		inline Real& operator [] ( const size_t i )
        {
            assert( i < 3 );

            return *(&x+i);
        }

I'm almost sure that C++ suggest that we don't assume the members of a class to be contigu because of the compiler can optimize the memory structure by adding some bytes between them. Right?

So those functions are not safe to use on all architectures, aren't they?

[Olemars]

Interesting catch. Might be better suited for developer talk really.

From what I gather, assuming the memory layout to be contiguous would be valid if the class could be considered an aggregate POD class. However, Vector3 doesn't fulfill the standard definition, since it's got both user defined operator= and constructors. Apparently it works OK anyway on x86 systems, but there are no guarantees. Since Ogre is supposed to also run on mobile platforms whose compilers might do all kinds of tricks, I'd say this is an unsafe assumption to make.

[Ruud v A]

I doubt optimisation would add extra bytes, but it is however bad practice to do things like this (for reasons mentioned above).

[madmarx]

Yes good catch.

the compiler can optimize the memory structure by adding some bytes between them

It can also add bytes in order to store classes/object informations (no joke) in some extrems cases (I read that on soustrup FAQ). So it depends on the compiler, more than the targeted architecture.
So yes, it is a real error.

[Chris Jones]

Maybe i'm wrong but padding is usually only done to make the data align to certain boundaries (e.g. a 4 byte value would be aligned to a multiple of 4 bytes). In this case Real will be 4 or 8 bytes so shouldn't need padding. Any additional data/padding for the class would be before or after those members which shouldn't affect alignment.

[syedhs]

Maybe i'm wrong but padding is usually only done to make the data align to certain boundaries (e.g. a 4 byte value would be aligned to a multiple of 4 bytes). In this case Real will be 4 or 8 bytes so shouldn't need padding. Any additional data/padding for the class would be before or after those members which shouldn't affect alignment.

That's my thought exactly - I have noticed about this for quite sometime.

[Klaim]

Yes but I was (as others) thinking about non-pc-mac platforms...

I guess someone would have pointed the problem if it was blocking a new platform portage.