Re: [boost] Re: Formal Review: Indexed Set

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-04-01 09:50:11

From: Matthew Vogt <mvogt_at_[hidden]>
> 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_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;