Boost logo

Boost :

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2004-03-03 02:24:02

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
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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at