Strategy

• P-trie in code, top-down parsing
• Message storage allocated from pool
• Bottom-up packaging

Example

struct BASE_MSG {
    enum MSG_TYPE type;
    size_t size;
};

struct PARENT_MSG {
    struct BASE_MSG base;
    enum PARENT_MSG_TYPE type;
    int pdata1;
};

struct CHILD_MSG {
    struct PARENT_MSG parent;
    int cdata1;
    int cdata2;
};

Pro

• Easy to initialise

  CHILD_MSG cm = {
      {
          {
              MSG_TYPE_PARENT, // contains PARENT_MSG
              sizeof(CHILD_MSG)
          }, // BASE_MSG
          PARENT_MSG_TYPE_CHILD, // contains CHILD_MSG
          parent_data1
      }, //PARENT_MSG
      child_data1,
      child_data2
  }; // CHILD_MSG
  
  

Con

• Member access looks a bit messy
• Bottom-up access is counter-intuitive

  cm.parent.pdata1 = parent_data1;
  cm.parent.pdata2 = parent_data2;
  
  

• Can only be used for fixed-size message hierarchies

Notes

• Either use global type for all messages (used in BASE_MSG and inherited)
• Or hierarchical type member (present in each sub-message)
• Global size for passing around safely
• Or hierarchical types