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