Boost logo

Boost Users :

From: jens-theisen_at_[hidden]
Date: 2006-01-07 13:08:00


Say a library programmer wants to make a virtual interface to his class
with a function that returns a collection of things. Usually one end up
writing something silly like

class interface
  virtual std::vector< ... > give_stuff() const;

which has some disadvantages, the most important being:

- The implementing function must calculate the whole result, even if some
of it might not be needed. Especially infinite collections of things are
not possible in this way.

- The vector is a container and that's a poorly defined concept. As a
consequence, we can't do very much with it. For instance, you can't write
give_stuff() + give_more_stuff() to concatenate. Though it's easy to
implement that, we really don't want to do this on the basis of containers
in general and we also don't want to do it again and again in every single
project for std::vector in particular.

- As the library gets used, it's poor interface is carved in stone, and so
are the other two problems for it.

The first problem can be addressed by using an iterator to some container.
We obviouly can't use an iterator to a vector since that wouldn't solve
any problems. It has to be a custom iterator

class lib_iterator_impl : ...
  virtual ... dereference() const;
  virtual ... advance() const;

class lib_iterator
  lib_iterator(lib_iterator_impl const* impl);

class interface
  virtual lib_iterator give_stuff() const;

where lib_iterator_impl than has to be extended by the client of the
library. Actually, there is no real need for lib_iterator to be a proper
iterator in the standard sense.

Especially, such iterators could be aware of there ends (or even their
beginnings) to make it unnecessary to have always two of them. Both the
virtualisation and halving the number of those iterators would also reduce
the complexity of error messages.

On such a framework, many small building blocks could be build, like
concatenation, filtering, mapping, cartesian products, etc.

In my opinion, at least the very low-level parts of such a framework are
so important that they belong in boost.

My question at this point is in what regard people share this opinion and
to what extend we already have these things.

I have heard of any_iterator in the past, but I can't find anything about
it in the boost malings list archives or google, which would be related to
this. Other than this, I'm not aware of anything in this regard.



Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at