[Dune] DGFParser interface

[Markus Blatt]

On Mon, Jul 24, 2006 at 03:56:34PM +0200, Christian Engwer wrote:
> 
> We considered the GridPtr class a hack to avoid pointers and to avoid
> the need of a uniq constructor for all grids.
> 
> Option one would be to define a uniq constructor in the interface and
> make this a requirement for all grids.
> 
> This uniq constructor might look like this:
> 
> DuneGridFormatParser p("filename");
> Grid<...> g(p, mpi_comm);
> g.lbegin();
> ...
> 

The problem I see here, is that dgf code might be split between
several repositories and thus the code is not any more easily
maintainable.
I would prefer having dgf code just in one place.

> The second option is to subclass the gridclass and do the
> specialization in this subclass grid:
> 
> template<class Grid>
> class MacroGrid<Grid> : public Grid, private DuneGridFormatParser
> {
> public:	
>   MacroGrid(const std::string &fname, MPI_Comm comm);
> }
> 
> We should also consider adding a second constructor 
>   MacroGrid(const std::string &fname)
> which instatiates sequentiell grids. If your grid uses MPI it could
> just use MPI_COMM_WORLD and test for a size of 1.
> 

This would break template specialization for different grids as every
grid construct with a dgf parser would be a Macrogrid in the first
place and the default implementation would be used.

Example code that proves this:

#include<iostream>

template<typename T>
struct Func
{
  enum {special = false};
};


struct A{};

struct C{};


struct B : public A, private C{};

template<>
struct Func<A>
{
  enum{special=true};
};

int main()
{
  std::cout<<Func<B>::special<<std::endl;
}


Is there any special reason to not make the grid accessible via a
method like
template<class G>
class DGFParser{
      ...
      G& grid();
      ...
}

Sure the user has to take care not delete the DGFParser and still
access grid. But that should be quite obviuous.

Just my 2 cents.

Markus

-- 
DUNE -- The Distributed And Unified Numerics Environment 
<http://www.dune-project.org>