[boost] Re: suggestion for iterator consistency predicates

From: Matthew Wilson (mwilson_at_[hidden])
Date: 2002-06-13 21:12:07

Largely agree. However, there are cases when one would benefit from
"knowing" a little about a manipulated type, within an algorithm operating
on such types.

"Herve Bronnimann" <hbr_at_[hidden]> wrote in message
news:20020612154605.A22878_at_geometry.poly.edu...
On Sun, Jun 09, 2002 at 09:10:26PM +0200, Yitzhak Sapir wrote:
> It occured to me that it might be useful to have a library of
> predicates that could, given iterators or a container, provide certain
> logical assertions about how operations affect the iterators.  That
> is, one could static_assert on some predicate called
> insert_does_not_invalidate_iterators<container_t>::value.  This would
> be useful if the container type container_t was later changed.
> Various functions that depend on specific properties of the containers
> would then have to pass a compile time check ensuring their
> pre-assumptions about the container holds.  Given the amount of
> different operations, and the variance in how different operations
> affect the container's iterators, and the ease with which STL lends
> itself to changing container types, having a ready-made library of
> these could be very useful as a general library or addition to the
> static assertions or concept checking libraries.

Some kind of container_traits might be more readable?

   template < class Container >
   struct container_traits
   {
      bool insert_does_not_invalidate_iterators = false;
      // ...
   };

On the other hand, to quote Scott Meyers (Effective STL, Item 2: Beware
of the illusion of container-independent code):

   "Alas, many programmers try to pursue it in a different manner.
   Instead of committing to particular types of containers in their
   software, they try to generalize the notion of a container so that
   they can use, say, a vector, but still preserve the option of
   replacing it with something like a deque or a list later --- all
   without changing the code that uses it. [...] This kind of
   generalization, well-intentioned though it is, is almost always
   misguided."

If you disagree with Scott, please read Item 2 thoroughly to hear his
reasons... I'm not making a judgement on your suggestion, merely point
out that if your intention was to allow this kind of programming, then
it may not be the best thing to provide support for.

Yours,
--
Hervé
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost