Dynamic und Static Cast? oder einfach nur ein normales Cast?
-
CStoll schrieb:
PS: Und wenn du hier nichts produktives beitragen kannst, solltest du dich lieber in deinen Sandkasten zurückziehen. (Sorry, das mußte jetzt raus)
ok, tut mir leid. ich lasse euch jetzt in diesem thread in ruhe.
(du kannst ja meine postings hier löschen, wenn sie dich stören).
-
pale dog schrieb:
CStoll schrieb:
PS: Und wenn du hier nichts produktives beitragen kannst, solltest du dich lieber in deinen Sandkasten zurückziehen. (Sorry, das mußte jetzt raus)
ok, tut mir leid. ich lasse euch jetzt in diesem thread in ruhe.
Ich schlage vor, du gehst noch einen Schritt weiter und lässt uns in diesem Board in Ruhe.
-
CStoll schrieb:
pale dog schrieb:
CStoll schrieb:
PS: Und wenn du hier nichts produktives beitragen kannst, solltest du dich lieber in deinen Sandkasten zurückziehen. (Sorry, das mußte jetzt raus)
ok, tut mir leid. ich lasse euch jetzt in diesem thread in ruhe.
Ich schlage vor, du gehst noch einen Schritt weiter und lässt uns in diesem Board in Ruhe.
das ganze board? einschliesslich aller unterforen?
-
pale dog schrieb:
das ganze board? einschliesslich aller unterforen?
Eigentlich meinte ich nur das C++ Board, aber wenn du komplett verschwinden willst, ist mir das noch lieber
-
CStoll schrieb:
aber wenn du komplett verschwinden willst, ist mir das noch lieber
na gut, dann werde ich mich hiermit offiziell verabschieden.
man soll zwar aufhören, wenn's am schönsten ist, aber egal.
an alle: viel spass noch, war lustig hier und ich habe viel gelernt von euch
-
@CSToll u. Pale dog: Nur wegen meinem lächerlichen Thread, müsst ihr euch nich bekriegen.. hier muss auch keiner gehen ... was ist denn bei euch los...
-
@Boris: Nur um dich zu beruhigen - es geht nicht um diesen Thread. Die "Feindschaft" zwischen pale dog (alias vista/net/net/...) und mir besteht schon eine Weile und kocht wohl bei jeder Gelegenheit wieder neu auf.
-
Noch mal zum Thema zurück zu kommen:
ich habe eine CAllocation klases, welche Knoten als CAllocNode Klasse in einer Baumstruktur verwaltet. Durch diverse funktionen bspw.
CAllocNode* add(CAllocNode *pNode
);
so nun hab ich diverse klassen, ich nenn sie mal A,B,C welceh von CAllocNode abgeleitet sind.
A,B,C enthalten spezifische methodne und parameter, wobei CAllocNode nur die verwaltung methoden add, delete, instert etc. enthält.
später kann ich dann quasie die A,B,C objekt als knoten in der Baumstrutkur verwalten
A->add(new A(...));
Problem ist nun, das add nicht ein A pointer sonder der CAllocNode Pointer zurückliefert (siehe oben Mehtodenrumpf), deswegen muss ich dies mit static_cast machen:
A *p= static_cast<A*> (A->add(new A(..)));
verstanden?
-
Das erklärt immer noch nicht, warum du so unterschiedliche Klassen bunt zusammenwürfeln willst.
Und warum merkst du dir nicht den Pointer, den du an add() übergeben hast - der hat doch (noch) den richtigen Typ:
A* p = new A(...); node->add(p);
-
jepp das würde natürlich auch gehen, da hast recht..
Wieso ist das bunt zusammengefwürfelt?
CAllocNode representiert ja einen Knoten der Baumstruktur.
CAllocNode *pFather=...; CAllocNode *pChild=....; pFather->add(pChild);
später hab ich 3 Unterschiedliche Allocationstypen A, B ,C welche jeweils unterschiedliche eigenschaften besitzen.
Theoretisch hätte ich das als Template progarmmieren können, wo ich dann jeweils A,B,C einsetze, aber das geht nich, weil ein CAllocNode noch 2 Eigesncahften bestutze was alle Allocationstypen verwenden, das ist quasie die gemeinsamkeit...
später werden dann in 3 unterschiedlichen Klassen jeweils mit A,B,C gearbeitet, wobei diese dann die Baumstruktur als basis verwenden.
-
Was sind denn das für Spezialeigenschaften der einzelnen Allokationstypen?
-
Also:
-----------------------------------------------------
AllocNode besitzt die Grundlegen eigenschaftendouble Allokationsstart;
double Allokationsdauer;davon abgeleitet:
A (Process)
String ProzessTyp;
B (Handling)
int StartModul;
int Endmodul;
BYTE StateFlags;C (Collision)
int Modul;
-----------------------------------------
es kann sein das noch divere Eigenscahfen hinzukommen...
-
*grml* OK, dann fällt es wohl aus, für alles eine gemeinsame Schnittstelle anzubieten.
(denkt mal wieder über Boris' Baumstruktur nach) Wie setzen sich diese verschiedenen Knotentypen eigentlich in deinen Bäumen um? Und welche Beziehung besteht zwischen einem Vater und seinen Kindknoten im Baum?
-
Grund für meine Baumstruktur ist die Gruppierung und sequenzierung von AllocationKnoten (AllocNode)
Nehmen wir an ich habe eine Allocation aus drei 4 Knoten:
---- Base -----
---/-----\-----
--B------C-----
-------/---\---
----- A-----D--Eine Allocation ist vergleichbar mit der Reservierung einer Ressoruce in einer best. Zeispanne.
d.h. die summe der Allocationzeistpanne entsprich C, wobei so die Summe der Gsammten Allocation "Base" sich aus B und C zusammen setzt.
-
Und nach welchen Gesichtspunkten werden die Allokationen gruppiert? (btw, kann eine Gruppen-Allokation wie C auch eigene Zusatzattribute haben? und sind alle Nachfolger eines Knotens vom selben Typ?)
-
Konrad Rudolph schrieb:
HumeSikkins schrieb:
for (Iterator<Control> c = form->controls.begin(); c != form->controls.end(); ++c) { Button* b = dynamic_cast<Button*>(c); if (b) b->perform_click(); }
Ob das der Beste Weg ist, sei mal dahin gestellt.
Jetzt hast Du mich neugierig gemacht. Was wäre denn eine bessere Alternative?
Besser ist immer Kontextabhängig. Da ich den nicht kenne, kann ich dir nur ne andere Alternative vorschlagen: da wäre z.B. ein Observer-basierter Ansatz (wie er z.B. mit den Signal/Slots in der Qt verwendet wird). Hier würde das Formular verschiedene Ereignisse definieren. Interessierte Controls würden sich für bestimmte Ereignisse registrieren.
Mal unabhängig davon sollte man imo darauf hinweisen, dass dein Beispiel nicht mit dem des OP zu vergleichen ist. Im Form-Beispiel ist der dynamic_cast mehr eine "capability query" und am Ende ein Cast hin zu einer (weiteren) Abstraktion des Frameworks. Die Schleife ist nach wie vor unabhängig von konkreten (bzw. benutzerdefinierten) Klassen. Der OP castet hingegen hin zu konkreten Klassen. Hier stehen konkrete Typen und nicht mehr absrakte Fähigkeiten im Vordergrund. Das wiederum führt sehr leicht zur switch-on-type-Programmierung - mit all den bekannten Nachteilen.
-
nicht unbedingt der selbe typ , éin abgeleitest typ
A (Handling)
class A : public AllocNode{ }; clas A1: public A{ }; class A2: public A{ };
---- Base-------
--- /----\------
---A------A-----
-/--\---/-|-\---
A1--A2-A1-A1-A2-ein Allocation kann nur Knoten mit den Bassis typen A,B,C und deren jweile abgeleiten kalssen enthalten.. also keine mischformen von A,B,C..
Es gibt zwei unterschiedliche gruppierungsmodi..
- sequentielle gruppierung, das heist alle Kinder allokationen folgen zeitlich aufeinandern und wird insgesammt dann als Vater allokation gesehen.
-parallele gruppierung, das heist alle Kinderkonten ihn ihren start und allokationdauer können/sind parallel angeodnet,
Bsp. Kind1 20 sek. länge. kind2 30sek., so wird die gsamtn Allokation (Vater ) 30 sek. sein...
-
Ohje, ich fürchte, bei deinem Ansatz fehlt vor allem eins: ein vernünftiges Konzept. Bevor du weiter über solche Details nachdenkst, solltest du wohl zum Zeichenbrett zurückkehren und dir genau überlegen, was du überhaupt umsetzen willst.
-
wie würdest es du denn machen? was ist sooo schlecht? Welche denkfehler hab ich drin? wenn du dir mal die gruppierung weg denkst?
-
Der Hauptfehler besteht darin, daß du dein Konzept nicht wirklich verständlich erklären konntest (wenn da überhaupt ein Konzept ist). Und da ich nicht weiß, was genau dein Ziel ist, wird es etwas schwierig, dort Hilfestellungen zu geben.