Darren Cook <darren <at> dcook.org> writes:
Hi, Here is my review of indexed_set.
Hello Darren, thank you for your contribution! [...]
I'd like to see greater uniformity between sequenced and normal indexes, so I can write generic functions that can take either.
I sketched a little proposal to add some "alias" memfuns to sequenced indices so that the common interface of regular and sequenced indices is broader. The sketch is in a response by mw to Gary Powell yesterday. Have you seen it?
I especially did not like that the container as a whole inherits the interface of the first named index. I think this is asking for trouble, and I want to be forced to write get<mytag> for all indexes.
Ummm... Nobody else complained. As Pavel has explained in other post, this lets you easily replace old code using a stl container with an indexed_set.
The error messages were *very* long, even by STL standards.
Yes, I'm sorry about that, but I cannot figure out some way to shorten these. The types involved are as compact as possible (in the sense that they are parameterized by the minimum amount of arguments possible), but basically if your test program had six indices then error messages will tend to be up to six times as long as those produced by say a std::set, and three times on average. (indices are stacked up on one another.)
Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion.
Yes.
Thank you!
Naming?
Someone mentioned boost::table, or indexed_table. I like that as it is not too long, is descriptive, and is more suitable now the library is more than just a super std::set.
Now I'm collecting all the suggestions of reviewers concerning naming, I'll try to post a naming candidate by the end of the review. So far indexed_set, multi_container, multicontainer, indexed_table and table have been mentioned. table or indexed_table I don't specially like since they are too broad and could clash with future, more SQL-oriented libraries (there are people working on such libraries). My personal leaning is probably multicontainer.
I mentioned before I want to lose one of the "type" words from: index_type<C,T>::type
Yes, me too. I have proposed in a response to Gary Powell an alternative that I like myself: template<int N> struct nth_index; template<typename Tag> struct index; template<int N> struct nth_index_iterator; template<int N> struct nth_index_const_iterator; template<typename Tag> struct index_iterator; template<typename Tag> struct index_const_iterator; Do you love/hate it? Thank you again for the reviewing effort. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarollo