OT: Nickdiskussion
-
Mr. N schrieb:
(Mr. N vs. CStoll) vs. Undertaker
Beweis erstmal die Assoziativitaet von vs.
-
Mr. N schrieb:
(Mr. N vs. CStoll) vs. Undertaker
Gegen dich habe ich nichts - und (Mr. N und CStoll) vs. Undertaker erschien mir doch etwas unfair
(wobei, wenn er alle früheren Inkarnationen seiner selbst reanimiert, hat er vielleicht eine Chance, uns totzuquatschen :D)
-
Mr. N schrieb:
Im Ernst, natürlich bräuchte man keine Richtlinien, wenn es nicht möglich wäre, Dinge schlecht zu lösen. Leider geht das aber, und zwar in jeder der beliebten Sprachen.
klar, aber mit einigen sprachen kann man leichter (aus versehen) mist bauen, als mit anderen sprachen.
CStoll schrieb:
Aber für Boris' Problem waren die Datenstrukturen "geordnete Liste" und "unstrukturierter Haufen" gleichermaßen schlecht geeignet - dadurch, daß er alle Objekte in einen Container von Basis-Zeigern untergebracht hatte, hat er (aus Compiler-Sicht) wichtige Typ-Informationen weggeworfen, die er durch Cast's rekonstruieren musst. Wenn du schon eine bessere Datenstruktur vorschlagen wolltest, dann eine, in der die Typinformationen festgehalten werden.
wirklich weg sind die typinformationen ja nicht, sonst könnte ein cast auch nicht mehr helfen. angenommen, du hast ein system, bei dem verschiedene objekte von aussen irgendwie eintrudeln, also so, dass man nicht vorhersehen kann, wann was kommt und du musst dir die die reihenfolge merken. ist es nicht einfach, sie in eine queue oder sowas zu stecken oder wie würdest du das coden?
Mr. N schrieb:
(Mr. N vs. CStoll) vs. Undertaker
von mir aus macht euch gegenseitig fertig
-
Undertaker schrieb:
angenommen, du hast ein system, bei dem verschiedene objekte von aussen irgendwie eintrudeln, ...
Einfachste Lösung :
Von vornherein ausschliessen, dass so etwas programmiert werden muss. Hat allerdings mehr mit Design zutun.
-
Undertaker schrieb:
Mr. N schrieb:
Im Ernst, natürlich bräuchte man keine Richtlinien, wenn es nicht möglich wäre, Dinge schlecht zu lösen. Leider geht das aber, und zwar in jeder der beliebten Sprachen.
klar, aber mit einigen sprachen kann man leichter (aus versehen) mist bauen, als mit anderen sprachen.
<<Hier war mal eine Antwort.>>
Undertaker schrieb:
CStoll schrieb:
Aber für Boris' Problem waren die Datenstrukturen "geordnete Liste" und "unstrukturierter Haufen" gleichermaßen schlecht geeignet - dadurch, daß er alle Objekte in einen Container von Basis-Zeigern untergebracht hatte, hat er (aus Compiler-Sicht) wichtige Typ-Informationen weggeworfen, die er durch Cast's rekonstruieren musst. Wenn du schon eine bessere Datenstruktur vorschlagen wolltest, dann eine, in der die Typinformationen festgehalten werden.
wirklich weg sind die typinformationen ja nicht, sonst könnte ein cast auch nicht mehr helfen. angenommen, du hast ein system, bei dem verschiedene objekte von aussen irgendwie eintrudeln, also so, dass man nicht vorhersehen kann, wann was kommt und du musst dir die die reihenfolge merken. ist es nicht einfach, sie in eine queue oder sowas zu stecken oder wie würdest du das coden?
Erstmal würde ich schauen, ob ich die Objekte alle gleich verwende. Wenn z.B. alle einfach nur aufgerufen werden müssen mit Methode run() o.ä., dann baue ich dafür eine Basisklasse (kommt dir das bekannt vor?)
Wenn das nicht geht und ich sie nachher auseinanderpfriemeln muss, kann ich das doch auch schon vorher machen, bzw. (viel besser!) dafür sorgen dass es gar nie nötig wird - C++ liefert einem dazu auch die nötigen Tools. Das Auseinanderpfriemeln lässt sich unter Umständen auch wesentlich performanter als dynamic_cast implementieren. (Ich fürchte, du hast keine Vorstellung wie unglaublich langsam dynamic_cast laut Standard sein darf und meistens auch sein wird.)
-
Mr. N schrieb:
Das Auseinanderpfriemeln lässt sich unter Umständen auch wesentlich performanter als dynamic_cast implementieren. (Ich fürchte, du hast keine Vorstellung wie unglaublich langsam dynamic_cast laut Standard sein darf und meistens auch sein wird.)
warum eigentlich? warum können in C++ die objekte nicht einfach ihre typinformation immer mit sich führen. dann wären down casts doch recht schnell.
-
Undertaker schrieb:
Mr. N schrieb:
Das Auseinanderpfriemeln lässt sich unter Umständen auch wesentlich performanter als dynamic_cast implementieren. (Ich fürchte, du hast keine Vorstellung wie unglaublich langsam dynamic_cast laut Standard sein darf und meistens auch sein wird.)
warum eigentlich? warum können in C++ die objekte nicht einfach ihre typinformation immer mit sich führen. dann wären down casts doch recht schnell.
Wetten, das wenn man es dir erklären würde, du trotzdem mit der Antwort nicht einverstanden sein würdest, und wieder von dir ein C++-Flamewar los geht?
-
Artchi schrieb:
Wetten, das wenn man es dir erklären würde, du trotzdem mit der Antwort nicht einverstanden sein würdest, und wieder von dir ein C++-Flamewar los geht?
das hört sich ja so an, als wüsstest du die antwort, bist damit aber auch nicht so ganz glücklich.
edit: ich rate mal.
C++ objekte sollen binärkompatibel zu C structs sein.
... und sagt mir bitte, dass ich mich jetzt getäuscht habe.
-
Undertaker schrieb:
das hört sich ja so an, als wüsstest du die antwort, bist damit aber auch nicht so ganz glücklich.
Nein, es soll heißen, egal was man dir für eine Antwort gibt, du wirst es eh nicht gut finden, und ein "Aber..." bringen. Also, erspar ich mir die Antwort, weil die Antwort das Thema nicht beenden würde... egal ob ich damit zufrieden bin oder es nicht bin.
-
Artchi schrieb:
...egal was man dir für eine Antwort gibt, du wirst es eh nicht gut finden...
es geht nicht darum, ob ich es 'gut finde'. ich will einfach nur wissen, warum dynamic_casts langsam sind (oder sein müssen). was ich dann davon halte, musst du schon mir überlassen.
-
Undertaker schrieb:
Mr. N schrieb:
Das Auseinanderpfriemeln lässt sich unter Umständen auch wesentlich performanter als dynamic_cast implementieren. (Ich fürchte, du hast keine Vorstellung wie unglaublich langsam dynamic_cast laut Standard sein darf und meistens auch sein wird.)
warum eigentlich? warum können in C++ die objekte nicht einfach ihre typinformation immer mit sich führen. dann wären down casts doch recht schnell.
Die Objekte bei denen dynamic_cast möglich ist haben ihre Typinformationen. (Merkregel: Jedes Objekt mit virtuellen Methoden.)
dynamic_cast ist dennoch nicht schnell. dynamic_cast kann nämlich nicht nur in den tatsächlichen Typ der Klasse casten sondern auch in (so gut wie) alle Basisklassen. Und die übliche Implementierung regelt das mit einer ganzen Menge Indirektion, und die kostet, wie du als C-Fan wissen solltest.
-
Mr. N schrieb:
dynamic_cast kann nämlich nicht nur in den tatsächlichen Typ der Klasse casten sondern auch in (so gut wie) alle Basisklassen.
ach so, und deshalb muss es sich durch die komplette vererbungshirarchie hangeln.
danke für die erklärung (der Artchi wusste das nämlich nicht)
naja, dann könnte man einen cast in den originaltypen ja so beschleunigen:... OriginalType *original = 0; if (typeid(OriginalType) == typeid(*Object)) original = (OriginalType*)Object; // <-- einfacher C style cast ...sollte so typsicher sein, wie ein dynamic_cast
-
...und was meinst du, macht
typeid? Narr!greetz, Swordfish
-
Undertaker schrieb:
sollte so typsicher sein, wie ein dynamic_cast
Mal ehrlich: manchmal weiß ich nicht ob du dich lächerlich machen willst oder trollen willst. Jedenfalls ernst nehmen kann dich keiner...
-
Swordfish schrieb:
...und was meinst du, macht
typeid? Narr!nun, in meinem grenzenlosen optimismus glaube ich fest daran, dass man mit 'typeid' einfach herauskriegen kann, ob ein objekt ganz genau eine instanz von dem erfragten typ ist, ohne dass dabei verwandschaftsgrade berücksichtigt werden (denn für den fall gibt es ja schon dynamic_cast). oder bin ich auf dem holzweg?
-
Warum antwortet ihr ihm denn? Ich hab doch schon gesagt, das er die Antwort nicht hinnehmen wird, und ein "Aber..." bringen wird. Genau das ist passiert und er hat sich wieder blamiert.
Undertaker! Ich wusste die Antwort, da dynamic_cast und seine Arbeitsweise schon mehrmals im C++-Forum beschrieben wurde. Aber ich muß mir das nicht antun, und meine Erklärungen vorwissentlich von einem Troll null und nichtig machen lassen.
-
-------------------------- /| /| | | ||__|| | Trolle bitte | / O O\__ nicht | / \ füttern! | / \ \ | / _ \ \ ---------------------- / |\____\ \ || / | | | |\____/ || / \|_|_|/ | __|| / / \ |____| || / | | /| | --| | | |// |____ --| * _ | |_|_|_| | \-/ *-- _--\ _ \ // | / _ \\ _ // | / * / \_ /- | - | | * ___ c_c_c_C/ \C_c_c_c____________
-
Shade Of Mine schrieb:
Undertaker schrieb:
sollte so typsicher sein, wie ein dynamic_cast
Mal ehrlich: manchmal weiß ich nicht ob du dich lächerlich machen willst oder trollen willst. Jedenfalls ernst nehmen kann dich keiner...
Wenn du das selbst gemacht hättest, wärs cool, aber mit so na billigen Anleitung. Gähn.
-
Wie's
typeidmacht ist IMHO nicht Standardisiert -> Jeder Compiler darf sein eigenes Süppchen kochen...greetz, Swordfish
-
Swordfish schrieb:
Wie's
typeidmacht ist IMHO nicht Standardisiert -> Jeder Compiler darf sein eigenes Süppchen kochen...ich hab's grad' mal ausprobiert:
class A {}; class B : public A {}; int main () { B *b = new B; if (typeid(B) == typeid(*b)) cout << "b is a B" << endl; if (typeid(A) == typeid(*b)) cout << "b is also an A" << endl; }scheint zu klappen.
aber wenn es so ist wie du sagst, könnte es dann auch compiler geben, die den zweiten vergleich durchlassen?
