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
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 >
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
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.
-- Hervé _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk