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

[Christian Engwer]

Hi Robert,
> Wo ist nochmal genau das Problem. Die Methode mark sollte
> selbstverständlich auf der Entity<0> bleiben, wo sie hingehört.
> Wenn ich ein Entity markieren möchte kann ich natürlich nicht mit einem
> const iterator übers Gitter laufen.

The main problem is:

You have a grid, this grid can be const and mutable. If you have
something representing a view on the grid, you need this to change
it's behavious depending on the constness of the grid,
i.e. Iterator<->ConstIterator

If we have a look at Entity and the mark method. Imagne you have an
Entity on a mutabe grid. Now you call the mark method. In contrast to
the content of a ususal Container you don't cahnge the Entity itself,
you only change the grid. So the Entity would be makred const (const
Entity) it wouldn't help. To change the behaviour of the Entity you
need an additional class ConstEntity with a slightly different
Interface.

Now you want to have two kind of Iterators:
- Iterator pointing to an Entity
- ConstIterator pointing to a ConstEntity
But you also want to write the code only once to cut the risk of
programming errors and these two Iterator classes do nearly the same.
The problem is that the dereferenced IteratorImp has to return an
Entity or a ConstEntity depending on the constness of the grid it is
working on.

Now we come to the point where you all can decide what to do. We were
able to mange all this. It is possible to change the return value
depending on the grid, but it is nasty.

Here the SLevelIterator as an example:

template<int codim, PartitionIteratorType pitype, // like usual
         class GridImp>  // the _real_ Grid it is living on i.e. const
                         // SGrid<2,2> so that you can decide what
                         // kind of Iterator you are
class SLevelIterator : 
  public LevelIteratorDefault <codim, pitype, GridImp, SLevelIterator>
{
  ...
public:
  // Depending on the constness of GridImp this gives us the right
  // return value for dereference
  typedef typename GridImp::template codim<codim>::Entity::
                            template AutoConst<GridImp>::Type Entity;

  //! dereferencing
  // This method changes it's semantic depending on the Type prvoded
  // by the AutoConst struct
  Entity& dereference() const;
  
  ...
};

This means we did not succeed in making the interface ,,foolproof''
because if you make it mistake with the AutoConst stuff you get very
strange error messages.

But it works. It is possible to keeps everything as it was.

On the other hand we could say that a view on the grid is never
allowed to change the grid. This would mean every Iterator is
automaticly a ConstIterator because every Entity is (like the Element)
automaticly a ConstEntity. We would the have a method

template<int dim, int dimworld>
void Grid<dim, dimworld>::
mark(const Dune::Entity<0,dim,const Grid<dim,dimworld> > & e)
{
  ...
}

And does not carry the keyword "const" it can not be called on a const
Grid.

So this would work as well. It would be easier to implement for the
grid developers but it would change our ideas of how the different
parts in a grid work together.

It is up to you. We don't care because we already managed to get it
running.

Cheers Christian