To abstract some code in CMobileCAI and CAirCAI, I want to make a super class to CAirMoveType and CTAAirMoveType and combine some of their standard fields and methods.
Anyway, I'm pretty sure it should be abstract, and was considering calling it AAirMoveType. Is that the correct convention (starting with A for abstract, instead of C for concrete) ?
Also, would it be a good idea to combine the very similar enum AircraftState, even though CTAAirMoveType has a hover state and CAirMoveType does not? I would endeavor to fix the compile warnings that would pop up because of an unused enum value in a switch by throwing a warning.
Edit: Also, I'm having some trouble making it a true abstract class because of CR_BIND_DERIVED, which is used by both it's sub and super types. Should I just jump CR_BIND_DERIVED from CTAAirType to CMoveType, and place all of CR_REG_METADATA members back into the subtypes, or am I doing something else wrong? Also, I have no idea what that CR stuff does.
C++ Abstract class naming convention
Moderator: Moderators
Re: C++ Abstract class naming convention
You can use CR_BIND_DERIVED_INTERFACE for abstract classes.
(Maybe it should be renamed though
)
(Maybe it should be renamed though

Re: C++ Abstract class naming convention
I've always thought the C simply stood for class, so I'd use it for abstract classes as well. (Then again, I really dislike this whole naming convention; I get it already that it's a class, thank you. But that's beside the point.)
But while we're at it, I too would like to know what this entire CR_* business is about. What does it do, and why do we need it? Can someone explain in a few sentences? It looks like some RTTI system...
But while we're at it, I too would like to know what this entire CR_* business is about. What does it do, and why do we need it? Can someone explain in a few sentences? It looks like some RTTI system...
Re: C++ Abstract class naming convention
It's a custom reflection system for C++, yeah.
Most well known usage of it is the custom explosion generator. It creates objects of projectile classes from TDF tags using reflection. Also the savegame functionality uses reflection to serialize the gamestate to disk.
As far as I know C has always been for 'concrete'. (An interface is a class too in C++ after all and we call that 'IMyInterface'.)
'A' is fine for abstract classes in my opinion. (Btw am I right in that we currently don't have any abstract classes at all? (not interfaces, I know we have those
))
I'm not a huge fan of this naming convention either but most of the code uses it so it's good to keep it as consistent as possible.
Most well known usage of it is the custom explosion generator. It creates objects of projectile classes from TDF tags using reflection. Also the savegame functionality uses reflection to serialize the gamestate to disk.
As far as I know C has always been for 'concrete'. (An interface is a class too in C++ after all and we call that 'IMyInterface'.)
'A' is fine for abstract classes in my opinion. (Btw am I right in that we currently don't have any abstract classes at all? (not interfaces, I know we have those

I'm not a huge fan of this naming convention either but most of the code uses it so it's good to keep it as consistent as possible.
Re: C++ Abstract class naming convention
Thank you CR_BIND_DERIVED_INTERFACE was exactly what I needed. Also, the only other abstract class I found was CExpGenSpawnable.
Last thing. What value should I put in for CR_RESERVED? CMoveType has 32, and CAirMoveType has 63. I'm storing 4 float3's, and 2 each of floats, bools, ints, and pointers. If I'm counting correctly, that's 66 bytes. Should I be higher to be safe? How much does it matter?
Edit: fixed counting.
Last thing. What value should I put in for CR_RESERVED? CMoveType has 32, and CAirMoveType has 63. I'm storing 4 float3's, and 2 each of floats, bools, ints, and pointers. If I'm counting correctly, that's 66 bytes. Should I be higher to be safe? How much does it matter?
Edit: fixed counting.
Re: C++ Abstract class naming convention
I think it's just for keeping the class size constant (in savefiles) when members are added. So you can set it to 16 now for example, and then you have room to add 4 int/float's before breaking compatibility.