Rob Stewart <stewart <at> sig.com> writes:
First, it depends upon how one views indexed_set. On the one hand, you can see it as a drop-in replacement for another container that happens to permit adding additional indices. Thus, the original code is largely unaffected by the substitution and new code can be written to take advantage of the new capabilities.
OTOH, you can see indexed_set as a completely different animal with different performance characteristics that happens to work similarly to existing containers. The similarity means that programming with an indexed_set is familiar, but the new capabilities require conscious application to ensure the differences are properly accounted for.
My view is the second one, but I can understand the value of the first.
I thought that the value of this facility was when you could replace an existing STL container with an indexed_set when you had a need to a second index, without disrupting the code that was already accessing the existing container. In this situation, the existing code, unchanged, uses the default index, while new code can be added which explicitly uses the additional index/indices to gain the advantages of the new characteristics. While it seems to increase the chance of erroneous usage, it strikes me as a useful characteristic.
No movitating example that I know of. It was implemented like that cause having multiple tags was no harder than having just one.
The explanation of indexed_set, if not its implementation, is more difficult. Without any reason for this "feature," it adds unwarranted complexity. Granted, you've said it wasn't any harder to support multiple tags, and the tutorial section on multiple tag support is very short. Still, it smacks of a solution in search of a problem.
Perhaps someone else can envision a good use for this feature?
I can't. Not only does it make indexed_set harder to understand, it becomes more difficult to understand code which uses indexed_sets with multiply-tagged indices. Whilst reading someone else's code, it would be confusing to find that searches tagged 'named' are really exactly the same as searches tagged 'by_name'... I think this facility should be removed, unless there's a compelling argument in its favour. Matt