From: Roland Richter (roland_at_[hidden])
Date: 2002-10-19 11:12:56
David A. Greene wrote:
> I've often found the need to construct container adaptors to provide
> things such as a fixed-size vector. After once again writing
> some of these things, I'm wondering whether it might be worth
> designing a container adaptor library similar to the iterator
> adaptor library. I can see a container traits library coming
> out of this as well.
I'd just like to add some points ...
+ Yes, it might be valueable to have a container adaptor or "views"
library (I like the later term better) which follows closely the
paths of the iterator adaptor library.
+ If given some further thought, such an container adaptor library
appears as a straight-forward extension to the iterator adaptor
library. As much as the iterator adaptor lib is designed to
make "smart iterators" out of dumb one's, a container adaptor
library would wrap STL containers and add functionality to them.
+ Another way to think of views is that these mimic STL containers
(i.e., provide a common subset of methods, such as begin(), end(),
size(), etc.), but do return adapted iterators instead of ordinary ones.
Simply put: filter_view::iterator = filter_iterator_type etc.
+ I do not know your exact requirements; however, I doubt that views
are what you really need to design a "fixed-sized vector", since,
as Martin Weiser already pointed out, such container adaptors provide
"immutable 'views' onto existing data".
Martin Weiser wrote:
> We raised this topic some time ago, but got only a limited response. Not
> much discussion evolved.
I guess the main reason for that is that STL supports a style of programming
where iterators are used in preference over containers. Thus, to adapt
iterators seems to be more important than to adapt containers.
As a final point, let me add that I hacked an own version of a views
library some time ago, completely relying on Boost.IteratorAdapor, which
makes things easier compared to VTL (not guaranteed to even
compile with any compiler different than gcc).
If there actually is some interest in it [is there?], I'd be happy
to contribute to the Boost community.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk