Re: [Boost-users] Using different variables based on template type

Subject: Re: [Boost-users] Using different variables based on template type
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-06-02 11:57:01

On Tue, Jun 2, 2009 at 10:19 AM, Ryan McConnehey <mccorywork_at_[hidden]>wrote:

> Zachary Turner wrote:
>
>> 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 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?

First thing is I actually made a slight mistake in my code example, the line
"map_type map;" inside the struct declaration should have been "static
map_type map;"

Regarding your other question, I'm not totally sure I understand, could you
post a short code snippet?  If you mean that you want different maps for the
same type, for example:

std::map<std::string, boost::uint16_t>   uint16map_1;
std::map<std::string, boost::uint16_t>   uint16map_2;
std::map<std::string, boost::uint16_t>   uint16map_3;

Then the design I mentioned doesn't support this directly, but I think it
could be made to support it a number of different ways.  The easiest way
would be to just add an additional argument to the
BEGIN_SERIALIZATION_DECLS() macro and use that argument for the namespace
name instead of "serialization".  Then you would have:

BEGIN_SERIALIZATION_DECLS(serialization_map1)
DECL_SERIALIZATION_SUPPORT(boost::uint16_t)
DECL_SERIALIZATION_SUPPORT(boost::uint32_t)
END_SERIALIZATION_DECLS()

BEGIN_SERIALIZATION_DECLS(serialization_map2)
DECL_SERIALIZATION_SUPPORT(boost::uint32_t)
DECL_SERIALIZATION_SUPPORT(foo)
END_SERIALIZATION_DECLS()

serialization_map1::kv_map<boost::uint16_t>::map["test1"] = 7;
serialization_map2::kv_map<boost::uint16_t>::map["test1"] = 8;

>
>  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?'

Sorry, I meant that for adding support for types which didn't need custom
storage / retrieval is just 1 line, because then all you do is do
DECL_SERIALIZATION_SUPPORT.  yea if you need custom storage / retrieval then
it's 1 line for the DECL_ macro and N lines for the storage / retrieval
logic.  You can do them in the form of template specializations for the type
of data to store/retrieve, or if you already have the functions implemented
somewhere else with different names that can't easily be adapted to template
specializations you could store a static boost::function object in the
kv_map specialization and take it as an argument to the macro.  It will
probably take some tinkering with to settle on something but I think the
basic idea can be adapted.

OTOH, macros can get pretty hairy the more complicated you make them, so if
that's a consideration you might consider something else.  You'd only want
to do something like this if you didn't think you'd end up needing to modify
the the actual macros very much, if at all, once you had them in place.