mood-indigo.org - Das unabhängige Silicon Graphics User Forum
Irix => Programmieren, Kompilieren => Thema gestartet von: majix am 19. April 2004, 01:48:11
-
Ich habe ein kleines Problem mit C++. Man stelle sich vor
class A {
virtual f();
}
class B : public A {
virtual f();
}
Ich habe also zwei Klassen A und B, und die haben jeweils eine virtuelle Funktion. Nun bekomme ich irgendwo im Programm zwei Pointer des Typs A*, und möchte nun gerne wissen, ob beide Objekte die gleiche Implementierung von f haben (sonst können sie sich unterscheiden). Also sowas wie
A* o1,o2;
if (o1->f == o2->f)
mach was tolles
Ich will sozusagen die Funktionspointer vergleichen. Nur leider - das geht eben nicht. Bei virtuellen Funktionen sind beide pointer immer identisch, obwohl die Implementierungen verschieden sind (!). Dieses Phänomen wird auch als solches beschrieben, und das ist wohl auch so gewollt. Nur eben von mir nicht.
Kann mir jemand einen Tipp geben, wie ich wirklich die Funktionspointer vergleichen kann?
Grüße,
Kaya
-
vielleicht findest hier was:
http://www.function-pointer.org/
rob
-
Hallo Kaya,
ich bin leider auch kein ausgesprochener C++-Spezialist :-(
Dass beide Funktionen denselben Pointer haben, liegt wohl im wesentlichen daran, dass die Auflösung des Methodenaufrufs eben indirekt über eine virtuelle Funktionentabelle funktionert, d.h. der Caller erhält im wesentlichen nur einen Zeiger in die VFT, und auf den Rest hast Du keinen Einfluss.
Sowas lässt sich m.E. nur mittels Metaklassen und/oder Funktionsobjekten statt Funktionen lösen, das ist aber bei Dir wohl keine Option. MIt Assemblerpfusch kriegst Du das sicher auch hin, willst Du aber nicht :-)
Zu Deiner Frage siehe z.B. auch:
http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&oe=UTF-8&threadm=760hin%24qva%241%40engnews1.eng.sun.com&rnum=10&prev=/groups%3Fhl%3Dde%26ie%3DUTF-8%26oe%3DUTF-8%26q%3Dvirtual%2Bmethod%2Bcompare%2Bimplementations%2Bc%252B%252B%26spell%3D1
Frage: Wozu brauchst Du das denn? Vielleicht kannst DU Dein Ziel auf anderen Wegen erreichen.
Gruss
JM
-
Hallo Kaya,
eigentlich willst Du ja wissen von welchem Typ A oder B sind ? Schau mal unter RTTI (Run Time Type Information) nach.
Viel Glück
Matthias
-
Hi Matthias, Jasper,
das ist eben mein Problem: Ich will nicht wirklich wissen, ob A und B den gleichen Typ haben, ich habe nämlich wesentlich mehr Ableitungen von A, und diese haben auch wieder Ableitungen. Ich will eben nur wissen, ob zwei abgeleitete Objekte die gleiche Funktion f besitzen - in anderen Punkten können und werden sich die Klassen sehr wohl unterscheiden.
Es hierbei um folgendes: Ich habe verschiedene Shaderklassen, und jede Klasse besitzt eine virtuelle Methode zum aktivieren des Shaders und eine zum deaktivieren. Wenn ich nun einen neuen Shader aktiviere, dessen Deaktivierungs-Funktion mit der des aktuellen Shaders übereinstimmt, dann brauch ich den alten auch erst gar nicht zu deaktivieren. Spart ein paar OpenGL-Aufrufe. Denn in vielen Fällen werden unterschiedlich Shader identisch dektiviert, aber verschieden aktiviert.
Grüße,
Kaya
-
Hört sich ja ganz schön fies an ::)
Wie wäre es denn wenn die abgeleitete Klasse gar kein f() definiert (wodurch f der Oberklasse aufgerufen wird) bzw. a::f() aufruft ? Das ist doch kein Laufzeitproblem, wenn ich das richtig verstehe, jede Klasse sollte ja wissen wie der Shader zu deaktivieren ist.
Gruß
Matthias
-
Moin,
koenntest Du nicht einfach jedes unterschiedliche f() in seine eigene kleine (Wrapper-)Klasse stecken und dann als Methode aufrufen ? Damit funktioniert der Vergleich ueber RTTI wieder.
Gruesse,
Chris
-
@Matthias:
Ich verstehe nicht ganz, was Du meinst... f soll ja gerade den Shader deaktivieren, und das kann ja von Klasse zu Klasse unterschiedlich sein. Beispiel: Environment Texture Mapping, hier würde f dann glDisable(GL_TEX_GEN_S) etc aufrufen.
@Chris:
Wäre eine Möglichkeit, aber solche komplizierten Konstrukte wollte ich vermeiden.
Ist eigentlich echt ein Witz: Ich will einfach nur die Pointer auf die Funktion vergleichen, genau diese Adressen, die im VTABLE stehen, nur C++ scheint mich da nicht ran zu lassen. Vielleicht schaffe ich es ja doch durch geschicktes casten, da hatte ich gestern zwar keinen Erfolg mit, aber ich werde es nochmals versuchen. Das MUSS doch irgendwie gehen.
Grüße,
Kaya
-
Es hierbei um folgendes: Ich habe verschiedene Shaderklassen, und jede Klasse besitzt eine virtuelle Methode zum aktivieren des Shaders und eine zum deaktivieren. Wenn ich nun einen neuen Shader aktiviere, dessen Deaktivierungs-Funktion mit der des aktuellen Shaders übereinstimmt, dann brauch ich den alten auch erst gar nicht zu deaktivieren. Spart ein paar OpenGL-Aufrufe. Denn in vielen Fällen werden unterschiedlich Shader identisch dektiviert, aber verschieden aktiviert.
Hallo Kaya,
generell finde ich es keine so tolle Idee, das Laufzeitsystem aus Performancegründen überlisten zu wollen. Meistens weder portabel noch nachvollziehbar. Ausserdem verbirgst Du dann die Implementierung nicht vor dem verwendenden Programm.
Du könntest z.B. Metainformationen mittels (leeren) Interfaces und Mehrfachvererbung organisieren, ähnlich wie das in Java geht, die z.B. nur klassifizieren, welche Shader eine gemeinsame Deaktivierung besitzen. Dann müsstest Du mit RTTI an die gewünschte Information kommen können. Ein optimierender Compiler sollte da nicht viel langsameren Code generieren.
Gruss
JM
-
Also das wäre mein Vorschlag (ist dem von Chris ähnlich):
Zuerst ein paar Basisklassen:
class Activator
{
public:
virtual void activate () = 0;
};
class Deactivator
{
public:
virtual void deactivate () = 0;
};
Von denen leitest Du für jede Möglichkeit, die Dir im Moment einfällt, eine Klasse ab. Diese registrieren sich bei einem Factory-Objekt:
class Factory
{
public:
static Activator *getActivator (const char *name);
static Deactivator *getDeactivator (const char *name);
static registerActivator (Activator *act, const char *name);
static registerDeactivator (Deactivator *deact, const char *name);
...
};
Die Shader-Basis-Klasse:
class Shader
{
public:
Shader (Activator *a, Deactivator *d)
: m_activator (a)
, m_deactivator (b)
{ }
virtual ~Shader ()
{
delete (m_activator);
delete (m_deactivator);
}
Activator *activator () { return (m_activator); }
Deactivator *deactivator () { return (m_deactivator); }
void begin ()
{
if ((m_lastActivator == 0) || (m_lastActivator != m_activator)
{
m_activator->activate ();
m_lastActivator = m_actiavator ();
}
}
void end ()
{
if ((m_lastDeactivator == 0) || (m_lastDeactivator != m_deactivator)
{
m_deactivator->activate ();
m_lastDeactivator = m_deactivator ();
}
}
private:
Activator *m_activator;
Deactivator *m_deactivator;
static Activator *m_lastActivator;
static Deactivator *m_lastDeactivator;
};
// static initializations (lives in Shader.cpp file)
Activator *Shader::m_lastActivator = 0;
Deactivator *Shader::m_lastDeactivator = 0;
Jetzt bastelst Du Dir einen Shader zusammen:
class MyShader : public Shader
{
public:
MyShader ()
: Shader (Factory::getActivator ("test"), Factory::getDeactivator ("test"))
{ }
...
};
Das letzte Problem ist jetzt, dass Du eigentlich die Shader::begin() und Shader::end() nicht implementieren kannst, wenn Du nicht weisst, welcher Shader als nächstes kommt. Aber das sollte auch kein Problem sein, wenn Du beide Funktionen in die Renderer-Klasse einbaust, die die Shader benutzt.
MfG,
Tilmann
-
@Jasper:
Für so unelegant halte ich meine Methode nicht - ich habe natürlich eine kleine Wrapper-Methode, die man aufruft, um weiterhin die Implementierung zu verbergen. D.h. die Programme werden sowieso nicht direkt die Funktion f aufrufen, sondern eine andere Funktion, die eben testet, ob der Aufruf von f überhaupt notwendig ist. Und ja, für höchstmöglichste Performance sollte man etwas tricksen, und vor allem redundante OpenGL Aufrufe eliminieren. Ich denke gerade im Grafikbereich kann sowas durchaus entscheidend sein.
@Tilman:
Wow, ein ganzer Haufen Code. Danke :)
Ist auf jeden Fall eine Überlegung wert - es stört mich halt nur, dass jetzt die beiden Funktionen (aktivieren, deaktivieren) in getrennte Klassen wandern, wobei diese ja eigentlich sehr eng miteinander verwandt sind.
Ich sehe schon, meine einfache Idee ist leider so nicht ohne weiteres machbar... naja, ich werde heute abend nochmal ein wenig rumspielen, vielleicht finde ich ja doch noch eine unkomplizierte Lösung.
Grüße,
Kaya
-
Und ja, für höchstmöglichste Performance sollte man etwas tricksen, und vor allem redundante OpenGL Aufrufe eliminieren. Ich denke gerade im Grafikbereich kann sowas durchaus entscheidend sein.
Hallo Kaya,
definitiv ;-) Kannst ja mal in den Code vom OpenSG (http://www.opensg.org) reinschauen, der ist selbst auf SGIs mittlerweile sehr performant und stellt das ein oder andere kommerzielle Produkt in den Schatten.
Gruß
atthias
-
Noch 'n Link, der in eine ähnliche Kerbe haut (wobei auf die ID-Software-eigene Definition von "shader" geachtet werden muss):
http://home.planet.nl/~monstrous/tutshader.html
MfG, Tilmann
-
Hallo Kaya,
unelegant ist das sicher nicht, was Du vorhast, aber eben problematisch. M.E. ist Tilmans Ansatz sicher eine gute Idee, denn er kapselt den Zugriff auf den Shader auf definierte Weise und kommt ohne Mehrfachvererbung und RTTI aus. Ob das von der Laufzeit besser ist? Ausprobieren.
Andere Vorschläge:
-> und oder == überladen, und statt einer Funktion f() ein Funktionsobjekt herzunehmen (nur 'ne Idee, keine Ahnung, ob man das so machen kann...)
Templateklassen verwenden, und auf virtual verzichten: So verzweifelt bist Du nicht
Du könntest natürlich auch für jede Shaderklasse eine virtuelle Methode f_overrides_baseclass einführen und das abfragen...
Und nein, die Funktionen activate und deactivate sind für dein Problem eben nicht eng miteinander verwandt...
Gruss
Jasper
-
@Matthias:
Bis heute habe ich mir OpenSG noch nicht angesehen, aber das werd ich demnächst mal nachholen. Gerüchteweise ist der Code aber derart komplex, dass es kaum jemanden mehr gibt, der ihn noch vollständig durchschaut.
@Tilman:
Danke für den Link, werd mir das mal etwas genauer ansehen. Allerdings sind die dortigen Struktuen bei mir eher Materialen, Shader sind für mich wirklich aktive Programme, die durch die Materialen parametrisiert werden. Das scheint so am meisten Sinn zu machen, was Flexibilität anbetrifft.
@Jasper:
Es kommt auf die Sichtweise an, ob die beiden Funktionen verwandt sind oder nicht. Aus Sicht des Shaders sind sie definitiv verwandt, und genau deshalb will ich sie nicht auseinanderreißen. Denn die "deactivate" Funktion muss immer einige OpenGL States ausschalten, die von der "activate" Funktion eingeschaltet worden sind. Sonst gibt es hässliche Resultate auf dem Monitor. Durch Auseinanderreißen von logisch eng zusammenhängenden Dingen scheint mir eine potentielle Fehlerquelle zu sein, deshalb sträube ich mich da ein wenig.
Aber ein gutes Buch über Design Pattern in C++ könnte mir nicht schaden... Kennt jemand eines?
Grüße,
Kaya
-
Kaya,
Gamma et al.: "Design Patterns". hat die Diskussion ueber Patterns losgetreten und ist immer noch eines der wichtigsten Werke.
Übrigens, allen Lösungsvorschlägen gemein ist, dass sie auf 'Delegation durch Vererbung' beruhen. Die Konstruktion laesst sich statisch mit vier oder fuenf extra Zeilen (bei gleicher Funktionalitaet wie in Deinem Beispiel) oder dynamisch mit einem Factory Pattern, wie von Tilmann vorgeschlagen, realisieren, die Performanz ist in jedem Fall die gleiche wie die einer virtuellen Funktion.
Gruesse,
Chris
-
Danke für den Link, werd mir das mal etwas genauer ansehen. Allerdings sind die dortigen Struktuen bei mir eher Materialen, Shader sind für mich wirklich aktive Programme, die durch die Materialen parametrisiert werden. Das scheint so am meisten Sinn zu machen, was Flexibilität anbetrifft.
Ja, das war's, was ich mit "ID-Software-Definition" meinte. Quake III ist dann halt doch etwas älter als die DirectX 8 Spec.
Aber das Prinzip sollte übertragbar sein, zumal IIRC irgendwo steht, dass die ID-Jungs die Funktionen nutzen, um OpneGL-Calls einzusparen. Allerdings bezieht sich das wohl darauf, den "shader" nicht jedes mal neu zu setzen, wenn mehrere Primitive hintereinander gleich gerendert werden.
MfG,
Tilmann
-
Und bevor ich's vergesse: Der Gamma ist Gold wert!
:D
MfG,
Tilmann
-
Um nur kurz über den Stand der Dinge zu berichten: Ich habe vorläufig meine Optimierungsidee rausgenommen, es gibt ja noch so viel anderes zu tun...
Grüße,
Kaya
-
Hallo Kaya!
Wichtig ist halt nur, dass Du dran denkst, das wir irgendwann auch mal das Ergebnis zu sehen kriegen.
Wenn Du es schaffst, die erste "mood-indigo.de"-Demo zu veröffentlichen, kann ich mich vielleicht auch aufraffen! ;)
Also programmier' nicht für den Eimer oder Dein Ego und gib unseren fetten Grafikkarten Futter! (Auch wenn ich aus dem restlichen Thread darauf schliesse, dass es auf meiner Octane/MXE wohl nicht läuft...)
Vor Vorfreude ganz aufgeregt,
Tilmann
-
Klar, sobald die Zeit reif ist... im Augenblick rennt das alles allerdings nur unter Windows - vor langer Zeit hatte ich auch mal eine IRIX Version am laufen, aber das wäre wieder eine Menge Arbeit und hat im Moment nur niedrige Priorität.
Bis jetzt gibbets auch noch nicht so wahnsinnig viel zu sehen, viel Arbeit geht halt immer in den ganzen Unterbau. Um genau zu sein, gibt es im Augenblick nur ein doofes 3DS Modell zu sehen... als nächte Schritte sind geplant:
1. Rendern in Texturen
2. Weitere Shader (Bump-Mapping fällt mir da spontan ein)
3. Loader für Milkshape Objekte
Die Gründe, weshalb ich im Moment mehr auf Windows mache sind schnell angegeben:
1. Die Grafikhardware kann einfach wesentlich mehr.
2. Visual C++ ist eine der besten Entwicklungsumgebungen, die ich je gesehen habe. Vor allem der Debugger ist ein Traum, da kommt der GNU-Kram nicht ran.
Aber irgendwann will ich wieder eine IRIX Version zum Laufen kriegen - wird aber halt noch dauern, bis ich die Zeit und Muße dazu habe. Meine Webseiten warten auch auf so manche Aktualisierung...
Grüße,
Kaya
-
2. Visual C++ ist eine der besten Entwicklungsumgebungen, die ich je gesehen habe. Vor allem der Debugger ist ein Traum, da kommt der GNU-Kram nicht ran.
Da kann ich Dir nur beipflichten. Ich muss unter IRIX sogar mit dem dbx ran, weil der gdb bei Programmen mit POSIX threads crasht.
Ausserdem habe ich mich dummerweise auf Arbeit so an das Visual Studio gewöhnt, dass ich schon nicht mehr auf den Luxus verzichten will.
Glücklicherweise bin ich zuhause in der glücklichen Lage, wenigstens auf einem SGI-PC entwickeln zu können. Und weil der CVS-Server auf der Octane läuft, mache ich auch ziemlich regelmässig IRIX-Builds von meinem Zeug. So bleiben die beiden Versionen eng beieinander und ich muss selten viel Zeit für den Port aufwenden.
Naja, Mittagspause ist um, dann gehe ich mal wieder weitercoden...
Schönen Tag noch,
Tilmann
-
Da kann ich Dir nur beipflichten. Ich muss unter IRIX sogar mit dem dbx ran, weil der gdb bei Programmen mit POSIX threads crasht.
Ist es das gleiche Problem wie unter Linux? Da hatte doch die Glibc einen Bug, der das debuggen bei Verwendung von POSIX-Threads verhinderte. Ab einer bestimmten Version ist es dann wieder gegangen, dürfte wohl etwa ein Jahr her sein. Hat mich zumindest damals mächtig genervt.
cu,
Michael
-
Ist es das gleiche Problem wie unter Linux? Da hatte doch die Glibc einen Bug, der das debuggen bei Verwendung von POSIX-Threads verhinderte.
Ne, leider nicht. Der gdb mag unter IRIX wirklich nicht mit mit pthreads zusammen. Siehe:
http://freeware.sgi.com/Installable/gdb-5.3.html
Dummerweise habe ich das erst gelesen, nachdem ich ein paar Tage lang versucht habe, meine Software zu debuggen.
MfG,
Tilmann
-
Schade, ich erinnere mich auch daran, dass ich beim Debuggen massiv Probleme wegen der pthreads hatte - keine Ahnung mehr, wie ich das Problem umgangen bin.
Aber alles in allem hatte ich eigentlich fast alles immer unter Windows programmiert, sogar die ganzen Fehler im Quelltext, die der gcc nicht mochte, hatte ich mit dem Visual Studio behoben, alles wieder auf die Octane kopiert und erneut gcc gestartet. So konnte ich die Arbeitszeit mit den GNU-Tools minimieren ;)
Was mich mal interessieren würde, wie ist das mit dem MipsPro? Ist das "nur" ein Compiler, oder sind da auch andere Entwicklungswerkzeuge dabei, wie eben zum Beispiel ein guter Debugger?
Grüße,
Kaya
-
Was mich mal interessieren würde, wie ist das mit dem MipsPro? Ist das "nur" ein Compiler, oder sind da auch andere Entwicklungswerkzeuge dabei, wie eben zum Beispiel ein guter Debugger?
Ja, ist dabei: Developer Magic/ Workshop
Aus den release notes:
The four main WorkShop components are the debugger cvd, the static analyzer cvstatic, the performance analyzer cvperf, and the coverage analyzer, cvcov (also known as Tester). In addition, WorkShop also provides an annotated source code viewer, a build analyzer, online documentation and help system.
Viele Gruesse
Roland
-
Apropos cvd,
bevor man den benutzt, sollte man sich dringend eine Dualhead-Maschine zulegen, um die vielen Fenster auch unterbringen zu können 8)
Beste Umgebung auf IRIX ist immer noch ddd in Kombination mit dbx.
Gruß
Matthias
-
Und apropos Dev Workshop:
einige (fast alle) commandline-tools funktionieren auch ohne Workshop lizenz und sind brauchbar.
z.B.
cvbuild: zeigt eine graphische Darstellung der Targets eines Makefiles - ist wirklich brauchbar
cvmeter: zeigt allerhand Daten ueber einen laufenden Prozess - auch nicht schlecht
cvmake: einfach ein frontend zu make - ich habe es noch nie wirklich benutzt
ahja, und wer es installiert hat, sollte sich mal das tutorial zum Dev WorkShop ansehen - einfach z.B. cvd starten, die Lizenz-Info wegklicken und im Menue <Help> auf <Tutorial...> klicken. ist wirklich sehenswert - auch fuer Nichtprogrammierer :)
Gruesse
Roland
-
Beste Umgebung auf IRIX ist immer noch ddd in Kombination mit dbx.
Echt jetzt? Ich habe den ddd (unter Linux) vor Jahren mal ausprobiert und bin damals nicht wirklich glücklich geworden, weil er instabil war.
Aber mittlerweile ist das Teil dann wohl wieder einen neuen Versuch wert! Werde ich gleich mal ausprobieren...
MfG,
Tilmann