Methoden mit bool-Parametern und "Lesbarkeit" im Kontext
-
So viele Geisterfahrer wieder auf Xins Autobahn.
-
Xin schrieb:
Mr. N schrieb:
Nun ja, meinetwegen könnte man auch asInt() und operator/ parallel erlauben. Warum operator int() schlecht ist, haben CStoll und Shade IMHO sehr schön erklärt.
IYHO.
Belassen wir es bei Geschmackssache, bevor wir hier noch eine Runde im Kreis drehen.Kommen wir da doch mal auf Typsicherheit zu sprechen von der ich ja keine Ahnung habe. Es gibt 2 Arten um int und Meter miteinander zu verbinden: über einen non-explicit CTor und über operator int.
operator int erlaubt Typenverlust, CTor erlaubt Typengewinn. Generell verwendet man deshalb operator int sehr sehr selten. Denn viele Typen wie zB std::string sind kein char*, wohl kann aber ein char* problemlos in einen std::string umgewandelt werden.
Ähnlich ist es mit Meter. Meter ist kein int - er ist mehr als ein int. Er ist ein int mit Typ-Information. Wenn wir einen operator int implementieren dann erlauben wir impliziten Typverlust. Das ist zB deswegen doof, weil es keine Compilerwarnungen gibt:
Meter m(7); cout<<m;Es sollte "7 Meter" ausgegeben werden, aber leider haben wir den op<< vergessen zu implementieren. Es wird 7 ausgegeben. Ohne Warnung. Das ist dann ein Problem wenn der int Wert keinen direkten Sinn macht: zB bei dem Umrechnungsproblem Millimeter <-> Meter wo wir nicht wissen ob das jetzt Millimeter oder Meter sind.
Compiler warnt nicht.
Bei einem non-explicit CTor gibt es nur ein Risiko: dass der Programmierer in einen Typenlosen Wert zuviel reininterpretiert.
m=getRandomInt();Das ist natürlich auch ein Problem - aber der Programmierer kann das kaum aus versehen machen. Denn wenn er einen falschen integer zuweist, dann kann er das auch explizit machen:
m=Meter(getRandomInt());
-
Meter = { komplexe physikalische Formel }Bei { komplexe physikalische Formel } ist irgendwas faul, es kommt int raus. Der Compiler verweigert es, aber was genau ist nun faul? Bei CStolls Templatesystem kommt eine prägnante Fehlermeldung à la "Keine Überladung für Sekunde * Haus". Alles ist sofort klar. DAS ist Typsicherheit.
Anderes Beispiel: In der Physik gibt es durchaus typlose Konstanten oder Ergebnisse, z.B. Brechzahl, oder Winkel, insbesondere trigonometrische Funktionen davon. Du weißt also ein int einem int zu, aber ist das int nun richtig entstanden? Man kann es nicht nachvollziehen.
-
Shade Of Mine schrieb:
Xin schrieb:
Belassen wir es bei Geschmackssache, bevor wir hier noch eine Runde im Kreis drehen.
Kommen wir da doch mal auf Typsicherheit zu sprechen von der ich ja keine Ahnung habe.
Das lasse ich mal unkommentiert so stehen... das hast Du gesagt.
Shade Of Mine schrieb:
Es gibt 2 Arten um int und Meter miteinander zu verbinden: über einen non-explicit CTor und über operator int.
operator int erlaubt Typenverlust, CTor erlaubt Typengewinn. Generell verwendet man deshalb operator int sehr sehr selten. Denn viele Typen wie zB std::string sind kein char*, wohl kann aber ein char* problemlos in einen std::string umgewandelt werden.
Ähnlich ist es mit Meter. Meter ist kein int - er ist mehr als ein int. Er ist ein int mit Typ-Information. Wenn wir einen operator int implementieren dann erlauben wir impliziten Typverlust.
Richtig, und zwar dann, wenn der Meter als typlose Größe benötigt wird.
Shade Of Mine schrieb:
Das ist zB deswegen doof, weil es keine Compilerwarnungen gibt:
Meter m(7); cout<<m;Es sollte "7 Meter" ausgegeben werden, aber leider haben wir den op<< vergessen zu implementieren. Es wird 7 ausgegeben. Ohne Warnung. Das ist dann ein Problem wenn der int Wert keinen direkten Sinn macht: zB bei dem Umrechnungsproblem Millimeter <-> Meter wo wir nicht wissen ob das jetzt Millimeter oder Meter sind.
Jow...
Und wenn Du mit einem Auto gegen einen Baum fährst, wird es auch implizit in einen Haufen Schrott umgewandelt.
Ohne Warnung. Schlussfolgerung: der Autohersteller hat nicht typsicher gearbeitet, weil er die Verbindung Baum + Auto nicht unterbindet und es so zu unerwarteten Ergebnissen kommt, wenn der Nutzer sich nicht an das hält, was er in seiner Ausbildung gelernt haben sollte.Wenn man vergisst, dass man einen Wert anders ausgeben möchte, dann braucht man sich nicht zu wundern, wenn der Wert eben nicht anders ausgegeben wird.
Ansonsten gucke ich mir meine Software an, ob sie tut, was ich will. Das ist kein Problem von Typsicherheit, sondern von Abgleich von "Was sollte ich programmieren?" und "Was habe ich programmiert?"Shade Of Mine schrieb:
Bei einem non-explicit CTor gibt es nur ein Risiko: dass der Programmierer in einen Typenlosen Wert zuviel reininterpretiert.
m=getRandomInt();Das ist natürlich auch ein Problem - aber der Programmierer kann das kaum aus versehen machen.
Schon wieder eine Kritik an den expliziten int-Konstruktoren?!? Wenn man keine Ahnung hat, einfach mal Fragen stellen. ^^
Es gibt viele Möglichkeiten mal eben irgendwie an ein int zu kommen, nicht nur die versehendliche, direkte Zuweisung.
C++ erlaubt hier die implizite Konstruktion eines Meters, um das int durch den Meter-Operator zu jagen.Folgendes wird somit zu validem Code:
Meter m = Meter( 4 ); Meter result = m + 5;Man stelle sich hier den kleinen Roboter aus "FoolProof" vor: "Fehler... Fehler... Fehler..."
Den Typ bei Bedarf implizit zu entfernen ist ungefährlich, ihn hinzuzufügen hingegen ist gefährlich, inbesondere dann, wenn man mit den Regeln zur Operator-Wahl nicht vertraut ist.
Und damit sind wir wieder am Anfang Deines Postings:
Shade Of Mine schrieb:
Kommen wir da doch mal auf Typsicherheit zu sprechen von der ich ja keine Ahnung habe.
(wer auf's eigene Tor schießt, muss damit rechnen, dass er ein Eigentor schießt)
-
Was macht ihr jetzt? 10 Seiten diskutieren wie man 4 Meter + 5 Meter rechnet? Wollt ihr immer so lang rumtrödeln, wenn ihr ein Programm schreib?
-
Xin schrieb:
Und wenn Du mit einem Auto gegen einen Baum fährst, wird es auch implizit in einen Haufen Schrott umgewandelt.
Wir müssen ja nicht die Fehler der realen Welt implementieren. In meiner schönen C++-Welt ist auto.auffahren(baum) einfach nicht legal.
-
Eben, und zur Zulassung von Crashtests mit Bäumen kann man immer noch explizit das Auto in ein Testauto umwandeln.
-
scrub schrieb:
Eben, und zur Zulassung von Crashtests mit Bäumen kann man immer noch explizit das Auto in ein Testauto umwandeln.
Ich würde casten - es geht ja sowieso um einen Unfall
-
...ich würd sagen xin hat mal wieder verloren, was meint ihr?
-
ach red doch keinen verbalen dünschiss...
es habt sich gezeigt, dass die vorteile xins methode im detail stecken,
und man sie eigentlich mit dem bloßem auge nicht erkennen kann,
die nachteile zwar manchmal erkennbar sind, aber dies nur sind, wenn man die
nachteile als solche definiert, und das nur, wenn es nachts kälter als draußen ist.Also ist doch alles eindeutig oder?
-
...nagut
:p
-
Xin schrieb:
Da Du das template aber nicht unendlich dimensional erzeugen kannst, jedenfalls nicht in der Realität, ist wohl eindeutig.
Stimmt, aber glücklicherweise genügt es ja, dass ich die Dimension beliebig groß machen kann.
Daher kommst Du mit dem Template nicht weiter als ohne. Schon mit den 7 Einheiten wird das ganze vollkommen unverständlich.
Natürlich verwenden wir typedefs. Weiterhin ist es glücklicherweise nicht nötig alle möglichen auftretenden Kombinationen zu typedefen. Wenn ein Zwischenergebnis halt kgm/s^2 hat und das kg noch wieder rausgekürzt wird im Verlauf der späteren Rechnung, dann brauche ich den Typ auch nicht explizit benennen.
Da ich typedefs benutze ist es völlig problemlos die Butterbrote einzufügen, ohne dass die Übersichtlichkeit leidet. Insbesondere muß ich für kg*Butterbrot keinen Typverlust hinnehmen -- komplizierte Welt!
Das will ich hoffen, ansonsten frage ich mich ernsthaft, wofür operator int() wohl gut sein sollte...
Das haben sie bestimmt eingebaut, weil man nicht von int erben kann!
-
Xin schrieb:
Jow...
Und wenn Du mit einem Auto gegen einen Baum fährst, wird es auch implizit in einen Haufen Schrott umgewandelt.
Ohne Warnung. Schlussfolgerung: der Autohersteller hat nicht typsicher gearbeitet, weil er die Verbindung Baum + Auto nicht unterbindet und es so zu unerwarteten Ergebnissen kommt, wenn der Nutzer sich nicht an das hält, was er in seiner Ausbildung gelernt haben sollte.Tja. Man kann es dem Benutzer halt leicht und schwer machen etwas falsch zu machen. Wir wollen es ihm möglichst schwer machen. Du hingegen stehst anscheinend auf dem Standpunkt, dass der Benutzer halt selber Schuld ist dass Mist rauskommt wenn er nen Fehler macht. Das ist natürlich schlecht, sei Dir aber unbelassen.
Schon wieder eine Kritik an den expliziten int-Konstruktoren?!? Wenn man keine Ahnung hat, einfach mal Fragen stellen. ^^
Das ist natürlich der Hammer. Ganz klar, wer Deine expliziten Konstruktoren kritisiert, der hat's nicht kapiert. -- Warum? -- Ganz klar, sonst würde er sie ja nicht kritisieren.
Das ist echt so unglaublich eingebildet, ignorant und vor allem unverschämt, dass es schon weh tut.
-
Das hat weh getan(also dem xin mein ich)
Auch wenn man generell auf diese wertlosen, zwischenraumfüllenden unreg posts verzichten könnte geben sie manchmal der diskussion eine interressante wende, oder machen zumindest manchmal die eigentlichen aussagen in den posts der ernsthaft diskutierenden klarer.
-
Jester schrieb:
Das ist natürlich der Hammer [...]
Das ist echt so unglaublich eingebildet, ignorant und vor allem unverschämt, dass es schon weh tut.das sag ich ja schon seit wochen aber auf mich hört ja niemand. selbst schuld wenn ihr euch immer wieder von dem typen provozieren lasst
-
Also bitte, wer hier seitenweise die Leute beleidigt, dann rumheult, dass er selbst angegriffen wird und sich anschließend damit rechtfertigt, dass er gar niemanden beleidigt, sondern nur wiedergegeben hat, was offensichtlich erkennbar wäre, muss ja irgenwelche Störungen haben.
-
Jester schrieb:
Xin schrieb:
Da Du das template aber nicht unendlich dimensional erzeugen kannst, jedenfalls nicht in der Realität, ist wohl eindeutig.
Stimmt, aber glücklicherweise genügt es ja, dass ich die Dimension beliebig groß machen kann.
Eine theoretisch perfekte Lösung. ^^
Jester schrieb:
Da ich typedefs benutze ist es völlig problemlos die Butterbrote einzufügen, ohne dass die Übersichtlichkeit leidet. Insbesondere muß ich für kg*Butterbrot keinen Typverlust hinnehmen -- komplizierte Welt!
In dem Fall sicherlich, aber Typsicherheit war in einer Zeit wo man dankbar war nicht mehr Assembler schreiben zu müssen, einfach noch kein Thema.
Jester schrieb:
Das will ich hoffen, ansonsten frage ich mich ernsthaft, wofür operator int() wohl gut sein sollte...
Das haben sie bestimmt eingebaut, weil man nicht von int erben kann!
Du kannst auch operator string() definieren und von string könnte man erben. ^^
Jester schrieb:
Tja. Man kann es dem Benutzer halt leicht und schwer machen etwas falsch zu machen. Wir wollen es ihm möglichst schwer machen. Du hingegen stehst anscheinend auf dem Standpunkt, dass der Benutzer halt selber Schuld ist dass Mist rauskommt wenn er nen Fehler macht. Das ist natürlich schlecht, sei Dir aber unbelassen.
Ich stehe auf dem Standpunkt, dass man nicht überall ein Sicherheitszäune hinbauen darf. Das bewahrt die Leuten, die wissen, was sie tun, davor gelegentlich versehentlich abzustürzen. Das spart den Leuten am Tag 5 Minuten. Es erzeugt aber auch Leute, die sich locker und unüberlegt durch ihre Welt bewegen, weil es überall ja Sicherheitszäune gibt.
Und dann gibt's eine Stelle, wo der Zaun ein Loch hat und keiner versteht, was passiert. Das lässt Weltbilder zusammenfallen. C++ ist kein Basic und ich mache auch keins draus.Diese Sicherheits-Mentalität habe ich nicht. Ich schütze nicht vor allen Fehlern. Wer dumme Fragen stellt, muss mit dummen Antworten rechnen - im wahrsten Sinne des Wortes. Es gibt viele Fallen und jeder Entwickler sollte jede einzelne ausprobieren, um Erfahrung zu sammeln und sich auch dort bewegen zu können, wo keiner Zäune aufgestellt hat. Ich persönlich schätze die freie Natur.
Jester schrieb:
Schon wieder eine Kritik an den expliziten int-Konstruktoren?!? Wenn man keine Ahnung hat, einfach mal Fragen stellen. ^^
Das ist natürlich der Hammer. Ganz klar, wer Deine expliziten Konstruktoren kritisiert, der hat's nicht kapiert. -- Warum? -- Ganz klar, sonst würde er sie ja nicht kritisieren.
Das ist echt so unglaublich eingebildet, ignorant und vor allem unverschämt, dass es schon weh tut.Dass er keine Ahnung hat, hat er geschrieben und anschließend noch die Beweisführung betrieben, darum bin ich eingebildet, ignorant und vor allem unverschämt.
Ich schrieb ja grade erst, dass jeder seine Erfahrungen machen muss, um ein erfahrener Entwickler zu werden. 'explicit' habe ich auch nicht gefunden, weil ich ein C++ Buch auswendig gelernt habe, sondern weil ich genau das Problem zu lösen hatte.
Wenn ihr das Problem anders lösen wollt... viel Erfolg, bisher habt ihr an den Konstruktoren nichts vorgelegt.Du und Shade könnt gerne auf explizite Konstruktoren verzichten. Niemand muss was ich hier von mir gebe, glauben oder akzeptieren. Auch wenn Du es als eingebildet, ignorant und unverschämt ansiehst, kann es nicht so dumm sein, dass ihr euch nicht damit beschäftigt. Wer an den expliziten Konstruktoren rütteln will, sollte es aber vorsichtig und schrittweise mit Fragen probieren. Mit Gewalt Behauptungen aufzustellen und dann zu versuchen die Behauptungen durchzusetzen, lässt einen nunmal nicht im besten Licht darstehen, wenn's schief geht.
Da rücke ich niemanden hin, aber ziehe euch auch nicht in ein besseres Licht.Es ist jedenfalls nicht eingebildet oder arrogant Shade sein Eigentor versenken zu lassen. Ignorant wäre es gewesen, ihn mit seinem Denkfehler stehen zu lassen.
Und beschimpft werde ich hier so oder so - so what?Da ich so "dünnhäutig" bin, lebe ich hier vermutlich meine masochistische Ader oder "irgendwelche Störungen" sonstiger Natur aus. Auf jeden Fall muss der Fehler bei mir liegen und wenn's nicht die expliziten Konstruktoren sind, dann muss ich wenigstens eingebildet, ignorant und unverschämt sein.
-
Beispiele schrieb:
Meter = { komplexe physikalische Formel }Bei { komplexe physikalische Formel } ist irgendwas faul, es kommt int raus. Der Compiler verweigert es, aber was genau ist nun faul? Bei CStolls Templatesystem kommt eine prägnante Fehlermeldung à la "Keine Überladung für Sekunde * Haus". Alles ist sofort klar. DAS ist Typsicherheit.
Anderes Beispiel: In der Physik gibt es durchaus typlose Konstanten oder Ergebnisse, z.B. Brechzahl, oder Winkel, insbesondere trigonometrische Funktionen davon. Du weißt also ein int einem int zu, aber ist das int nun richtig entstanden? Man kann es nicht nachvollziehen.
Warum gehst du hierauf eigentlich nicht ein Oo
-
dfggfg schrieb:
ach red doch keinen verbalen dünschiss...
es habt sich gezeigt, dass die vorteile xins methode im detail stecken,
und man sie eigentlich mit dem bloßem auge nicht erkennen kann,
die nachteile zwar manchmal erkennbar sind, aber dies nur sind, wenn man die
nachteile als solche definiert, und das nur, wenn es nachts kälter als draußen ist.Also ist doch alles eindeutig oder?
Kann man dich mieten?
-
Hallo
Oh Mann Xin gefällst du dir in der Rolle des Unverstandenen?
chrische
