Re: [boost] Formal Review: Indexed Set

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2004-03-30 12:19:23

Hi Rob

Rob Stewart ha escrito:

> From: =?iso-8859-1?Q?Joaqu=EDn=20M=AA=20L=F3pez=20Mu=F1oz?= <joaquin_at_[hidden]>
> > Rob Stewart ha escrito:
> >
> > > The main page mentions "STL-like indices," but I don't think of
> > > the Standard Library as providing indices, so this doesn't mean
> > > anything to me.
> >
> > Well the meaning is that indices (italicized as the term is first
> > introduced) have STL-like characteristics. I'd be happy to rewrite this
> > in a cleaner way if only you provided me with a different wording.
>
> Rereading the text, I think that you're trying to say that the
> various indices one can configure in an indexed_set have
> interfaces like those of the container types provided in the STL,
> making using them familiar.

Yeah. Rephrased it, hope it reads better now:

"The Boost.IndexedSet library provides a class template named indexed_set
which enables the construction of containers maintaining one or more indices
with different sorting and access semantics. Indices provide interfaces similar to

those of STL containers, making using them familiar."

[...]

> Other documentation notwithstanding, I'm suggesting that all of
> the pieces that come from your library be highlighted by an
> "is::" prefix so they stand apart from the other components used
> in the examples.  IOW, any lambda, mpl, tuples, etc. code would
> be unqualified, through the use of "using namespace ..." and the
> Indexed Set code would be distinct.

Ummm... gotta think of it.

>    Boost.IndexedSet features "regular" indices, which are sorted
>    by keys using predicates, and were designed to help
>    programmers in need of sequences of elements for which more
>    than one sorting criteria are relevant.
>
> The difference is the "short and sweet" definition of a "regular"
> index that allows the reader to continue in the current context.

OK, I'll change that.

>
>
> > > Your "safe mode" name is inconsistent with the
> > > "invariant-checking mode."  The latter clearly indicates what is
> > > being checked, whereas the other doesn't.
> >
> > I retained the name "safe mode" because users are likely
> > familiar with the name as given in STLport.
>
> I've never used STLport, so that carries no significance for me.
> I'm still in favor of being explicit and consistent.

I dissent here. Safe mode IMHO is popular enough.

[...]

> > > I have two questions.  First, why is this information buried in
> > > the advanced topics page?  The mode should be highlighted in the
> > > main documentation path.
> >
> > I thought the tutorial was hard enough as it was and decided to
> > move all the non-essential stuff to a different page. Admittedly,
> > other topics covered in this section are really much more advanced.
>
> The point is that this issue isn't "advanced."  It is part of
> normal usage of the library.  Indeed, it is quite possibly of
> more use to less advanced users.

I'll think of it. I don't feel comfortable with this section being in
the tutorial, which is more about concepts than configuration.

[...]

> > > I don't like the assymmetry between get<> and the pair
> > > nth_indexed_type<> and indexed_type<>.  I'd prefer that
> > > indexed_type<> be used, like get<>, for either a number or a tag.
> >
> > I'd prefer it also, but AFAIK it cannot be done. You just cannot
> > "overload" a template to accept type and non-type arguments.
>
> I haven't looked at the code, but I'm confused.  How can one use
> type and non-type arguments with get<> but not with the others?

get<> is a function template, index_type is a class template.
Future revisions of the language may allow for class template
overloading, if I'm not wrong.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo