OT: Nickdiskussion

[Mr. N]

Undertaker schrieb:

Mr. N schrieb:

Deswegen gibt es in C++ ja auch viele konkurrierende Design-Prinzipien, kennst du sie?

nein, aber ich wette mit dir, dass das alles workarounds sind, damit man C++ annähernd sinnvoll einsetzen kann.

Sagt ein Fan von C und Java, den Sprachen von strcat und Design-Patterns-im-Quadrat respektive.

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.

Undertaker schrieb:

Mr. N schrieb:

Und so Phrasen wie "gutes C++ design" (in Anführungszeichen, deinerseits) klingen doch so, als wäre jede C++-Design-Richtlinie (im Gegensatz zu EU-Richtlinien sind die nicht verbindlich) grundsätzlich abzulehnen, weil sie ja aus C++ stammt.

auch das nicht. als C++ user sollte man schon solche 'richtlinien' beachten, um keine fehler zu machen, die andere schon 1000 mal vorher gemacht haben. aber ich finde, man sollte sein ziel nicht aus den augen verlieren vor lauter beschäftigung mit den 'c++ design flaws'.

Sag mal, programmierst du in anderen Sprachen einfach drauf los, ohne Richtlinien und Best Practices einzuhalten? (Und sei es aus Gewohnheit.)

Undertaker schrieb:

Mr. N schrieb:

Mr. N vs. Undertaker

nee, lass mal. wärst du nicht so'n extremer c++ fanboy, könntest du mir direkt sympathisch sein.

Naja, ich kann auch Sprachen, die nicht C++ heißen, gut finden.

[Ein ehemaliger Benutzer]

Undertaker schrieb:

TravisG schrieb:

C++ vs ASM

äpfel vs. birnen
RISC vs. X86
Artchi vs. Java
VW vs. Opel
Mr.N vs. Marc++us
Hello vs. World

Du hast anscheinend verstanden, was ich aussagen wollte. Gratulation meinerseits

[CStoll]

Undertaker schrieb:

CStoll schrieb:

Undertaker schrieb:

CStoll schrieb:

...und du hast dich daran aufgehangen, ob die betroffenen Objekte in einer Kette oder einem unstrukturierten Haufen liegen sollten.

klar, weil der vergleich mit dem 'unstrukturierten haufen' ausgemachter blödsinn war.
...aber vielleicht frage ich dich besser das nächste mal, was ich schreiben darf und was nicht

Aus deiner Sicht vielleicht, aber aus Sicht des Compilers ist es egal, wie die unterliegende Datenstruktur aussieht (und das Kernziel war es zu erklären, daß Cast's in 90% der Fälle auf schlechtes Design hindeuten).

es ging ja nicht darum, was compiler daraus machen. die verwendung einer optimalen, dem zweck dienenden datenstruktur bringt meistens vorteile mit sich, die man mit 'gutem C++ design' niemals ausgleichen kann. beim programmieren in der realität heisst es nie 'der weg ist das ziel' sondern oftmals 'der zweck heiligt alle mittel'. darüber solltest du vielleicht mal nachdenken, wenn du das nächste mal in deinem hobbykeller an komplizierten C++ -konstrukten tüftelst

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.

(btw, ich betreibe C++ nicht nur als Hobby ;))

CStoll schrieb:

Undertaker schrieb:

Artchi schrieb:

Also was erwartet man für eine Reaktion in einer C++-Gruppierung, wenn mind. 90% der Gruppe zu C++ stehen?

immerhin führt dieses board C als erstes im namen und deshalb bin ich hier. C++ interessiert mich einen sch...dreck!

Und was treibt dich dann dazu, ständig irgendwelchen Unsinn im C++ Bereich (btw mit Abstand das umfangreichste Thema des Forums) zu verzapfen?

wenn ich in die liste der neuen beiträge schaue, achte ich meistens nicht darauf, in welchem forum das steht. ist doof, isch weiss.
ausserdem werden im C++ forum oftmals sehr umständliche lösungsvorschläge gemacht und wenn mir sowas auffällt, schmeisse ich mal 'nen tip in die runde, wie's meiner meinung nach einfacher ist.

Das kannst du gerne machen (zumindest solange du die "komplizierte C++ Lösung" nicht durch irgendwelche C-Bitmanipulationen verbessern willst). Aber du solltest schon auf die Experten hören, wenn die dir erklären, daß deine Bemerkungen bestenfalls das Problem tangieren.

Mr. N schrieb:

Mr. N vs. Undertaker

Bitte stell dich hinten an - momentan geht's hier noch um CStoll vs. Undertaker

[Mr. N]

CStoll schrieb:

Mr. N schrieb:

Mr. N vs. Undertaker

Bitte stell dich hinten an - momentan geht's hier noch um CStoll vs. Undertaker

Pfft.

(Mr. N vs. CStoll) vs. Undertaker

[Gast]

Mr. N schrieb:

(Mr. N vs. CStoll) vs. Undertaker

Beweis erstmal die Assoziativitaet von vs.

[CStoll]

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)

[Undertaker]

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

[Gast]

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.

[Mr. N]

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.)

[Undertaker]

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.

[Artchi]

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?

[Undertaker]

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.

[Artchi]

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.

[Undertaker]

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.

[Mr. N]

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.

[Undertaker]

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

[Swordfish]

...und was meinst du, macht typeid ? Narr!

greetz, Swordfish

[Shade Of Mine]

Undertaker schrieb:

sollte so typsicher sein, wie ein dynamic_cast

Hier ist dein Schild

Mal ehrlich: manchmal weiß ich nicht ob du dich lächerlich machen willst oder trollen willst. Jedenfalls ernst nehmen kann dich keiner...

[Undertaker]

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?

[Artchi]

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.