From: David B. Held (dheld_at_[hidden])
Date: 2002-10-21 22:37:06
Jeremy B. Maitin-Shepard wrote:
> On Mon, 2002-10-21 at 22:32, David B. Held wrote:
>
> >[...]
> >interleave the two sets over the same tree nodes. It could be
> >possible to generalize map into an arbitrary-arity tuple ordering
> >container. After all, why not a trimap? I could imagine this
> >
>
> It seems that there would be the problem of all elements of the tuple
> having to be const so that modifications do not change the ordering.
> [...]
It is certainly possible to select const or non-const operators at
compile time. For instance, Loki::SmartPtr declares the standard
copy c'tor:
SmartPtr(SmartPtr const&);
for normal pointer types, and a non-const c'tor for auto_ptr<>
emulation:
SmartPtr(SmartPtr&);
The type is controlled by metacode. The same type of trick could
be used for the uber-map. However, it seems me that the generalized
map has these properties:
1) [1, N] key fields
2) {0, 1} value fields (since the value field itself could be a tuple)
So a set is merely a map with 1 key field and 0 value fields.
std::map has 1 key field, 1 value field. The bimap has 2 key fields
and 0 value fields. Why not have a map with 2 key fields and 1 value
field? That's essentially a database table with a 2-field key index.
And just like database tables, the uniqueness of any given key field
should be user-configurable. Hence, set, multiset, map, and multimap.
Combined with the KeyOfValue policy in my map, it would be possible for
the generalized map to simply *be* an in-memory database table, where
the value_type is the record type, and the keys are defined as members
in the record.
Dave