|
Boost : |
From: Matthew Vogt (mvogt_at_[hidden])
Date: 2004-03-31 20:00:30
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk