Glas List: Re: [glas] dense and sparse vectors

From: Theodore Papadopoulo (Theodore.Papadopoulo_at_[hidden])
Date: 2005-08-12 08:02:43

On Fri, 2005-08-05 at 17:00 +0200, Toon Knapen wrote:
> Theodore Papadopoulo wrote:
> 
> > Maybe having both versions: begin(XXX) and begin() would make sense.
> 
> I just switched from nz_begin() and all_begin() to begin(glas::nz) and 
> begin(glas::all) in the tk1 branch and is simplifies at least the 
> dense-adaptor (which makes begin() default to either of these). Next up 
> is implementing an axpy operation to see what interface is actually 
> needed to support an efficient implementation of algorithms.

        Hi Toon,

I finally took the time of making some trial of what I was proposing.
First, you forgot to add the glas/iterators.hpp file to the repository
(hence a bunch of #if 0 ... #endif in the attached patch, sorry but I
had to do this to be able to compile the test).

Here is a very crude implementation of what I was thinking (just for nz
iterators and only for structured_vector). For the time being, I tried
to modify your code as little as possible and put most of my added stuff
in a specific namespace to better discriminate it. This can obviously
change (eg everything can go into details).

I only changed the following three files:

glas/structured_vector.hpp
glas/types.hpp
test/structured_vector.cpp

I tried to give details in the code comments... but:

As you can see, I introduced two markers BEGIN and END just to delay the
construction. Also I introduced a templated iterator in
structured_vector that delegate the actual iterator implementation of
the iterator to some outside class (and reused your nz struct to specify
the few things I needed). This allows for:

- Expandable iterators (create your iterator, your tag and this is it...
  at least if the container class provides enought information for you
  to implement your iterator).
- Can be used with the std stuff (sorting elements, finding elements,
  for_each,....). Well, if the iterators obey the std rules (which is
  not yet the case with this sample code).
- Homogeneous syntax (see test/structured_vector.cpp for a complete
  simple example):
  for (vector_type::iterator<nz> itv=v.begin();itv!=v.end();++itv) {}

The only two drawbacks I can see (and I'm using this quite a lot) are:

- You cannot use the future (if adopted) auto proposal since here the
  information cannot be determined by the return type of begin(), thus
  the idea of keeping your begin(nz) stuff (but maybe redistributing the
  code slightly).
- Because of the forwarding of iterators twice (once in
  structured_vector, and once with generic_vector which just aims at
  keeping the repetition within all the classes like structured_vector 
  as small as possible), errors messages can sometimes be somewhat
  confusing. It could be possible to avoid one of the forwarding by
  using include hackery, but I do not like the idea much...

Let me know what you think of this idea... if it seems OK, then I'll try
to adapt more containers/iterators and eventually reorganise some of the
code).

All comments are welcome.

        Theo.