[Dune] Changes during constification - problems regarding mark-method

[Thimo Neubauer]

Hi,

after quite some work Christian and I succeeded in a constified
grid-interface and SGrid. The major design goals were:

1. the grid-implementation class should provide most of the
   information the other implementations need

2. create normal and const-datastructures with only one implementation

3. use the ForwardIteratorFacade for iterators

4. mostly compatible usage from outside

For the first goal we pass a single grid implementation instead of a
list of classes which are connected via a grid implementation
anyway. The new form reads

template<class GridImp>
class SIntersectionIterator : 
      public IntersectionIteratorDefault <GridImp,SIntersectionIterator>

instead of

template<int dim, int dimworld>
class SIntersectionIterator : 
      public IntersectionIteratorDefault <dim,dimworld,sgrid_ctype,
               SIntersectionIterator,SEntity,SElement,SBoundaryEntity>

Values like dim can be extraced via 

  enum { dim=GridImp::dimension};

types with

  typedef typename GridImp::template codim<1>::Element Element;


The second goal is possible with this syntax as well: depending on if
GridImp represents a normal grid or a const GridImp the single
implementation expresses an iterator on a normal or a const grid,
i.e. a normal or a const-iterator. A conversion from a mutable to a
const-iterator has to be provided as well as the three functions
needed for the ForwardIteratorFacade (increment, equals and
dereference) and the implementation should be finished. There is,
however, a major problems with this approach...

Unlike normal containers with iterators declared on it the grid offers
a different functionality: dereferencing an iterators doesn't return a
component but a view on a part of the grid. This means even though an
entity is declared "const" you may want to change the container,
i.e. the grid: via the "mark"-method. Of course, an entity created by
dereferencing a const-iterator should not offer such a method which
means that the entity-interface needs to change depending on the
constness of the grid it's living on. Therefore we need Entity and
ConstEntity like the usual Iterator and ConstIterator.

This means that at least the dereference-method of each iterator
has to change the _return value_ depending on if GridImp is const or
not! We created a "AutoConst"-template trick which can be used for
this but that's rather nasty, because every grid-developer has to
remember using it or he'll get a whole lot of weird compiler errors.

A different fix which would ease the constification a lot would be to
move the mark-functionality to the grid-interface, e.g.

  Grid::mark(Entity &e)

which we would prefer... :) This should be pretty easy to implement,
as the grid-implementation which filled the entity-datastructure can
use it's own information.

Do we have more operations planned which would modify the grid via an
entity? Any reasons not to move mark to the grid?

Cheers

   Christian & Thimo