Map von Pointern auf Membervariablen

[Student83]

Ganz ruhig, der Code lässt sich halt nicht weiter vereinfachen. Und das Problem habe ich jetzt auch schon mehrfach benannt. Habe jetzt nochmal Kommentare hinzugefügt. ich hoffe es wird jetzt klar was gewollt ist.
Was wäre denn die Antwort auf das Slicing Problem?

[Gast]

So, was soll denn passieren, wenn der Object-Zeiger nicht auf die Object-Basis eines Doubles zeigt?

[Student83]

Darüber mache ich mir gedanken wenn es soweit ist. Man könnte zum Beispiel ganz einfach erstmal schauen ob es denn auch ein Double ist:

std::wstring type = ((*it).second)->GetType().Name();
std::wcerr << type << std::endl;

Das gibt sogar Double aus ;). Jetzt aber bitte nicht vom Thema abschweifen sonst blickt hier im Thread echt niemand mehr durch.

[Gast]

Aber du hast schon verstanden, warum dein Code nicht so funktioniert, wie du es gerne hättest, ja? Was ist eigentlich die aktuelle Frage?

[Student83]

Wie kann ich einer Membervariablen einer Klasse dynamisch zur Laufzeit einen Wert zuweisen wenn ich nur den Namen bzw. Wert als String aus einer Datei ausgelesen bekomme. Das ist meine Frage.
Mein Lösungsansatz war nun dieser, dass ich Referenzen bzw. da man diese nicht in einer Map speichern kann, Pointer auf diese zeigen lasse um dann über den Zeiger den Wert dynamisch zuzuweisen. Da wusste ich allerdings noch nicht dass das wegen Slicing nicht geht.
Darum wollte ich jetzt wissen ob es dafür eine Lösung gibt.

[Gast]

class Object {
public:
    virtual void Assign( const Object& other ); // oder meinetwegen operator=
};

class Double : public Object {
public:
    void Assign( const Object& other ) {
         assert( other.GetType().Name() == "Double" ); // Oder was du zu gedenken tust
         *this = static_cast< const Double& >( other ); // oder dynamic_cast, aber dann bräuchtest du die Typnamen auch gar nicht mitschleifen
    }
};

[Student83]

Es funktioniert. Danke dir für die Lösung. War auch ne schwierige Geburt ;). Ist zwar nicht 100% optimal weil jetzt jede Klasse diese Assign-Funktion mitbekommt und ich diese für jede Klasse individuell anpassen muss. Aber anders wird es wohl nicht gehen. Der Tipp mit dem überschreiben des =-Operators ist auch gut.

[Gast]

template< typename T >
void Assign( Object& lhs, const T& rhs )
{
	assert( lhs.GetType() == rhs.GetType() );
	static_cast<T&>(lhs) = rhs;
}

Ginge auch Wir, und du selbst, wissen ja noch nicht, was du am Ende nun damit machen willst

[Student83]

Das wäre praktisch. Leider scheint man in templates keine Funktionen aufrufen zu können als typename. Hätte mir sonst ne Menge Schreibarbeit abgenommen.

[Nexus]

Polymorphie und Wertsemantik vertragen sich nicht. Es irgendwie doch hinfrickeln zu wollen, führt garantiert zu Problemen. Ich kenne keinen einzigen Fall, in dem virtuelle Zuweisungsoperatoren sinnvoll sind.

Wenn man Deep-Copy-Semantik möchte, ohne den dynamischen Typen zu kennen, kann man z.B. das Clone-Idiom anwenden. Dann überschreibt man gleich den (Smart-)Pointer und nicht nur das Objekt, wodurch auch Slicing verunmöglicht wird.

[Gast]

Also ganz so generell würde ich das jetzt nicht ausdrücken. Ich hab ersteres Beispiel schon erfolgreich verwenden können. Das ist nichts, worauf man ein komplettes Projekt aufbauen würde und anschließend auf Typen nicht mehr achtet, aber hat halt seine Anwendungen, bei denen zB. das reine Klonen andere Nachteile hätte.
Ein paar Begründungen wären auch ganz nett gewesen, auch wenn ich weiß, dass man da immer sehr ausholen muss Aber so kommt das halt so rüber wie die Bibel, bei der auch jeder halbwegs intelligente hinterher fragt: Warum nur?

