Al's Game Programming Blog

This is another example of CDL. I am posting it in response to Noel Llopis' comment on another thread. This is intended to demonstrate how CDL could allow the structure of the schema to differ from that of the member variables.

// Orientation.cdl
// Hand written annotated class
CDL class Orientation
{
public:
 
  Orientation(): x(0), y(0), z(0), w(1) {}
 
  // Public API uses Euler angles
  float GetX() const;
  void SetX(float);
 
  float GetY() const;
  void SetY(float);
 
  float GetZ() const;
  void SetZ(float);
 
  // Other members...
 
private:
 
  // Implemented in terms of quaternions
  float x, y, z, w;
};

// Orientation.xml
// Automatically generated schema for binding with level editing tool
// and to allow a build tool to cook C++ CInfo structs from level
// data. The field names and types are inferred from the accessor
// functions in class Orientation.
[schema]
  [class name="Orientation"]
    [field name="X" type="float"/]
    [field name="Y" type="float"/]
    [field name="Z" type="float"/]
  [/class]
[/schema]
 
// Orientation.auto.cpp
// More automatically generated code
 
struct OrientationCInfo
{
  float X;
  float Y;
  float Z;
};
 
// These are invoked automatically by the serializer
// when loading or saving level data.
void Load(Orientation &l, const OrientationCInfo &r)
{
  l.SetX(r.X);
  l.SetY(r.Y);
  l.SetZ(r.Z);
}
 
void Save(const Orientation &l, OrientationCInfo &r)
{
  r.X = l.GetX();
  r.Y = l.GetY();
  r.Z = l.GetZ();
}
 
// Other automatically generated code for factory, factory
// registration, etc...

I have changed things so that properties are identified through a naming convention rather than through explicit annotations. Instead, annotations would be used when the wrong interpretation would be implied by the naming convention, for example if Orientation had a function called GetAxisAngle, which should not be serialized.