Boost logo

Boost :

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2002-11-09 23:33:32

On Saturday 09 November 2002 16:05, Jason D Schmidt wrote:
> Should algorithms that take an array of data simply take some
> container as an argument and return as a container (if appropriate), or
> should they take input iterators, an output iterator, and return an
> output iterator (ala STL)? An STL-style algorithm would work just as
> well for C arrays as for any standard container. If the algorithm takes
> a std::valarray<T> (not a standard container), for example, then the
> programmer who writes the algorithm can take full advantage of the
> natural math operations defined for
> that class. After all, why should we even allow a user to integrate a
> std::list of data? That's not the intended use of the list class.
> However, that is THE one and only intended use of the valarray class, and
> providing an iterator interface doesn't allow numerical algorithms to
> operate on C++'s only numeric array class because valarrays don't have
> iterators. Then again, maybe someone will want to use a boost::array as
> often as a plain C array as often as their own array class; then that
> user is forced to use the valarray class when it doesn't necessarily fit
> his needs.

You can find a solution to this in

For making bindings to several libraries from also a multitude of containers
(in our case vectors and matrices) Kresimir Fresl developed a traits class
that provides a uniform interface for a number of vector and matrix libraries
such as boost::ublas, boost::array, std::vector, tnt etc.

Since the algorithms you mention are really operations on vectors and
matrices, pass the container to the function but access it via the above
traits to be able to handle a multitude of different vector/matrix


Boost list run by bdawes at, gregod at, cpdaniel at, john at