Yes, pretty much. That effectively compounds my logic about the length of the
word.

Cheers

A hint: if you want efficient storage, you have to think as a C
programmer (not C++). You can do it either with pointers
to the first child and to the next sibling (NULL for child means
no children, NULL for sibling means no more siblings), or you
can use flat portable layout using offsets. Flat layout may allow
you to optimize the size for small trees, since you won't need
32 bits for offsets (with even greater impact on the upcoming
64-bit platforms!). Then depending on the approach, you either
generate a bunch of struct instances with pointers within them,
or you generate a single byte chunk (can be comprised of
WORDs/DWORDs instead if you align your data with the
offsets) with the entire tree. In either case you'd use some
code to generate your source from the original tree format.

Note: I'd advise the no-sibling pointer/offset optimization. E.g.
you have all siblings in a continuous chunk of memory and
use some tag (an invalid input char as an entry after the last
sibling for example, or a bit flag in each node) to determine the
end of the chunk. This is natural for flat memory representation.

Another advantage of the flat representation is you can load
and save the data to disk files for an alternative storage method.
Then you simply map a view of the file in your process and
use it as embedded data.

Another optimization, only possible in flat layout, is there you
can use variable size entries. If a node doesn't have children,
you don't need the offset after all. If you use the optimization
suggested to compress consecutive children with no siblings
in a single node, the data (the substring) can be varibale length.
Otherwise you'd either use a pointer for the string, or have all
nodes allocate memory sufficient for the largest string.

A word on offsets: you can use either absolute offsets from
the beginning of the whole structure, or relative offsets from
the beginning of the current node. The latter are more efficient
since they may allow you greater trees with narrower offsets.
Furthermore, even though it's natural to generate the tree in
left to right order, you can randomize the internal representation
since you use offsets to locate each chunk anyway. This may
allow you even greater trees when using narrower relative
offsets.

The top of the icing, useful mostly for larger trees where memory
is more important than speed, is that you can use progressive
Huffman encoding on each chunk to potentially minimize the
size even further.

Of course, the logic to traverse the tree will go into a C++
class, you only need C for the data itself.

As you may notice, I've done these and other embedded data
structures quite a bit in my past... :)