OT: Nickdiskussion
-
C++ vs. Java
C++ vs. C
Was kommt als nächstes?
C++ vs. FORTH?
-
C++ vs ASM
-
Mr.N schrieb:
Diese Aussagen stammem von jemandem, der laut eigenem Bekunden nur wenig Ahnung von C++ hat?
klar, wieso wundert dich das?
das hat ja so direkt nichts mit c++ zu tun. man kann's auch allgemein sehen. irgendwelche 'design prinzipien', die für eine programmiersprache allgemein anerkannt sind, sind oft suboptimal in bezug auf 'real world' anforderungen.
-
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
-
Undertaker schrieb:
Mr.N schrieb:
Diese Aussagen stammem von jemandem, der laut eigenem Bekunden nur wenig Ahnung von C++ hat?
klar, wieso wundert dich das?
das hat ja so direkt nichts mit c++ zu tun. man kann's auch allgemein sehen. irgendwelche 'design prinzipien', die für eine programmiersprache allgemein anerkannt sind, sind oft suboptimal in bezug auf 'real world' anforderungen.
Deswegen gibt es in C++ ja auch viele konkurrierende Design-Prinzipien, kennst du sie? Wenn hingegen mehrere erfahrene Nutzer (zu Recht) erklären, dass das jetzige Design höchstvermutlich unangemessen ist, kommst du und redest von "Real World Anforderungen", ohne aber die geringste Ahnung zu haben.
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.
Mr. N vs. Undertaker
-
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.
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'.
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.
-
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.
-
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
-
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
-
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
-
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.