mRad private in Ogre::Radian

[KarenRei]

In Ogre::Radian, mRad is private. This makes it a pain when extending the class. Please switch it to public or protected, like the member variables of other similar classes (Vector3, Quaternion, etc).
.

[so0os]

You should NEVER derive from Ogre::Radian

[Jabberwocky]

You should NEVER derive from Ogre::Radian

Good advice, but it would be a more helpful post if you explained it a little.

[so0os]

You should NEVER derive from Ogre::Radian

Good advice, but it would be a more helpful post if you explained it a little.

OK.

A base class takes as many space in memory as its members, Radian has 1 float member, so it takes 4 bytes. When you derive, however, each class needs to store virtual function pointers, so you can call stuff on a base class and it gets executed for each derived child respectively. thus, size of the class grows with number of functions uhm.. methods there. It's all OK, until you do heavy math on radians (and tons of junk has to be moved in and out of stack every cycle) OR i.e. you put such struct into a VBO (that would be an overkill) or try to manually memcpy it somewhere.

[syedhs]

I really think Radian class (along with Degree) should be treated like POD (Plain Old Data) and it is - so deriving from it make it complicated unnecessarily.

[dark_sylinc]

I agree with syedhs, there should be no virtual members in the class, and the variable should change from "private" to "protected".
Not public to avoid accidental (or noobie) direct access to mRad while working with Radians.

[Kojack]

When you derive, however, each class needs to store virtual function pointers, so you can call stuff on a base class and it gets executed for each derived child respectively. thus, size of the class grows with number of functions uhm.. methods there.

Inheritance on it's own doesn't add virtual function pointers. The vtable pointer is only added to an object if the class has methods which are declared as virtual.
Any number of virtual methods will cause the class to increase by only one vtable pointer, the size doesn't grow with the number of methods.
Since Radian has no virtuals, you can add as many methods to it in a derived class as you want (as long as they are non virtual too), it won't grow the object past 4 bytes.

[madmarx]

A base class takes as many space in memory as its members, Radian has 1 float member, so it takes 4 bytes.

No. Not only does the C++ standard not force it to be the same size, but it actually happens rarely.
For that reason, Visual Studio provides some pragma to force data alignment.

class A
{
};

what is sizeof(A)?
=> 1 on VS2008

class B
{
bool b1;
bool b2;
bool b3;
double b4;
};

what is sizeof(B)?
=> 16 on VS2008

Such simple tests are very easy to set up...

Best,

Pierre

EDIT : and compiler options can make this size change too.

[dark_sylinc]

@madmarx: I don't think data alignment could be highly relevant on the topic, and it is very compiler option specific, and architecture specific.. The main reason for not using derived classes are virtual functions, but since there are none, there is no overhead to worry about.

[madmarx]

I don't think data alignment could be highly relevant on the topic

Yes, you are right, it is not really relevant. I just wanted to explain that a base class does not have to be the same size than its member.

[so0os]

I just didn't want to elaborate too much on that.

[CABAListic]

You're getting slightly off-topic
The simple answer is that Radian is not meant or designed to be extended, and as such there is no reason to make mRad non-private.