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] Proxy indirect container adaptor: 4 claims
by Victor A. Wagner Jr. other posts by this author
Feb 28 2004 4:36AM messages near this date
Re: [boost] BOOST_TRY like macros: time to add them? | [boost] Re: dynamic inheritance with FC++
At Thursday 2004-02-26 09:13, you wrote:
>  > -----Original Message-----
>  > From: christian.engstrom@[...].org
>  > [mailto:christian.engstrom@[...].org]
>  > Sent: Thursday, February 26, 2004 4:40 PM
>  > To: boost@[...].org
>  > Subject: [boost] Proxy indirect container adaptor: 4 claims
>  >
>  > --Is there a way to define a package for indirect containers, so that
>  > one can take a program that uses a direct container, and
>  > convert it to
>  > using an indirect container just by changing the definition of the
>  > container type?
> 
> You could define a container adaptor that takes a container, and modifies 
> the begin()/end() iterators to return indirect iterators to the original 
> begin()/end().  Then instead of:
>    typedef some_container container_type;
> you would have:
>    typedef adaptor<some_container> container_type;
> 
>  > --Would it be any useful to be able to switch containers like that?
>  >
>  > The problem here is of course that "usefulness" is very much
>  > in the eye
>  > of the beholder, so all that I can say with certainty is that I
>  > personally would find it quite useful, and that I don't see why other
>  > people as well shouldn't sometimes find themselves in situations when
>  > they would want to change container types easily.  After all,
>  > isn't one
>  > of the great benefits of the STL containers that they have
>  > (reasonably)
>  > uniform interfaces, so that it's easy to switch between the different
>  > container types, often by just changing a typedef?
> 
> You might want to read "Beware the Illusion of container-independent 
> code", by Scott Meyers in his book: 
> http://www.awprofessional.com/isapi/content/images/0201749629/items/item2-2.pdf
> The full book is at: 
> http://www.awprofessional.com/catalog/product.asp?product_id={AA4735AF-4407-4011-B7D3-0C924
DFA675D%7d

I've read it and am considering writing an article explaining that although 
he's correct, part of the problem lies directly with "the 
Committee".  Scott writes about how things _are_, not as they 
could(should?) be.  Many of the restrictions are completely 
artificial.  I've said it before, and I'll continue saying it.  One of the 
big problems of the "C heritage" is that too many people think that syntax 
implies implementation.

> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr.      http://rudbek.com
The five most dangerous words in the English language:
               "There oughta be a law" 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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