Methoden mit bool-Parametern und "Lesbarkeit" im Kontext
-
Erstmal entschuldige ich mich, daß ich jetzt nicht auf jeden Beitrag der letzten Tage einzeln eingehe.
Xin schrieb:
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."Wir" stellen uns oben an die Baugrube und sagen dem Gast, daß es hier gefährlich sein könnte - wenn er doch weitergehen will, bieten wir einen Sturzhelm an. Du wartest unten in der Baugrube und sagst den abstürzenden Gästen "Mit Helm wäre die Landung nicht so hart gewesen. Mag sein, daß das eine andere Einstellung von Sicherheit ist - aber ich will meinen Sturzhelm lieber bevor ich abgestürzt bin.
Xin schrieb:
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?Wäre mal interessant mitzuzählen, wieviele Eigentore du inzwischen geschossen hast. Ich hab' zwar irgendwo den Überblick verloren, aber da dürfte einiges zusammenkommen.
(btw, wenn du jeden, der nicht deiner Meinung bist, dem "Forumskindergarten" zuordnest, hilft das der Diskussion überhaupt nicht.
Xin schrieb:
Theston schrieb:
Volt = Butterbrot*Katze*VoltButtrebrot*Katze ergibt typlos.
Falsch, ergibt Unit, konvertierbar auf typlos.
Theston schrieb:
Allerdings ist es physikalisch sinnvoll, einen Operator typlos*Volt zu haben, der Volt liefert, als Beispiel genannte Brechzahl und Wurzelfunktionen, das Endergebnis der Operation ist also VOLT, Zuweisung funktioniert. Typsicherheit?
Tut mir leid, Du bist etwa 10-20 Seiten zu spät. Die Lösung hatten wir schon.
Nur eine Randbemerkung zu deiner "Lösung" - sie ist herrlich mehrdeutig:
class Unit : public int {}; class Laenge : public Unit {}; class Gewicht : public Unit {}; int operator*(int,int); //0a - build-in Unit operator*(Unit,Unit); //1a Laenge operator*(int,Laenge); //2a - Skalierung Laenge operator*(Laenge,int); //3a - -"- //Für Gewicht analog int operator+(int,int); //0b - build-in Unit operator+(Unit,Unit); //1b Laenge operator+(Laenge,Laenge); //2b Gewicht operator+(Gewicht,Gewicht);//3b Laenge l,b; Gewicht g /* A: */ cout<<l*b; /* B: */ l = (l+g)*b;Die Überladungsauflösung findet bei Aufruf A für den ersten Operanden Funktion 3 (exact Match - alle Alternativen erfordern eine Umwandlung zum Basistyp) und für den zweiten Operanden Funktion 2 (nach den selben Kriterien) - BUMM.
Bei Aufruf B greift zunächt Funktion 1b und anschließend hat der Compiler die Wahl zwischen Funktion 1a (exact Match für ersten Operanden) und 2a (exact Match für zweiten Operanden) - BUMM. (hier fällt der Fehler erst bei der Multiplikation auf - woher soll der Programmierer da wissen, daß er eigentlich schon viel früher aufgetreten ist?)(btw, wenn du darüber stolperst, daß man von int nicht ableiten kann - dann ersetze ich es gerne durch eine Pseudo-Int-Klasse)
Shade Of Mine schrieb:
In C++ ist es generell so, dass der Weg weg von operator int und hin zu non-explicit CTor geht. std::string hat keinen operator char* aber eine Methode c_str() für die Fälle wo es mal nötig ist. Weiters hat er einen non-explicit CTor für char*. Natürlich ist std::string nicht das beste Beispiel für gutes Klassendesign - aber jede gute String Klasse wird so arbeiten.
Beim String ist es was anderes - std::string erweitert die char* um eine Möglichkeit der einfacheren Verarbeitung. Bei den Einheiten würde ich WEDER implizite Umwandlungen nach int NOCH non-explizite Konstruktoren zur Verfügung stellen. Die arbeiten zwar intern mit int-Werten, aber das sollten sie nicht unbedingt in die Welt hinausschreien (und weil hier schon mehrfach die Genauigkeit angesprochen wurde - ich kann eine Größenangabe auch auf zwei Member verteilen: Zahlenwert und Einheitenpräfix. (dann wird 5 Meter als {5;0} gespeichert und 5 Millimeter als {5;-3})
Xin schrieb:
Okay... ich gebe zu, dass ich gewisse Grundfähigkeiten als Voraussetzung ansehe, z.B. eine Expression zu debuggen, die inkompatible Typen aufweist. Ist ja nicht so, als wäre das ein Problem, dass in C++ sonst nie auftreten würde...
Selbst wenn der Compiler mitunter kryptische Fehlermeldungen bringt - sie sind jedenfalls genau an der Stelle, wo der Fehler aufgetreten ist - und nicht erst am Ende der gesamten Anweisung. (und nebenbei bist du auch ein Programmierer
Xin schrieb:
Shade Of Mine schrieb:
Unser Ziel ist es, korrekte Software zu schreiben. Wir tun deshalb alles was in unserer Macht steht um Fehler zu verhindern.
Wen bezeichnest Du denn mit "wir"? "Ihr", die gegen Xin texten?
Mit der Typsicherung habe ich hier angefangen und CStoll kritisierte es.Ja, ich habe kritisiert, daß du mit deinen Bemühungen nicht weit genug gehst.
Xin schrieb:
Wieso gehst Du nicht darauf auf die Zeile ein, wo ich Dir leider vorrechnen muss, dass Meter/Meter (wenn ich Deinen Tippfehler also korrigiere) im Template leider immernoch typlos ist, Deinem Posting also komplett die Grundlage fehlt?
Warum regst Du Dich darüber auf, dass man sich über Deine Fehler amüsiert, aber nicht darüber, dass Du meine Zeit verschwendest, weil Du nicht nachgedacht hast, bevor Du etwas gepostet hast, was nicht mehr als einen Tippfehler enthielt?Meter/Meter ist nicht typlos, sondern nur einheitenlos - etwas typloses hast nur du daraus gemacht. Der Cosinus eines Winkels ist genauso eine einheitenlose Größe - und damit kompatibel zum Quotienten zweier Längenangaben. Meter*Kilogramm ist nicht einheitenlos und darum inkompatibel zu cos_alpha.
Xin schrieb:
Wir haben das, was ich vorgeschlagen habe, als Grenze des praktisch machbaren, vor ~15 Seiten im Detail durch Unit verbessert. Wir haben CStolls Klassen, die gleichwertig sind. Er macht das gleiche wie ich, er erzeugt sie nur über ein Template. Ich habe nie verboten, meine Klassen per Template zu erzeugen.
Wir haben eine theoretisch perfekte Lösung.Ich mache nicht das gleiche - ich frage den Programmierer, ob er wirklich mit nackten int-Werten hantieren will.
Xin schrieb:
Mal ehrlich, Jungs, kaum einer hat sich wirklich mit dem auseinandergesetzt, was ich geschrieben habe. Ich lese es ja an den Antworten.
Wozu das? Du setzt dich schließlich auch nicht mit dem auseinander, was wir geschrieben haben. Du hast auf den letzten Seiten nur EINE Bemerkung als echtes Argument anerkannt - und durch deine "Verbesserung" auch nur an den Sysmptomen herumgepfuscht, anstatt dir die Ursachen der (von dir akzeptierten) Schwachstelle anzusehen.
----
Off-Topic:
Undertaker schrieb:
CStoll schrieb:
[*]dich stufe ich als (vereinfacht formuliert) "gelegentlich nervtötend" ein - du magst zwar recht gut im Umgang mit C sein, aber wenn du versuchst, das auf C++ Probleme anzuwenden, landest du schnell auf der ***
[/list]sowas würde ich niemals machen. wenn ich im C++ forrum code poste, dann nur solchen, der anstandslos durch einen stinknormalen C++ compiler geht.
Dir ist klar, daß es einen Unterschied gibt zwischen der C++ Lösung eines Problems und einer C++tauglich zurechtgebogenen C-Lösung? Wenn du etwas präsentierst, dann meist letzteres.
Mr. N schrieb:
Badestrand schrieb:
Mr. N schrieb:
Undertaker schrieb:
ich will kein thread-hijacking betreiben.
Danke!
Es geht doch sowieso längst nicht mehr um das Ursprüngliche, es ging schließlich mal um Flags
Ja, aber ohne künstliche Wendung zu einem "Undertaker vs C++"-Thread. Von denen gibts außerdem schon genug.
Stimmt, Undertaker darf gerne seine eigenen Threads anfangen - hier geht's immer noch um "Xin vs. C++".
-
CStoll schrieb:
Off-Topic:
Undertaker schrieb:
CStoll schrieb:
[*]dich stufe ich als (vereinfacht formuliert) "gelegentlich nervtötend" ein - du magst zwar recht gut im Umgang mit C sein, aber wenn du versuchst, das auf C++ Probleme anzuwenden, landest du schnell auf der ***
[/list]sowas würde ich niemals machen. wenn ich im C++ forrum code poste, dann nur solchen, der anstandslos durch einen stinknormalen C++ compiler geht.
Dir ist klar, daß es einen Unterschied gibt zwischen der C++ Lösung eines Problems und einer C++tauglich zurechtgebogenen C-Lösung? Wenn du etwas präsentierst, dann meist letzteres.
ja, so ist es. es liegt aber weniger an meinem nicht vorhandenen C++-wissen (in einer STL reference nachzuschlagen bekomme selbst ich hin), sondern daran, dass bei solchen einfachen C-lösungen, der ablauf für den fragesteller meistens leichter nachvollziehbar ist.
-
CStoll schrieb:
Erstmal entschuldige ich mich, daß ich jetzt nicht auf jeden Beitrag der letzten Tage einzeln eingehe.
-
Undertaker schrieb:
ja, so ist es. es liegt aber weniger an meinem nicht vorhandenen C++-wissen (in einer STL reference nachzuschlagen bekomme selbst ich hin), sondern daran, dass bei solchen einfachen C-lösungen, der ablauf für den fragesteller meistens leichter nachvollziehbar ist.
Du meinst also, (z.B.) Strings über strcpy() und strcat() zusammenzubauen (inklusive der gesamten Verwaltungsarbeit, um Speicherüberläufe zu vermeiden) ist leichter verständlich als die "Arithmetik" von std::string?
-
CStoll schrieb:
Undertaker schrieb:
ja, so ist es. es liegt aber weniger an meinem nicht vorhandenen C++-wissen (in einer STL reference nachzuschlagen bekomme selbst ich hin), sondern daran, dass bei solchen einfachen C-lösungen, der ablauf für den fragesteller meistens leichter nachvollziehbar ist.
Du meinst also, (z.B.) Strings über strcpy() und strcat() zusammenzubauen (inklusive der gesamten Verwaltungsarbeit, um Speicherüberläufe zu vermeiden) ist leichter verständlich als die "Arithmetik" von std::string?
nö, dabei muss man ja wissen, was die funktionen tun, das kommt auf's gleiche raus.
ich meinte mehr solche einfachen sachen, die man gut 'zu fuss' erledigen kann, wie z.b. 'ich will einen int als binärzahl anzeigen'. dabei sieht man dann gleich, wie's funktioniert. mit C++'s 'bitset' geht's irgendwie auch, aber für den einsteiger ist das kaum nachvollziehbar.
-
Xin schrieb:
Als schäbiger FH-Absolvent, kömmt mein Ego ganz gut mit der Kritik der Uni-Studenten zurecht - ich habe die Postings ja gelesen.
Offensichtlich kommst du mit der Kritik nicht zurecht. Wunderst dich ja sogar, dass nicht alle über deine Beleidigungen lachen. Und konterst mit noch mehr Beleidigung.
Zum Thema "Wissen, das man nicht braucht"... wer nutzt enum-Klassen, weil er denkt, enum wäre nicht typsicher? Wer glaubt, ein C++-Optimierer könne nicht optimieren, was erwiesenermaßen optimiert wird? Du hast deine Pflicht, dich auf dem laufenden Stand zu halten sträflich vernachlässigt und kompensierst das dadurch, dass du alle möglichen Leute beleidigst.
CStoll und Shade Of Mine sind - ganz im Gegensatz zu mir, das gebe ich gerne zu - nicht kindisch, sondern überaus konstruktiv und bereit zu einer ernsthaften Diskussion gewesen. Wider besseres Wissen, denn das ist mit dir nicht möglich.
-
CStoll schrieb:
Erstmal entschuldige ich mich, daß ich jetzt nicht auf jeden Beitrag der letzten Tage einzeln eingehe.
Nichts zu entschuldigen, eher zu danken...
CStoll schrieb:
"Wir" stellen uns oben an die Baugrube und sagen dem Gast, daß es hier gefährlich sein könnte - wenn er doch weitergehen will, bieten wir einen Sturzhelm an. Du wartest unten in der Baugrube und sagst den abstürzenden Gästen "Mit Helm wäre die Landung nicht so hart gewesen. Mag sein, daß das eine andere Einstellung von Sicherheit ist - aber ich will meinen Sturzhelm lieber bevor ich abgestürzt bin.
Hmm... das Beispiel klingt eher so, als würdest Du meine Gäste an den Haaren herbeiziehen, um sie dann in die Grube zu werfen und zu sagen, hättet ihr meinen Sturzhelm genommen, hättet ihr euch wenigstens nicht weh getan.
Nebenher definieren wir beide unsere Position nicht in der Grube.
Meine Position ist eher so: Augen auf, dann gewöhnt man sich an, um die Grube herum zu gehen. Und es gibt keinen Weg schneller zu lernen, dass man die Augen offen zu haben hat, als wenn man hier und da mal aus der Grube gekrabbelt kommt.
Meine Schüler schubse ich jede Grube. Dann machen sie den Fehler nochmal alleine, wissen aber selbst, dass und welchen Mist sie gebaut haben und dann achten sie darauf, diesen Mist nicht mehr zu bauen.CStoll schrieb:
Xin schrieb:
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?Wäre mal interessant mitzuzählen, wieviele Eigentore du inzwischen geschossen hast. Ich hab' zwar irgendwo den Überblick verloren, aber da dürfte einiges zusammenkommen.
Keine Ahnung, dafür, dass ich aus einer theoretischen Möglichkeit im Stehgreif das perfekte Typsystem zu bieten haben soll, finde ich, dass ich mich nicht schlecht mache.
CStoll schrieb:
(btw, wenn du jeden, der nicht deiner Meinung bist, dem "Forumskindergarten" zuordnest, hilft das der Diskussion überhaupt nicht.
Das tue ich nicht. Ich sage, dass hier eine Menge Kiddies rumlaufen.
Ich wiederhole immer wieder, dass man meine Lösungen nicht nehmen muss. Ich bin sogar dafür, dass sich jeder etwas eigenes entwickelt.
An den expliziten Ctors kommt man trotzdem nicht vorbei.
Wen ich in den Forumskindergarten schicke, der stellt mit fehlender Kenntnis von Fachwissen und fehlernder Kenntnis über bereits Geschriebenes innerhalb Threads Behauptungen auf, die sich keinen inhaltlichen Wert (mehr) haben. Es macht einen Unterschied eine Möglichkeit zu diskutieren oder "FACTS" (unregistriert, aber afair als scrub kenntlich gemacht), die einfach mal in den Raum posaunt werden.
Scrub war nebenher der einzige, der sagte, dass er unter unterschiedlichen unregistrierten Pseudonymen gepostet hat, aber nicht, um den Eindruck zu erwecken, dass mehr Leute gegen mich wären, sondern weil er davon ausgeht, dass jeder seine unterschiedlichen Nicks kennt. Ich kenne sie nicht.An erster Front der Kiddies die Reihe derer, die hier als Unregistrierte noch "Höflichkeiten" reinposten - mir kann doch keiner erzählen, dass das alles wirklich unregistrierte Leute sind, die nur mal eben ins Forum schauten, um ihr Mißfallen mir gegenüber zum Ausdruck bringen.
Wer alt genug ist, um zu wissen, dass derartige Äußerungen dem Image der eigenen, registrierten Forum-Identität schadet, aber noch nicht reif genug ist, zu bemerken, dass die derartige Äußerungen nicht besser werden, nur weil man sie nicht mit der registrierten Identität in Verbindung bringen kann, der muss noch recht 'jung' sein. Bei den meisten endet die Pubertät mit etwa 20 Jahren. Bei der Menge an Unregistrierten, glaube nicht, dass jeder hier das Ende der Pubertät schon erreicht hat.
So kommt es zu dem, was ich als Kindergarten bezeichne.CStoll schrieb:
Xin schrieb:
Tut mir leid, Du bist etwa 10-20 Seiten zu spät. Die Lösung hatten wir schon.
Nur eine Randbemerkung zu deiner "Lösung" - sie ist herrlich mehrdeutig:
...Die Überladungsauflösung findet bei Aufruf A für den ersten Operanden Funktion 3 (exact Match - alle Alternativen erfordern eine Umwandlung zum Basistyp) und für den zweiten Operanden Funktion 2 (nach den selben Kriterien) - BUMM.
Bei Aufruf B greift zunächt Funktion 1b und anschließend hat der Compiler die Wahl zwischen Funktion 1a (exact Match für ersten Operanden) und 2a (exact Match für zweiten Operanden) - BUMM. (hier fällt der Fehler erst bei der Multiplikation auf - woher soll der Programmierer da wissen, daß er eigentlich schon viel früher aufgetreten ist?)Ich verstehe jetzt nicht, wo Du drauf hinaus willst?
Die Mehrdeutigkeit weist in C++ doch darauf hin, dass einer der Faktoren hakt. Also eigentlich hast Du damit doch genau das, was Du als fehlend kritisierst.
Afair kommen Dir dann nur noch die Fehlermeldung der Compiler in den Weg. Der GCC meckert bei derartigen Dingen zwar und nennt Möglichkeiten, sagt aber nicht warum es überhaupt geknallt hat.
Die Methode ist typsicher, denn sie ist nicht übersetzbar.Ich sehe Unit als die vorrangige Lösung an und erlaube den Rechenweg. Damit wird die Gleichung ausgerechnet, aber kann nicht zugewiesen werden. Ich löse also Typinformationen auf, um die Rechnung zu erlauben, was darin endet, dass ein Konflikt erst bei der Zuweisung entsteht: Es sind nicht mehr genug Typinformationen für eine typsichere Zuweisung vorhanden.
Damit bleibt es typsicher, weil auch das ist nicht übersetzbar.CStoll schrieb:
(btw, wenn du darüber stolperst, daß man von int nicht ableiten kann - dann ersetze ich es gerne durch eine Pseudo-Int-Klasse)
Warum sollte ich jetzt meckern? Mein Part ist schließlich als Gedankenspiel von Möglichkeiten gestartet und nicht als C++-Produktivlösung. Das darf meinetwegen sogar noch ein Shade verwechseln, aber Du warst bei der Geburt des Gedankenspiels dabei... schon vergessen?
Wir erinnern uns? Meine Produktivlösung ist ähnlich, aber nicht identisch und sie leitet logischerweise auch nicht von int ab.
CStoll schrieb:
Xin schrieb:
Okay... ich gebe zu, dass ich gewisse Grundfähigkeiten als Voraussetzung ansehe, z.B. eine Expression zu debuggen, die inkompatible Typen aufweist. Ist ja nicht so, als wäre das ein Problem, dass in C++ sonst nie auftreten würde...
Selbst wenn der Compiler mitunter kryptische Fehlermeldungen bringt - sie sind jedenfalls genau an der Stelle, wo der Fehler aufgetreten ist - und nicht erst am Ende der gesamten Anweisung. (und nebenbei bist du auch ein Programmierer
Schonmal ein Semikolon vergessen und eine längere Dokumentations zwischen dem vergessenen Semikolon und anderem Code gehabt?
Inhalt der angegebenen Zeile: etwas wie "a = 7;", Fehlermeldung: Semikolon vergessen.
Genau an der Stelle, wo der Fehler aufgetreten ist? Nein, der Fehler lag ein paar Dutzend Zeilen dadrüber.
Fällt mir mal so auf die Schnelle ein, weil ich in meinen Compiler extra eingebaut habe, zum Token zurückzugehen, hinter dem das Semikolon zu erwarten wäre.Wenn Dir der Fehler zu primitiv ist, weil das weiß ja jeder, dass nahezu alle C-Compiler das Semikolon vor der nächsten Anweisung erwarten und nicht hinter der Anweisung, dann beschwer Dich nicht über die Verkettung der Operatoren.
Weiterverwurstung von Datentypen findet auch in C++ ohne meine Klassen statt, damit der Fehler irgendwo anders auftritt. Eine Fehlermeldung innerhalb einer langen Expression ist vollkommen unplatziert. Fehlerhafte if-Bedingungen werden am Ende von if kritisiert, egal über wieviele Zeilen die Bedingung sich zieht.CStoll schrieb:
Xin schrieb:
Shade Of Mine schrieb:
Unser Ziel ist es, korrekte Software zu schreiben. Wir tun deshalb alles was in unserer Macht steht um Fehler zu verhindern.
Wen bezeichnest Du denn mit "wir"? "Ihr", die gegen Xin texten?
Mit der Typsicherung habe ich hier angefangen und CStoll kritisierte es.Ja, ich habe kritisiert, daß du mit deinen Bemühungen nicht weit genug gehst.
Und nichts gebracht, was wirklich weiter gehen würde.
Der Punkt ist, dass Einheiten etwas statisches sind, man C++ aber nunmal schlecht beibringen kann, statische Informationen - also Typinformationen - zu verrechnen. Und solange C++ das nicht kann, wird man nicht umhinkommen, Klassen selbst zu erzeugen oder per Template erzeugen zu lassen und anschließend zu benennen, weil kein Mensch sich ein Templatemuster merken kann/will, dass für SI-Einheiten schon 7 Parameter braucht oder fünf Zeilen Deklaration um eine Variable anzumelden.
Typsicherheit ist in C++ aufwendig. Und den Mittelweg zwischen machbar und handhabbar zu finden ist eine Geschmackssache. Wie ich das sehe, sind wir uns mit unseren Ansätzen eigentlich einig, da wir mehr oder minder das gleiche tun.
Strittig ist - aber halt nicht mit Dir - ob die Welt explizite CTors braucht oder nicht.
CStoll schrieb:
Xin schrieb:
Wieso gehst Du nicht darauf auf die Zeile ein, wo ich Dir leider vorrechnen muss, dass Meter/Meter (wenn ich Deinen Tippfehler also korrigiere) im Template leider immernoch typlos ist, Deinem Posting also komplett die Grundlage fehlt?
Warum regst Du Dich darüber auf, dass man sich über Deine Fehler amüsiert, aber nicht darüber, dass Du meine Zeit verschwendest, weil Du nicht nachgedacht hast, bevor Du etwas gepostet hast, was nicht mehr als einen Tippfehler enthielt?Meter/Meter ist nicht typlos, sondern nur einheitenlos - etwas typloses hast nur du daraus gemacht.
Bei Dir war's unit<0,0,0,0,0,0,0>, bei mir heißt's nur unit. In beiden Fällen haben wir einen Typen, der nichts aussagt. Zumindest nicht Meter/Meter. Horray.
Winkel kann man auch durch kgm/s²/(kgm/s²) ausdrücken. Welche Einheiten darf man - obwohl sie sowieso gekürzt sind, ignorieren, welche müssen selbst gekürzt drin bleiben, damit es einheitenlose Winkel ergeben?Wenn ich den cosinus von 2*PI berechnet, so ist 2*PI 6,28... und da ist kein Typ dahinter: typlos.
Da irgendwas reinzuinterpretieren ist Haarspalterei.
Typsicherheit zu fordern bei Dingen, die nicht typsicherbar sind, bringt niemanden weiter.CStoll schrieb:
Der Cosinus eines Winkels ist genauso eine einheitenlose Größe - und damit kompatibel zum Quotienten zweier Längenangaben. Meter*Kilogramm ist nicht einheitenlos und darum inkompatibel zu cos_alpha.
Vielleicht war Dir aufgefallen, dass ich typsichere Versionen von cos usw. forderte, die Winkelgrade (ob die jetzt mit 0..2Pi oder Winkelgrade oder gon dargestellt werden, who cares) übergeben bekommen würden => expliziter Konstruktor => typsicher => Meter * Kg ist kein Winkelmaß => Compilermecker.
CStoll schrieb:
Xin schrieb:
Wir haben das, was ich vorgeschlagen habe, als Grenze des praktisch machbaren, vor ~15 Seiten im Detail durch Unit verbessert. Wir haben CStolls Klassen, die gleichwertig sind. Er macht das gleiche wie ich, er erzeugt sie nur über ein Template. Ich habe nie verboten, meine Klassen per Template zu erzeugen.
Wir haben eine theoretisch perfekte Lösung.Ich mache nicht das gleiche - ich frage den Programmierer, ob er wirklich mit nackten int-Werten hantieren will.
Ich lasse ihn und verbiete ihm die implizite Zuweisung. Das Ergebnis ist, dass er sich damit auseinandersetzen muss, wie er etwas ausdrückt, um zuweisen zu können. Solange er nur rumrechnet und nichts zuweist, kann er keinen Programmfehler auslösen.
5+Meter( 4 );ist eine gültige Anweisung und selbst wenn Dir das nicht gefällt und Du sagst, es ist nicht typsicher... den Compiler interessiert es nicht, die Anweisung ist sinnlos, legal und ungefährlich.
Ich greife nur an dem Punkt ein, wo es gefährlich werden kann: der Zuweisung.CStoll schrieb:
Xin schrieb:
Mal ehrlich, Jungs, kaum einer hat sich wirklich mit dem auseinandergesetzt, was ich geschrieben habe. Ich lese es ja an den Antworten.
Wozu das? Du setzt dich schließlich auch nicht mit dem auseinander, was wir geschrieben haben. Du hast auf den letzten Seiten nur EINE Bemerkung als echtes Argument anerkannt - und durch deine "Verbesserung" auch nur an den Sysmptomen herumgepfuscht, anstatt dir die Ursachen der (von dir akzeptierten) Schwachstelle anzusehen.
Ich schaue mir die Schwachstellen sehr genau an. Ich sehe allerdings nicht, dass irgendwer etwas angebracht hat, was sicherer ist. Hier und da etwas andere Syntax, ich konzentriere mich auf die Zuweisung, Du schränkst alles ein, aber im Endeffekt kommt nicht mehr raus. Wenn Gefahr droht, schlagen wir beide Alarm und der Entwickler muss sich klarer ausdrücken.
Sich falsch ausdrücken kann er in beiden Fällen. Das werfe ich Dir nicht zur Last, weil das kein Argument wäre, wieso sollte ich derartiges als Argument anerkennen?
Bisher kam nur ein Argument und sehr viel Text und viel Blahblah, wer hier wen ignoriert und wer hier wen beleidigt.Wie ich schon sagte, wir werden hier nicht weiterkommen, denn wir sind an einer Grenze von C++. Und weil wir nicht weiterkommen und keiner außer mir seinen Willen bekommt, fliegen die Beleidigungen durch die Gegend - wobei ich natürlich derjenige gewesen bin, der andere auf's schärfste angegangen ist und vor allem damit begonnen hat.
Warum bekomme grade ich meinen Willen? Weil ich nie etwas Perfektes versprochen habe. Weil ich eigentlich überhaupt nie etwas versprochen habe, da ich die ganze Zeit mit einem Gedankenspiel in diesem Thread arbeite, das Du mir auferlegt hast: "Wo könnte eine Ableitung von int Sinn haben?".
Du hast das Gedankenspiel wieder auf C++ Syntax gebracht, es weiter eingeschränkt, aber niemand konnte ihm etwas wichtiges hinzufügen. Jemand brachte die theoretisch perfekte Lösung, die aber nicht handhabbar ist.Egal in welche Richtung der Thread sich entwickelte oder noch entwickeln könnte; Wir stehen an der Grenze von C++. Bevor C++0x diese Grenzen nicht verschiebt, man sich auf eine andere Sprache konzentriert oder meinetwegen sich in Gedankenspielen verliert, geht es einfach nicht weiter.
Sprachen mit statischer Typlogik brachte keiner vor. Statische Typlogik ist machbar, aber dann darf man selbst an der Grenze von C++ nicht stehenbleiben und muss dementsprechend das derzeit aktuelle C++ zurücklassen.
Man kann mit C++ nicht die Grenzen von C++ überschreiten, so lobenswert die Absichten auch sind.
-
Mr. N schrieb:
Xin schrieb:
Als schäbiger FH-Absolvent, kömmt mein Ego ganz gut mit der Kritik der Uni-Studenten zurecht - ich habe die Postings ja gelesen.
Offensichtlich kommst du mit der Kritik nicht zurecht. Wunderst dich ja sogar, dass nicht alle über deine Beleidigungen lachen. Und konterst mit noch mehr Beleidigung.
?
Wo beleidige ich hier denn schon wieder? Und wieso sollte irgendwer über Beleidigungen lachen, ich mich darüber wundern!? Willst Du auf "Grüße vom Planeten Erde" raus? Darüber konnte ich lachen, das reicht mir vollkommen und das Posting hatte es definitiv verdient veräppelt zu werden, zumal ich auch ernsthaft argumentiert habe. Als Beleidigung sehe ich das nicht, wer Winkel in Quadratmetern rechnet, muss auch mit entsprechenden Comments rechnen.Kann es sein, dass nicht ich derjenige bin, der hier zu "dünnhäutig" ist.
Mr. N schrieb:
Zum Thema "Wissen, das man nicht braucht"... wer nutzt enum-Klassen, weil er denkt, enum wäre nicht typsicher?
Keine Ahnung, ich nutze enum äußerst selten, weil sie keinen Namensraum erzeugen. Außerdem - und das habe ich in diesem Thread erfahren, sind sie nur in C mit int typisiert. Deswegen sind sie dennoch nur bedingt einsetzbar, denn sie erzeugen immernoch keinen eigenen Namensraum.
Mr. N schrieb:
Wer glaubt, ein C++-Optimierer könne nicht optimieren, was erwiesenermaßen optimiert wird? Du hast deine Pflicht, dich auf dem laufenden Stand zu halten sträflich vernachlässigt und ...
Du übernimmst also die Garantie, dass "ein" C++-Optimierer das (was war's noch gleich?) erwiesenermaßen optimieren kann.
Was ist "ein"? Irgendein? Gilt das für genau einen oder alle? Und wenn es nur für einen gilt, dann ist es kein C++ Optimierer, sondern ein GCC-C++-Optimierer.
Garantierst Du die Optimierung für GCC, Intel, MSVC, Watcom, StormC++, SAS/C++, dem Digital Mars Compiler, und die etlichen Compiler, die sonst noch nachweislich entwickelt wurden?Habe ich die Pflicht vernachlässigt, mich auf dem Laufenden zu halten, in dem ich erstmal davon ausgehe, dass leichter zu optimierende Dinge von mehr Compilern geschluckt wird, als schwierigere?
Oder warst Du etwas vorschnell, als Du diese Äußerung schriebst?Mr. N schrieb:
kompensierst das dadurch, dass du alle möglichen Leute beleidigst.
Wenn Du meinst...
Mr. N schrieb:
CStoll und Shade Of Mine sind - ganz im Gegensatz zu mir, das gebe ich gerne zu - nicht kindisch, sondern überaus konstruktiv und bereit zu einer ernsthaften Diskussion gewesen.
Stopp...!?
Du sagst, Du hast Dich hier kindisch verhalten. Das finde ich erstmal gut, das einzugestehen, das ist nämlich mal etwas Konstruktives, was von Dir kommt. Das kann ich respektieren.
Nimm's mir nicht übel, wenn ich diese Äußerung trotzdem konsequent weiterführe: Du sagst damit nämlich auch, dass es hier durchaus einen Forumskindergarten gibt: Leute, die kindisch sind.
Ergo kann meine Aussage, dass hier ein Forumskindergarten existiert keine Beleidigung sein, denn Du stimmst mir ja zu, dass hier Leute sind, die noch kindisch sind und führst Dich selbst als Beispiel an.Darf ich fragen, ob ein Meldung der "Unregistrierten" auch von Dir stammt und bekomme von Dir dann ein ehrliches "Nein"? Ich akzeptiere ein ehrliches "Nein", ich respektiere ein ehrliches "Ja".
CStoll und Shade haben sicherlich versucht konstruktiv zu diskutieren. Mit etlichen Ausrutschern, aber der Versuch wurde durchaus bemerkt, oder meinst Du ich texte hier über die ganze Zeit mit für den Schwachsinn, den die meisten Unregistrierten hier abladen? Wenn der Versuch nicht erkennbar wäre, wäre ich schon lange nicht mehr hier.
Und klar habe ich nicht immer die perfekte Laune, um ohne zynischen Kommentar jedem mit einem Lächeln den Kopf grade zu rücken. Du wirst also sicher auch böse Kommentare von meiner Seite finden, ich wage aber zu bezweifeln, dass Du etwas Nennenswertes findest, bevor ich beleidigt werde.
Mr. N schrieb:
Wider besseres Wissen, denn das ist mit dir nicht möglich.
Die Aussage ist mit einem Gegenbeispiel widerlegt und die gibt es zu genüge.
Du kannst mit mir nicht konstruktiv diskutieren. Das liegt natürlich an mir, denn Du bist derjenige, der grade behauptet hat, sich kindisch zu verhalten.
Steht der Bann in #cpp noch?Wenn Du Dich wie ein Erwachsener verhältst und mich darauf hinweisen kannst, dass Du dem Forumskindergarten entwachsen bist, dann habe ich kein Problem Dich neutral anzusprechen.
-
Xin schrieb:
CStoll schrieb:
"Wir" stellen uns oben an die Baugrube und sagen dem Gast, daß es hier gefährlich sein könnte - wenn er doch weitergehen will, bieten wir einen Sturzhelm an. Du wartest unten in der Baugrube und sagst den abstürzenden Gästen "Mit Helm wäre die Landung nicht so hart gewesen. Mag sein, daß das eine andere Einstellung von Sicherheit ist - aber ich will meinen Sturzhelm lieber bevor ich abgestürzt bin.
Hmm... das Beispiel klingt eher so, als würdest Du meine Gäste an den Haaren herbeiziehen, um sie dann in die Grube zu werfen und zu sagen, hättet ihr meinen Sturzhelm genommen, hättet ihr euch wenigstens nicht weh getan.
Nebenher definieren wir beide unsere Position nicht in der Grube.
Meine Position ist eher so: Augen auf, dann gewöhnt man sich an, um die Grube herum zu gehen. Und es gibt keinen Weg schneller zu lernen, dass man die Augen offen zu haben hat, als wenn man hier und da mal aus der Grube gekrabbelt kommt.
Meine Schüler schubse ich jede Grube. Dann machen sie den Fehler nochmal alleine, wissen aber selbst, dass und welchen Mist sie gebaut haben und dann achten sie darauf, diesen Mist nicht mehr zu bauen.Und wieviel Anlernzeit bekommt jemand zugewiesen, um alle Eigenheiten deines Systems zu verstehen?
Xin schrieb:
CStoll schrieb:
(btw, wenn du jeden, der nicht deiner Meinung bist, dem "Forumskindergarten" zuordnest, hilft das der Diskussion überhaupt nicht.
Das tue ich nicht. Ich sage, dass hier eine Menge Kiddies rumlaufen.
Ich wiederhole immer wieder, dass man meine Lösungen nicht nehmen muss. Ich bin sogar dafür, dass sich jeder etwas eigenes entwickelt.
An den expliziten Ctors kommt man trotzdem nicht vorbei.
Wen ich in den Forumskindergarten schicke, der stellt mit fehlender Kenntnis von Fachwissen und fehlernder Kenntnis über bereits Geschriebenes innerhalb Threads Behauptungen auf, die sich keinen inhaltlichen Wert (mehr) haben. Es macht einen Unterschied eine Möglichkeit zu diskutieren oder "FACTS" (unregistriert, aber afair als scrub kenntlich gemacht), die einfach mal in den Raum posaunt werden.Und genau auf dem Niveau, das du hier bei anderen kritisierst (nicht nur an unregistrierten), diskutierst du selber.
(die gelegentlichen [edit] sinnfreien [/edit] Einwürfe von unregistrierten hier im Thread nerven mich wohl genauso wie dich - aber ich bemühe mich, sie zu ignorieren.)
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Tut mir leid, Du bist etwa 10-20 Seiten zu spät. Die Lösung hatten wir schon.
Nur eine Randbemerkung zu deiner "Lösung" - sie ist herrlich mehrdeutig:
...Die Überladungsauflösung findet bei Aufruf A für den ersten Operanden Funktion 3 (exact Match - alle Alternativen erfordern eine Umwandlung zum Basistyp) und für den zweiten Operanden Funktion 2 (nach den selben Kriterien) - BUMM.
Bei Aufruf B greift zunächt Funktion 1b und anschließend hat der Compiler die Wahl zwischen Funktion 1a (exact Match für ersten Operanden) und 2a (exact Match für zweiten Operanden) - BUMM. (hier fällt der Fehler erst bei der Multiplikation auf - woher soll der Programmierer da wissen, daß er eigentlich schon viel früher aufgetreten ist?)Ich verstehe jetzt nicht, wo Du drauf hinaus willst?
Die Mehrdeutigkeit weist in C++ doch darauf hin, dass einer der Faktoren hakt. Also eigentlich hast Du damit doch genau das, was Du als fehlend kritisierst.
Afair kommen Dir dann nur noch die Fehlermeldung der Compiler in den Weg. Der GCC meckert bei derartigen Dingen zwar und nennt Möglichkeiten, sagt aber nicht warum es überhaupt geknallt hat.
Die Methode ist typsicher, denn sie ist nicht übersetzbar.Und dich sollte die Mehrdeutigkeit eher darauf hinweisen, daß etwas am grundlegenden Design nicht stimmt.
Xin schrieb:
Ich sehe Unit als die vorrangige Lösung an und erlaube den Rechenweg. Damit wird die Gleichung ausgerechnet, aber kann nicht zugewiesen werden. Ich löse also Typinformationen auf, um die Rechnung zu erlauben, was darin endet, dass ein Konflikt erst bei der Zuweisung entsteht: Es sind nicht mehr genug Typinformationen für eine typsichere Zuweisung vorhanden.
Damit bleibt es typsicher, weil auch das ist nicht übersetzbar.Ich wiederhole mich nur ungern aber:
- Arbeit ohne Typinformationen ist schlecht
- Typinformationen wegwerfen (und anschließend darauf hinweisen, daß keine mehr da sind), ist etwas besser - hier steht deine Lösung
- Typinformationen behalten (und nur auf Aufforderung wegwerfen), wäre optimal - dahin würdest du kommen, wenn du die implizite Umwandlung nach int (oder Unit) rausnehmen würdest
Xin schrieb:
CStoll schrieb:
(btw, wenn du darüber stolperst, daß man von int nicht ableiten kann - dann ersetze ich es gerne durch eine Pseudo-Int-Klasse)
Warum sollte ich jetzt meckern? Mein Part ist schließlich als Gedankenspiel von Möglichkeiten gestartet und nicht als C++-Produktivlösung. Das darf meinetwegen sogar noch ein Shade verwechseln, aber Du warst bei der Geburt des Gedankenspiels dabei... schon vergessen?
Und wieso betonst du dann in regelmäßigen Abständen, daß man in C++ nicht von int ableiten kann?
Xin schrieb:
Wir erinnern uns? Meine Produktivlösung ist ähnlich, aber nicht identisch und sie leitet logischerweise auch nicht von int ab.
Welche Produktivlösung? Die mit den Kiloweise Hilfsklassen, um einem Fenster mehrere Pixelmaße oder Orientierungspunkte geben zu können?
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Okay... ich gebe zu, dass ich gewisse Grundfähigkeiten als Voraussetzung ansehe, z.B. eine Expression zu debuggen, die inkompatible Typen aufweist. Ist ja nicht so, als wäre das ein Problem, dass in C++ sonst nie auftreten würde...
Selbst wenn der Compiler mitunter kryptische Fehlermeldungen bringt - sie sind jedenfalls genau an der Stelle, wo der Fehler aufgetreten ist - und nicht erst am Ende der gesamten Anweisung. (und nebenbei bist du auch ein Programmierer
Schonmal ein Semikolon vergessen und eine längere Dokumentations zwischen dem vergessenen Semikolon und anderem Code gehabt?
Inhalt der angegebenen Zeile: etwas wie "a = 7;", Fehlermeldung: Semikolon vergessen.
Genau an der Stelle, wo der Fehler aufgetreten ist? Nein, der Fehler lag ein paar Dutzend Zeilen dadrüber.
Fällt mir mal so auf die Schnelle ein, weil ich in meinen Compiler extra eingebaut habe, zum Token zurückzugehen, hinter dem das Semikolon zu erwarten wäre.Ja, niemand ist perfekt - aber in einer längeren Formel ist mir trotzdem eine Meldung "du kannst Längen und Gewichte nicht addieren" (bezogen auf einen Teilausdruck irgendwo in der Mitte) lieber als "du kannst einer Kraft keine nackte Unit zuweisen" (bezogen auf den Gesamtausdruck, bei dem der Compiler irgendwo aufgegeben hat, mit korrekten Einheiten zu rechnen).
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Shade Of Mine schrieb:
Unser Ziel ist es, korrekte Software zu schreiben. Wir tun deshalb alles was in unserer Macht steht um Fehler zu verhindern.
Wen bezeichnest Du denn mit "wir"? "Ihr", die gegen Xin texten?
Mit der Typsicherung habe ich hier angefangen und CStoll kritisierte es.Ja, ich habe kritisiert, daß du mit deinen Bemühungen nicht weit genug gehst.
Und nichts gebracht, was wirklich weiter gehen würde.
Doch, habe ich - du hast die entsprechenden Teile meiner Antwort(en) nur gekonnt überlesen.
Xin schrieb:
Der Punkt ist, dass Einheiten etwas statisches sind, man C++ aber nunmal schlecht beibringen kann, statische Informationen - also Typinformationen - zu verrechnen. Und solange C++ das nicht kann, wird man nicht umhinkommen, Klassen selbst zu erzeugen oder per Template erzeugen zu lassen und anschließend zu benennen, weil kein Mensch sich ein Templatemuster merken kann/will, dass für SI-Einheiten schon 7 Parameter braucht oder fünf Zeilen Deklaration um eine Variable anzumelden.
Typsicherheit ist in C++ aufwendig. Und den Mittelweg zwischen machbar und handhabbar zu finden ist eine Geschmackssache. Wie ich das sehe, sind wir uns mit unseren Ansätzen eigentlich einig, da wir mehr oder minder das gleiche tun.
OK, ich teile mal das Problem in zwei Teile auf:
- Erstens: Einzelne Klassen gegen Templatelösung?
Einzelne Klassen zu schreiben ist aufwendig und potentiell fehleranfällig - also dürfte die Lösung in beiden Fällen darauf hinauslaufen, die Klassen automatisiert (via Template) anzulegen. - Zweitens: Besteht eine Verwandschaft zwischen verscheidenen Größen-Klassen?
Hier besteht noch eine (vorsichtig ausgedrückt) Unstimmigkeit zwischen unseren Lösungsansätzen - bei mir sind die einzelnen Klassen unabhängig voneinander und interagieren nur über die vorgegebenen Operatoren, du siehst eine Verwandschaftsbeziehung und rechtfertigst damit, alle physikalischen Größen auf int bzw. Unit zurückzuführen.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Wieso gehst Du nicht darauf auf die Zeile ein, wo ich Dir leider vorrechnen muss, dass Meter/Meter (wenn ich Deinen Tippfehler also korrigiere) im Template leider immernoch typlos ist, Deinem Posting also komplett die Grundlage fehlt?
Warum regst Du Dich darüber auf, dass man sich über Deine Fehler amüsiert, aber nicht darüber, dass Du meine Zeit verschwendest, weil Du nicht nachgedacht hast, bevor Du etwas gepostet hast, was nicht mehr als einen Tippfehler enthielt?Meter/Meter ist nicht typlos, sondern nur einheitenlos - etwas typloses hast nur du daraus gemacht.
Bei Dir war's unit<0,0,0,0,0,0,0>, bei mir heißt's nur unit. In beiden Fällen haben wir einen Typen, der nichts aussagt. Zumindest nicht Meter/Meter. Horray.
Winkel kann man auch durch kgm/s²/(kgm/s²) ausdrücken. Welche Einheiten darf man - obwohl sie sowieso gekürzt sind, ignorieren, welche müssen selbst gekürzt drin bleiben, damit es einheitenlose Winkel ergeben?Der Quotient zweier (gleichartiger) Größen ist nunmal ein (einheitenloses) Größenverhältnis, das kannst du drehen und wenden wie du willst. Das ist möglicherweise eine Grenze der Physik, aber wenn alle Einheiten rausgekürzt sind, bleibt wirklich nur eine nackte Zahl zurück (der kannst du von mir aus ein 'rad' oder 'dB' dranschreiben, aber effektiv bleibt's eine nackte Zahl).
Xin schrieb:
Vielleicht war Dir aufgefallen, dass ich typsichere Versionen von cos usw. forderte, die Winkelgrade (ob die jetzt mit 0..2Pi oder Winkelgrade oder gon dargestellt werden, who cares) übergeben bekommen würden => expliziter Konstruktor => typsicher => Meter * Kg ist kein Winkelmaß => Compilermecker.
OK, was du vorne in cos() reinsteckst bzw. hinten aus acos() herausbekommst, ist ein Winkel. Aber in welcher Einheit misst du den Cosinus eines Winkels?
Xin schrieb:
Ich mache nicht das gleiche - ich frage den Programmierer, ob er wirklich mit nackten int-Werten hantieren will.
Ich lasse ihn und verbiete ihm die implizite Zuweisung. Das Ergebnis ist, dass er sich damit auseinandersetzen muss, wie er etwas ausdrückt, um zuweisen zu können. Solange er nur rumrechnet und nichts zuweist, kann er keinen Programmfehler auslösen.
5+Meter( 4 );ist eine gültige Anweisung und selbst wenn Dir das nicht gefällt und Du sagst, es ist nicht typsicher... den Compiler interessiert es nicht, die Anweisung ist sinnlos, legal und ungefährlich.
Ich greife nur an dem Punkt ein, wo es gefährlich werden kann: der Zuweisung.
[/quote]Hast du mal daran gedacht, daß dieser Ausdruck nur selten alleine in der Landschaft steht? Wenn du Glück hast, prallst du mit dem Ergebnis dieser Addition ein paar Zeilen weiter an eine Mehrdeutigkeit (siehe oben) oder an eine (durch den expliziten Ctor) verbotene Zuweisung - aber irgendwer schafft es mit Sicherheit, sie so in eine größere Formel einzubauen, daß sie fehlerfrei übersetzt wird (und dann technisch unsinnige Werte liefert).Xin schrieb:
CStoll schrieb:
Xin schrieb:
Mal ehrlich, Jungs, kaum einer hat sich wirklich mit dem auseinandergesetzt, was ich geschrieben habe. Ich lese es ja an den Antworten.
Wozu das? Du setzt dich schließlich auch nicht mit dem auseinander, was wir geschrieben haben. Du hast auf den letzten Seiten nur EINE Bemerkung als echtes Argument anerkannt - und durch deine "Verbesserung" auch nur an den Sysmptomen herumgepfuscht, anstatt dir die Ursachen der (von dir akzeptierten) Schwachstelle anzusehen.
Ich schaue mir die Schwachstellen sehr genau an. Ich sehe allerdings nicht, dass irgendwer etwas angebracht hat, was sicherer ist. Hier und da etwas andere Syntax, ich konzentriere mich auf die Zuweisung, Du schränkst alles ein, aber im Endeffekt kommt nicht mehr raus. Wenn Gefahr droht, schlagen wir beide Alarm und der Entwickler muss sich klarer ausdrücken.
Sich falsch ausdrücken kann er in beiden Fällen. Das werfe ich Dir nicht zur Last, weil das kein Argument wäre, wieso sollte ich derartiges als Argument anerkennen?Wenn du deine Formeln tasächlich runterbrichst bis auf die Form "a = b op c;", dann macht es tatsächlich keinen Unterschied, ob du jetzt die Zuweisung verhinderst oder die Rechenoperation. Aber die wenigsten Anwender werden das so machen - und dann macht es doch einen Unterschied, WO in einem Ausdruck der Fehler entdeckt wird.
Xin schrieb:
Wie ich schon sagte, wir werden hier nicht weiterkommen, denn wir sind an einer Grenze von C++. Und weil wir nicht weiterkommen und keiner außer mir seinen Willen bekommt, fliegen die Beleidigungen durch die Gegend - wobei ich natürlich derjenige gewesen bin, der andere auf's schärfste angegangen ist und vor allem damit begonnen hat.
Warum bekomme grade ich meinen Willen? Weil ich nie etwas Perfektes versprochen habe. Weil ich eigentlich überhaupt nie etwas versprochen habe, da ich die ganze Zeit mit einem Gedankenspiel in diesem Thread arbeite, das Du mir auferlegt hast: "Wo könnte eine Ableitung von int Sinn haben?".
Du hast das Gedankenspiel wieder auf C++ Syntax gebracht, es weiter eingeschränkt, aber niemand konnte ihm etwas wichtiges hinzufügen. Jemand brachte die theoretisch perfekte Lösung, die aber nicht handhabbar ist.Ja, du hast ein Beispiel gebracht, wo du eine Ableitung von int sehen könntest. Aber um es mal auf den Punkt zu bringen: Du hast bisher niemanden hier davon überzeugt, daß diese Ableitung irgendeinen Vorteil bringen würde. Und wenn du es noch nichtmal bei "uns" schaffst, sehe ich schwarz für das ISO-Kommitee.
-
@Xin: Vorsicht, wirf mir nicht vor, nicht konstruktiv zu diskutieren, das will ich gar nicht.
Xin schrieb:
Mr. N schrieb:
Xin schrieb:
Als schäbiger FH-Absolvent, kömmt mein Ego ganz gut mit der Kritik der Uni-Studenten zurecht - ich habe die Postings ja gelesen.
Offensichtlich kommst du mit der Kritik nicht zurecht. Wunderst dich ja sogar, dass nicht alle über deine Beleidigungen lachen. Und konterst mit noch mehr Beleidigung.
?
Wo beleidige ich hier denn schon wieder? Und wieso sollte irgendwer über Beleidigungen lachen, ich mich darüber wundern!? Willst Du auf "Grüße vom Planeten Erde" raus? Darüber konnte ich lachen, das reicht mir vollkommen und das Posting hatte es definitiv verdient veräppelt zu werden, zumal ich auch ernsthaft argumentiert habe. Als Beleidigung sehe ich das nicht, wer Winkel in Quadratmetern rechnet, muss auch mit entsprechenden Comments rechnen.Auch wenn du das nicht Beleidigung nennen willst, es ist eine. "Comments"... was für ein herrlicher Versuch, die wahre Bedeutung hinter einem Anglizismus zu verstecken!
Xin schrieb:
Mr. N schrieb:
Zum Thema "Wissen, das man nicht braucht"... wer nutzt enum-Klassen, weil er denkt, enum wäre nicht typsicher?
Keine Ahnung, ich nutze enum äußerst selten, weil sie keinen Namensraum erzeugen. Außerdem - und das habe ich in diesem Thread erfahren, sind sie nur in C mit int typisiert. Deswegen sind sie dennoch nur bedingt einsetzbar, denn sie erzeugen immernoch keinen eigenen Namensraum.
Du hättest selber wissen müssen, dass enums nicht mit int typisiert sind. Das ist "Basiswissen C++".
Xin schrieb:
Mr. N schrieb:
Wer glaubt, ein C++-Optimierer könne nicht optimieren, was erwiesenermaßen optimiert wird? Du hast deine Pflicht, dich auf dem laufenden Stand zu halten sträflich vernachlässigt und ...
Du übernimmst also die Garantie, dass "ein" C++-Optimierer das (was war's noch gleich?) erwiesenermaßen optimieren kann.
Was ist "ein"? Irgendein? Gilt das für genau einen oder alle? Und wenn es nur für einen gilt, dann ist es kein C++ Optimierer, sondern ein GCC-C++-Optimierer.
Garantierst Du die Optimierung für GCC, Intel, MSVC, Watcom, StormC++, SAS/C++, dem Digital Mars Compiler, und die etlichen Compiler, die sonst noch nachweislich entwickelt wurden?Wenn ein Compiler schlechter ist als ein anderer, dann nehme ich eben den besseren. Also reicht es, zu wissen, dass GCC das kann. Bei anderen Compilern kann ich es nicht prüfen, da ich sie nicht habe.
Wenn dir das nicht reicht, prüf es selber! Du hast deine Aussage, dass Division nicht optimierbar sei, selbst zu belegen, ich muss sie nicht für jeden einzelnen Compiler widerlegen.
Xin schrieb:
Habe ich die Pflicht vernachlässigt, mich auf dem Laufenden zu halten, in dem ich erstmal davon ausgehe, dass leichter zu optimierende Dinge von mehr Compilern geschluckt wird, als schwierigere?
Es ist nicht erwiesen, dass der Ausdruck wirklich schwerer zu optimieren ist.
Xin schrieb:
Oder warst Du etwas vorschnell, als Du diese Äußerung schriebst?
Nein.
Xin schrieb:
Mr. N schrieb:
CStoll und Shade Of Mine sind - ganz im Gegensatz zu mir, das gebe ich gerne zu - nicht kindisch, sondern überaus konstruktiv und bereit zu einer ernsthaften Diskussion gewesen.
Stopp...!?
Du sagst, Du hast Dich hier kindisch verhalten. Das finde ich erstmal gut, das einzugestehen, das ist nämlich mal etwas Konstruktives, was von Dir kommt. Das kann ich respektieren.
Gut, nur ich kann dich nicht respektieren.
Xin schrieb:
Nimm's mir nicht übel, wenn ich diese Äußerung trotzdem konsequent weiterführe: Du sagst damit nämlich auch, dass es hier durchaus einen Forumskindergarten gibt: Leute, die kindisch sind.
Ergo kann meine Aussage, dass hier ein Forumskindergarten existiert keine Beleidigung sein, denn Du stimmst mir ja zu, dass hier Leute sind, die noch kindisch sind und führst Dich selbst als Beispiel an.Dreh nicht deine eigenen Worte im Mund herum. Du hast nicht nur mir, sondern allen vorgeworfen, ein Kindergarten zu sein. Pauschal. Und das ist eine Beleidigung.
Xin schrieb:
Darf ich fragen, ob ein Meldung der "Unregistrierten" auch von Dir stammt und bekomme von Dir dann ein ehrliches "Nein"? Ich akzeptiere ein ehrliches "Nein", ich respektiere ein ehrliches "Ja".
Ja, eine Aussage eines Unregistrierten stammt von mir, aber bei weitem nicht alle. (Ich saß an einem Rechner, an dem ich mich nicht unbedingt einloggen wollte, zuhause schreibe ich immer als Registrierter.)
Xin schrieb:
CStoll und Shade haben sicherlich versucht konstruktiv zu diskutieren. Mit etlichen Ausrutschern,
Nein, ohne Ausrutscher. Du bist ausgerutscht. (Und von mir reden wir einfach gar nicht, ok?)
Xin schrieb:
aber der Versuch wurde durchaus bemerkt, oder meinst Du ich texte hier über die ganze Zeit mit für den Schwachsinn, den die meisten Unregistrierten hier abladen? Wenn der Versuch nicht erkennbar wäre, wäre ich schon lange nicht mehr hier.
Von wegen. In anderen Threads hast du gleich mehrfach behauptet, nicht mehr da zu sein, und es kam immer noch eine Antwort von dir.
Xin schrieb:
Und klar habe ich nicht immer die perfekte Laune, um ohne zynischen Kommentar jedem mit einem Lächeln den Kopf grade zu rücken.
Rücke dir lieber selbst den Kopf gerade. "Zynisches Kommentar" werte ich als Euphemismus für "Beleidigung".
Xin schrieb:
Du wirst also sicher auch böse Kommentare von meiner Seite finden, ich wage aber zu bezweifeln, dass Du etwas Nennenswertes findest, bevor ich beleidigt werde.
Ich werde deine inhaltslosen Romane nicht durchforsten.
Xin schrieb:
Mr. N schrieb:
Wider besseres Wissen, denn das ist mit dir nicht möglich.
Die Aussage ist mit einem Gegenbeispiel widerlegt und die gibt es zu genüge.
Du kannst mit mir nicht konstruktiv diskutieren. Das liegt natürlich an mir, denn Du bist derjenige, der grade behauptet hat, sich kindisch zu verhalten.
Steht der Bann in #cpp noch?Genau das meine ich. Dieser exemplarische Seitenhieb tut nichts zur Sache und zeigt, dass man mit dir nicht diskutieren kann.
Xin schrieb:
Wenn Du Dich wie ein Erwachsener verhältst und mich darauf hinweisen kannst, dass Du dem Forumskindergarten entwachsen bist, dann habe ich kein Problem Dich neutral anzusprechen.
Selbstreflektion ist nicht dein Ding?
---------
CStoll schrieb:
(die gelegentlichen Einwürfe von unregistrierten hier im Thread nerven mich wohl genauso wie dich - aber ich bemühe mich, sie zu ignorieren.)
Da einige Unregs (und nicht nur mein Post als Unreg) durchaus sinnvolle Dinge gesagt haben, ist das kontraproduktiv.
-
Mr. N schrieb:
CStoll schrieb:
(die gelegentlichen Einwürfe von unregistrierten hier im Thread nerven mich wohl genauso wie dich - aber ich bemühe mich, sie zu ignorieren.)
Da einige Unregs (und nicht nur mein Post als Unreg) durchaus sinnvolle Dinge gesagt haben, ist das kontraproduktiv.
OK, wenn du das in den falschen Hals bekommen hast, entschuldige ich mich - und präzisiere meine Aussage: Ich bezog mich nicht auf alle unregistrierten, die sich hier geäußert haben, sondern auf so "sinnvolle" Beiträge wie "aha, mhm, aah, ich merke." - oder "[Zitat vom Vorgänger]
". Xin schien solche Einwürfe sehr persönlich zu nehmen.(PS: Seitdem ich hier einen Account habe, habe ich nicht mehr als unreg gepostet - soviel Zeit habe ich noch, daß ich micht vor einer Antwort einloggen kann)
-
CStoll schrieb:
(PS: Seitdem ich hier einen Account habe, habe ich nicht mehr als unreg gepostet - soviel Zeit habe ich noch, daß ich micht vor einer Antwort einloggen kann)
Vielleicht will man nicht überall seine Login-Daten und Cookies rumliegen lassen? Naja, was solls.
-
Mr. N schrieb:
@Xin: Vorsicht, wirf mir nicht vor, nicht konstruktiv zu diskutieren, das will ich gar nicht.
du willst nicht konstruktiv diskutieren
-
Xin schrieb:
Das ist nicht notwendig, aber es ist wirklich leichter Professionalität zu erreichen, indem man Halbwissen über Programmierung abschaltet - ob durch entsprechende Bildung oder indem man wirklich eine Grenze einbaut, die man man als Professioneller problemlos überschreiten kann und als Halbwissender nicht überschreiten möchte.
Professionalität erreicht man dadurch, in dem man lernt, 1000 Codezeilen gleichzeitig zu überblicken und nicht durch "immer nur eine zur Zeit".
Xin schrieb:
Nein, nicht alles.
Aber an das, was besser war, könnte man sich gelegentlich erinnern und sich fragen, warum hat sich das verschlechtert?Aber Du solltest das "früher" nicht so weit nach hinten setzen. "Früher" heisst heute bereits "Vor 2 Jahren" und nicht "Vor 20 Jahren".
Xin schrieb:
Fortschritt bedeutet eben auch Rückschritt zu vermeiden und dafür muss nunmal in beide Richtungen schauen.
Fortschritt bedeutet immer "Rückschritt vermeiden".
-
Undertaker schrieb:
Mr. N schrieb:
@Xin: Vorsicht, wirf mir nicht vor, nicht konstruktiv zu diskutieren, das will ich gar nicht.
du willst nicht konstruktiv diskutieren
Das war nicht auf dich bezogen.
- Deine Meinung ist zwar oft das genaue Gegenteil von meiner, aber du hast noch nie jemanden beleidigt, wenn ich mich richtig erinnere.
-
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Wir haben das, was ich vorgeschlagen habe, als Grenze des praktisch machbaren, vor ~15 Seiten im Detail durch Unit verbessert. Wir haben CStolls Klassen, die gleichwertig sind. Er macht das gleiche wie ich, er erzeugt sie nur über ein Template. Ich habe nie verboten, meine Klassen per Template zu erzeugen.
Wir haben eine theoretisch perfekte Lösung.Ich mache nicht das gleiche - ich frage den Programmierer, ob er wirklich mit nackten int-Werten hantieren will.
Ich lasse ihn und verbiete ihm die implizite Zuweisung. Das Ergebnis ist, dass er sich damit auseinandersetzen muss, wie er etwas ausdrückt, um zuweisen zu können. Solange er nur rumrechnet und nichts zuweist, kann er keinen Programmfehler auslösen.
5+Meter( 4 );ist eine gültige Anweisung und selbst wenn Dir das nicht gefällt und Du sagst, es ist nicht typsicher... den Compiler interessiert es nicht, die Anweisung ist sinnlos, legal und ungefährlich.
Ich greife nur an dem Punkt ein, wo es gefährlich werden kann: der Zuweisung.In Hoffnung ...
Du sagst es ja selbst, du kontrollierst nur bei der Zuweisung, indem du dich auf explicit CTors beschränkst. Man hat somit nur die Kontrolle das irgendein Typ verloren gegangen ist.
Bei Variante B (Shade/CStoll) bekommt man die Information wann, wo, welcher Typ verloren geht.Wenn also der Verlust eines Typs zu einem falschen Ergebnis führt, dann wird das bei Variante B (Shade/CStoll) immer bemerkt, bei dir aber nur, wenn eine explizite Zuweisung vorher nicht nötig war.
Beispiel (altbekannt):
Unit() u = Baum(4) + Haus(3) + Sonstiges(5) + Millimeter(4) + Unit(3) + Meter(4)
Die Zuweisung macht man immer, weil man durch Baum(4) + Haus(3) schon den Typ verloren hat, dass auch der Typ Millimeter(4) verloren geht kann übersehen werden, weil vom Compiler nicht bemängelt.
Bei Variante B bekommt man zu jedem einzelnen Typverlust einen passenden Fehler.Dein Gegenargument ist es zu sagen Millimeter und Meter sind dann total schlecht und sowas macht man nciht, falsches Design ... bla.
Dazu das Argument, dass der Programmierer ja drauf achten muss und es schon genug Deppen gibt die programmieren. Man muss halt darauf achten welcher Typ verloren geht.Der Punkt ist aber, dass Millimeter/Meter nur ein Beispiel dafür ist, dass es einen Unterschied geben kann zwischen:
1: TypA(3) + TypA(3) + Unit(0)
2: TypA(3) + Unit(0) + TypA(3)
Sobald 1 und 2 unterschiedliche Ergebnisse liefern ist eine potentielle Fehlerquelle geboren.
Wie gesagt, Millimeter/Meter war nur ein Beispiel dafür, dass ein Typverlust zu einem falschen Ergebnis führen kann und das Beispiel ist dazu noch sehr sehr einfach gehalten.Folglich:
Eine Beschränkung auf Typen, bei denen 1 und 2 das selbe Resultat liefern (also auf Typen, bei denen ein Typverlust zu keinem falschen Ergebnis führt), oder die ehrenvolle Aufgabe keinen Typenverlust zu übersehen, nehme ich nicht hin, wenn eine Variante B (CStoll/Shade) existiert die damit keine Probleme hat und mich rundum versorgt!
Warum sollte man das auch?
Und wieso ist deine Variante dennoch das beste was wir hier haben?
-
Ich antworte mal kurz für Xin auf Tellerrand...
Such dir was aus:
Antwort 1: Es kann aber nicht zugewiesen werden und ist damit typsicher!
Antwort 2: Und auch du hast den expliziten Konstruktor nicht verstanden!
Antwort 3: Ihr habt gar nix!
Antwort 4: Kindergarten!
-
Xin ist für mich ein heißer Anwärter auf den "Troll des Jahres 2007" Award
-
Kleine Korektur:
Unit() u = Unit(Baum(4) + Haus(3) + Sonstiges(5) + Millimeter(4) + Unit(3) + Meter(4))
sollte es natürlich sein.
-
Tellerrand schrieb:
Kleine Korektur:
Unit***()*** u = Unit(Baum(4) + Haus(3) + Sonstiges(5) + Millimeter(4) + Unit(3) + Meter(4))
sollte es natürlich sein.Du meinst eher das?
Unit u = Unit(Baum(4) + Haus(3) + Sonstiges(5) + Millimeter(4) + Unit(3) + Meter(4));
