Well, to sum it up, these are the public names of the library:
0 multiindex_set (haven't decided on the final name, still doubting between indexed_set and indexed_table).
1 swap, equality and comparison operators
2 index_type
3 get (function to retrieve refs to an index of a given multiindex_set)
4 iterator_type
5 const_iterator_type
6 project (function to convert between different indices's iterators)
7 index_list (a type list for specifying the indices composing a multiindex_set)
8 unique and non_unique (index traits classes that go into the index_list)
get() and project() are sufficiently well specified that they won't clash with similar overloads belonging to namespace boost. But the rest of names, which are classes instead of functions, are problematic: their names are too general to be safely put into namespace boost without risk of collision. So I guess some namespace have to be set up for them. Besides, there's the problem of the yet to be written member<> utility (that you're already familiar with). This clearly is a very general utility that has no particular ties to multiindex_set, so I don't know where it should go.
So the two problems are:
* Where to put 2,4,5,7, and 8? For known reasons, boost::multiindex_set is not a good candidate (problems with having a class and a namespace named the same).
* Where to put member<>?
2. 4. 5. 7. Couldn't these be internal typedef's in the multi-index set class? (If you meant the original definitions, I don't know since I don't have a copy of your code right now.)
8. Could go with the original definition of [7].
member: Could go with the other functional stuff in Boost, but I don't think there is a unified domain for that stuff right now. The functional stuff is spread all over the top-level namespace, except for Boost.Lambda (which uses its own exclusive sub-namespaces).
Daryle
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
