Partitioned Multikey Map

Below is the code for what I've called a partitioned_multitype_map. This has two major facets:

• Allowing a lookup based on keys of multiple lengths and of multiple types. For example:

typedef partitioned_multitype_map map_t;

would allow keys of any length 1 to a (specified) maximum, where each member
in the key is one of the template types.

• The second facet is that it partitions keys based on length, giving easy access to all key/value pairs of a given key length.

I'm looking for any comments or criticisms, but particularly, there is quite a bit of code duplication lying around. Simply because of the complexity of the types, I'm having some trouble trying to reduce it, so anything that's directed to that effect would be great.

```
/*! \file partitioned_multitype_map.hpp
* \brief Implementation of a compile time checked multi-key multi-value store.
*
* A partitioned_multitype_map defines a multi-key multi-value store. The types
* that the keys can store are specified at compile time via variadic template
* parameters Args...
* There are a few concepts that must be adhered to:
* 1) Each type that is to be part of a key must be Hashable.
* 2) Each type that is to be part of a key must be equality comparable
* (using ==).
* 3) At least one of the types must be DefaultConstructable.
* 4) Each type must be either CopyConstructible or MoveConstructable.
*
* Currently, the values must correspond to the types that are stored as keys;
* that is keys and values are composed of the same set of types.
*
* The map is partitioned on key length to make it easy to get all keys (and
* (associated values) of a given length.
*
* The current API is -slightly- awkward as we have to store the inserted
* key iterator to be able to insert a value into that spot. Variadic templates
* makes creating a nice API for this more difficult.
*
* Finally, note that this container isn't parameterized on an Allocator,
* a

I'd say that the biggest problem with it is the problem it is trying to solve. A collection of objects of unknown types is a very confusing and inefficient thing. Once retrieved, one must then ascertain the identity of the object before deciding what can be done with it. There are only three real use cases:

• You don't know the type of the object, but you know that it has certain operations you can perform on it to do what you need. In this case, you should turn it into something you do know, by defining a wrapper type that can enclose any of the desired types and handle the compatibility logic.

• You don't even know what they type of the key is; it is supplied by external sources. In that case, use a wrapper type to turn it into something you do know, as suggested previously.

• You already know what type everything is supposed to be, in which case you should have several different collections, one for each type, and retrieve objects from the applicable collection. (You could even put them all in the same class, where you have http_response.get_uri("location") and http_response.get_int("status-code") or some such thing, if you really have to.)

In short, there is no need for multi-type maps. If you use them, all the dynamic typing needed will plague your code forever and ever, never to be erased or blotted out.

StackExchange Code Review Q#40505, answer score: 3