C++Talk.NET

Tino Schumacher · Guest

Hallo Newsgroup,

ich beschäftige mich gerade mit der Umsetzung von Kartenprojektionen, also
der Transformation von geographischen ( phi, lambda) in rechtwinklige
Koordinaten (x, y).

Hier meine Idee zur Umsetzung (meine Frage ist unten):

class // Basisklasse

CProjection

{

public:

CProjection(){}

virtual ~CProjection(){}

virtual CCoordinate transform( const double& dPhi, const double& dPhi) = 0;

};

class // abgeleitete Klasse für eine Projektion (Beispiel)

CAzimuthalProjection: public CProjection

{

public:

CAzimuthalProjection(){}

virtual ~CAzimuthalProjection(){}

virtual CCoordinate transform( const double& dPhi, const double& dPhi)

{

//Transformationsvorschrift für die entsprechende Transformation

// ....

return (CCoordinate(dX, dY));

}

};

class // Klaase die Projektionen verwendet

CUseCProjection : public CProjection

{

public:

CUseCProjection(const CProjection* ptrProjection)

: m_ptrProjection(ptrProjection) {}

virtual ~CUseCProjection(){}

void doSomeStuff

{

double dPhi = 0.,

dLambda = 0.;

// hier kommen viele, viele Transformationen

// ....

CCoordinate Point;

Point = m_ptrProjection->transform(dPhi , dLambda);

}

private:

CProjection* m_ptrProjection;

};

In dem Programm sollen mehrere Projektionen angebeten werden. Um die
Implementierung so übersichtlich wie möglich zu gestallten und spätere
Erweiterungen zu realisieren, wollte ich jede "neue" Projektion in eine
extra Klasse schreiben.

In dem Projekt sind sehr, sehr viele (!) Transformationsschritte
durchzuführen. Ist das oben dargestellte Design mit dem Zugriff auf eine
gemeinsame Basisklasse (RTTI-Run Time Type Information ) effizient oder ist
einen andere Lösung besser?

Um welchen Faktor würde das Programm schneller, wenn alle Projektionen in
einer gemeinsamen Klasse verwaltet und entsprechen einer
switch/case-Anweisung aufgerufen werden?

Danke Tino

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Karl Heinz Buchegger · Guest

Tino Schumacher wrote:

Frank Thilo · Guest

Tino Schumacher <tschumi (AT) cs (DOT) tu-berlin.de> wrote:
: Um welchen Faktor würde das Programm schneller, wenn alle Projektionen in
: einer gemeinsamen Klasse verwaltet und entsprechen einer
: switch/case-Anweisung aufgerufen werden?

Ich gehe davon aus, dass die Entscheidung, welche Projektion verwendet
werden soll, eher selten geschieht und diese Projektion dann auf sehr viele
Einzelpunkte angewendet wird? Somit wäre der polymorphe Dispatch für jeden
einzelnen Punkt eigentlich unnötig. Die Idee wäre dann, diese Entscheidung
vorzulagern. Eine triviale Variante wäre z.B., dass eine virtuelle Funktion
in den ProjektionsKlassen einen Funktionszeiger auf eine statische FUnktion
zurückliefert, etwa:

//////////////
#include <algorithm>

struct base {
typedef double (*transform_func)(double,double);
virtual transform_func get_transform() const=0;
};

struct derived : base
{
static double transform(double a,double b) {return a+b;}
transform_func get_transform() const {return transform;}
};

int main()
{
base *b=new derived;
base::transform_func f=b->get_transform();
const int count=10000;
double data[count];
std::fill(data,data+count,0.0);

for (int i=0;i data[i]=f(data[i],data[i+1]);

delete b;
}
///////////////

Ich habe dabei das Problem etwas vereinfacht, um das Prinzip zu
verdeutlichen. Der Geschwindigkeitszuwachs bei Verwendung von g++ 3.3 mit
-O3 ist bei obiger einfacher Transform-Operation deutlich (im Vergleich zu
einer virtuellen Transform-Funktion). Warum der Cpmpiler die Optimierung in
diesem einfachen Beispiel nicht selbst vornehmen kann, ist mir allerdings
unklar, evtl. entgeht mir etwas.

Das Beispiel geht weiterhin davon aus, dass die Transform-Funktion nicht von
weiteren Daten abhängt. Ansonsten bietet sich stattdessen ein Funktionsobjekt
an.

Wenn du wirklich pro Datum dynamisch die Auswahl der richtigen Projektion
brauchst, dürfte die Variante mit der direkten virtuellen Funktion wohl
schon das Optimum sein. Ich lasse mich durch Benchmarks aber vom Gegenteil
überzeugen Smile

.

--
Frank Thilo - [email]thilo (AT) unix-ag (DOT) org[/email] IRC: Chestal

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Albrecht Fritzsche · Guest

Tino Schumacher wrote:

Albrecht Fritzsche · Guest

Rolf Magnus wrote:

Rolf Magnus · Guest

Karl Heinz Buchegger wrote:

Torsten Robitzki · Guest

Hallo,

Tino Schumacher wrote:

Tino Schumacher · Guest

Karl Heinz Buchegger · Guest

Tino Schumacher wrote:

Tino Schumacher · Guest

"Karl Heinz Buchegger" <kbuchegg (AT) gascad (DOT) at> schrieb im Newsbeitrag
news:3FC7441F.E4183F35 (AT) gascad (DOT) at...