Methoden mit bool-Parametern und "Lesbarkeit" im Kontext

[OMG_2]

Mr. N schrieb:

Xin schrieb:

Ansonsten werden Winkel bei mir in Grad gemessen.

Bei mir in Bogenmaß. (Übrigens auch eine einheitenlose Zahl.)

Sehr richtig, des Weiteren sprach ich auch von trigonometrischen Funktionen, da kannst du gar keine Einheit dazu konstruieren.

Xin schrieb:

Der Brechungsindex ist eine typlose Größe. Wie soll irgendwer eine typlose Größe typsichern?

Man kann es typsichern, wie sie entsteht, sie kann durch Meter/Meter entstehen, aber darf nicht durch Meter*Haus entstehen. CStolls Variante sichert das wunderbar.

[Xin]

Mr. N schrieb:

Xin schrieb:

Ansonsten werden Winkel bei mir in Grad gemessen.

Bei mir in Bogenmaß. (Übrigens auch eine einheitenlose Zahl.)

Die sich aber einem Typ Gradmaß oder Gon zuordnen läßt und somit wieder typsicher (weiter-)verarbeitet werden kann.

Sind die Winkelfunktionen auf Winkeltypen festgelegt, käme kaum einer auf die Idee Winkel dauerhaft als typlose Größe zu beschreiben.

Mr. N schrieb:

Xin schrieb:

Der Brechungsindex ist eine typlose Größe. Wie soll irgendwer eine typlose Größe typsichern?

Wo es nicht geht, geht es nicht. Aber wo es geht, sollte man es tun.

Eben.

Mr. N schrieb:

Xin schrieb:

chrische5 schrieb:

Xin gefällst du dir in der Rolle des Unverstandenen?

Nein. Sollte man mir eine angenehmere anbieten, werde ich mit Begeisterung wechseln.

Also ich würde dir empfehlen, weniger oft das Wort 'Kindergarten' zu benutzen, dann fühlst du dich bestimmt gleich besser.

Wenn sich hierdurch einige Leute auf den Schlips getreten fühlen, stellt sich die Frage, warum sie sich angesprochen fühlen. Dem Unregistrierten, denn Du eben mit "Kann man Dich mieten?" geantwortet hast - wie würdest Du derartige Poster denn beschreiben? Als Erwachsene?

Und wenn ich von einem Admin aus dem #cpp gebannt werde mit Begründungen wie "Ich banne Dich in #cpp, weil ich Dich nicht aus dem Forum werfen kann" und "Willkür ist Willkür", dann spricht das auch nicht unbedingt für ein erwachsenes Verhalten. Das ist für mich ein Kindergarten.

Das ist meine Meinung und zu der stehe ich. Ich erzähle niemanden etwas, hinter dem ich nicht stehe. Ich kann mich irren, aber wer in meinen Augen nicht zum Forumskindergarten gehören möchte, der sollte sich auch nicht wie ein Dreijähriger aufführen.

[OMG_3]

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Ansonsten werden Winkel bei mir in Grad gemessen.

Bei mir in Bogenmaß. (Übrigens auch eine einheitenlose Zahl.)

Die sich aber einem Typ Gradmaß oder Gon zuordnen läßt und somit wieder typsicher (weiter-)verarbeitet werden kann.

Sind die Winkelfunktionen auf Winkeltypen festgelegt, käme kaum einer auf die Idee Winkel dauerhaft als typlose Größe zu beschreiben.

Was redest du jetzt schon wieder? Kennst du dich mit Physik überhaupt aus, und weiß, wie ein Cosinus in eienr Formel aussieht? Er entsteht z.B. aus Meter/Meter, wie willst du deinem Programm mitteilen, dass das ein Cosinus ist, Meter*Haus aber nicht?

[Mr. N]

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

chrische5 schrieb:

Xin gefällst du dir in der Rolle des Unverstandenen?

Nein. Sollte man mir eine angenehmere anbieten, werde ich mit Begeisterung wechseln.

Also ich würde dir empfehlen, weniger oft das Wort 'Kindergarten' zu benutzen, dann fühlst du dich bestimmt gleich besser.

Wenn sich hierdurch einige Leute auf den Schlips getreten fühlen

Es geht um dein Wohlbefinden.

Xin schrieb:

, stellt sich die Frage, warum sie sich angesprochen fühlen. Dem Unregistrierten, denn Du eben mit "Kann man Dich mieten?" geantwortet hast - wie würdest Du derartige Poster denn beschreiben? Als Erwachsene?

Also ich fand seine Zusammenfassung sehr schön. Liest sich wie ein Gedicht.

Xin schrieb:

Und wenn ich von einem Admin aus dem #cpp gebannt werde mit Begründungen wie "Ich banne Dich in #cpp, weil ich Dich nicht aus dem Forum werfen kann" und "Willkür ist Willkür", dann spricht das auch nicht unbedingt für ein erwachsenes Verhalten. Das ist für mich ein Kindergarten.

Ja, #cpp ist ein Hort der Willkürherrschaft. Da herrscht noch das Feudalrecht!

Xin schrieb:

Das ist meine Meinung und zu der stehe ich. Ich erzähle niemanden etwas, hinter dem ich nicht stehe. Ich kann mich irren, aber wer in meinen Augen nicht zum Forumskindergarten gehören möchte, der sollte sich auch nicht wie ein Dreijähriger aufführen.

Ich wollte dir ja nur einen Rat geben, wie du dich vielleicht besser fühlen könntest.

[Xin]

Mr. N schrieb:

Es geht um dein Wohlbefinden.

Ich fühle mich nicht wohl, wenn ich Leute dafür belügen muss.

Mr. N schrieb:

Xin schrieb:

Und wenn ich von einem Admin aus dem #cpp gebannt werde mit Begründungen wie "Ich banne Dich in #cpp, weil ich Dich nicht aus dem Forum werfen kann" und "Willkür ist Willkür", dann spricht das auch nicht unbedingt für ein erwachsenes Verhalten. Das ist für mich ein Kindergarten.

Ja, #cpp ist ein Hort der Willkürherrschaft. Da herrscht noch das Feudalrecht!

Ich war mal Admin eines IRC-Servers und dort in der Regel nichtmals als ChannelOp unterwegs.

Ich frage mich immer, wie das reale Ego von Leute aussieht, die ihr virtuelles Ego auf einem virtuellen Thron platzieren müssen.

Mr. N schrieb:

Ich wollte dir ja nur einen Rat geben, wie du dich vielleicht besser fühlen könntest.

Wenn Du noch einen Rat hast, für den ich mich nicht für einen Forenkindergarten verbiegen muss, lass hören. Ansonsten... obwohl ich hörte, dass der Bann aufgehoben wurde, kann ich auch ohne #cpp ganz gut leben.

[Theston]

Xin schrieb:

Ansonsten werden Winkel bei mir in Grad gemessen.
Der Brechungsindex ist eine typlose Größe. Wie soll irgendwer eine typlose Größe typsichern?

Nun, bei dir ist

Brechzahl = Butterbrot*Schraube*Meter

und

cos_alpha = Meter/Butterbrot

völlig legaler Code, der niemals Fehler ausspucken wird. Ich finde das nicht typsicher, ka, wie du das siehst.
Meiner Ansicht nach dürfte nur

cos_alpha = Meter/Kilogramm*Meter*Kilogramm

legal sein, denn nur das hat physikalisch einen Sinn. Und die Templatevariante deckt das wunderbar. Typsicherheit fängt eben nicht erst bei der Zuweisung an. Wie willst du das absichern?

[Mr. N]

Xin schrieb:

Mr. N schrieb:

Es geht um dein Wohlbefinden.

Ich fühle mich nicht wohl, wenn ich Leute dafür belügen muss.

Na dann entschuldige vielmals.

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Und wenn ich von einem Admin aus dem #cpp gebannt werde mit Begründungen wie "Ich banne Dich in #cpp, weil ich Dich nicht aus dem Forum werfen kann" und "Willkür ist Willkür", dann spricht das auch nicht unbedingt für ein erwachsenes Verhalten. Das ist für mich ein Kindergarten.

Ja, #cpp ist ein Hort der Willkürherrschaft. Da herrscht noch das Feudalrecht!

Ich war mal Admin eines IRC-Servers und dort in der Regel nichtmals als ChannelOp unterwegs.

Ich frage mich immer, wie das reale Ego von Leute aussieht, die ihr virtuelles Ego auf einem virtuellen Thron platzieren müssen.

Also, wenn ich nicht gerade in der Ecke sitze und weine, beleidige ich am liebsten unschuldige, bevorzugt ältere, Leute.

Xin schrieb:

Mr. N schrieb:

Ich wollte dir ja nur einen Rat geben, wie du dich vielleicht besser fühlen könntest.

Wenn Du noch einen Rat hast, für den ich mich nicht für einen Forenkindergarten verbiegen muss, lass hören. Ansonsten... obwohl ich hörte, dass der Bann aufgehoben wurde, kann ich auch ohne #cpp ganz gut leben.

Nein, der Bann wurde nicht aufgehoben. Woher hast du das denn?

[Theston]

Noch eine Problematik, die mir auffiel.

Volt = Butterbrot*Katze*Volt

Buttrebrot*Katze ergibt typlos. 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?

[Xin]

Theston schrieb:

Xin schrieb:

Ansonsten werden Winkel bei mir in Grad gemessen.
Der Brechungsindex ist eine typlose Größe. Wie soll irgendwer eine typlose Größe typsichern?

Nun, bei dir ist

Brechzahl = Butterbrot*Schraube*Meter

und

cos_alpha = Meter/Butterbrot

völlig legaler Code, der niemals Fehler ausspucken wird. Ich finde das nicht typsicher, ka, wie du das siehst.

Genauso, aber ich kann keine Wunder vollbringen und habe auch nie behauptet. Typlose Größen kann ich nicht typisisieren.

Theston schrieb:

Meiner Ansicht nach dürfte nur

cos_alpha = Meter/Kilogramm*Meter*Kilogramm

legal sein, denn nur das hat physikalisch einen Sinn.

Grüße vom Planeten Erde!

So langsam wird mir hier einiges klar. Das Forum muss also ein Tor in ein anderes Universum mit anderen Naturgesetzen darstellen...

Theston schrieb:

Und die Templatevariante deckt das wunderbar.

Auf meinem Heimatplaneten scheitert das Template da genauso dran, denn unit< 0, 0, ... > enthält genausowenig Meter/Meter, wie cos_alpha. Typlos bliebt Typlos.
Quadratmeter werden zugegebenermaßen vom Template wunderbar abgebildet, in diesem Universum werden Winkel aber nicht in Quadratmetern ausgedrückt.

Danke für's Mitspielen, leider nicht gewonnen.
Dein Posting fiel aber durch besonderen Unterhaltungswert positiv auf.

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Ja, #cpp ist ein Hort der Willkürherrschaft. Da herrscht noch das Feudalrecht!

Ich war mal Admin eines IRC-Servers und dort in der Regel nichtmals als ChannelOp unterwegs.
Ich frage mich immer, wie das reale Ego von Leute aussieht, die ihr virtuelles Ego auf einem virtuellen Thron platzieren müssen.

Also, wenn ich nicht gerade in der Ecke sitze und weine, beleidige ich am liebsten unschuldige, bevorzugt ältere, Leute.

...also ein Sympathieträger in Reinkultur.

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Ich wollte dir ja nur einen Rat geben, wie du dich vielleicht besser fühlen könntest.

Wenn Du noch einen Rat hast, für den ich mich nicht für einen Forenkindergarten verbiegen muss, lass hören. Ansonsten... obwohl ich hörte, dass der Bann aufgehoben wurde, kann ich auch ohne #cpp ganz gut leben.

Nein, der Bann wurde nicht aufgehoben. Woher hast du das denn?

Was man so hört. Keine Sorge, Du musst ihn nicht wieder erstellen. Die älteren Leute gucken mal durch den Zaun auf den Spielplatz und gehen weiter.

[Xin]

Theston schrieb:

Noch eine Problematik, die mir auffiel.

Er geht in die zweite Runde...

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.

Danke für's Mitspielen undviel Erfolg beim nächsten Versuch.

Ich glaube, ich werde zynisch, Zeit ins Bett zu gehen...

[rüdiger]

Xin schrieb:

Liebelein... guck doch nochmal nach, was Du alles so schreibst... Du erklärst mir hier, warum Spannung keine Größe ist, sondern eine Einheit. Dann erklärtest Du den Unterschied zwischen Einheit und Größe: nämlich Volt ist eine Größe und Butterbrote ist eine Größe. Wo da der Unterschied zwischen Einheit und Größe liegt, zwei synonymen Begriffen, das weißt vermutlich nur Du.

Konzentriere Dich doch mal darauf, was Du erklären möchtest und nicht nur darauf, einfach zu texten, um Textstellen wie "Du begreifst es nicht, oder wie?" reinzubringen. Ich äußerte vorher schon den Verdacht, dass es Dir vorangig darum geht dagegen zu sein und grade hier textest Du nur unzusammenhängendes Zeugs.
Was Du hier erklärst kann niemand begreifen, es ist nämlich vollkommen ohne inhaltlichen Wert.

Am Rande: eine Anzahl wird in Stück gemessen und Stück bedeutet lediglich, dass etwas zählbar ist, gewissermaßen ein Integer. Eine Spannung hingegen wird nicht in Stück gemessen, weil nicht abzählbar. Mehl ist auch nicht abzählbar, darum mißt man es in Gewicht. Egal worin man mißt, man braucht eine Einheit.
Und wenn Du Dir bei Butterbroten unsicher bist, ob Du sie zählen kannst, dann darfst Du Deine Zählklasse auch gerne StückButterbrote nennen, um sie von StückHäuser zu unterscheiden. Und Deine Mehlklasse in GrammMehl, damit Du Deine Pfannkuchen nicht mit GrammUran verwechselst.
Stück ist jedenfalls keine Einheit und darum nenne ich die Einheit, in der ich Butterbrote zähle Butterbrot.
Und wenn ich zwei StückButterbrote und zwei StückHäuser addiere, dann kommen da bei mir vier Unit raus. Nur halt nicht Häuser oder Butterbrote - nur Unit. Und wenn ich 5 GrammUran mit 10 GrammMehl addiere, dann kommen da 15 Unit raus. Als Klassenhersteller habe ich keine Ahnung, was das ist, aber der Entwickler weiß es und kann das nun mit dem entsprechenden expliziten Konstruktor auf GrammSondermüll zuweisen.

ROFL Das ist gut. Damit kannst du glaube ich jeden Physiker mit vor lachen vom Stuhl hauen. Falls der Beitrag kein Spaß war, würde ich dir aber mal zum lesen eines Physik Buches (da reicht was simples, ist ja ein sehr grundlegendes und einfaches Thema) raten.

[scrub]

Hmmm, aber ob man diesen Lehrbüchern trauen kann? Das glauben ja inzwischen Millionen Menschen, was da drinsteht... diese Bücher sind ja quasi eine "BILD" der Physiker.

[Gast]

Xin schrieb:

Theston schrieb:

Volt = Butterbrot*Katze*Volt

Buttrebrot*Katze ergibt typlos.

Falsch, ergibt Unit, konvertierbar auf typlos.

Sowas erschwert nur die Strategie zur Aufspürung logischer Fehler im Programm. Finde mal heraus, welches Objekt die Daten versemmelt haben könnte.

[Shade 0f Mine]

Was macht ihr da? Ihr wollt Code schreiben um irgendwelche Sachen auszurechnen und vom Compiler Fehlermeldungen, wenn die Einheiten nicht passen? Ich hab noch nie eine größere Anwendung geschrieben, die sowas macht, aber ich denke die Formeln sind beim schreiben des Programms doch bekannt. Also ich würde mir nicht irgendwelche Klassen für Spannung Strom usw.. machen und mit denen dann rechnen, dass ist doch viel zu langsam. Wenn ich irgendwelche Echtzeitberechnungen machen muss, würde ich das direkt int den Code schreiben mit int und/oder double und die Einheit erst bei der Anzeige (falls vorhanden) hinschreiben. Wenn ich ein Formelnbastelprogramm schreiben will, dann könnte man sowas machen, aber da stell ich es mir viel zu Aufwendig vor, bis ich alle Kombinationen habe. Hat von euch schon einer ein Programm geschrieben, dass viele Berechnungen macht und denn Code so geschrieben, dass es Compilerfehler gibt, wenn man falsche Formeln baut (nicht für sich privat)?

[Shade Of Mine]

Xin, dass ich von Typsicherheit keine Ahnung habe kam von dir - ich habe es lediglich wiederholt. Lies deine Posts bei Zeiten mal

Und ich nenne dich ja auch nicht ein dummes kleines Kind weil du eine andere Meinung hast als die Forengrößen. Es ist dein gutes Recht eine andere Meinung zu haben. Aber genauso ist es unser Recht ebenfalls anderes zu denken als du. Deshalb wäre es sehr schön wenn nicht alles gleich Kindergarten ist oder sowieso von garnix eine Ahnung hat, was nicht deine Meinung vertritt.

Das Problem für mich ist, dass du alle Fehler als "Schuld vom Programmierer" abstempelst. Das ist es zwar auch, aber es geht darum dem Programmierer bei der Fehlersuche zu helfen. Die Fehlermeldungen der Compiler sind super dafür. Sie sind nicht die besten der Welt - aber ich kenne jetzt spontan keine Plattform die mir deutlich bessere Fehlerbeschreibungen bringen als die modernen C++ Compiler.

Unser Ziel ist es, korrekte Software zu schreiben. Wir tun deshalb alles was in unserer Macht steht um Fehler zu verhindern. Fehler passieren aber - jede Software ist Fehlerhaft. Es geht nun darum die Fehler so gering wie möglich zu halten. Jeder Programmierer macht Fehler. Jedes Tool dass wir dem Programmierer geben um die Fehlerquote zu reduzieren ist Gold Wert.

Dein Ansatz verhindert keine Fehler. Natürlich sind Fehler immer Fehler und somit Schuld des Programmierers - aber es ist lächerlich zu behaupten, dass der Programmierer einfach keine Fehler machen soll. Denn die wird er machen. Typsicherheit soll nun dem Programmierer helfen weniger Fehler zu machen - indem unlogische Operationen wie "kilogramm - meter" nicht erlaubt sind. Du erlaubst sie aber und hast dadurch eine potenzielle Gefahrenquelle.

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.

Denn operator int ist problematisch. Es wird dadurch nämlich eine Art "ist-ein" Beziehung gebaut, die nicht vorhanden sein sollte. Es mag zwar logisch klingen zu sagen, ein Meter ist ein int. Aber das ist ein Trugschluss. Wenn Meter ein int wäre - dann wäre Meter eng mit Celsius verwandt. Tatsächlich haben Meter und Celsius miteinander aber nichts am Hut. Sie haben beide nur zufällig eine Beziehung zu int.

Durch den operator int sind beide aber plötzlich miteinander eng verbunden und können Operationen aufeinander ausführen die der Programmierer ursprünglich garnicht wollte. Das kann zu Problemen führen.

Wenn man den operator int einfach nicht anbietet für diese beiden Typen, spart man sich diese ganzen Probleme.

