3. vector mit Interface Klasse

vector mit Interface Klasse

  • ?

    dynamic_cast gibt es eigentlich nur um dich darauf hinzuweisen das dein Klassendesign falsch ist.

    0

  • ;> schrieb:

    dynamic_cast gibt es eigentlich nur um dich darauf hinzuweisen das dein Klassendesign falsch ist.

    Nein. Oder hast Du eine Begründung für Deine Aussage?

    0
  • V

    mgaeckler schrieb:

    MichelRT schrieb:

    Wenn Du wissen musst welche konkrete Klasse Du gerade aus dem vector geholt hast, dann ist Dein Klassendesign falsch.

    Wie kommst Du darauf? Was meinst Du wozu es** dynamic_cast **gibt?

    mfg Martin

    Dann sei auch konsequent und ermittle mit dem dynamic-cast und einer if-orgie einen enum, den den klassentyp darstellt und verzweige je mit goto zu, passenden code.
    Was meinste Du, wozu es goto gibt?

    0
  • V

    mgaeckler schrieb:

    ;> schrieb:

    dynamic_cast gibt es eigentlich nur um dich darauf hinzuweisen das dein Klassendesign falsch ist.

    Nein. Oder hast Du eine Begründung für Deine Aussage?

    Er hat trotzdem recht. In Marc++us' Buch ist es ganz eindringlich beschrieben.

    0

  • volkard schrieb:

    Dann sei auch konsequent und ermittle mit dem dynamic-cast und einer if-orgie einen enum, den den klassentyp darstellt und verzweige je mit goto zu, passenden code.
    Was meinste Du, wozu es goto gibt?

    Goto ist ein schlechtes Beispiel, weil es das nur aus historischen Gründen gibt.

    0
  • V

    mgaeckler schrieb:

    volkard schrieb:

    Dann sei auch konsequent und ermittle mit dem dynamic-cast und einer if-orgie einen enum, den den klassentyp darstellt und verzweige je mit goto zu, passenden code.
    Was meinste Du, wozu es goto gibt?

    Goto ist ein schlechtes Beispiel, weil es das nur aus historischen Gründen gibt.

    ok, dynamic_cast gibt es auch nur aus historischen Gründen. Ich hab's in den letzten 10 Jahren nicht verwendet. Man dachte halt früher, man bräuchte es.

    goto hingegen ist vielleicht wirklich manchmal praktisch.

    UND NU MACH DIR GEDANKEN, WAS VIRTUELLE FUNKTIONEN DIR GERADE HELFEN KÖNNEN, statt hier rumzubesserwissern. Du willst schließlich Hilfe, dann zieh auch in Erwägung, daß die Antworter recht haben könnten.

    0
  • V

    in meyers mehr effektiv c++ programmieren stehen ein paar mögliche vorgehensweisen, wie man dies&jenes performant und/oder wartungsarm hinkriegt, wo auch fantasieloserweise an dynamic_cast denken könnte.
    muttu wohl lesen, fürchte ich, dir scheint es ja um dispatcher zu gehen.

    0

  • volkard schrieb:

    mgaeckler schrieb:

    volkard schrieb:

    Dann sei auch konsequent und ermittle mit dem dynamic-cast und einer if-orgie einen enum, den den klassentyp darstellt und verzweige je mit goto zu, passenden code.
    Was meinste Du, wozu es goto gibt?

    Goto ist ein schlechtes Beispiel, weil es das nur aus historischen Gründen gibt.

    ok, dynamic_cast gibt es auch nur aus historischen Gründen. Ich hab's in den letzten 10 Jahren nicht verwendet. Man dachte halt früher, man bräuchte es.

    goto hingegen ist vielleicht wirklich manchmal praktisch.

    UND NU MACH DIR GEDANKEN, WAS VIRTUELLE FUNKTIONEN DIR GERADE HELFEN KÖNNEN, statt hier rumzubesserwissern. Du willst schließlich Hilfe, dann zieh auch in Erwägung, daß die Antworter recht haben könnten.

    Wer sagt, daß ich Hilfe will? Der Fragesteller wollte Hilfe, hat er aber bis jetzt nicht wirklich bekommen. Ich nenne jetzt mal ein Beispiel:

    Ich habe einen Klassenbaum mit vieleicht 30-40 Klassen. Manche Operationen machen aber nur mit einem Teilbaum Sinn. Der Aufrufer weiß das aber nicht:

    bool ACTION_ADD_VERSION::acceptItem( THE_ITEM *theItem )
{
	doEnterFunction("ACTION_ADD_VERSION::acceptItem");
	bool	accepted = false;

	const THE_FILE *theFile = dynamic_cast<const THE_FILE *>(theItem);
	if( theFile )
		accepted = theFile->canCreateVersion() && ACTION_BASE::acceptItem( theItem );

	doShowLog();
	return accepted;
}

    Ich kann hier auch nicht einfach nach einer Klassenid prüfen, denn es könnte abgeleitetete Klassen mit einer eigenen ID geben, die ich noch nicht kenne. Die Basisklasse kann das auch nicht prüfen, denn es könnte ACTIONS geben, die es noch nicht kennt.

    Jetzt erkläre mir mal, wie man das ohne dynamic_cast lösen will.

    mfg Martin

    0
  • V

    Virtuelle Funktion in die Wurzel des Teilbaums.

    mgaeckler schrieb:

    bool ACTION_ADD_VERSION::acceptItem( THE_ITEM *theItem )
{
	doEnterFunction("ACTION_ADD_VERSION::acceptItem");
	bool	accepted = false;

	const THE_FILE *theFile = dynamic_cast<const THE_FILE *>(theItem);
	if( theFile )
		accepted = theFile->canCreateVersion() && ACTION_BASE::acceptItem( theItem );

	doShowLog();
	return accepted;
}

    Völlig unklar, was das soll. Dein Code smellt nach http://en.wikipedia.org/wiki/Inner-platform_effect

    0
  • N

    mgaeckler schrieb:

    Ich habe einen Klassenbaum mit vieleicht 30-40 Klassen.

    Well, there's your problem.

    0

  • Nathan schrieb:

    mgaeckler schrieb:

    Ich habe einen Klassenbaum mit vieleicht 30-40 Klassen.

    Well, there's your problem.

    Welches Problem?

    0

  • volkard schrieb:

    Virtuelle Funktion in die Wurzel des Teilbaums.

    Und wie bekommst Du dann von einem Zeiger auf ein Objekt der Wurzelklasse (in diesem Fall THE_ITEM) auf einen Zeiger auf das Objekt der Wurzel des Teilbaums (THE_FILE)?

    volkard schrieb:

    mgaeckler schrieb:

    bool ACTION_ADD_VERSION::acceptItem( THE_ITEM *theItem )
{
	doEnterFunction("ACTION_ADD_VERSION::acceptItem");
	bool	accepted = false;

	const THE_FILE *theFile = dynamic_cast<const THE_FILE *>(theItem);
	if( theFile )
		accepted = theFile->canCreateVersion() && ACTION_BASE::acceptItem( theItem );

	doShowLog();
	return accepted;
}

    Völlig unklar, was das soll. Dein Code smellt nach http://en.wikipedia.org/wiki/Inner-platform_effect

    Designziel war, daß der Klassenbaum erweiterbar sein sollte, ohne, daß die Wurzel geändert werden muß. Das Hauptfenster kennt nur die Basisklasse (ITEM_TREE). Die verschiedenen Actionsklassen kennen dann aber die jeweiligen abgeleiteten Klassen und deren Methoden. Das Hauptfenster hat eine Liste aller Objekte der Actionklassen, kennt aber auch nur die Basisklasse (ACTION_BASE). ALLE Methoden von ACTION_BASE sind pure virtual. Das Hauptfenster ruft beim Aufbau eines Popupmenus daher einfach für jedes Actionobjekt die Methode acceptItem mit der Adresse des Itemobjektes auf und acceptItem entschiedet dann u.a. an Hand der Klasse, ob es was damit anfangen kann.

    Kannst Du eine wartbare Version zeigen, die ohne dynamic_cast auskommt?

    mfg Martin

    0
  • ?

    Du hast bislang nur beschrieben, wie du es machst, nicht, was du damit erreichen willst. In der vorgelegten Form kann ich dir nur sagen, dass dein Design hoffnungslos kaputt ist, aber nicht, wodurch man es ersetzen könnte. Aber ich mach mal ein bisschen Kaffeesatzleserei.

    Wenn es nur um den Aufbau von Popup-Menüs geht, sollte die Sache einfach zu regeln sein; immerhin braucht eine Action ja nur eine parameterlose Methode (mehr als anklicken kann man einen Eintrag nicht). Halte einen std::vector<std::function<void()>> menu_entries (oder std::pair<std::string, std::function<void()>> für eine Beschreibung, oder was auch immer du zum Rendern brauchst) und wirf da Binder rein; dann kennen die Binder den konkreten Typ des Kontextobjekts, und du musst das Zeug nicht mehr aus einem Container rauskramen, der sich die notwendigen Informationen nicht gemerkt hat.

    0
  • V

    mgaeckler schrieb:

    volkard schrieb:

    Virtuelle Funktion in die Wurzel des Teilbaums.

    Und wie bekommst Du dann von einem Zeiger auf ein Objekt der Wurzelklasse (in diesem Fall THE_ITEM) auf einen Zeiger auf das Objekt der Wurzel des Teilbaums (THE_FILE)?

    volkard schrieb:

    mgaeckler schrieb:

    bool ACTION_ADD_VERSION::acceptItem( THE_ITEM *theItem )
{
	doEnterFunction("ACTION_ADD_VERSION::acceptItem");
	bool	accepted = false;

	const THE_FILE *theFile = dynamic_cast<const THE_FILE *>(theItem);
	if( theFile )
		accepted = theFile->canCreateVersion() && ACTION_BASE::acceptItem( theItem );

	doShowLog();
	return accepted;
}

    Völlig unklar, was das soll. Dein Code smellt nach http://en.wikipedia.org/wiki/Inner-platform_effect

    Designziel war, daß der Klassenbaum erweiterbar sein sollte, ohne, daß die Wurzel geändert werden muß. Das Hauptfenster kennt nur die Basisklasse (ITEM_TREE). Die verschiedenen Actionsklassen kennen dann aber die jeweiligen abgeleiteten Klassen und deren Methoden. Das Hauptfenster hat eine Liste aller Objekte der Actionklassen, kennt aber auch nur die Basisklasse (ACTION_BASE). ALLE Methoden von ACTION_BASE sind pure virtual. Das Hauptfenster ruft beim Aufbau eines Popupmenus daher einfach für jedes Actionobjekt die Methode acceptItem mit der Adresse des Itemobjektes auf und acceptItem entschiedet dann u.a. an Hand der Klasse, ob es was damit anfangen kann.

    Kannst Du eine wartbare Version zeigen, die ohne dynamic_cast auskommt?

    mfg Martin

    Schwachsinn. Da helfe ich Dir für 500€/Tag (Vorkasse) raus.

    0
  • M

    mgaeckler schrieb:

    Das Hauptfenster hat eine Liste aller Objekte der Actionklassen, kennt aber auch nur die Basisklasse (ACTION_BASE). ALLE Methoden von ACTION_BASE sind pure virtual. Das Hauptfenster ruft beim Aufbau eines Popupmenus daher einfach für jedes Actionobjekt die Methode acceptItem mit der Adresse des Itemobjektes auf und acceptItem entschiedet dann u.a. an Hand der Klasse, ob es was damit anfangen kann.

    Wieso schreibst du Klassennamen komplett groß und mit Unterstrichen? Das ist ja echt hässlich.

    Man kann u.U. schon dynamic_cast verwenden, ich schließe das nicht so kategorisch aus wie die anderen hier. Nur sollte man das wenn nur irgendwie möglich vermeiden und erst recht nicht als Teil des Designs benutzen.
    Man könnte z.B. eine virtuelle Methode itemClass einführen, die einen string zurückgibt und den zum matchen benutzen. Die Funktion könnte man dann vielleicht auch an anderen Stellen verwenden. Man könnte auch IDs verwenden, die irgendwann über den Klassennamen registriert werden (ich denk da an sowas wie Q_DECLARE_METATYPE).

    0
  • ?

    Mechanics schrieb:

    Man könnte z.B. eine virtuelle Methode itemClass einführen, die einen string zurückgibt und den zum matchen benutzen. Die Funktion könnte man dann vielleicht auch an anderen Stellen verwenden. Man könnte auch IDs verwenden, die irgendwann über den Klassennamen registriert werden (ich denk da an sowas wie Q_DECLARE_METATYPE).

    Was willst du mit der Information anfangen, wenn du nicht casten willst?

    0
  • V

    mgaeckler schrieb:

    Designziel war, daß der Klassenbaum erweiterbar sein sollte, ohne, daß die Wurzel geändert werden muß.

    Dann kannste gleich Zeiger auf void nehmen. Das Designziel würde ich zuerst überdenken.
    Also ein Hauptfenster kriegt Nachrichten udn verteilt sie an alle EMpfänger, die diese Nachrichtensorte verarbeiten können? Ginge auch pro Nachrichtensorte ein Slot?

    0

  • seldon schrieb:

    Du hast bislang nur beschrieben, wie du es machst, nicht, was du damit erreichen willst. In der vorgelegten Form kann ich dir nur sagen, dass dein Design hoffnungslos kaputt ist, aber nicht, wodurch man es ersetzen könnte. Aber ich mach mal ein bisschen Kaffeesatzleserei.

    Wenn es nur um den Aufbau von Popup-Menüs geht, sollte die Sache einfach zu regeln sein; immerhin braucht eine Action ja nur eine parameterlose Methode (mehr als anklicken kann man einen Eintrag nicht). Halte einen std::vector<std::function<void()>> menu_entries (oder std::pair<std::string, std::function<void()>> für eine Beschreibung, oder was auch immer du zum Rendern brauchst) und wirf da Binder rein; dann kennen die Binder den konkreten Typ des Kontextobjekts, und du musst das Zeug nicht mehr aus einem Container rauskramen, der sich die notwendigen Informationen nicht gemerkt hat.

    Ja ganz so einfach ist es aber nicht. Grundsätzlich habe ich ja so eine Liste. Es muß aber einen Weg geben, mit dem entschieden werden kann, ob jetzt eine konkretet Funktion mit dem konkreten Objekt überhaupt möglich ist. In dem Container könnten verschiedene Objekte enthalten sein. Jedes dieser Objekte kann, muß aber nicht, eigene Einträge in dem Popupmenu enthalten, es könnte sogar möglich sein, daß ein Objekt einen Popupeintrag erhält, von dem es sogar selbst keine Ahnung hat. Das Hauptfenster hat daher einfach eine Liste aller überhaupt möglichen Einträge des Popupmenüs.
    So wird die Liste der Einträge eines Popupmenüs aufgebaut:

    void getItemActions(
	const USER_OR_GROUP *actUser,
	THE_ITEM *theItem,
	Array<ACTION_BASE *> *actions
)
{
	actions->clear();

	for( size_t i=0; i<allActions->getNumElements(); i++ )
	{
		ACTION_BASE *theAction = (*allActions)[i];

		if( theAction->acceptUser( actUser )
		&& theAction->acceptItem( theItem ) )
			actions->addElement( theAction );
	}

	actions->sort( actionCompare );
}

    mfg Martin

    0
  • V

    mgaeckler schrieb:

    Ja ganz so einfach ist es aber nicht. Grundsätzlich habe ich ja so eine Liste. Es muß aber einen Weg geben, mit dem entschieden werden kann, ob jetzt eine konkretet Funktion mit dem konkreten Objekt überhaupt möglich ist.

    Aber muss die Funktion das wissen? Kann das Objekt nicht die Entscheidung treffen, ob es mit der Funktion spielen mag?

    0

  • volkard schrieb:

    Schwachsinn. Da helfe ich Dir für 500€/Tag (Vorkasse) raus.

    Nein danke, Deine Qualifikation reicht dafür leider nicht aus. Nachdem Du hier wohl auch eine Moderatorenrolle übernommen hast, solltest Du vielleicht wenigstens diesen Artikel lesen: http://de.wikipedia.org/wiki/Moderation_(Gruppenarbeit)

    0
Anmelden zum Antworten