Hi Darren Darren Cook ha escrito:
Hi, Some thoughts on design/naming after reading docs of indexed_set (version 9). I've not tried compiling anything yet.
Please download v9.2 at http://groups.yahoo.com/group/boost/files/indexed_set.zip. Review should take place by the second half of March, so I don't think I'll apply any more changes to the code until then. If you run the tests for a compiler other than MSVC++6 SP5, ICC 7.1 or GCC 3.3.1 I'd be grateful if you report the results back. Thank you.
1. The naming here seems redundant: employee_set::nth_index_type<1>::type employee_set::index_type<name>::type
Can't the "::type" bit be dropped"? Or the _type, e.g. employee_set::nth_index<1>::type employee_set::index<name>::type
I don't think the "::type" bit can be dropped. As for the "_type" suffix I'm all with you that it is redundant, and matter of fact my first attempts did not use it. The only reason for the suffix is that it avoids MSVC++ 6.0 from choking due to some obscure bug having to do with collision with an internal "index" class. Thinking of it, I now believe that I can manage to eliminate that suffix. Consider this issue in the after-review todo list.
2. Do tags have to be structs? struct name{}; ... non_unique<tag<name>,member<employee,std::string,&employee::name> ... employee_set::index_type<name>::type
While it looks okay in tutorial examples, I can see not wanting that in the main namespace in a real program. But then having to use a namespace each time I use the tag will be make it a bit ugly: non_unique<tag<tags::name>,member<employee,std::string,&employee::name> ... employee_set::index_type<tags::name>::type
If it was a string instead is it less efficient (or maybe it does not compile)? non_unique<tag<"name">,member<employee,std::string,&employee::name> ... employee_set::index_type<"name">::type
You can use whatever type you want for tagging purposes. As for using string literals as tags, it is simply not possible. See for instance http://www.comeaucomputing.com/techtalk/templates/#stringliteral It is likely that this problem will be addressed at C++0x. Meanwhile, I don't think we can do anything about it.
3. I think the compose_key example will be needed enough that it should be part of the main library.
I take note.
4. I think some macros would be useful to enhance readability (rather than just to handle compiler incompatibilities as currently). I'll see what I come up with as I try to use the library.
Please do so. Thanks for your interest in indexed_set. Stay tuned for the upcoming review! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo