ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> boost
boost
Re: [boost] suggestion for iterator consistency predicates
by Herve Bronnimann other posts by this author
Jun 12 2002 7:46PM messages near this date
Re: [boost] Re: suggestion for iterator consistency predicates | [boost] bind(ref(f), ...) support added to CVS
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
Thread:
Yitzhak Sapir
Matthew Wilson
David Abrahams
Herve Bronnimann

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved