Views, Smart Iterators, and all the rest

A view is an adaptor for STL type containers that provides access to transformed or a subset of elements of the underlying container it is applied to. Transformation and filtering is done on the fly, without affecting the data actually stored in the container.

The interface provided by the views is the well known STL container interface, such that views can usually be used transparently as a drop-in replacement for the corresponding STL containers, if data is only to be read. Additionally, views can be applied to views, permitting a mix and match approach to construct increasingly complex views by layering suitable VTL components on top of each other (see section 4). Nearly all of the container requirements are met, except for occasional technical details and complexity guarantees.

Figure 1: Relation of views to containers, iterators, algorithms, and smart iterators.

0.5

From a read-only user's view, the relation between views and smart iterators is the same as between containers and iterators: views and containers are just factories for smart iterators and iterators, respectively, providing some additional meta information such as the number of elements.

There are essentially three ways to get a different sight onto the data stored in a container. First, one can use a view. Second, one can rely directly on smart iterators. And third, one can use a second container storing the result of an STL algorithm generating the required data.

Compared to using smart iterators, views

• are a natural extension. Providing the iterator interface but not the container interface is going only half the way.
• are not invalidated if the underlying container is modified. In general, smart iterators will be invalidated together with their underlying iterator.
• can clean up interfaces. Instead of providing several begin_xy() and end_xy() methods for data sets provided by a class, the class can provide access to views which in turn provide the usual container interface: xy().begin() and xy().end().
• can contain the underlying container by value. This permits layering views on top of each other as well as creating and giving around self-contained views.
• provide meta data such as size() which is sometimes more convenient or more efficient than obtaining the same information from smart iterators.

On the other hand, smart iterators are sufficient in many situations, e.g. for feeding them into a STL algorithm. In many of those cases, the use of views does not provide any benefit. Note that, since all the hard work is done by the smart iterators produced by the views, there is no performance difference between using smart iterators and views.

Compared to transforming the data into a second container, views

• have a smaller memory footprint, since the provided elements are generated or accessed on the fly without copying.
• are more efficient if only parts of the data are accessed. The copy approach usually must generate the whole data set, and reproduce it if the original data changes.
• provide data consistency, since the view's elements are rendered on demand. Tracing changes in the original data and updating the second container may be a difficult task, otherwise.
• can lead to worse compiler error messages if used incorrectly.

On the other hand, the generate-on-demand technique of the views is likely to be less efficient if the data elements are accessed very often, and the complete control over the second container enables the use of suitable access patterns.