[Dune] Re: Frage Grid Interface.

Peter Bastian Peter.Bastian at iwr.uni-heidelberg.de
Mon Mar 24 12:30:42 CET 2003


Robert Kloefkorn schrieb:
> 
> Hi Peter,
> 
> ich werde heute die Arbeit an der Albert Anbindung abschliessen und
> einchecken. Eine Sache ist mir noch nicht so ganz klar. Ich denke wir
> sollen ein gridinterface.hh oder so anlegen, in dem die mindest
> Funktionalität eines Gitters überprüft werden sollte.
> Mir ist nicht klar, in welchem von beiden Verzeichnissen, dune oder
> duneapps, man dieses interface.hh ablegen sollte. Eigentlich ist es ja
> keine Anwendung, sondern gehört zum Paket dazu, andererseits liefert es
> auch keine Funktionalität, bis die, unsere Implementierungen auf
> Konsistenz zu überprüfen. Beim Implementieren dieses Interface Checkers
> sollten wir sorgfältig vorgehen, denn damit steht und fällt die ganze
> Sache.
> 
> Im wesentlichen sollte in diesem Interface file das enthalten sein, was
> sich im Moment in deinem main.cc befindet.
> 
> Ein Möglichkeit wäre, im Verzeichnis des jeweiligen Gitters, also z.B.
> 
> dune/grid/sgrid ein interfacecheck.hh oder so anzulegen, welches dem
> momentanen main.cc entspricht und dann ein file
> dune/grid/common/gridinterface.hh einbindet, welches z.B. ein Funktion
> wie iterate_level implementiert.
> 
> Oder aber, jede Grid Klasse enthält eine Mehtode test, welche dann
> mittels der Funktionen in gridinterface.hh den Schnittstellen Test
> übernimmt.
> 
Hallo Robert,

Du hast vollkommen Recht. Genau dieses ist mir beim implementieren von
sgrid auch klar geworden. Man kann die Schnittstelle nicht
anhand einer Pilotimplementierung dokumentieren, da dort
Schnittstelle (was ist ein Grid) und Implementierung (spezielle
Methoden und Klassen, die ich für SGrid brauche) miteineander
verwoben sind. 

Es muss doch etwas wie eine Basisklasse im Barton Nackman geben.
Man wird diese zwar nicht in den generischen Algorithmen verwenden,
aber um sicherzustellen, dass alle Methoden im mit den richtigen
Typen implementiert sind ist das praktisch.

Ich habe auch schon eine Idee wie das implementiert werden kann.
Ich habe nämlich gefunden, dass man templates als template-Parameter
übergeben kann (stroustrup C.13.3). Hier ein Beispiel wie Grid aussehen
könnte:

template<int dim, int dimworld, template<int,int> class GridEngine>
class Grid {
public:
	int maxlevel() { return gref.maxlevel; }
	... hier würde man alle Methoden von Grid aufführen ...
	GridIF (GridEngine<dim,dimworld>& g) : gref(g) {}
private:
	GridEngine<dim,dimworld>& gref;
};

Der dritte Parameter von Grid ist ein Klassentemplate mit
zwei int Parametern (das wäre zB SGrid). Die Methoden von
Grid sind nun mittels member function forwarding auf
die Engine implementiert.

verwenden würde man das dann so:

template<class T>
void test (T& t)
{
	cout << t.maxlevel(); << endl;
}

SGrid<2,2> sgrid( Tupel<int,2>(1,1) , Tupel<double,2>(1.0,1.0) , 2 );
Grid<2,2,SGrid> grid = sgrid;
test(grid);

Man kann natürlich Grid als Basisklasse für SGrid verwenden und
dann wie im Barton-Nackman verfahren.

Mein nächstes Ziel wäre nun ein grid.hh, das genau die Schnittstelle
auf diese Weise beschreibt und dokumentiert. in dune/grid/common
könnte man dann noch Testfunktionen unterbriengen. Denn es muss
jede Methode einer Template-Klasse auch einmal aufgerufen werden damit
auch der Code wirklich übersetzt wird.

Wie findest Du das?

Gruß

-- Peter
------------------------------------------------------------------
Peter Bastian, IWR,Uni Heidelberg, INF 348,R 020, 69120 Heidelberg
email: Peter.Bastian at iwr.uni-heidelberg.de   Tel: +49 6221 54 4984
WWW: http://www.iwr.uni-heidelberg.de/~Peter.Bastian Fax: ... 8860




More information about the Dune mailing list