[volkard]

Decimad schrieb:

Also ganz so generell würde ich das jetzt nicht ausdrücken. Ich hab ersteres Beispiel schon erfolgreich verwenden können.

Schon möglich.
Aber würdest Du heute noch so agieren?

[Gast]

Ich stand in der Zwischenzeit nicht wieder vor selber Problematik, daher weiß ich da jetzt auf Anhieb keine Antwort drauf! Ich denke aber mal, damals war so der Zeitpunkt, als ich von der Welt des statisch kompilierten in die Welt des dynamisch konfigurier- und parametrierbaren gegangen bin, da schießt man halt manchmal auch über das Ziel hinaus (irgendwie habe ich mir das aber damals auch einfach selber so zusammengebastelt, ohne da aus 10 Foren Hilfe zu benötigen). Inzwischen würde ich wahrscheinlich konservativer rangehen. Dafür zermartere ich mir aber jetzt vor lauter "du sollst nicht"-Regeln desöftern mal den Kopf und statt sie zu ignorieren quäle ich mich dann rum, auch wenn es bloß auf ein hinreichend funktionierendes Ergebnis ankommt

[Nexus]

Decimad schrieb:

Aber so kommt das halt so rüber wie die Bibel, bei der auch jeder halbwegs intelligente hinterher fragt: Warum nur?

Slicing wurde ja in diesem Thread schon mindestens ein Dutzend Mal erwähnt. Das ist ein allgegenwärtiges Problem bei solchem Gefrickel. Dazu kommt der umgekehrte Fall Derived = Base , wo nur das halbe Objekt überschrieben wird und undefiniertes Verhalten entstehen kann.

Zuweisungen kann man genau dann zuverlässig verwenden, wenn man statische Typen vor sich liegen hat. Sonst muss man doch wieder Fälle unterscheiden, was den ganzen Versuch, das mit virtual unter einen Hut zu bringen, nutzlos macht. In dem Fall, wo statische Typen involviert sind, ist allerdings normale Wertsemantik ausreichend, und man kann sich die Frickelei sparen.

Aber das Thema ist nicht neu:

volkard schrieb:

Ich verstehe den Bedarf gar nicht. Typverändernde Zuweisungen mache ich nicht auf Objekten, zum Beispiel weil das eh zu selten klappt, sondern auf Basisklassenzeigern, und auf einmal ist es logisch, einfach, schnell und einfach.

Nexus schrieb:

Nebenbei: Ein virtueller Zuweisungsoperator ist ein wenig fragwürdig. Und zwar einfach, weil C++ kein Double-Dispatching kann und der rechte Operand somit als statischer Typ interpretiert wird, was bei polymorphem Code wie

Base* a = ...;
Base* b = ...;

*a = *b;

nur die Basisklassenversion Base::operator= in Betracht zieht.

Alternativen sind oft auch semantisch sinnvoller: Entweder, man verbietet Wertsemantik komplett (durch privaten Kopierkonstruktor und Zuweisungsoperator), oder man lässt sie auf Objekten gleichen Typs (in der gleichen Hierarchiestufe) zu, wodurch man wiederum kein virtual benötigt.

Nexus schrieb:

Das Problem ist, dass Wertsemantik (und damit Dinge wie Kopierkonstruktor oder Zuweisungsoperator) nicht direkt polymorph implementiert werden kann, weil die Objekte oft inkompatibel sind und man Slicing oder sonstiges undefiniertes Verhalten leichtfertig in Kauf nimmt, wenn man versucht, gleich wie bei statischen Typen vorzugehen.

