BEGIN_SERIALIZATION_DECLS() DECL_SERIALIZAITON_SUPPORT(boost::uint16_t) DECL_SERIALIZATION_SUPPORT(boost::uint32_t) END_SERIALIZATION_DECLS() I like how easy this is to expand for new types. A requirement that didn't seem important at the time, but now may affect this design, is having multiple variable names at different levels. For example, within
Zachary Turner wrote: the level (the levels are only one deep)"Bob" and "Sue" the variable "test1" can exist. They are not required to be the same type though. Since types can change I remove the variable name before I store the new variable at the given level. This means current I have a structure with all my different type maps and then a map of levels (level names as the key) and type structures. I have a shared_ptr, to the current level structure of types, and all inputed variables name and values are placed within the shared_ptr structure. I don't think the design would need to change but do you see any problem?
If you need to provide different storage / retrieval logic for different types then just specialize the store_kv and retrieve_kv functions. When you want to support a new type you only add 1 line of code, a DECL_SERIALIZATION_SUPPORT macro. If the storage / retrieval logic is customized for different types, how is this only adding one line for a new type? Don't you have to add the one line and the extra storage / retrieval logic for the new type?'
Ryan