Auch non-explicit CTors sollten mit Bedacht eingesetzt werden, da sie ebenfalls Typkonvertierungen sind - aber im Gegensatz zu operator int findet kein Verlust der Typinformationen statt. In den meisten Situationen macht es wenig Unterschied ob ich einen explicit oder non-explicit CTor habe. Denn wenn "foo=bar;" nicht geht, weil ich einen Fehler bekomme kann ich einfach "foo=Foo(bar);" schreiben und schon ist der Fehler weg. Es gibt nur wenige Situationen mit Überladung wo ein non-explicit CTor Probleme bereitet. Dafür ist er in vielen Situationen unheimlich praktisch:

Meter m(7);
m+=3;

ich brauche hier keinen operator += für int definieren - der operator+= für Meter reicht. Das reduziert den nötigen Code.

Weiters kann man

Millimeter mm(convertMeter2Millimeter(12));

und ähnliches schreiben ohne nochmal explizit Meter(12) schreiben zu müssen. Die hält den Code schlanker und ist lediglich dann relevant wenn convertMeter2Millimeter eine Überladung für int hat die etwas anderes macht als die Überladung für Meter.

Es geht dabei eigentlich nur darum sich so gut es geht gegen Murphy zu schützen. Oberstes Prinzip bei der Programmierung ist: es muss funktionieren. Wenn es nicht funktioniert kann es noch so schön, elegant, schnell oder sonstwas sein - es ist wertlos. Deshalb sollte jeder Programmierer so weit es ihm möglich ist alle eventualitäten Abfangen die Fehler produzieren können. Denn der Code wird Fehler enthalten - die Programmierer die damit arbeiten müssen werden Fehler rein machen. Es liegt nun an uns unseren Code so zu gestalten, dass es möglichst schwer wird Fehler unabsichtlich einzubauen.

Zu erlauben "Meter - Brot" zu rechnen ist ganz witzig, aber es zu verbieten verhindert schonmal viele Tippfehler.

Deine Methode verbietet zum Beispiel ein

Meter m;
Brot b;
Kilogramm k;
m=b*k;

Aber sie verbietet auch ein:

m=2*10;

also gewöhnt man sich sowieso an

m=Meter(x);

zu schreiben und da du einen CTor für int hast - hast du wieder ein Problem. Non-explicit CTors schützen nicht vor ungewollten Konvertierungen wenn man einen operator int anbietet.

Deshalb ist das Argument, dass "m=k*b;" nicht geht sehr fragwürdig. Denn genausowenig geht ein "m=m+10*millimeter;" oder andere sinnvolle Konstrukte. Man wird also oft einfach den expliziten Weg gehen und damit deine Sicherung ungewollt aushebeln.

Oder anders ausgedrückt:

m=a+b;

liefert mir die Meldung dass die Konvertierung von int nach Meter nur explizit möglich ist - erste Aktion von mir:

m=Meter(a+b);

und schon ist das Problem umgangen - ich habe aber einen Fehler eingebaut, den ich so wunderschön vertuscht habe. Der Compiler meldet mir ja extra "Konvertierung implizit nicht möglich". Dass das Problem woanders liegt, fällt kein bisschen auf. Genau das ist problematischer Code.

[Theston]

Xin schrieb:

Theston schrieb:

Meiner Ansicht nach dürfte nur

cos_alpha = Meter/Kilogramm*Meter*Kilogramm

legal sein, denn nur das hat physikalisch einen Sinn.

Grüße vom Planeten Erde!

So langsam wird mir hier einiges klar. Das Forum muss also ein Tor in ein anderes Universum mit anderen Naturgesetzen darstellen...

Sehr gut, dass du dich an Tippfehlern aufziehst, man merkt, du hasts drauf!

[Gast]

Hallo

Xin schrieb:

Grüße vom Planeten Erde!

So langsam wird mir hier einiges klar. Das Forum muss also ein Tor in ein anderes Universum mit anderen Naturgesetzen darstellen...

Xin schrieb:

Danke für's Mitspielen, leider nicht gewonnen.
Dein Posting fiel aber durch besonderen Unterhaltungswert positiv auf.

Xin schrieb:

Was man so hört. Keine Sorge, Du musst ihn nicht wieder erstellen. Die älteren Leute gucken mal durch den Zaun auf den Spielplatz und gehen weiter.

Für Xin: Nur mal eine Zusammenfassung deiner Art in nur einem Posting. Vielleicht solltest du wirklich langsam anfangen auch dein eigenes Verhalten nicht als unfehlbar einzuschätzen. Du regst dich auf, dass du nicht ernst genommen wirst und lässt hier eine dermaßen überhebliche Art durchscheinen. Keine Ahnung, ob es hilft, aber sie es als konstruktive Kritik.

chrische

[Undertaker]

Shade Of Mine schrieb:

aber ich kenne jetzt spontan keine Plattform die mir deutlich bessere Fehlerbeschreibungen bringen als die modernen C++ Compiler.

