From: Matthew Vogt <mvogt@juptech.com>
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.
You're right. That does sound valuable, but I didn't walk away from reading the documentation with that idea. I just saw it as inconsistent treatment of the first index. Maybe it was there and I'm just blind.
While it seems to increase the chance of erroneous usage, it strikes me as a useful characteristic.
That is useful, but only if the resulting indexed_set is sufficiently semantically similar to the container it replaces. indexed_set doesn't provide the subscript operator, so the replacement won't be seamless if you use that operator on a map. There are other differences which may cause problems. However, I haven't got any experience with these problems or with it working well, so I'm speaking entirely theoretically. If there are important behavioral differences between std::set and an indexed_set configured like a set, or between std::map and an indexed_set configured like a set (other than the missing operator, which will simply fail to compile), or between std::list and an indexed_set configured like a list, then silent substitution doesn't seem appropriate. If the differences are unimportant semantically or if they only change a constant in the complexity guarantees, for example, then silent substitution is appropriate. I'm not qualified to judge this, but I'm sure Joaquín is. IIRC, get<0>() works, but is not necessary. Given that, generic code won't have to treat the first index differently than the others, so that aspect seems fine, regardless of whether it inherits the interface of the first index. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;