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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost