Methoden mit bool-Parametern und "Lesbarkeit" im Kontext

[Mr. N]

Undertaker schrieb:

Mr. N schrieb:

Es geht hier schon ewig um Typsicherheit. Wobei man sagen muss dass deine Sicht wenigstens verständlicher ist als die von Xin.

vielleicht liegt's daran, dass wir beide einfache menschen sind und deshalb leichter einen konsens finden können, als in abstrakten sphären schwebende informatiker wie shady, Xin und CStoll

(Konsens?)

Undertaker schrieb:

wobei ich allerdings eingestehen muss, dass Xin's postings eine gewisse bewusstseinserweiternde wirkung haben, wenn man die 'richtigen filter' einschaltet.

Verstehe ich "bewusstseinserweiternd" richtig? :p

Undertaker schrieb:

merker schrieb:

Undertaker schrieb:

reale programmierer frickeln und tricksen dass sich die balken biegen. jede beschränkung, die deine lib ihnen entgegensetzt, entfacht ihren sportlichen ehrgeiz.

Muss ja voll abgehen in eurer Firma.

ja, ist echt so. kunde XY will unbedingt 'gleich morgen' eine spezielle funktionalität haben und dann kriegt er das einfach. nicht selten bekamen wir folgeaufträge, weil wir schnell und unbürokratisch kundenwümsche erfüllten. wie schäbig die software gefrickelt ist, interessiert keinen, solange sie zuverlässig das tut, was sie tun soll.
ich persönlich finde das auch nicht gut und arbeite lieber an grösseren systemen, bei denen mehr 'architektur' gefragt ist.
aber was will man machen? kleine firma, der kunde ist könig und 'time is money'

Für sowas find ich Perl gut.

[Undertaker]

Mr. N schrieb:

Undertaker schrieb:

Mr. N schrieb:

Es geht hier schon ewig um Typsicherheit. Wobei man sagen muss dass deine Sicht wenigstens verständlicher ist als die von Xin.

vielleicht liegt's daran, dass wir beide einfache menschen sind und deshalb leichter einen konsens finden können, als in abstrakten sphären schwebende informatiker wie shady, Xin und CStoll

(Konsens?)

na, wir bräuchten jedenfalls keine ~30 seiten

Mr. N schrieb:

Undertaker schrieb:

wobei ich allerdings eingestehen muss, dass Xin's postings eine gewisse bewusstseinserweiternde wirkung haben, wenn man die 'richtigen filter' einschaltet.

Verstehe ich "bewusstseinserweiternd" richtig? :p

also, wenn du so fragst - sicherlich nicht.

Mr. N schrieb:

Undertaker schrieb:

merker schrieb:

Undertaker schrieb:

reale programmierer frickeln und tricksen dass sich die balken biegen. jede beschränkung, die deine lib ihnen entgegensetzt, entfacht ihren sportlichen ehrgeiz.

Muss ja voll abgehen in eurer Firma.

ja, ist echt so. kunde XY will unbedingt 'gleich morgen' eine spezielle funktionalität haben und dann kriegt er das einfach. nicht selten bekamen wir folgeaufträge, weil wir schnell und unbürokratisch kundenwümsche erfüllten. wie schäbig die software gefrickelt ist, interessiert keinen, solange sie zuverlässig das tut, was sie tun soll.
ich persönlich finde das auch nicht gut und arbeite lieber an grösseren systemen, bei denen mehr 'architektur' gefragt ist.
aber was will man machen? kleine firma, der kunde ist könig und 'time is money'

Für sowas find ich Perl gut.

viel spass mit perl auf 'nem 16-bitter mit 8K RAM.

[Mr. N]

Undertaker schrieb:

Mr. N schrieb:

Für sowas find ich Perl gut.

viel spass mit perl auf 'nem 16-bitter mit 8K RAM.

Ne, da passen die Dateien, die ich verarbeiten soll, nicht rein.

[Xin]

Shade Of Mine schrieb:

Xin, du hast eine komplett andere Vorstellung von Typsicherheit (oder Physik) als jeder andere Mensch den ich kenne.

Dann kennst Du die falschen Menschen oder wohnst vielleicht auch in einem anderen Universum.

Shade Of Mine schrieb:

Dir wurden eine Menge Nachteile deines Systems gezeigt - du hast uns allesamt dafür beleidigt und die hälfte aller Argumente ignoriert.
...
Ich bin es deshalb langsam leid, dass du alle Argumente immer vollkommen ignorierst...

Mir wurde vor allem nichts besseres präsentiert. Folgerichtig ignoriere ich merkwürdige Behauptungen. In diesem Posting kannst Du Dich noch nichtmals darauf einigen, ob ich "alle Argumente vollkommen" oder nur "die Hälfte" ignoriere.
Wenn Du nicht mitgezählt hast, ich habe genau ein Argument anerkannt und bin ihm durch die Einführung der Klasse Unit gefolgt. Den Rest der Diskussion kannst Du so wie sie ist in die Tonne kloppen.

Shade Of Mine schrieb:

...und nur behauptest wir alle haben keine Ahnung.

Ich behaupte, dass Du nicht weißt, wovon Du sprichst und Du hast es wiederholt belegt.
Also würde ich sagen, wir sind uns in diesem Punkt einig.

Shade Of Mine schrieb:

Wikipedia schrieb:

Typsicherheit bezeichnet den Zustand (einer Programmausführung), bei dem die Datentypen gemäß ihren Definitionen in der benutzten Programmiersprache verwendet werden und keine Typverletzungen auftreten. Werden dementsprechend Typfehler spätestens zur Laufzeit erkannt, spricht man von „typsicheren Sprachen“. Typsicherheit herzustellen ist Aufgabe des Compilers bzw. Interpreters.

Und hat damit eine andere Definition als du.

Nein, die Definition stimmt schon überein.
Das Problem ist nur, dass wir C++ programmieren und C++ in einem beliebig großen Typsystem leider keine typsichere Sprache ist.
Schöner Quote, leider kein Argument.

Shade Of Mine schrieb:

Nur als kleiner Denkanstoss: du unterhältst dich hier nicht mit Kiddies - die meisten von uns arbeiten seit Jahren täglich mit C++ oder anderen Sprachen (Sprachen von denen du vermutlich noch nichtmal etwas gehört hast - also bezüglich Horizont erweitern und so).

Erzähl mir doch mal etwas, was ich noch nicht weiß. Ich erweitere gerne meinen Horizont. Der alte Mann und das Meer der Programmiersprachen (frei nach MrN) sind schon häufiger aufeinandergetroffen.

Shade Of Mine schrieb:

Wir wissen also sehr wohl wovon wir reden.

Da ist es wieder... das "wir". Eingelullt in einer Floskel, der selbstverständlich niemand widersprechen würde.

Shade Of Mine schrieb:

Die Masse hat natürlich nicht immer recht - aber es sollte dir dennoch zu denken geben wenn deine Ansichten komplett anders sind als die aller Anderen. Vielleicht bist du ein Genie dass einfach um Jahrzehnte uns allen voraus ist - vielleicht sind deine Ideen und Ansichten aber auch einfach nur falsch.

Vielleicht. Da meine Ideen und Ansichten funktionieren, schließe ich Möglichkeit B aus.
Möglichkeit A kann ich noch nicht beurteilen, üblicherweise sind meine Prognosen recht genau eingetroffen. Allerdings habe ich mir alleine schon über ein Jahrzehnt Zeit genommen, bevor ich mir eine erste Prognose zugetraut habe und ich habe erst zwei Jahrzehnte Erfahrung. An den Jahrzehnten arbeite ich also noch.
Frag 2017 nochmal nach.

Shade Of Mine schrieb:

Ich weiß, dass mein Chef mir den Hals umdrehen würde wenn ich ihm erklären würde dass ein Fehler durch unachtsamkeit der Firma ein paar Tausend Euro gekostet hat.

Darum sagte ich Dir ja, dass Du beim Debuggen nicht Symptome, sondern Fehler bekämpfen solltest. Das spart Geld, auch wenn Du 5-10 Minuten mehr Zeit investieren musst.

Shade Of Mine schrieb:

Ein "selber Schuld" kann ich nicht anbringen. Klar hat dann ein anderer Programmierer den Fehler gemacht und nicht ich - aber ich hätte ihn verhindern können.

Du kannst keine Fehler verhindern.
Es ist eigentlich eine evolutionäre Sache: Die Evolution bringt immer bessere Entwickler heraus, die noch bessere Programme und noch bessere Libs erstellen, produziert aber gleichzeitig immer noch bessere DAUs.
Schau Dir doch mal an, was sich alles "Informatik-Student" nennt oder wie oft man auf ein geistiges Vakuum im produktiven Einsatz trifft.

Ich habe kein Problem damit, einem Vollspacken zu erklären, dass er für den Beruf des Informatikers nicht geeignet ist. Und wenn Dein Chef einen Vollspacken an seine Software setzt, dann wird er Fehler machen - egal, wieviele Fehlermöglichkeiten Du abfängst: Dein Chef wird trotzdem die Erfahrung machen, dass eine Fachkraft billiger ist, als ein Vollspacken.
Schönen Gruß vom Experiment Indien.

Damit ein Vollspacken weiß, warum er kein goto verwenden soll, muss er erstmal goto verwenden. Das alleine ist für mich Grund genug, dass jede Sprache über ein goto verfügen sollte.
Gebranntes Kind scheut das Feuer, aber ohne Feuer kein gebranntes Kind...

Die Qualität der Programmiersprachen entwickelt sich kontinuierlich weiter, genauso die Blödheit der Nutzer dieser Sprachen. Schau Dir mal alte Literatur zu C an. Dort wird die Einfachheit und die Möglichkeiten der Sprache gelobt. Aus damaliger Perspektive ein Fortschritt. Die heutige Perspektive ist eine andere.

Überhaupt gibt es heute andere Statistiken.
So findest Du beispielsweise heraus, dass ein Assemblerprogrammierer genauso produktiv ist, wie ein C++ Programmierer, obwohl er scheinbar viel mehr tippen muss und das Ganze auch noch total unleserlich ist. Wie kommt sowas?
Die Idee, dass Assembler ineffektiv und unleserlich ist, kommt von einer Generation, die nie wirklich Assembler programmiert hat. Genauso wie die Vorstellung, dass C keine einfache Sprache sei.
Ein guter Assemblerprogrammierer wird C effektiv zu nutzen wissen, ein guter C programmierer wird C++ effektiv zu nutzen wissen. Und wer C++ gelernt hat, wird sich darüber beschweren, dass "man" in Assembler heutzutage nicht mehr arbeiten kann.
Als ich Assembler lernte, waren Computer noch lange nicht in jedem Haushalt. Für den Assembler zahlte ich noch 200 DM, der C++-Compiler des SAS-Institute kostete damals 695 DM.
Allein die Preise hielten die Spacken davon ab, einfach mal loszutexten.
Heute sind derartige Tools kostenlos. Die wichtigste Frage im C++-Forum ist vermutlich, warum nach dem Programmstart immer das Konsolenfenster sofort zugeht.

Als ich mir das erste Modem kaufte - und das war spät, weil ich die Zeit davor einfach keine 1000 Mark für ein 2400er Modem nicht einsah. 9600 Baud war schnell, ich war mit einem 14400er Modem damals mit absolutem Hi-Speed unterwegs, die Dinger waren frisch auf'm Markt.
Die Übertragungsrate von bis zu 1,5kb/s war sensationell, 4 Minuten Onlinezeit kosteten 23 Pfennig - falls man eine kostenlose Gegenstelle hatte. Da sah die Onlinewelt noch anders aus.
Als Anfänger hatte man es schwer, zwischen den Informationen einen Einstieg zu finden, weil nahezu jeder der Online war wußte, was er da tat. Wenn sich jemand also die Mühe machte, etwas zu beschreiben, war das noch höheres Niveau.
Heute haben wir Breitbandzugänge mit Flatrates für alle. Jeder ist online und zwischen dem ganzen Geschwafel einen intelligenten Satz zu finden bedarf aufwendiger Suche.

Der Einsatz vom Computern hat die Produktivität von Büros nachweislich verringert. Früher suchte man 30 Sekunden die Akten im Aktenschrank, heute sucht man den Admin in einer externen Firma. Früher hat man Bürokratie aus gesundem Menschenverstand beschränkt, heute erstickt man darin, weil Computer sie eben nicht bewältigen.
Wer heute einen Brief tippt und sich verschreibt, korrigiert den Brief schnell am Computer. Heute kann jeder einen fehlerfreien Brief drucken.
Leider schreiben die meisten so langsam, dass eine brauchbare Sekretären in der Zeit zwei Briefe an der Schreibmaschine getippt hätte.
Nicht alles, was als Fortschritt angesehen wird, ist auch einer.

Fortschritt findet nicht nur an einem Punkt statt. Nicht nur der Punkt, der Hi-Tech markiert, verschiebt sich, sondern es folgt auch die Position, die angibt, was jetzt Standard ist.
Wenn Du es schaffst ein Problem zu lösen, fallen tausende anderer Probleme nach: was vorher Hi-Tech und wenigen vorenthalten war, wird jetzt von der Masse genutzt. Und das bringt vor allem eine Masse Dummheit mit sich.
Nun heißt es den Punkt zu finden, an dem man möglichst wenig Probleme hast, also möglichst wenig Dummheit.

Und jetzt gebe ich Dir eine Prognose, die im Jahr 2017 vielleicht erkannt wird:
Fortschritt wird nicht dadurch erreicht, dass man 1 Problem löst, sondern dass man dafür sorgt, dass keine tausend Probleme nachfallen. Für die Programmiersprachen heißt das, dass der Hebel bei den Entwicklern angesetzt wird: Eine Hürde, über die die Vollspacken nicht drüber kommen.
Assemblerprogrammierer sind deswegen so überraschend effektiv, weil Assemblerprogrammierer keine Vollspacken sein können, die Hürde schafft ein Depp einfach nicht. Wer OOP in Assembler verwendet, weiß sehr exakt, was er da grade tut.
In C++ muss man nicht unbedingt so genau wissen, was man tut. Ansonsten existiert ein großer Markt an Büchern ("kein Vorwissen erforderlich"), ein Haufen halbgarer Tutorials und Foren mit tausenden von Experten.
Qualitätative Bücher hingegen lassen sich an einer Hand.

Diese Prognose leite ich übrigens aus einem Buch ab, dass sich mit Programmierern auseinandersetzt: "Die Psychologie des Programmierers". Das Buch kannst Du in jeder Buchhandlung kaufen, geschrieben wurde es aber afair in den 1960ern.
Die Tatsache, dass es für jede gefundene Lösung auch mindestens ein passendes Folgeproblem gibt hält das Buch bis heute aktuell. Ich könnte mir vorstellen, dass es auch in 50 Jahren noch aktuell ist.

Shade Of Mine schrieb:

Programmierer haben auch idR komplexere Probleme zu lösen als darauf zu achten ob man da jetzt einen non-explicit CTor schreiben darf (der logisch das richtige wäre) und dann noch alles richtig funktioniert oder nicht. Solche Fehler kosten Tage um sie zu finden. Und Zeit ist Geld.

Deshalb weiß ich, dass ich deinen Ansatz nie in einem produktiv System rechtfertigen kann. Es ist einfach fahrlässig statische Checks nicht einzubauen weil der Anwender des Codes gefälligst selber denken soll. Das ist eine Argumentation die nicht wirklich zieht.

Ähh... Sekunde... Du baust meine statischen Tests aus, weil Du keine expliziten Konstruktoren haben möchtest und argumentierst dann so...?

Hallo...? Echo...?

Shade Of Mine schrieb:

Deine Ansichten und Definitionen sind komplett anders als so ziemlich alles was ich je gehört habe (und ich habe schon eine Menge gehört). Das alleine sollte Grund genug sein die herkömmlichen Ansätze nicht als "dumm" hinzustellen - du stellst damit so ziemlich die gesamte Programmiererschaft der letzten 40 Jahre als dumm hin.

Expansion der ersten Person plural. Alternativ Shade im Größenwahn - als Sprecher der gesammten Programmierschaft der letzten 40 Jahre - dabei gibt's C grade mal 35. ^^

Shade Of Mine schrieb:

Es mag vielleicht sein dass wir alle Dumm sind und deine Ansätze um soviele Klassen besser sind dass Niemand den Vorteil zu sehen vermag den sie bieten - aber sind wir uns ehrlich: wie groß ist diese Wahrscheinlichkeit?

In diesem Thread?
In diesem Thread, wo hauptsächlich der Forenkindergarten Postings absetzt?
Wo der Fragesteller gegen sich selbst argumentiert und ernsthaft auch noch glaubt das wäre ein kluges Argument?
Unter der Berücksichtigung, dass ich eigentlich sehr kritisch bin und weiß, warum ich für meine Sprache Lösungen suchen musste, die ich in C++ nicht ausdrücken kann, um dem Problem zu begegnen?
Wie hoch könnte sie sein?
Wenn man davon ausgeht, dass es immer ein theoretisches Epsilon gibt...

Nein, bleiben wir realistisch... CStoll hat den Vorteil erkannt. Er macht schließlich das gleiche wie ich und ich habe nie verboten, meine Klassen über Templates zu erzeugen. Dass er seine Klassen über ein Template erzeugt bringt ihn halt auch nicht weiter.
Ich bin nicht sicher, aber aktuell glaube ich, dass Du der einzige bist, der nicht kapiert, dass in C++ "soviele" Typen auch entsprechend "soviele Klassen" benötigen - und das ist keine Frage der Wahrscheinlichkeit - das ist einfach so...

Undertaker schrieb:

wobei ich allerdings eingestehen muss, dass Xin's postings eine gewisse bewusstseinserweiternde wirkung haben, wenn man die 'richtigen filter' einschaltet.

Hehehe, nett ausgedrückt.
Unabhängig, ob Du Dich mit meinen Aussagen anfreunden kannst oder nicht, ich freue mich über jeden, der mit offenen Sinnen durch die Welt zieht.

[scrub]

ROFLMAO
Sei froh, daß es hier keinen Kindergarten gibt, sonst würdest Du spätestens jetzt im Mülleimer stecken

Hast Du inzwischen wenigstens enum verstanden? Oder das "2 + 2 = 5"-Beispiel aus dem anderen Thread? Ach was solls, schreib Deinen plattformunabhängigen Assembler fertig und beeindruck damit Deine Tutanden. Viel Spaß noch beim weiteren Leben unter der "Informatiker(=>Softwareentwickler)"-Käseglocke.

[Gast]

Xin schrieb:

Fortschritt wird nicht dadurch erreicht, dass man 1 Problem löst, sondern dass man dafür sorgt, dass keine tausend Probleme nachfallen.
Für die Programmiersprachen heißt das, dass der Hebel bei den Entwicklern angesetzt wird: Eine Hürde, über die die Vollspacken nicht drüber kommen.

Das lässt nur Böses ahnen über die zukünftige Syntax der Programmiersprachen.
Fehlervermeidung durch Reduzierung potentieller Fehlerverursacher ist kein Fortschritt sondern das genaue Gegenteil davon.

Xin schrieb:

Als ich Assembler lernte, waren Computer noch lange nicht in jedem Haushalt.
Für den Assembler zahlte ich noch 200 DM, der C++-Compiler des SAS-Institute kostete damals 695 DM.
Allein die Preise hielten die Spacken davon ab, einfach mal loszutexten.

Da haben wir es ja wieder : "Früher war alles viel besser".

[Apollon]

@Xin: ich als "A-Prollo des Forums", der mittlerweile - dank scrub - eh nichts zu verlieren hat, bezeichne _dich_ als Vollspacken der in seinem Kindergarten lebt. Ja. Einfach mal so. Just for fun. Weil es mir halt eben danach ist. Vielleicht aber auch weil ich von einem anderem Planeten komme. Such' es dir ruhig aus.

Ganz ehrlich, deine Ausraster sind fuer meinen Geschmack unverzeilich. Viel zu schnell nimmst Du sachliche Kritik an dir als eine Beleidigung wahr und konterst auch entsprechend. Voellig unberechtigt. Ist das Ego eines FH-Absolventen wirklich derart schaebig, dass es der Kritik eines Uni-Stundenten nicht Stand halten kann?

[ahaaaa]

Ist das Ego eines FH-Absolventen wirklich derart schaebig, dass es der Kritik eines Uni-Stundenten nicht Stand halten kann?

aha, mhm, aah, ich merke.

[ein unreg]

Und an allem sind natürlich wieder mal die unregs schuld, von denen Xin seinen schlimmen ruf hat.

[Shade Of Mine]

Ich denke ich habe viel gelernt hier. Xin darf man wohl nicht ernst nehmen - schade dass wir soviel Zeit verschwendet haben Aber wenigstens wissen jetzt alle die hier mitgelesen haben dass man ihn nichts glauben darf. Das ist schonmal ein guter Schritt in die richtige Richtung.

[Xin]

merker schrieb:

Xin schrieb:

Fortschritt wird nicht dadurch erreicht, dass man 1 Problem löst, sondern dass man dafür sorgt, dass keine tausend Probleme nachfallen.
Für die Programmiersprachen heißt das, dass der Hebel bei den Entwicklern angesetzt wird: Eine Hürde, über die die Vollspacken nicht drüber kommen.

Das lässt nur Böses ahnen über die zukünftige Syntax der Programmiersprachen.

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.

merker schrieb:

Xin schrieb:

Als ich Assembler lernte, waren Computer noch lange nicht in jedem Haushalt.
Für den Assembler zahlte ich noch 200 DM, der C++-Compiler des SAS-Institute kostete damals 695 DM.
Allein die Preise hielten die Spacken davon ab, einfach mal loszutexten.

Da haben wir es ja wieder : "Früher war alles viel besser".

Nein, nicht alles.
Aber an das, was besser war, könnte man sich gelegentlich erinnern und sich fragen, warum hat sich das verschlechtert?
Fortschritt bedeutet eben auch Rückschritt zu vermeiden und dafür muss nunmal in beide Richtungen schauen.

Apollon schrieb:

Viel zu schnell nimmst Du sachliche Kritik an dir als eine Beleidigung wahr und konterst auch entsprechend. Voellig unberechtigt. Ist das Ego eines FH-Absolventen wirklich derart schaebig, dass es der Kritik eines Uni-Stundenten nicht Stand halten kann?

Ich muss sagen, dass mich Beleidigungen ziemlich wenig interessieren, ich finde es nerviger, dass sie mehr Aufmerksamkeit auf sich ziehen, als die Argumentation. Ich finde es nervig, dass hier niemand den Humor mitbringt, wenn ich auf eine Beleidigung etwas schreibe wie "Hier darf nur ich beleidigen, ich habe einen Ruf zu verlieren", dass darauf dann auch noch in der Form reagiert wird.
Und an meinem Ego zu zweifeln, finde ich amüsant. Würde ich mich einem Uni-Studenten derart unterlegen fühlen, würde ich hier nicht schreiben - nebenher ist es amüsant, mir erst ein zu großes Ego vorzuwerfen ("Selbstbeweihräucherung") und jetzt mit Minderwertigkeitskomplexen zu kommen. Ihr stochert offenbar ziemlich dunkeln, wenn ihr das einschätzen wollt.