na, nun übertreib' mal nicht. ein C++ compiler macht doch bloss statische code checks, und oft sind die fehlermeldungen alles andere als gut.
das kann z.b. http://www.splint.org/ viel besser, ist für 'C++' aber nur bedingt einsetzbar.
bei sprachen, die eine weniger wirre syntax als C++ haben, sind solche automatischen überprüfungen ohnehin einfacher. kennst du vielleicht 'IntelliJ IDEA'? es ist schon faszinierend, was das teil an potentiellen fehlerquellen aufdecken kann.

[Mr. N]

Undertaker schrieb:

Shade Of Mine schrieb:

aber ich kenne jetzt spontan keine Plattform die mir deutlich bessere Fehlerbeschreibungen bringen als die modernen C++ Compiler.

na, nun übertreib' mal nicht. ein C++ compiler macht doch bloss statische code checks, und oft sind die fehlermeldungen alles andere als gut.
das kann z.b. http://www.splint.org/ viel besser, ist für 'C++' aber nur bedingt einsetzbar.
bei sprachen, die eine weniger wirre syntax als C++ haben, sind solche automatischen überprüfungen ohnehin einfacher. kennst du vielleicht 'IntelliJ IDEA'? es ist schon faszinierend, was das teil an potentiellen fehlerquellen aufdecken kann.

Lass uns doch bitte in Ruhe mit deinem lächerlichen Kreuzzug gegen C++.

[Xin]

rüdiger schrieb:

ROFL Das ist gut. Damit kannst du glaube ich jeden Physiker mit vor lachen vom Stuhl hauen. Falls der Beitrag kein Spaß war, würde ich dir aber mal zum lesen eines Physik Buches (da reicht was simples, ist ja ein sehr grundlegendes und einfaches Thema) raten.

Ein bißchen weiter gelesen und Du hättest gemerkt, dass Du kalten Kaffee aufwärmst. Was CStoll da erklärt hat ist mir bis jetzt unverständlich, Jester glaubt, dass er Spannung und Volt unterscheiden möchte, was ich für sehr gut möglich halte, aber für irrelevant bei Typsicherheit. CStoll äußerte ein "Du kapierst es nicht" und wird das Geheimnis was er erklärte wohl mit ins Grab nehmen.

merker schrieb:

Xin schrieb:

Falsch, ergibt Unit, konvertierbar auf typlos.

Sowas erschwert nur die Strategie zur Aufspürung logischer Fehler im Programm. Finde mal heraus, welches Objekt die Daten versemmelt haben könnte.

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

Shade 0f Mine schrieb:

Ich hab noch nie eine größere Anwendung geschrieben, die sowas macht, aber ich denke die Formeln sind beim schreiben des Programms doch bekannt. Also ich würde mir nicht irgendwelche Klassen für Spannung Strom usw.. machen und mit denen dann rechnen, dass ist doch viel zu langsam.

...

Shade 0f Mine schrieb:

Hat von euch schon einer ein Programm geschrieben, dass viele Berechnungen macht und denn Code so geschrieben, dass es Compilerfehler gibt, wenn man falsche Formeln baut (nicht für sich privat)?

Yepp, habe ich.

Shade Of Mine schrieb:

Xin, dass ich von Typsicherheit keine Ahnung habe kam von dir - ich habe es lediglich wiederholt. Lies deine Posts bei Zeiten mal

Ich weiß das schon... aber Du schriebst dass Du keine Ahnung hast, nicht dass ich Dir das zuschreiben würde. Weiterhin hast Du anschließend einen netten Beweis hingelegt, dass Du keine Ahnung hast.
Vergleiche mal Dein den Ausschnitt aus Deinem letzten Posting, dass ich hier mit "..." kommentiert habe.
Ich halte Dich nicht für unfähig, aber es fällt stark auf, dass Du Dich bei diesem Thema im Grenzbereich Deiner Kenntnisse bewegst.
Und da Du keine Fragen stellst, sondern Feststellungen triffst, die Du bestenfalls vom Forumskindergarten bestätigt bekommst, macht das ganze einfach keinen guten Eindruck.

Shade Of Mine schrieb:

Das Problem für mich ist, dass du alle Fehler als "Schuld vom Programmierer" abstempelst. Das ist es zwar auch,

Es ist ein Problem für Dich, dass ich das Problem korrekt erkannt habe... geile Argumentation
Wäre ich Deiner Meinung, wäre die Diskussion auch viel einfacher für Dich... kann ich schon nachvollziehen.

Shade Of Mine schrieb:

aber es geht darum dem Programmierer bei der Fehlersuche zu helfen. Die Fehlermeldungen der Compiler sind super dafür. Sie sind nicht die besten der Welt - aber ich kenne jetzt spontan keine Plattform die mir deutlich bessere Fehlerbeschreibungen bringen als die modernen C++ Compiler.