Das heisst nicht, dass polymorphe Klassen generell keine Kopierkonstruktoren und Zuweisungsoperatoren haben dürfen, jedoch sollten diese nicht virtuell sein. Beim Konstruktor ist bereits durch die Sprache gegeben, dass der dynamische Typ des neuen Objekts bekannt sein muss, beim Zuweisungsoperator jedoch nicht, was zu solchen Experimenten verleitet. Wertsemantik ist sehr wohl möglich, aber nur auf gleicher Ebene und mit statischen Typen. Für "polymorphe Wertsemantik" stellen immer noch Smart-Pointer eine Möglichkeit dar, welche z.B. eine virtuelle Clone()-Funktion aufrufen und sicherstellen, dass kein Slicing zum Tragen kommt.

Edit: Mehr Zitate gefunden

[Student83]

Zuweisungen kann man genau dann zuverlässig verwenden, wenn man statische Typen vor sich liegen hat. Sonst muss man doch wieder Fälle unterscheiden, was den ganzen Versuch, das mit virtual unter einen Hut zu bringen, nutzlos macht. In dem Fall, wo statische Typen involviert sind, ist allerdings normale Wertsemantik ausreichend, und man kann sich die Frickelei sparen.

Aber das bedeutet doch auch dass unter diesen Bedingungen ein dynamisches Erzeugen von Objekten zur Laufzeit nicht möglich ist, oder?

Was ist eigentlich von QVariant oder boost::any zu halten?
http://www.heise.de/developer/artikel/Exkurs-Boost-Variant-versus-QVariant-992958.html
Wäre soetwas wie

std::map<std::string, QVariant*>
oder
std::map<std::string, boost::any*>

besser als meine Implementierung?

@Nexus
Sehe ich das richtig, dass deiner Meinung nach Referenzen nach Möglichkeit immer vermieden werden sollten?

[Nexus]

Student83 schrieb:

Aber das bedeutet doch auch dass unter diesen Bedingungen ein dynamisches Erzeugen von Objekten zur Laufzeit nicht möglich ist, oder?

Doch, das geht gut, ich sehe ehrlich gesagt den Zusammenhang nicht. Nur kannst du unterschiedliche Typen (die du zur Kompilierzeit nicht kennst) einander nicht sinnvoll zuweisen. Aber mit einer Indirektion (Smart-Pointer) geht auch das gut.

Student83 schrieb:

Sehe ich das richtig, dass deiner Meinung nach Referenzen nach Möglichkeit immer vermieden werden sollten?

Nein, natürlich nicht. Auch hier ist mir deine Schlussfolgerung ein Rätsel...

Student83 schrieb:

Was ist eigentlich von QVariant oder boost::any zu halten?

Bisher habe ich noch keines wirklich gebraucht. Es gibt sicher sinnvolle Fälle, allerdings sind die wohl recht selten. Die Möglichkeit, alles in einen Container zu stopfen, verleitet schnell zu schlechtem Design, da man das Typsystem damit stark auflockert. Boost.Variant ist allerdings weniger kritisch als Boost.Any, da die Menge möglicher Typen vorgegeben ist. Mit dem Visitor-Pattern kann man die Elemente auch elegant besuchen.

Ich würde allerdings zuerst nach einem konventionellen Lösungsansatz suchen, denn die genannten Massencontainer sind für vereinzelte Spezialfälle konzipiert.

[volkard]

Student83 schrieb:

Was ist eigentlich von QVariant oder boost::any zu halten?

Habe ich noch nie gebraucht.
Könnte sein, daß man sowas praktisch nur braucht, um den Inner-Platform Effect intensiv ausleben zu können.

[Student83]

@nexus
Kannst du mal einen Beispielcode geben bzw. grob skizzieren wie du z.B. den Zugriff auf die Membervariablen einer Klasse implementieren würdest.

[Gast]

Und Gott sprach: "Es werde ein Anti-Inner-Plattform-Fanatiker".
Und es ward ein Anti-Inner-Plattform-Fanatiker.

[Nexus]

Bevor ich nochmals alles aus diesem Thread wiederhole: Was willst du überhaupt erreichen? Wieso Strings auf Member mappen? Brauchst du das zur Serialisierung?