Studenten sind in der Theorie immer besser als jeder, der bereits von der FH/Uni weg ist. Das Problem ist halt dieses "in der Theorie". Theorie ist wichtig, aber Gödelnummern und Diagonalbeweise sind mir nach dem Studium nicht mehr untergekommen.
Vieles, was man im Studium gelernt hat, aber nicht mehr braucht, vergisst man im Alltag auch wieder.
Dafür weiß und lernt man hingegen, was man im Alltag braucht.
Als schäbiger FH-Absolvent, kömmt mein Ego ganz gut mit der Kritik der Uni-Studenten zurecht - ich habe die Postings ja gelesen.

Shade Of Mine schrieb:

Ich denke ich habe viel gelernt hier. Xin darf man wohl nicht ernst nehmen - schade dass wir soviel Zeit verschwendet haben Aber wenigstens wissen jetzt alle die hier mitgelesen haben dass man ihn nichts glauben darf.

Ich habe niemanden gebeten, seine (und meine) Zeit hier zu verschwenden.
Ich sehe Deinen Text durchaus als beleidigend an, ich las aber auch, was Du geschrieben hast und das steht im Widerspruch zu dem, was Du hier schreibst.
Whoops... das war vermutlich auch schon eine Beleidigung, schließlich war das nur sachliche Kritik, oder? Und ich kontere jetzt bösartig.

Mal ehrlich, Jungs, kaum einer hat sich wirklich mit dem auseinandergesetzt, was ich geschrieben habe. Ich lese es ja an den Antworten. Das Verständnis der expliziten Konstruktoren verschiedener Diskussionsteilnehmer zeigt, dass C++ noch nicht vollständig beherrscht wird, aber trotzdem kräftig "argumentiert" wird. Auch als Uni-Student kann man nicht in der Form mitreden, wenn die notwendigen C++-Kenntnisse fehlen.

Shade, was Du dazu hier schreibst, enttäuscht mich ehrlich gesagt. Der Rest der hier Gequoteten springt auf einen Zug auf ohne die Diskussion verfolgt zu haben. Du hast zumindest Teile davon verfolgt.
Statt Dich damit auseinander zu setzen, warum ich so auf die expliziten Konstruktoren bestehe und in diesem Punkt eben keine andere "Meinung" neben der eigenen bestehen lasse, schreibst Du erst, dass explizite CTors daneben sind und hier, dass man mich nicht ernstnehen kann. Wäre hier jemand, der nachvollziehen kann, warum ich auf die exp. CTors bestehe und sich diesen Thread tatsächlich antäte, was liest derjenige aus Deiner Ablehnung?
Die exp. CTors sind nunmal eben keine Geschmackssache und man kann sie auch nicht dazu definieren.

Als professionell Lernender würde es Dir eigentlich leicht fallen zu sagen, ich habe etwas dazu gelernt, auch weil Xin auf die exp. CTors bestand. Stattdessen pfefferst Du mir derartiges hinterher.
Ist das die richtige Richtung für einen Uni-Studenten? Grade als Student sollte man mit offenen Augen sich umschauen und nicht nur passiv Informationen aufnehmen und wieder abspielen.

Sollten Dir mal exp. CTors über den Weg laufen, denk nochmal an diesen Thread und daran, dass Du als Uni-Student einem FH-Absolventen nicht ernstnehmen brauchst.
Viel Erfolg beim Studium.

[Tellerrand]

Xin schrieb:

Mal ehrlich, Jungs, kaum einer hat sich wirklich mit dem auseinandergesetzt, was ich geschrieben habe. Ich lese es ja an den Antworten.

Mal ehrlich, Junge, du hast keine Ahnung was du da schreibst, ich lese es ja in deinen Postings.

Langsam geht mir die Art der Argumente auf den Zeiger.

[Highlighter]

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

Mal ehrlich, Junge, du hast keine Ahnung was du da schreibst, ich lese es ja in deinen Postings.

Langsam geht mir die Art der Argumente auf den Zeiger.

[CStoll]

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*Volt

Buttrebrot*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++".

[Undertaker]

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.

[Kommentator]

CStoll schrieb:

Erstmal entschuldige ich mich, daß ich jetzt nicht auf jeden Beitrag der letzten Tage einzeln eingehe.

[CStoll]

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?

[Undertaker]

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.

[Mr. N]

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.

[Xin]

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.