Die alten Compiler.
Der Compiler des SAS-Institute wird seit über 10 Jahren nicht mehr entwickelt, aber die Fehlermeldungen waren punktgenau und die Beschreibung häufig so exakt und gut erklärt, dass ich mich häufig ärgerte, dass der Compiler den Fehler nicht einfach selbst korrigiert.
Für den GCC habe ich auf der Homepage eine kleine Ecke mit Übersetzungen von unverständlichen Compilermeldungen und mir schrieb mal jemand ein Dankeschön, weil er die Fehlermeldungen auch erst durch meine HP entschlüsseln konnte.
Die Fehlermeldungen des GCC und des MSVC sind unterirdisch schlecht.
Ich nehme mir für das Fehlermeldungen meines Compilers etwas mehr Zeit und kann aus Erfahrung sagen, dass es kein Problem ist, hier mehr zu leisten.

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.
"Ihr" habt alles in eurer Macht stehende getan, um gegen etwas zu sein, was praktisch handhabbar ist. Das dann als "wir tun alles um Fehler zu verhindern" zu verkaufen, zeugt von einem gesunden Selbstbewußtsein.

Shade Of Mine schrieb:

Denn operator int ist problematisch. Es wird dadurch nämlich eine Art "ist-ein" Beziehung gebaut, die nicht vorhanden sein sollte. Es mag zwar logisch klingen zu sagen, ein Meter ist ein int. Aber das ist ein Trugschluss. Wenn Meter ein int wäre - dann wäre Meter eng mit Celsius verwandt. Tatsächlich haben Meter und Celsius miteinander aber nichts am Hut. Sie haben beide nur zufällig eine Beziehung zu int.

Das haben wir schon als Geschmackssache erledigt.
Beides sind Zahlenwerte mit Zahlen darf man meiner Überzeugung arbeiten, mit Einheiten nicht.
Das ist (immernoch) kein Gefahrenpotential, weil man kann diese Zahlen nicht einfach so zuweisen.

Shade Of Mine schrieb:

Auch non-explicit CTors sollten mit Bedacht eingesetzt werden, da sie ebenfalls Typkonvertierungen sind - aber im Gegensatz zu operator int findet kein Verlust der Typinformationen statt. In den meisten Situationen macht es wenig Unterschied ob ich einen explicit oder non-explicit CTor habe.

Richtig. Der Punkt ist, dass genau hier eine Situation ist, wo es nicht nur wenig Unterschied macht.
Es entscheidet zwischen typsicher und nicht typsicher.
Es macht den Unterschied.

Shade Of Mine schrieb:

Denn wenn "foo=bar;" nicht geht, weil ich einen Fehler bekomme kann ich einfach "foo=Foo(bar);" schreiben und schon ist der Fehler weg. Es gibt nur wenige Situationen mit Überladung wo ein non-explicit CTor Probleme bereitet. Dafür ist er in vielen Situationen unheimlich praktisch:

Meter m(7);
m+=3;

ich brauche hier keinen operator += für int definieren - der operator+= für Meter reicht. Das reduziert den nötigen Code.

Meter m(7);
m += array.GetIndex( Element );

Worum ging die Diskussion noch gleich? Typsicherheit?

Shade Of Mine schrieb:

Weiters kann man

Millimeter mm(convertMeter2Millimeter(12));

und ähnliches schreiben ohne nochmal explizit Meter(12) schreiben zu müssen. Die hält den Code schlanker

Super, gleich mit redundanten Klassen nochmal einen nachlegen und das dann auch noch als schlanken Code bezeichnen.

Die Situation erinnert mich an einen Dreijährigen, der sich verbotenerweise ein Bonbon geklaut hat und nun mit vollen Mund nuschelt, dass er kein Bonbon genommen hat, während das Papier in seinen Fingern raschelt.

Es hilft nicht, einen Fehler mit einem anderen auszutauschen. Eine sinnvollere Lösung für den Wunsch mit Millimetern zu arbeiten, findest im Thread.

Shade Of Mine schrieb:

Deine Methode verbietet zum Beispiel ein

Meter m;
Brot b;
Kilogramm k;
m=b*k;

Aber sie verbietet auch ein:

m=2*10;

also gewöhnt man sich sowieso an

m=Meter(x);

zu schreiben und da du einen CTor für int hast - hast du wieder ein Problem. Non-explicit CTors schützen nicht vor ungewollten Konvertierungen wenn man einen operator int anbietet.

Das kann passieren.
C++ setzt Grenzen. Ein expliziter Konstruktor ist ein Gefahrenhinweis. Wer darüber unbesorgt hinweggeht, weil 'hat ja immer geklappt', den kann und will ich in C++ nicht beschützen.
Wenn er es verkehrt gemacht hat, wird er nicht behaupten, dass es immer geklappt hat.

Menschen sind dumm, aber sie in Watte zu packen, lässt sie total verdummen.

Shade Of Mine schrieb:

Oder anders ausgedrückt:

m=a+b;

liefert mir die Meldung dass die Konvertierung von int nach Meter nur explizit möglich ist - erste Aktion von mir:

