Methoden mit bool-Parametern und "Lesbarkeit" im Kontext
-
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));
-
Mr. N schrieb:
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. :)...
ich weiss, aber dein posting kam so rüber, als hätte dir Xin extrem auf den schlips getreten (ja fast schon gesprungen).
immer schön --> <-- bleiben.
-
Mr. N schrieb:
Du meinst eher das?
[...]Ja, so wäre es natürlich ordentlich.
Habe halt den CTor vergessen und der ist ja wichtig
-
Xin schrieb:
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.
Das war eigentlich ein kleines Wortspiel, das ich ganz witzig fand.
Xin schrieb:
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.
Nicht "jeder", sondern Du- weil Du ihn ja sicher im Channel gelesen hast, als Du Dich dort wie ein verkleidetes Kind in den Kindergarten geschlichen hast.
Außerdem spielt hier für niemanden die Personenzahl eine große Rolle. Wäre Deine Argumentation überzeugend, störte sich niemand daran, daß Du allein bist. Aber Du überzeugst eben nicht mit Unkenntnis von enum oder mit dem immer noch im Raum stehenden Wortwechsel (CStoll)"Fenster haben Flags, sind aber keine Flags" - (Xin)"Man kann sich vieles von verschiedenen Perspektiven ansehen. Ich würde mich an Deiner Stelle nicht so allgemeingültig festlegen." -> (mathematiklegasthenisch veranlagter Informatiker[1])"Schon die Voraussetzungen sind falsch."[1] Jester
-
CStoll schrieb:
Und wieviel Anlernzeit bekommt jemand zugewiesen, um alle Eigenheiten deines Systems zu verstehen?
Da ich eigentlich immer das selbe mache, ist das Framework eigentlich ganz gut gelungen.
Da es eigentlich aber eh nur die Test-Version darstellt, bin ich für die Final eigentlich optimistisch.CStoll schrieb:
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.
Werde ruhig konkreter, ich höre zu.
CStoll schrieb:
(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.)
Das ist einfacher, wenn man für toll erklärt wird statt beleidigt. ^^
CStoll schrieb:
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.[/quote]In C++ sicherlich. In der prinzipiellen Möglichkeit sicherlich nicht.
CStoll schrieb:
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?
Um darauf hinzuweisen, dass ich nicht ausschließlich von C++ spreche? Dass Du ein Gedankenspiel angeleiert und dann kritisiert hast?
Weil Gedankenspiel und reine C++ Programmierung laufend durcheinander geworfen werden?CStoll schrieb:
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).
Ich hab's mal ausprobiert. Der GCC liefert die Fehlermeldung jedenfalls nicht... der sagt "Geht nicht", such Dir eine Alternative aus folgnden operator Überladungen aus... <Liste>.
Das hilft jetzt nicht wirklich weiter.CStoll schrieb:
Und nichts gebracht, was wirklich weiter gehen würde.
Doch, habe ich - du hast die entsprechenden Teile meiner Antwort(en) nur gekonnt überlesen.[/quote]
Was war denn so wichtig, dass ich es trotzdem überlesen habe?CStoll schrieb:
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.Dann wiederhole ich mal, dass ich nicht verbiete, meine Klassen per Template zu erzeugen.
CStoll schrieb:
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.Ich sehe eine "Verwandtschaft" darin, dass Objekte zählbar sind.
CStoll schrieb:
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).
Wem erzählst Du das? Schreib das denjenigen, die aus Deinen Templates eine Einheit "Meter/Meter" hevorzaubern.
CStoll schrieb:
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?
In der Einheit, die das Ergebnis der cosinus-Funktion bringt...?
Keine...
Was für eine Frage...<kopfschüttel>CStoll schrieb:
Xin schrieb:
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.Hast du mal daran gedacht, daß dieser Ausdruck nur selten alleine in der Landschaft steht?
Yepp... und weil man nichts verändern kann, spielt es bei der Typsicherung keine Rolle.
CStoll schrieb:
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.
*lach*, ich habe nie gesagt, dass es einen Vorteil hätte.
Ich bin derjenige, der sagt, dass Komposition und Ableitung gleichwertig ist.
Ableitungen braucht kein Mensch, um irgendwas zu programmieren.
Du kannst absolut alles mit Komposition ausdrücken. Und du kannst auch alles in Ableitungen ausdrücken.
Ableitung ist eine Möglichkeit, die eine andere Sicht auf einen Datensatz erlaubt. Es ist ein Wechsel der Perspektive, nicht der Möglichkeiten.
Ob Du Ableitungen als Vorteil ansiehst...
Die Ableitung von int erlaubt die Sicht auf die Zahl, was die so Komposition so nicht erlaubt.
Und was das ISO-Komitee davon hält kann ich Dir sagen: man kann es durch eine Zwischenklasse abbilden und alles bereits abzubilden ist, wird nicht eingeführt oder geändert.
Ich persönlich halte von einer Sonderregelung für Primitive nichts; ich halte allgemein nichts von Sonderregelungen. Das Fehlen von Sonderregelungen vereinfacht eine Sprache.Mr. N schrieb:
@Xin: Vorsicht, wirf mir nicht vor, nicht konstruktiv zu diskutieren, das will ich gar nicht.
Ich finde die Information recht ehrlich am Anfang Deines Postings. Du hast bewiesen, dass ich meine Aussage über den Forumskindergarten korrekt ist und entziehst damit jedem die Grundlage, der sich darüber beschwert, dass ich das so offen anspreche.
Deine Form von Ablehnung stützt meine Aussagen, wieso sollte ich gegen jemanden vorgehen, der meine Aussagen so eindeutig belegt?Tellerrand schrieb:
Xin schrieb:
Ich greife nur an dem Punkt ein, wo es gefährlich werden kann: der Zuweisung.
In Hoffnung ...
...
Tellerrand schrieb:
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.Wie ich schon sagte - den Punkt halte ich für eine Geschmackssache. Ich halte eine Typkonvertierung auf einen Basistyp nicht zwangsläufig für einen Fehler. Also warte ich hier erstmal und gucke, was passiert.
Die Möglichkeit ist zum einen nicht verkehrt und zum anderen interessant.Tellerrand schrieb:
Dein Gegenargument ist es zu sagen Millimeter und Meter sind dann total schlecht und sowas macht man nciht, falsches Design ... bla.
Ich "blahte", dass mehrere Klassen für einen Zweck redundant sind. Redundanz ist in meinen Augen ein Designmangel, daher sollte Millimeter() eine Funktion, die auf Meter umrechnet, und kein Konstruktor sein - wie immer "Meter" auch implementiert ist.
Tellerrand schrieb:
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.Kommt doch in beiden Unit(6) raus? Keine unterschiedlichen Ergebnisse, also keine potentielle Fehlerquelle!?
Tellerrand schrieb:
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?Was die Typsicherheit angeht, macht CStoll das gleiche wie ich. Das ist gleichwertig. Mehr geht nicht. Wir kompilieren beide falsche Typzuweisungen nicht.
Was die Reihenfolge der Kombinationen angeht, erlaube ich mehr als CStoll. Die Ableitungen erlauben das. Ich finde das nicht schlimm, eigentlich sogar interessant, weil es eben das Zählen von Objekten erlaubt.
Ihr seht das anders, kein Problem. Es ist eine Geschmackssache.
Typsicher ist beides. CStoll löst es über die Komposition, ich über die Ableitung. Andere Unterschiede gibt es nicht.Tellerrand schrieb:
Kleine Korektur:
Unit u = Unit(Baum(4) + Haus(3) + Sonstiges(5) + Millimeter(4) + Unit(3) + Meter(4))
sollte es natürlich sein.Unter Berücksichtigung der von mir genannten Funktion Millimeter() kommt u = 19.004 Unit raus, unabhängig davon, ob Du Unit explizit aufführst oder nicht. (Natürlich nicht, wenn die Basis wirklich int wäre, dann käme 19 raus).
scrub schrieb:
Xin schrieb:
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.
Nicht "jeder", sondern Du- weil Du ihn ja sicher im Channel gelesen hast, als Du Dich dort wie ein verkleidetes Kind in den Kindergarten geschlichen hast.
Nopes, ich kannte ihn nicht.
Bevor Du mir die E-Mail geschrieben hast, wo Du Dich auch unter Deinem anderen Nick geoutet hast, wußte ich nicht, dass Du mehr als einen Nick verwendest. Ich habe nur den Bildschirm hier, keine Kristallkugel. Und ich führe auch nicht Buch über jeden einzelnen Nick, also nehme ich Dich mit einem anderen Nick als neue Person wahr.scrub schrieb:
Außerdem spielt hier für niemanden die Personenzahl eine große Rolle.
Posten hier mehr Nicks als Personen, dann verschiebt sich das Meinungsverhältnis.
Damit verliert auch die "wir"-Schreibweise an Wert, weil gar nicht mehr geklärt ist, wieviele "wir" eigentlich sind.
Ich poste hier ausschließlich unter diesem einem Nick. Du unter verschiedenen, was ich für ziemlich daneben halte. Inzwischen schreibst Du Deinen Namen drunter, was die Sache immerhin nachvollziehbar macht - so witzig finde ich es deswegen nicht.
-
Xin schrieb:
Mr. N schrieb:
@Xin: Vorsicht, wirf mir nicht vor, nicht konstruktiv zu diskutieren, das will ich gar nicht.
Ich finde die Information recht ehrlich am Anfang Deines Postings. Du hast bewiesen, dass ich meine Aussage über den Forumskindergarten korrekt ist und entziehst damit jedem die Grundlage, der sich darüber beschwert, dass ich das so offen anspreche.
Deine Form von Ablehnung stützt meine Aussagen, wieso sollte ich gegen jemanden vorgehen, der meine Aussagen so eindeutig belegt?Du kannst MIR "Kindergartenverhalten" vorwerfen, ABER NICHT DEM FORUM.
