Re: [boost] Indexed set: reverse

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2004-03-17 02:15:37

Darren Cook ha escrito:

> > reverse is not a member function of indexed_set, but rather of
> > sequenced indices. The line:
> >
> > tc.reverse();
> >
> > works because the indexed_set inherits the public interface of
> > its first index. So this is but an abbreviation of:
> >
> > tc.get<0>().reverse();
> >
> > (This particular point of indexed_set inheriting index #0 interface
> > has originated some perplexities in other readers.)
>
> That is clever, but the potential for confusion far outweighs any benefit
> (IMHO). Do you have any strong supporters for the idea?
>

Not really, apart from me :) The idea is that the first index can be
thought of as the *primary* index in some sense. So, the following

indexed_set<
  int,
  index_list<
    unique<identity<int> >,
    sequenced<>
  >
>

can be treated as a std::set with an aditional sequenced index, while

indexed_set<
  int,
  index_list<
    sequenced<>,
    unique<identity<int> >
  >
>

puts greater emphasis on the sequenced index, and its
"default" interface is that of a std::list.

>
> > Now, reverse is a memfun of sequenced indices for the simple
> > reason that it is also present in std::list (and sequenced indices
> > mimic its interface as closely as possible.) As std::sets do not
> > have a reverse operation, neither do regular indices (furthermore,
> > this op does not make sense for such indices.)
>
> I think the function makes sense: I can call reverse on the index then call
> some complex function that uses begin/end, to save having to write a
> rbegin/rend version. E.g. to process a list from oldest to youngest instead
> of youngest to oldest.
>

But you cannot have such a thing as a reverse op for regular
indices. Think of std::sets: a reverse() memfun would alter
the basic invariant of the set, namely that the elements are
arranged in a definite order imposed by the comparison predicate.
The same happens with regular indices. The complex function
you talk about can be made more generic if it is templatized according
to the iterator type, so that it accepts rbegin/rend as well as
begin/end --admittedly, this might not be sufficient in some cases.

>
> I also think the interface for regular and sequenced indices should be as
> close as possible, as I'm sure I'm going to want to write generic functions
> that take either type.
>

Ummm... the common subset of operations between regular and
sequenced indices is currently:

* operator=,get_allocator,empty,size,max_size,
* (r)begin/(r)end,
* erase,update,modify,clear,swap,

The main differences are with respect to insertion, where
semantics are very dissimilar (regular indices do have a definite
ordering, not so sequenced indices.) Gotta think of it, maybe
I can add the following to sequenced indices:

insert(const value_type& x);
insert(InputIterator first,InputIterator last);

with the implied assumption that insertion takes place
at the end of the index. This would provide of fair amount
of interface commonality between regular and sequenced
indices. Comments?

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