m=Meter(a+b);

und schon ist das Problem umgangen

Als Du geschrieben hast, dass Du ja keine Ahnung hast, klang das wenigstens noch intelligent.
Wenn das Deine erste Reaktion ist, dann werde bitte niemals professioneller Entwickler.

Debuggen bedeutet nicht Symptome zu bekämpfen, sondern Fehler zu entfernen, so dass keine Symptome auftreten. Es geht nicht darum den Compiler zufrieden zu stellen, sondern den Kunden.
Deine erste Reaktion sollte also nicht sein, den Compiler zum schweigen zu bringen, sondern Dich zu fragen, warum der Compiler meckerte. Bevor Du das nicht genau verstanden hast, änderst Du an dem Code überhaupt nichts, um auf keinen Fall zu riskieren, dass Du die Fehlermeldung verlierst.

Theston schrieb:

Xin schrieb:

Theston schrieb:

Meiner Ansicht nach dürfte nur

cos_alpha = Meter/Kilogramm*Meter*Kilogramm

legal sein, denn nur das hat physikalisch einen Sinn.

Grüße vom Planeten Erde!

So langsam wird mir hier einiges klar. Das Forum muss also ein Tor in ein anderes Universum mit anderen Naturgesetzen darstellen...

Sehr gut, dass du dich an Tippfehlern aufziehst, man merkt, du hasts drauf!

Gerne doch.

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?

Du hattest Deinen Spaß, als Du mir zeigen konntest, dass meine Lösung zu blöd ist Meter/Meter von typlos zu unterscheiden und ich hatte meinen Spaß Dein Posting als sinnfrei entlarvt in der Luft zu zerreißen.
Wir hatten beide unseren Spaß, damit ist die Sache doch fair.
Wenn Du Angst hast, dass ich mir aus Dir einen Spaß mache oder ernst genommen werden möchtest, dann schreib doch einfach etwas Entsprechendes.

Hier wird soviel Sch.... gepostet und dann erklärt, dass das auch noch ein Argument ist und ob Du das als Beleidigung auffasst oder nicht - was Du gepostet hast hatte auch nicht mehr Wert, wenn es keinen Tippfehler hätte. Durch den Tippfehler war es wenigstens noch amüsant.

chrische5 schrieb:

Nur mal eine Zusammenfassung deiner Art in nur einem Posting. Vielleicht solltest du wirklich langsam anfangen auch dein eigenes Verhalten nicht als unfehlbar einzuschätzen. Du regst dich auf, dass du nicht ernst genommen wirst und lässt hier eine dermaßen überhebliche Art durchscheinen. Keine Ahnung, ob es hilft, aber sie es als konstruktive Kritik.

Ich stehe hier seit bald 30 Seiten im Kreuzfeuer und jeder postet hier ohne 2 Sekunden nachzudenken wertlose Argumente. Was Shade da grade "argumentiert" ist alles, abgesehen von Typsicherung.
Theston ist dafür ein schönes Beispiel - guckt sich das Template nicht an, behauptet, dass es Meter/Meter abbildet, baut auch noch einen Tippfehler ein, der dazu führt, dass es nur physikalisch Sinn macht, Winkel in Quadratmetern zu messen und wundert sich dann, dass ich ihn nicht für voll nehme?
Ich soll hier brav eine Antwort schreiben. Das habe ich jetzt 25 Seiten gemacht. Ich bin keine kostenlose Servicenummer.

Seit 15 Seiten kippt jeder hier mal seinen geistigen Abfall rein und erwartet, dass ich mir die Zeit nehme, das freundlich lächelnd wieder sauberzu machen und dabei nichts äußere, was Kritik vermuten lässt.

Wer den Mut hat, ohne zu denken zu posten, muss auch ertragen, wenn er dafür nicht in den Himmel gelobt wird.

Wenn es überheblich ist, auf Denkfehler hinzuweisen und Texte, die bereits vor 20 Seiten Seiten erklärt wurden nur noch zu in der Luft zu zerreißen, dann ist es halt so. Eine Diskussion ist nunmal nicht möglich in dem man Gegenargumente analysiert und anschließend auseinandernimmt oder anerkennt. Ich nehme hier mehr auseinander als ich anerkenne. Würde hier nicht soviel Unsinn behauptet, könnte ich mehr anerkennen und ich würde nicht so überheblich wirken. Leider kann ich die Qualität der Beiträge nicht steuern.

Wer werden hier aber auch nicht mehr weiterkommen, wir bewegen uns an einer Grenze von C++.
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.
Es gibt Gründe, warum ich eine eigene Programmiersprache schreibe und das ist nunmal, dass C++ auch hier Grenzen setzt, die ich gerne überschreiten möchte, weil ich mit den Lösungen hier auch nicht zufrieden bin.
Aber mehr haben wir nicht und mehr können wir in C++ nicht erreichen, ob "ihr" nun davon begeistert seid oder nicht.