Methoden mit bool-Parametern und "Lesbarkeit" im Kontext
-
Xin schrieb:
Anstatt mich darüber zu ärgern, dass ich das nicht kompilieren kann, habe ich wenigstens ein Ergebnis.
Das ist also die viel gelobte Qualität deiner Software?
Vielleicht ist es besser nicht ganz so schöne Syntax zu haben sondern lieber etwas mehr Sicherheit im Code zu haben
-
Xin schrieb:
Nur eine paar Zeilen weiter steht, warum es doch Sinn ergibt, wenn der Compiler grade die passende Formelsammlung nicht parat hat.
Man gestattet also unsinnige Operationen weil?
Xin schrieb:
Abgesehen davon, werden sich die Mathematiker nicht geschlagen fühlen, immerhin müssen sie zur Zeit damit leben, dass alles nur typlose Integer (bzw. Floats) sind.
Der Mathematiker wundert sich über Integer / Float nicht, denn die verschiedenen Zahlensysteme sind bis auf einige Ausnahmen, wie die rationalen, komplexen, ..., gut umgesetzt. (Lisp wäre gründlicher aber es reicht auch so)
Nur wenn man schon eine Maßeinheit einführt, dann sollte man diese auch in Berechnungen beachten.
Der Mathematiker wird sich wundern, wenn aus Meter plus Gramm eine natürliche Zahl entsteht.
(Hmmm, eigentlich sind es eher die Physiker)Aber was nutzt eine Klasse Meter, wenn ich Werte daraus mit Gewicht addieren kann und das Resultat ein Integer ist?
Wozu dann die extra Klasse überhaupt?
-
2am schrieb:
Wenn ich Code schreibe, möchte ich doch Details der Implementierung möglichst zentral halten und vor dem Aufrufer verbergen:
if (window & WindowFlags::UseFullscreen) // schlecht if (window.isFullscreen()) // besserVom Prinzip her habe ich da kein Problem mit, es lässt sich auch problemlos in eine Klasse WindowFlags einbrinen.
Was mir hier fehlt sind zusammenhängende Abfragen:if( window & ( WindowFlags::UseFullScreen | WindowFlags::HasFocus ) )
Ich schätze auch die 5 Takte, die man hier spart, insbesondere bei Flags, die in stark zu optimierenden Algorithmen auftauchen. Das fehlt mir beim Aufruf von Funktionen (selbst, wenn sie inline kompiliert werden).
Ich entwickle grundsätzlich optimierungskritisch, d.h. eine (inline-)Funktion wie isFullscreen wird bei mir nur dann benutzt, wenn ich auch wirklich ausschließlich das eine Flag abfragen möchte.2am schrieb:
Mein Lösungsansatz in Sachen Fenster sieht übrigens so aus:
Ich habe seit Jahren zwei Dateien; in der einen ist der Code zum Öffnen eines Win32-Fensters, in der anderen das ganze für X11. Es ist sperrig, es ist hässlich. Ich habe keine Sekunde daran verschwendet, dies in eine OOP-Struktur zu integrieren. Aber der Code ist ausgiebig getestet und x-mal von mir wiederverwendet worden, jedesmal per copy&paste binnen Sekunden. Wenn ihr mit einer Fensterklasse diese Wiederverwendungsrate erreichen wollt, müsst ihr noch verdammt oft vererben und komposi... äh... ihr wisst schon.So habe ich früher auch mal gearbeitet. Inzwischen lagere ich alle interessanten Klassen und Algorithmen in ein Framework aus und alle Programme nutzen das identische Framework. Weiterentwicklungen werden über SVN wieder zusammengeführt.
Shade Of Mine schrieb:
Xin schrieb:
Anstatt mich darüber zu ärgern, dass ich das nicht kompilieren kann, habe ich wenigstens ein Ergebnis.
Das ist also die viel gelobte Qualität deiner Software?
Eleganz vor Frikelei. Machbarkeit vor Eleganz.
Shade Of Mine schrieb:
Vielleicht ist es besser nicht ganz so schöne Syntax zu haben sondern lieber etwas mehr Sicherheit im Code zu haben
Mit Einheiten zu rechnen bietet a) mehr Sicherheit und b) sorgt für kompaktere und leichter lesbare Parameterlisten. Wenn dies nicht möglich ist, mache ich das selbe wie jeder andere.
Kommt man von höherer Typsicherheit also wieder auf das Normalmaß herunter, hat man keinen Verlust.Tellerrand schrieb:
Xin schrieb:
Nur eine paar Zeilen weiter steht, warum es doch Sinn ergibt, wenn der Compiler grade die passende Formelsammlung nicht parat hat.
Man gestattet also unsinnige Operationen weil?
Man nicht garantieren kann, dass sie unsinnig sind und zumindest ich möchte keine Möglichkeiten einschränke, die ich nicht verstehe.
Was ist Gewicht * Strecke? Was ist Zeit im Quadrat?
Gewicht * Strecke / Zeit / Zeit ist jedenfalls Kraft.Was ich verstehe ist, dass ich nicht ungefragt irgendwas auf einen festgelegten Typ zuweisen kann.
Wenn ich also 4 Kühlschränke mit 3 Broten addiere, dann erhalte ich 7 Objekte. Objekte kann man zählen. Warum sollte ich das verbieten?Tellerrand schrieb:
Xin schrieb:
Abgesehen davon, werden sich die Mathematiker nicht geschlagen fühlen, immerhin müssen sie zur Zeit damit leben, dass alles nur typlose Integer (bzw. Floats) sind.
Der Mathematiker wundert sich über Integer / Float nicht, denn die verschiedenen Zahlensysteme sind bis auf einige Ausnahmen, wie die rationalen, komplexen, ..., gut umgesetzt. (Lisp wäre gründlicher aber es reicht auch so)
Nur wenn man schon eine Maßeinheit einführt, dann sollte man diese auch in Berechnungen beachten.Bin ich absolut dafür. Aber wenn man Maßeinheiten einführt und eine Rechnung nicht vom Compiler nicht verstanden wird, weil der Entwickler etwas neues macht, dann ist es nicht Aufgabe der Sprache ihm das grundsätzlich zu verbieten.
Am Rande, in meiner kleinen Umfrage zum Thema Programmiersprachen, äußerten sich auch Mathematiker über die fehlenden Ausdrucksmöglichkeiten durch Programmiersprachen.
Von daher bin ich vorsichtig, wenn Menschen aus dem Informatik-Umfeld darüber spekulieren, dass Mathematiker, Physiker usw. die Ideen der Informatiker so toll finden. Auch hier schadet ein gelegentlicher Perspektivenwechsel nicht.Tellerrand schrieb:
Aber was nutzt eine Klasse Meter, wenn ich Werte daraus mit Gewicht addieren kann und das Resultat ein Integer ist?
Wozu dann die extra Klasse überhaupt?Wozu? Damit Du weißt, dass ein Meter plus ein Meter wieder ein Meter ergibt. Oder ein Meter * Meter einen Quadratmeter. Das ist ein Mehrwert und ein Mehrwert rechtfertigt eine Klasse.
Da wo Du es nicht weißt, hast Du nicht mehr als zuvor - aber eben auch nicht weniger.
Woher soll ich wissen, wem Meter + Gewicht hilft? Ich kann garantieren, dass ein class Meter + ein class Meter wieder ein class Meter ergibt. Wie soll ich garantieren, dass Meter + Gewicht grundsätzlich sinnlos ist? Wenn ich das nicht garantieren kann, wie soll ich dann eine Einschränkung begründen?
Vor dem BMI gab es diese "Formel" für richtiges Gewicht: Gewicht = Groesee - 100
Mathematisch bedeutet das auch Groesse = Gewicht + 100cm
Wenn jemand das rechnen will, warum sollte ich ihm das verbieten?
Soll er doch rechnen. Was die Sprache nicht darf, ist ein solches Ergebnis kritiklos einem Typ wie Meter zuweisen.
Bei Gewicht + 100cm kommt beispielsweise typlose 175 raus. Wenn ich das einer Größe zuordnen will, dann muss ich das bestätigen: Groesse = Zentimeter( Gewicht + 100 );Ich muss verstehen, was meine Einschränkung bedeutet und dafür garantieren, dass sie nützlich ist. Verbaue ich einem Entwickler etwas, so dass dieser auf Workarounds o.ä. umsteigen muss, habe ich aus Unverständnis einen Fehler begangen.
Ich sehe mich nicht in der Lage alle mathematischen und physikalischen Formen, die existieren und in Zukunftexistieren werden, in meinen Klassen abzubilden. Deswegen darf ich aber nicht die Kreativität der Entwickler enschränken.Tellerrand schrieb:
Anderst wird es noch deutlicher (und lustiger) ... 3 Bäume - 8 Häuser = ?
Es macht definitiv keinen Sinn solch eine Frage zu stellen!Bei der Rechnung würden hier typlose -5 Objekte herauskommen. Und? Das stimmt doch.
3 Personen sind im Fahrstuhl, 8 steigen aus, wieviele müssen einsteigen, damit der Fahrstuhl leer ist?
Nur weil die Frage in der Realität keinen Sinn ergibt, lässt sich das mathematisch problemlos ausrechnen.
Mathematisch lassen sich aus negativen Zahlen Wurzeln ziehen, aber nur weil ich das beim Kauf eines Grundstücks die Kantenlänge einer negativen Baufläche in der Regel nicht verstehe, muss das mathematisch nicht sinnlos sein.Ich bin da eher vorsichtig, wenn ich nicht sicher bin, ob nicht doch jemand für derartiges eine sinnvolle Anwendung findet.
Ich kann verstehen, dass ich auf eine Variable für Äpfel nicht ungefragt Birnen zuweisen kann. Trotzdem muss ich es erlauben, wenn der Entwickler das so für richtig hält. Mein Job ist es hierbei eine Hilfe zu bieten, kein Verbot.
Birne b = Birne( 3 ); Apfel a = Apfel( b );
-
Ohne jetzt die vollen 13 Seiten gelesen zu haben:
Ich kann verstehen, dass ich auf eine Variable für Äpfel nicht ungefragt Birnen zuweisen kann. Trotzdem muss ich es erlauben, wenn der Entwickler das so für richtig hält. Mein Job ist es hierbei eine Hilfe zu bieten, kein Verbot.
Birne b = Birne( 3 ); Apfel a = Apfel( b );Würde das nicht bedeuten, das Apfel für alle Typen eine Konvertierung anbieten muss ? Wenn nicht, verbietet die Sprache die Konvertierung von T nach Apfel.
Wie schaut denn nun die Hilfe aus um T in einen Apfel zu konvertieren ?
-
Xin schrieb:
(...)
if( window & ( WindowFlags::UseFullScreen | WindowFlags::HasFocus ) )Ich schätze auch die 5 Takte, die man hier spart, insbesondere bei Flags, die in stark zu optimierenden Algorithmen auftauchen. Das fehlt mir beim Aufruf von Funktionen (selbst, wenn sie inline kompiliert werden).
Ich entwickle grundsätzlich optimierungskritisch, d.h. eine (inline-)Funktion wie isFullscreen wird bei mir nur dann benutzt, wenn ich auch wirklich ausschließlich das eine Flag abfragen möchte.Vor jeder Optimierung sollte eine Prüfung der Notwendigkeit und der Machbarkeit stehen. In C++ zu programmieren, und dabei in Takten zu denken ist ziemlich sinnlos. Du weisst ja nicht, was der Compiler daraus macht und noch viel weniger, was am besten für aktuelle hochoptimierende Multikern-Prozessoren ist.
(Selbst wenn meine Unterstellung falsch ist, weisst du sicher nicht, was die nächste Compilergeneration aus deinem Code macht und wie der auf der nächsten Prozessorgeneration läuft.)Darüberhinaus wird eine Prüfung der speziellen Form (WindowFlags::Dieses | WindowFlags::Jenes) eher nicht innerhalb kritischer Schleifen auftauchen, ist es doch "loop invariant code".
-
Knuddlbaer schrieb:
Ohne jetzt die vollen 13 Seiten gelesen zu haben: [...]
Würde das nicht bedeuten, das Apfel für alle Typen eine Konvertierung anbieten muss ? Wenn nicht, verbietet die Sprache die Konvertierung von T nach Apfel.Wie schaut denn nun die Hilfe aus um T in einen Apfel zu konvertieren ?
Es lohnt deswegen nicht, die letzten 13 Seiten nachzulesen, aber die Antwort ist nein.
In dem Fall handelt es sich um eine Ableitung von int, wobei die Klassen einen expliziten Konstruktor für int besitzen. (Ja, es ist bekannt, dass das kein C++ ist...)
Ansonsten nehme man operator int().2am schrieb:
Xin schrieb:
(...)
if( window & ( WindowFlags::UseFullScreen | WindowFlags::HasFocus ) )Ich schätze auch die 5 Takte, die man hier spart, insbesondere bei Flags, die in stark zu optimierenden Algorithmen auftauchen. Das fehlt mir beim Aufruf von Funktionen (selbst, wenn sie inline kompiliert werden).
Ich entwickle grundsätzlich optimierungskritisch, d.h. eine (inline-)Funktion wie isFullscreen wird bei mir nur dann benutzt, wenn ich auch wirklich ausschließlich das eine Flag abfragen möchte.Vor jeder Optimierung sollte eine Prüfung der Notwendigkeit und der Machbarkeit stehen.
Man kann sich auch angewöhnen, manche Dinge grundsätzlich in optimaler Form zu schreiben.
Insbesondere dann, wenn die optimale Form schneller zu schreiben ist, als über die Möglichkeit einer Prüfung nachzudenken.2am schrieb:
In C++ zu programmieren, und dabei in Takten zu denken ist ziemlich sinnlos. Du weisst ja nicht, was der Compiler daraus macht und noch viel weniger, was am besten für aktuelle hochoptimierende Multikern-Prozessoren ist.
Ich weiß, was ein zustandsbasiertes System daraus machen kann.
In dem Fall spielt es keine Rolle, ob hier eine 386er CPU oder ein Quadcore-Cluster auf die Anweisung stößt.
Was ich weiß ist, dass ein Compiler viel optimieren kann und diese Details schlecht erkennen kann. Also wozu ihm die Arbeit nicht ersparen und mir garantieren, dass die Optimierung stattfindet?2am schrieb:
(Selbst wenn meine Unterstellung falsch ist, weisst du sicher nicht, was die nächste Compilergeneration aus deinem Code macht und wie der auf der nächsten Prozessorgeneration läuft.)
Solange sich die grundlegende Idee eines Computers nicht ändert, ändert sich grade an dieser Anweisung definitiv nichts mehr. Es ist eine der grundlegendsten Anweisungen, die man überhaupt machen kann.
Entsprechend ist die Anweisung von einem 386er genauso schnell (in Takten) verarbeitet, wie von einem Quadcore-Cluster. Schneller als 1 Takt geht auf getakteten Systemen nicht.2am schrieb:
Darüberhinaus wird eine Prüfung der speziellen Form (WindowFlags::Dieses | WindowFlags::Jenes) eher nicht innerhalb kritischer Schleifen auftauchen, ist es doch "loop invariant code".
Loop invariant?
Wenn hier ein Compiler was brauchbar optimiert, ist bleibt hier keine Variable sondern nur eine Konstante über. Konstanten sind allgemein äußerst invariant und ihr Wert ist im Vergleich zu zwei Funktionsaufrufen auch sehr schnell auszurechnen.
Und das soll eine Optimierung ja erreichen, möglichst wenig Arbeit, um schnell zu Ergebnissen zu kommen.
while( window.isDieses() && window.isJenes() ) lässt sich nunmal nicht auslagern und der Compiler muss verdammt klever sein, wenn er die zwei Funktionsaufrufe zu einem while( window.flags & (dieses|jenes) ) umwandeln kann.
-
Xin schrieb:
Eleganz vor Frikelei. Machbarkeit vor Eleganz.
Bei mir geht es so rum:
Stabilität über allem.Vorallem da Eleganz sehr subjektiv ist.
Mit Einheiten zu rechnen bietet a) mehr Sicherheit und b) sorgt für kompaktere und leichter lesbare Parameterlisten. Wenn dies nicht möglich ist, mache ich das selbe wie jeder andere.
Kommt man von höherer Typsicherheit also wieder auf das Normalmaß herunter, hat man keinen Verlust.Ich sehe da absolut keine Sicherheit wenn ich Kilogramm + Meter addieren kann. Und du hast es selber gesagt, dass da quark rauskommt aber es kompiliert wird.
Man nicht garantieren kann, dass sie unsinnig sind und zumindest ich möchte keine Möglichkeiten einschränke, die ich nicht verstehe.
Es ist deine Klasse in deiner Domain und du kannst nicht die Operationen der Klasse definieren? Das ist fragwürdig.
Soll ich deshalb immer einen Template Konvertierungsoperator anbieten der halt rand() returned damit jedeweder Code kompiliert?
C++ bietet hier typsicherheit an um eine Menge an Fehlern vorzubeugen. Das beste Beispiel ist wohl dieser Thread hier. Wieviele Probleme wurden bei der Vererbung von WinFlags -> Win aufgezählt und an wieviele hast du davor gedacht?
Das alles sind potentielle Fehler in der Software - und für was? Was ist der große Vorteil davon dass man die Typsicherheit über Board wirft? Eine einfachere Syntax.
Was ist Gewicht * Strecke? Was ist Zeit im Quadrat?
Gewicht * Strecke / Zeit / Zeit ist jedenfalls Kraft.Und was spricht dagegen dafür explizit etwas zu definieren? Ich kann jederzeit operatoren definieren damit Gewicht*Strecke/Zeit ein Objekt der Klasse Kraft liefert. Das Problem ist, wenn du daraus reine integers machst, verlierst du die komplette Typsicherheit und du kannst dir die Klassen sparen - rechne gleich mit integern - ist deutlich simpler und weniger aufwendig.
Kommen wir auf die einfachere Syntax zurück:
Ich kann jederzeit ein Kraft Objekt erstellen indem ich:Kraft k(g.asInt() * s.asInt() / z.asInt());schreibe.
Das ist syntaktisch nicht schön, aber man erkennt sofort dass hier etwas außergewöhnliches passiert. Natürlich nur wenn ich hier nicht die Operatoren passend überladen will (passend im Sinne von, dass kein Gewicht * Zeit ein Kraft Objekt liefert).
Dadurch erreiche ich eine Typsicherheit ohne einbussen der Funktionalität auf kosten einer (unter Umständen) komplizierteren Syntax. Denn um mehr geht es nicht - es geht nach wie vor nur um Syntax. Und ich denke nicht dass Syntax es wert ist dafür potentielle Fehler einzubauen. Allein der 1. Ansatz deiner WinFlags war voller Fehler. Keiner dieser Fehler wäre bei Komposition aufgetreten. Und technisch wären beide gleichwertig - lediglich Sicherheit <-> Syntax.
@Knuddlbaer:
Apfel muss nur eine Konvertierung für den Basistypen von Birne anbieten:struct Flags { }; struct Win : public Flags { Win(Flags f=Flags()) {} }; struct Socket : public Flags { Socket(Flags f=Flags()) {} }; int main() { Win w; Socket s(w); }Das Problem dabei ist halt: Win und Socket haben nichts gemeinsam. Sie haben lediglich ein gleiches Property. Wenn wir nun aber von dem Property public erben - passieren viele solcher Sachen. Es hat einen Grund warum es den Leitsatz gibt: Make sure inheritance models an is-a relationship.
-
@Side naja, das verständnisproblem kam daher, das ich diesem Thread nicht gefolgt bin. Ich hab daher die Aussage
Ich kann verstehen, dass ich auf eine Variable für Äpfel nicht ungefragt Birnen zuweisen kann. Trotzdem muss ich es erlauben, wenn der Entwickler das so für richtig hält. Mein Job ist es hierbei eine Hilfe zu bieten, kein Verbot.
Code:
Birne b = Birne( 3 );
Apfel a = Apfel( b );Allgemeiner gesehen als
T t = T(U);Man hat ja auch Häuser von Bäumen abgezogen und Butterbrote addiert =o) Ich schmöcker mal, scheint doch viel interesanntes in den langen Threads zu stecken.
-
Shade Of Mine schrieb:
Xin schrieb:
Eleganz vor Frikelei. Machbarkeit vor Eleganz.
Bei mir geht es so rum:
Stabilität über allem.Vorallem da Eleganz sehr subjektiv ist.
Stabilität sowieso. Bzgl. Eleganz gibt es durchaus einige Dinge, die man beachten kann und die haben häufig nichts mit festgelegten Regeln von Einrücken zu tun.
Da die Sache natürlich subjektiv bleibt, ist jede öffentliche Äußerung in die Richtung zur Kritik verdammt und grade hier spare ich mir das lieber.
Shade Of Mine schrieb:
Mit Einheiten zu rechnen bietet a) mehr Sicherheit und b) sorgt für kompaktere und leichter lesbare Parameterlisten. Wenn dies nicht möglich ist, mache ich das selbe wie jeder andere.
Kommt man von höherer Typsicherheit also wieder auf das Normalmaß herunter, hat man keinen Verlust.Ich sehe da absolut keine Sicherheit wenn ich Kilogramm + Meter addieren kann. Und du hast es selber gesagt, dass da quark rauskommt aber es kompiliert wird.
Hier wird wieder frei interpretiert. Ich sagte nicht "Quark". Ich sagte typlos. Das bedeutet, dass der Typ nicht aussagt, was man damit anfangen kann. Wenn der Compiler nicht weiß, was man damit anfangen kann, heißt das nicht, dass der Entwickler mit der Information damit nichts anfangen kann.
Shade Of Mine schrieb:
Man nicht garantieren kann, dass sie unsinnig sind und zumindest ich möchte keine Möglichkeiten einschränke, die ich nicht verstehe.
Es ist deine Klasse in deiner Domain und du kannst nicht die Operationen der Klasse definieren? Das ist fragwürdig.
Sorry, aber das hier steht in keinem Zusammenhang zu meinen Klassen, was Dir bewußt sein dürfte, da in C++ nicht von int geerbt werden kann.
Operatoren zu den Klassen kann ich problemlos aufzählen und dazu gehören nunmal auch die geerbten, da ich sie nicht verbieten würde, also die Möglichkeiten nicht einschränke.
Shade Of Mine schrieb:
Soll ich deshalb immer einen Template Konvertierungsoperator anbieten der halt rand() returned damit jedeweder Code kompiliert?
Soll ich auf Dein Posting antworten oder möchtest Du nur ein wenig herumsticheln, dann kann ich mir das auch schenken.
Shade Of Mine schrieb:
C++ bietet hier typsicherheit an um eine Menge an Fehlern vorzubeugen. Das beste Beispiel ist wohl dieser Thread hier. Wieviele Probleme wurden bei der Vererbung von WinFlags -> Win aufgezählt und an wieviele hast du davor gedacht?
Erstens sehe ich bei der Vererbung weiterhin kein zu großes Problem. if( win ) ist eine Definition, die sich aus der Vererbung ergibt, die CStoll und Dir nicht gefallen. Mir gefällt es auch nicht sonderlich, aber ein Problem habe ich damit nicht.
Shade Of Mine schrieb:
Das alles sind potentielle Fehler in der Software - und für was? Was ist der große Vorteil davon dass man die Typsicherheit über Board wirft? Eine einfachere Syntax.
Das hat grade nichts mit klassifizierten Einheiten zu tun...?
Shade Of Mine schrieb:
Was ist Gewicht * Strecke? Was ist Zeit im Quadrat?
Gewicht * Strecke / Zeit / Zeit ist jedenfalls Kraft.Und was spricht dagegen dafür explizit etwas zu definieren?
Nichts und ich habe auch nicht behauptet, dass etwas dagegen sprechen würde.
Trotzdem kann es sein, dass man diese Typen aus einer Lib nimmt und erstmal feststellt, dass eine Konvertierung nicht dabei ist.
Shade Of Mine schrieb:
Ich kann jederzeit operatoren definieren damit Gewicht*Strecke/Zeit ein Objekt der Klasse Kraft liefert. Das Problem ist, wenn du daraus reine integers machst, verlierst du die komplette Typsicherheit und du kannst dir die Klassen sparen - rechne gleich mit integern - ist deutlich simpler und weniger aufwendig.
Ich verliere die Typsicherheit nicht. Ein Typ ist nur dann gegeben, wenn es sicher ist, ihn zu benennen. Ansonsten darf gerechnet werden, aber der Entwickler bekommt eine typlose Information.
Er kann nun entweder etwas passendes definieren, oder muss die Verantwortung dafür übernehmen, eine typlose Information zu klassifizieren.
Shade Of Mine schrieb:
Kommen wir auf die einfachere Syntax zurück:
Ich kann jederzeit ein Kraft Objekt erstellen indem ich:Kraft k(g.asInt() * s.asInt() / z.asInt());schreibe.
Richtig, kannst Du. Das ist eine andere Möglichkeit. Es spricht nichts dagegen - aber in meinen Augen auch nichts dafür im Vergleich zu einer (theoretisch möglichen) Ableitung.
Shade Of Mine schrieb:
Dadurch erreiche ich eine Typsicherheit ohne einbussen der Funktionalität auf kosten einer (unter Umständen) komplizierteren Syntax.
Falsch. Du erreichst nicht mehr Typsicherheit, der einzige Unterschied ist, dass Du bei jeder Variable "asInt()" dahinter schreiben musst. Du erhältst also wieder ein typloses int.
In meinem Fall wird - sofern nicht typsicher gerechnet werden kann - mit ints gerechnet und Du erhältst ebenfalls ein typloses int.
In beiden Fällen kannst Du das typlose int nicht zuweisen. Du gewinnst also mit asInt keinen Vorteil.Shade Of Mine schrieb:
Denn um mehr geht es nicht - es geht nach wie vor nur um Syntax. Und ich denke nicht dass Syntax es wert ist dafür potentielle Fehler einzubauen. Allein der 1. Ansatz deiner WinFlags war voller Fehler. Keiner dieser Fehler wäre bei Komposition aufgetreten. Und technisch wären beide gleichwertig - lediglich Sicherheit <-> Syntax.
Ich weiß nicht, von welchen Fehlern Du sprichst. Was ich beschrieb, funktioniert problemlos und korrekt - auch unter Mehrfachvererbung, sobald Du die Operatoren in den Namensraum der Klasse holst.
Shade Of Mine schrieb:
@Knuddlbaer:
Apfel muss nur eine Konvertierung für den Basistypen von Birne anbieten:struct Flags { }; struct Win : public Flags { Win(Flags f=Flags()) {} }; struct Socket : public Flags { Socket(Flags f=Flags()) {} }; int main() { Win w; Socket s(w); }Das Problem dabei ist halt: Win und Socket haben nichts gemeinsam. Sie haben lediglich ein gleiches Property. Wenn wir nun aber von dem Property public erben - passieren viele solcher Sachen. Es hat einen Grund warum es den Leitsatz gibt: Make sure inheritance models an is-a relationship.
struct Flags { }; struct Win { Flags f; Win(Flags f=Flags()) {} }; struct Socket { Flags f; Socket(Flags f=Flags()) {} }; int main() { Win w; Socket s(w.f); }Das rettet die Welt?
Wie wir sehen, haben win und socket hier etwas gemeinsames, nämlich die gleichen Flags. Und wenn das passt, dann passt das - und wenn nicht, dann fragt Socket die falschen Flags ab.
Das ist kein Vererbungs oder Kompositionsproblem, das wäre ein Designfehler - egal als ob Vererbung oder Komposition.
-
Xin schrieb:
struct Flags { }; struct Win { Flags f; Win(Flags f=Flags()) {} }; struct Socket { Flags f; Socket(Flags f=Flags()) {} }; int main() { Win w; Socket s(w.f); }Das rettet die Welt?
Es ist auf jedenfall schon mal klarer. Wenn wir nämlich nicht von Win und Socket ausgehen, sondern von etwas näher verwandten Sachen wie Win und Dialog wobei Dialog keinen CCtor für Win bietet. Da hat man so leicht mehrdeutigkeiten für den Programmierer.
Aber das lustige ist: du verteidigst immer noch nur die Nachteile - aber Vorteile nennst du immer noch keine.
Ansonsten darf gerechnet werden, aber der Entwickler bekommt eine typlose Information.
Problem ist aber:
Kraft k = gewicht * hoehe;Das wird ziemlich sicher klappen, da du eine Konvertierung von int zu Kraft haben willst - richtig?
Aber genau das ist das Problem - convenience ist nicht immer das beste. Wenn man einfach gewicht*hoehe verbietet, gibt es da keine Probleme. Und wenn ich in die seltene Situation komme wo ich das brauche, gibt es immer noch ein
Kraft k = gewicht.asInt() * hoehe.asInt();Hier sieht man dann sofort dass etwas "Typenloses" raus kommt und vom Programmierer erst interpretiert werden muss. Während das bei "gewicht * hoehe" nicht der Fall ist - es ist eine definierte Operation also erwarte ich ein vernünftiges Ergebnis.
Klar ist es schlecht diese Operation zu verbieten - aber es gibt eben Abstufungen zwischen "operation direkt implementiert im interface" und "operation möglich". Ich denke dass man gewicht mit hoehe nicht multiplizieren können muss. Dass es nicht teil des interfaces von Höhe ist diese Operation zu implementieren. Es sollte aber möglich sein wenn ich es unbedingt will.
Das führt zu sicheren Programmen da man einfach Fehler wie gewicht*hoehe wo man breite*hoehe meinte einfach zur Compilezeit eliminiert.
-
Xin schrieb:
if (window & WindowFlags::UseFullscreen) // schlecht if (window.isFullscreen()) // besserVom Prinzip her habe ich da kein Problem mit, es lässt sich auch problemlos in eine Klasse WindowFlags einbrinen.
Was mir hier fehlt sind zusammenhängende Abfragen:if( window & ( WindowFlags::UseFullScreen | WindowFlags::HasFocus ) )
[/quote]Und da sind wir wieder bei der semantischen Frage: Was bedeutet diese Abfrage? "Das Fenster hat beide Flags"? Oder doch "Das Fenster hat mindestens eins der Flags"? (Mit der für int üblichen Bedeutung, die du bisher als Rechengrundlage genommen hast, ist es letzteres)Xin schrieb:
Shade Of Mine schrieb:
Xin schrieb:
Anstatt mich darüber zu ärgern, dass ich das nicht kompilieren kann, habe ich wenigstens ein Ergebnis.
Das ist also die viel gelobte Qualität deiner Software?
Eleganz vor Frikelei. Machbarkeit vor Eleganz.
Und wo steht in deiner Prioritätenliste die Typsicherheit? Soweit ich das überblicke, sehr weit unten.
Xin schrieb:
Shade Of Mine schrieb:
Vielleicht ist es besser nicht ganz so schöne Syntax zu haben sondern lieber etwas mehr Sicherheit im Code zu haben
Mit Einheiten zu rechnen bietet a) mehr Sicherheit und b) sorgt für kompaktere und leichter lesbare Parameterlisten. Wenn dies nicht möglich ist, mache ich das selbe wie jeder andere.
Kommt man von höherer Typsicherheit also wieder auf das Normalmaß herunter, hat man keinen Verlust.Ja, solange man mit Einheiten rechnet und nicht nur mit aufbereiteten int's - indem du alle Einheiten von int ableitest, pulverisierst du dir deine heißgeliebte Typsicherheit wieder (Beispiel: Du hast eine Einheit Kraft und Weg - das Produkt davon wäre eigentlich eine Leistung, aber nun bekommst du plötzlich eine reine Zahl heraus, weil Leistung nicht in deiner Einheitensammlung erwähnt wird).
btw, außerdem brauchst du praktisch unendlich viele Einheitenkombinationen, um alle möglichen Multiplikationen darstellen zu können - mit der bereits angerissenen Template-Klasse Measure<...> hast du die alle auf einen Haufen.
Xin schrieb:
Tellerrand schrieb:
Xin schrieb:
Nur eine paar Zeilen weiter steht, warum es doch Sinn ergibt, wenn der Compiler grade die passende Formelsammlung nicht parat hat.
Man gestattet also unsinnige Operationen weil?
Man nicht garantieren kann, dass sie unsinnig sind und zumindest ich möchte keine Möglichkeiten einschränke, die ich nicht verstehe.
Was ist Gewicht * Strecke? Was ist Zeit im Quadrat?
Gewicht * Strecke / Zeit / Zeit ist jedenfalls Kraft.Gewicht*Strecke ist ein Wert, den man in kg*m angibt, Zeit im Quadrat hat die Einheit Quadratsekunden - was die physikalisch darstellen, ist erstmal bedeutungslos. Ich kann diese Zwischenwerte bei Bedarf als Measure<1,0,1,...> bzw. Measure<0,2,0,...> behandeln und miteinander verrechnen, ohne mich um ihre physikalische Bedeutung zu kümmern - der Quotient aus beidem ist ein Measure<1,-2,1,...>, also eine Kraft.
Xin schrieb:
Tellerrand schrieb:
Xin schrieb:
Abgesehen davon, werden sich die Mathematiker nicht geschlagen fühlen, immerhin müssen sie zur Zeit damit leben, dass alles nur typlose Integer (bzw. Floats) sind.
Der Mathematiker wundert sich über Integer / Float nicht, denn die verschiedenen Zahlensysteme sind bis auf einige Ausnahmen, wie die rationalen, komplexen, ..., gut umgesetzt. (Lisp wäre gründlicher aber es reicht auch so)
Nur wenn man schon eine Maßeinheit einführt, dann sollte man diese auch in Berechnungen beachten.Bin ich absolut dafür. Aber wenn man Maßeinheiten einführt und eine Rechnung nicht vom Compiler nicht verstanden wird, weil der Entwickler etwas neues macht, dann ist es nicht Aufgabe der Sprache ihm das grundsätzlich zu verbieten.
Wenn du schon Maßeinheiten einführst, solltest du auch darauf achten, daß der Compiler sie zu schätzen weiß, andernfalls sind sie nutzlos.
Xin schrieb:
Tellerrand schrieb:
Aber was nutzt eine Klasse Meter, wenn ich Werte daraus mit Gewicht addieren kann und das Resultat ein Integer ist?
Wozu dann die extra Klasse überhaupt?Wozu? Damit Du weißt, dass ein Meter plus ein Meter wieder ein Meter ergibt. Oder ein Meter * Meter einen Quadratmeter. Das ist ein Mehrwert und ein Mehrwert rechtfertigt eine Klasse.
Ja, das ist ein Mehrwert, der die Klasse rechtfertigt. Aber die implizite Behandlung des Meters als reinen int, die du durch deine (ich weiß: hypothetische) Ableitung nachgeworfen bekommst, rechtfertigst du damit noch lange nicht. Und außerdem mußt du dem Compiler noch zusätzlich sagen, daß "ein Meter plus ein Meter wieder ein Meter" bzw. "ein Meter * Meter einen Quadratmeter" ergibt - andernfalls stuft er beide als blanke int's ein.
Xin schrieb:
Woher soll ich wissen, wem Meter + Gewicht hilft? Ich kann garantieren, dass ein class Meter + ein class Meter wieder ein class Meter ergibt. Wie soll ich garantieren, dass Meter + Gewicht grundsätzlich sinnlos ist? Wenn ich das nicht garantieren kann, wie soll ich dann eine Einschränkung begründen?
Kannst du begründen, daß diese Addition irgendeinen Sinn ergibt? Wenn nein, warum willst du sie dann erlauben?
Xin schrieb:
Vor dem BMI gab es diese "Formel" für richtiges Gewicht: Gewicht = Groesee - 100
Mathematisch bedeutet das auch Groesse = Gewicht + 100cm
Wenn jemand das rechnen will, warum sollte ich ihm das verbieten?
Soll er doch rechnen. Was die Sprache nicht darf, ist ein solches Ergebnis kritiklos einem Typ wie Meter zuweisen.
Bei Gewicht + 100cm kommt beispielsweise typlose 175 raus. Wenn ich das einer Größe zuordnen will, dann muss ich das bestätigen: Groesse = Zentimeter( Gewicht + 100 );Ja, solche Formeln sind auch der Alptraum für jeden Physiker - und vermutlich auch nicht der richtige Einsatzort für ein typisiertes Einheitensystem. Und aus physikalischer Sicht würde ich die Formel eher als "Groesse/1cm == Gewicht/1kg + 100" schreiben.
Xin schrieb:
Ich sehe mich nicht in der Lage alle mathematischen und physikalischen Formen, die existieren und in Zukunftexistieren werden, in meinen Klassen abzubilden. Deswegen darf ich aber nicht die Kreativität der Entwickler enschränken.
Und darum gibt es Templates - mit denen können alle Einheiten und -kombinationen des SI-Systems mit einem Schlag erfasst werden.
(aber gib's zu, du hast dir den Ansatz noch nicht einmal angesehen)Xin schrieb:
Shade Of Mine schrieb:
Mit Einheiten zu rechnen bietet a) mehr Sicherheit und b) sorgt für kompaktere und leichter lesbare Parameterlisten. Wenn dies nicht möglich ist, mache ich das selbe wie jeder andere.
Kommt man von höherer Typsicherheit also wieder auf das Normalmaß herunter, hat man keinen Verlust.Ich sehe da absolut keine Sicherheit wenn ich Kilogramm + Meter addieren kann. Und du hast es selber gesagt, dass da quark rauskommt aber es kompiliert wird.
Hier wird wieder frei interpretiert. Ich sagte nicht "Quark". Ich sagte typlos. Das bedeutet, dass der Typ nicht aussagt, was man damit anfangen kann. Wenn der Compiler nicht weiß, was man damit anfangen kann, heißt das nicht, dass der Entwickler mit der Information damit nichts anfangen kann.
Dann solltest du dafür sorgen, daß der Compiler dein Einheitensystem versteht. Wenn ich gezwungen bin, die (typlosen) Rechenergebnisse von Hand in den richtigen Typ zu quetschen, bleibt von deiner Typsicherheit nicht mehr viel übrig.
Xin schrieb:
Shade Of Mine schrieb:
Man nicht garantieren kann, dass sie unsinnig sind und zumindest ich möchte keine Möglichkeiten einschränke, die ich nicht verstehe.
Es ist deine Klasse in deiner Domain und du kannst nicht die Operationen der Klasse definieren? Das ist fragwürdig.
Sorry, aber das hier steht in keinem Zusammenhang zu meinen Klassen, was Dir bewußt sein dürfte, da in C++ nicht von int geerbt werden kann.
Also ist alles, was nicht zu deiner Argumentation passt, unsinnig und irrelevant? Auch eine interessante Einstellung, um unbeliebten Argumenten aus dem Weg zu gehen.
Xin schrieb:
Operatoren zu den Klassen kann ich problemlos aufzählen und dazu gehören nunmal auch die geerbten, da ich sie nicht verbieten würde, also die Möglichkeiten nicht einschränke.
Hast du schonmal daran gedacht, daß int zu viele Operatoren zur Verfügung stellt, um es als Ausgangsbasis für ein typsicheres Einheitensystem dienen zu können? Wenn ich sowas entwerfe, beginne ich lieber bei einer leeren Klasse und definiere mir genau die Operationen, die ich als nötig ansehe. Dann muß ich mir keinen Kopf darüber machen, welche geerbten Operatoren Sinn machen - bzw. wie ich ihr Ergebnis interpretieren soll.
Xin schrieb:
Shade Of Mine schrieb:
C++ bietet hier typsicherheit an um eine Menge an Fehlern vorzubeugen. Das beste Beispiel ist wohl dieser Thread hier. Wieviele Probleme wurden bei der Vererbung von WinFlags -> Win aufgezählt und an wieviele hast du davor gedacht?
Erstens sehe ich bei der Vererbung weiterhin kein zu großes Problem. if( win ) ist eine Definition, die sich aus der Vererbung ergibt, die CStoll und Dir nicht gefallen. Mir gefällt es auch nicht sonderlich, aber ein Problem habe ich damit nicht.
if(win) ist eine Möglichkeit, die dein Entwurf bietet - zwar technisch unsinnig, aber trotzdem verfügbar. In einem vernüftigen Design sollten solche unsinnigen Anweisungen gar nicht erst möglich sein.
Xin schrieb:
Shade Of Mine schrieb:
Das alles sind potentielle Fehler in der Software - und für was? Was ist der große Vorteil davon dass man die Typsicherheit über Board wirft? Eine einfachere Syntax.
Das hat grade nichts mit klassifizierten Einheiten zu tun...?
Shade Of Mine schrieb:
Was ist Gewicht * Strecke? Was ist Zeit im Quadrat?
Gewicht * Strecke / Zeit / Zeit ist jedenfalls Kraft.Und was spricht dagegen dafür explizit etwas zu definieren?
Nichts und ich habe auch nicht behauptet, dass etwas dagegen sprechen würde.
Trotzdem kann es sein, dass man diese Typen aus einer Lib nimmt und erstmal feststellt, dass eine Konvertierung nicht dabei ist.
Shade Of Mine schrieb:
Ich kann jederzeit operatoren definieren damit Gewicht*Strecke/Zeit ein Objekt der Klasse Kraft liefert. Das Problem ist, wenn du daraus reine integers machst, verlierst du die komplette Typsicherheit und du kannst dir die Klassen sparen - rechne gleich mit integern - ist deutlich simpler und weniger aufwendig.
Ich verliere die Typsicherheit nicht. Ein Typ ist nur dann gegeben, wenn es sicher ist, ihn zu benennen. Ansonsten darf gerechnet werden, aber der Entwickler bekommt eine typlose Information.
Nur ist es immer schlecht, wenn der Entwickler dem Compiler explizit sagen muß, was für ein Typ da auftritt. Wer in der Lage ist (oder sogar gezwungen wird), das Ergebnis von "Gewicht*Strecke/Zeit/Zeit" in eine Kraft umzucasten, nur weil der Compiler nicht selbst erkennt, womit er rechnet, wird genauso schnell anfangen, beliebige Rechenergebnisse in beliebige Einheiten zu konvertieren - und schon ist dein Typsystem im Eimer.
Xin schrieb:
Er kann nun entweder etwas passendes definieren, oder muss die Verantwortung dafür übernehmen, eine typlose Information zu klassifizieren.
Shade Of Mine schrieb:
Kommen wir auf die einfachere Syntax zurück:
Ich kann jederzeit ein Kraft Objekt erstellen indem ich:Kraft k(g.asInt() * s.asInt() / z.asInt());schreibe.
Richtig, kannst Du. Das ist eine andere Möglichkeit. Es spricht nichts dagegen - aber in meinen Augen auch nichts dafür im Vergleich zu einer (theoretisch möglichen) Ableitung.
Shade Of Mine schrieb:
Dadurch erreiche ich eine Typsicherheit ohne einbussen der Funktionalität auf kosten einer (unter Umständen) komplizierteren Syntax.
Falsch. Du erreichst nicht mehr Typsicherheit, der einzige Unterschied ist, dass Du bei jeder Variable "asInt()" dahinter schreiben musst. Du erhältst also wieder ein typloses int.
In meinem Fall wird - sofern nicht typsicher gerechnet werden kann - mit ints gerechnet und Du erhältst ebenfalls ein typloses int.
In beiden Fällen kannst Du das typlose int nicht zuweisen. Du gewinnst also mit asInt keinen Vorteil.Da lobe ich mir doch die (oben erwähnte) Template-Variante - ich kann "Kraft k = g*s/(t*t);" schreiben und der Compiler wird mich darauf aufmerksam machen, wenn ich irgendwo in dieser Rechnung eine Einheit durcheinandergeworfen habe. Keine Probleme mit impliziten oder expliziten Umwandlungen nach int in Sichtweite.
Xin schrieb:
Shade Of Mine schrieb:
Denn um mehr geht es nicht - es geht nach wie vor nur um Syntax. Und ich denke nicht dass Syntax es wert ist dafür potentielle Fehler einzubauen. Allein der 1. Ansatz deiner WinFlags war voller Fehler. Keiner dieser Fehler wäre bei Komposition aufgetreten. Und technisch wären beide gleichwertig - lediglich Sicherheit <-> Syntax.
Ich weiß nicht, von welchen Fehlern Du sprichst. Was ich beschrieb, funktioniert problemlos und korrekt - auch unter Mehrfachvererbung, sobald Du die Operatoren in den Namensraum der Klasse holst.
Falls du es noch nicht bemerkt hast, wir sprechen hier nicht von Fehlern im Sinne von "syntaktisch falsch", sondern von Fehlern im Design - aber die hast du ja bisher erfolgreich ignoriert.
-
Shade Of Mine schrieb:
Xin schrieb:
Das rettet die Welt?
Es ist auf jedenfall schon mal klarer.
Wenn Dich das überzeugt... mir soll's recht sein. Wenn Socket und Window Gemeinsamkeiten haben, dann soll mir das recht sein - dann interessiert mich auch nicht, um welche es sich handelt, wenn ich einen Socket anhand eines Fensters konstruiere. Sollte es mich doch interessieren, hätte ich das entsprechend ausgedrückt.
Socket s( Flags( w ) );
Shade Of Mine schrieb:
Aber das lustige ist: du verteidigst immer noch nur die Nachteile - aber Vorteile nennst du immer noch keine.
Ich verteidige keine Nachteile, ich verteidige eine legitime Möglichkeit davor kaputtgeredet zu werden.
Spaßig empfinde ich das aber auch nicht mehr.Shade Of Mine schrieb:
Ansonsten darf gerechnet werden, aber der Entwickler bekommt eine typlose Information.
Problem ist aber:
Kraft k = gewicht * hoehe;Das wird ziemlich sicher klappen, da du eine Konvertierung von int zu Kraft haben willst - richtig?
Ich rede bei euch beiden echt gegen eine Wand, hmm? Ich schreibe die ganze Zeit, dass genau derartiger Unsinn nicht klappt. Zum einen direkt, zum anderen frage ich mich, ob Dir "expliziter Konstruktor" etwas sagt? Ich habe es (hoffentlich) oft genug geschrieben, auf jeden Fall mehr als einmal und das nicht grundlos.
Shade Of Mine schrieb:
Aber genau das ist das Problem - convenience ist nicht immer das beste. Wenn man einfach gewicht*hoehe verbietet, gibt es da keine Probleme. Und wenn ich in die seltene Situation komme wo ich das brauche, gibt es immer noch ein
Kraft k = gewicht.asInt() * hoehe.asInt();Sorry, aber wenn soetwas erlaubt wäre, brauche ich mir nicht die Mühe zu machen, irgendetwas zu benennen, dann kann ich auch gleich nur mit Intergern oder Floats rechnen.
Was Du da schreibst, ist eigentlich die totale Katastrophe. Du verwendest hier einen impliziten Konstruktor, um aus ints Kraft zu machen. Typsicherheit komplett ade. Dazu das Ablegen der Typen von gewicht und hoehe, in dem Du als Ints zurückgeben lässt. Für das, was hier steht, hättest Du direkt Integers nehmen können, denn die Typsicherheit ist hier vollkommen ausgehöhlt.
CStoll schrieb:
Xin schrieb:
if (window & WindowFlags::UseFullscreen) // schlecht if (window.isFullscreen()) // besserVom Prinzip her habe ich da kein Problem mit, es lässt sich auch problemlos in eine Klasse WindowFlags einbrinen.
Was mir hier fehlt sind zusammenhängende Abfragen:if( window & ( WindowFlags::UseFullScreen | WindowFlags::HasFocus ) )
Und da sind wir wieder bei der semantischen Frage: Was bedeutet diese Abfrage? "Das Fenster hat beide Flags"? Oder doch "Das Fenster hat mindestens eins der Flags"? (Mit der für int üblichen Bedeutung, die du bisher als Rechengrundlage genommen hast, ist es letzteres)
Stimmt, für einen exakten Abgleich musst Du musst den Vergleich auf die Flags ziehen. Mea maxima culpa, dass ich einem Forumsbeitrag in einem kleinen Textarea nicht die Aufmerksamkeit widmen kann, wie einem Programm.
CStoll schrieb:
Und wo steht in deiner Prioritätenliste die Typsicherheit? Soweit ich das überblicke, sehr weit unten.
CStoll, was soll der Müll? Der Thread wird aus x Seiten geführt, weil Typsicherheit weit oben steht, also was soll diese unsinnige Behauptung!?
CStoll schrieb:
Xin schrieb:
Shade Of Mine schrieb:
Vielleicht ist es besser nicht ganz so schöne Syntax zu haben sondern lieber etwas mehr Sicherheit im Code zu haben
Mit Einheiten zu rechnen bietet a) mehr Sicherheit und b) sorgt für kompaktere und leichter lesbare Parameterlisten. Wenn dies nicht möglich ist, mache ich das selbe wie jeder andere.
Kommt man von höherer Typsicherheit also wieder auf das Normalmaß herunter, hat man keinen Verlust.Ja, solange man mit Einheiten rechnet und nicht nur mit aufbereiteten int's - indem du alle Einheiten von int ableitest, pulverisierst du dir deine heißgeliebte Typsicherheit wieder (Beispiel: Du hast eine Einheit Kraft und Weg - das Produkt davon wäre eigentlich eine Leistung, aber nun bekommst du plötzlich eine reine Zahl heraus, weil Leistung nicht in deiner Einheitensammlung erwähnt wird).
Und wo ist ads Problem!?
Der Compiler sichert mir keinen Typ zu, das tut er sonst auch nicht, also kein Verlust an Information und ich kann weiterarbeiten, in dem ich die Typsicherung notfalls selbst zusichern muss.
Bei allen bekannten Operatoren, kann er mir einen Typen zusichern, also ein Gewinn an Information.CStoll schrieb:
btw, außerdem brauchst du praktisch unendlich viele Einheitenkombinationen, um alle möglichen Multiplikationen darstellen zu können - mit der bereits angerissenen Template-Klasse Measure<...> hast du die alle auf einen Haufen.
Du musst sie trotzdem aufführen.
CStoll schrieb:
Wenn du schon Maßeinheiten einführst, solltest du auch darauf achten, daß der Compiler sie zu schätzen weiß, andernfalls sind sie nutzlos.
Abgesehen davon, dass Du mir erzählst, dass ich keine Typsicherheit favorisiere, hast Du in der Richtung nichts gemacht. Also erzähl mir etwas von "nutzlos".
CStoll schrieb:
Xin schrieb:
Tellerrand schrieb:
Aber was nutzt eine Klasse Meter, wenn ich Werte daraus mit Gewicht addieren kann und das Resultat ein Integer ist?
Wozu dann die extra Klasse überhaupt?Wozu? Damit Du weißt, dass ein Meter plus ein Meter wieder ein Meter ergibt. Oder ein Meter * Meter einen Quadratmeter. Das ist ein Mehrwert und ein Mehrwert rechtfertigt eine Klasse.
Ja, das ist ein Mehrwert, der die Klasse rechtfertigt. Aber die implizite Behandlung des Meters als reinen int, die du durch deine (ich weiß: hypothetische) Ableitung nachgeworfen bekommst, rechtfertigst du damit noch lange nicht. Und außerdem mußt du dem Compiler noch zusätzlich sagen, daß "ein Meter plus ein Meter wieder ein Meter" bzw. "ein Meter * Meter einen Quadratmeter" ergibt - andernfalls stuft er beide als blanke int's ein.
Du hast selbst eine Möglichkeit angerissen, dass für grundlegende Operationen wie m*m=m² zu automatisieren...
Du lieferst die Lösung und beschwerst Dich, dass es ein Problem wäre?CStoll schrieb:
Xin schrieb:
Woher soll ich wissen, wem Meter + Gewicht hilft? Ich kann garantieren, dass ein class Meter + ein class Meter wieder ein class Meter ergibt. Wie soll ich garantieren, dass Meter + Gewicht grundsätzlich sinnlos ist? Wenn ich das nicht garantieren kann, wie soll ich dann eine Einschränkung begründen?
Kannst du begründen, daß diese Addition irgendeinen Sinn ergibt? Wenn nein, warum willst du sie dann erlauben?
Weil ich nicht garantieren kann, dass sie keinen Sinn ergibt.
CStoll schrieb:
Ja, solche Formeln sind auch der Alptraum für jeden Physiker - und vermutlich auch nicht der richtige Einsatzort für ein typisiertes Einheitensystem. Und aus physikalischer Sicht würde ich die Formel eher als "Groesse/1cm == Gewicht/1kg + 100" schreiben.
Sehe ich ähnlich, aber ich sehe mich nicht im Recht, andere Entwickler einzuschränken, nur weil ich eine persönliche Auffassung über das Thema habe. Um das deutlicher zu machen. Ich (meine subjektive Meinung) stimme Dir zu, dass derartige Rechnungen voll daneben sind. Ich bin aber noch mehr überzeugt, dass ich etwas zu definieren habe, was einen Mehrgewinn an Informationen ergibt (bestimmte Operationen ergeben entsprechende Datentypen), aber einen Entwickler nichts zu verbieten habe. Er darf rechnen wie immer - und er bekommt das Ergebnis wie erwartet: eine typlose Zahl, deren Klassifizierung er selbst zu verantworten hat.
CStoll schrieb:
Xin schrieb:
Ich sehe mich nicht in der Lage alle mathematischen und physikalischen Formen, die existieren und in Zukunftexistieren werden, in meinen Klassen abzubilden. Deswegen darf ich aber nicht die Kreativität der Entwickler enschränken.
Und darum gibt es Templates - mit denen können alle Einheiten und -kombinationen des SI-Systems mit einem Schlag erfasst werden.
(aber gib's zu, du hast dir den Ansatz noch nicht einmal angesehen)Doch habe ich, ich sehe nur "alle Einheiten und -Kombinationen des SI-Systems mit einem Schlag erfasst werden", als etwas optimistisch an. Fehlt eins, eine Relation, die vielleicht so noch gar nicht so bewußt ist, bekommt der Entwickler erstmal ein No-Go.
Weiterhin sind die SI-Einheiten nur vier von tausenden Einheiten. Schrauben mit der Einheit Schrauben gemessen, Butterbrote in der Einheit Butterbrot. Möchte ich wissen, wieviele Teile in meiner Werkzeugkiste sind, kann ich das nicht einfach durchzählen und erhalte typsicher x Objekte (eben ein int) heraus.Ich werde nicht verbieten unterschiedliche Einheiten zu addieren - ich werde lediglich keinen Typ dazu verkünden.
CStoll schrieb:
Xin schrieb:
Shade Of Mine schrieb:
Ich sehe da absolut keine Sicherheit wenn ich Kilogramm + Meter addieren kann. Und du hast es selber gesagt, dass da quark rauskommt aber es kompiliert wird.
Hier wird wieder frei interpretiert. Ich sagte nicht "Quark". Ich sagte typlos. Das bedeutet, dass der Typ nicht aussagt, was man damit anfangen kann. Wenn der Compiler nicht weiß, was man damit anfangen kann, heißt das nicht, dass der Entwickler mit der Information damit nichts anfangen kann.
Dann solltest du dafür sorgen, daß der Compiler dein Einheitensystem versteht. Wenn ich gezwungen bin, die (typlosen) Rechenergebnisse von Hand in den richtigen Typ zu quetschen, bleibt von deiner Typsicherheit nicht mehr viel übrig.
Wenn ich den Programmierer nicht mehr an die Tastatur lassen darf, um Entscheidungen zu treffen, dann brauche ich auch keine Typsicherheit. Wenn niemand die Entscheidung treffen kann, was damit gemacht wird, dann wird es auch keine Software mehr geben.
CStoll schrieb:
Xin schrieb:
Operatoren zu den Klassen kann ich problemlos aufzählen und dazu gehören nunmal auch die geerbten, da ich sie nicht verbieten würde, also die Möglichkeiten nicht einschränke.
Hast du schonmal daran gedacht, daß int zu viele Operatoren zur Verfügung stellt, um es als Ausgangsbasis für ein typsicheres Einheitensystem dienen zu können? Wenn ich sowas entwerfe, beginne ich lieber bei einer leeren Klasse und definiere mir genau die Operationen, die ich als nötig ansehe. Dann muß ich mir keinen Kopf darüber machen, welche geerbten Operatoren Sinn machen - bzw. wie ich ihr Ergebnis interpretieren soll.
Es stehen die gleichen Operatoren zur Verfügung wie jetzt auch. Ich schränke nicht ein, ich liefere Zusatzinformationen.
Wenn Du es programmierst, darfst Du alles so reglementieren, wie Du es für richtig hältst.CStoll schrieb:
Xin schrieb:
Shade Of Mine schrieb:
Ich kann jederzeit operatoren definieren damit Gewicht*Strecke/Zeit ein Objekt der Klasse Kraft liefert. Das Problem ist, wenn du daraus reine integers machst, verlierst du die komplette Typsicherheit und du kannst dir die Klassen sparen - rechne gleich mit integern - ist deutlich simpler und weniger aufwendig.
Ich verliere die Typsicherheit nicht. Ein Typ ist nur dann gegeben, wenn es sicher ist, ihn zu benennen. Ansonsten darf gerechnet werden, aber der Entwickler bekommt eine typlose Information.
Nur ist es immer schlecht, wenn der Entwickler dem Compiler explizit sagen muß, was für ein Typ da auftritt. Wer in der Lage ist (oder sogar gezwungen wird), das Ergebnis von "Gewicht*Strecke/Zeit/Zeit" in eine Kraft umzucasten, nur weil der Compiler nicht selbst erkennt, womit er rechnet, wird genauso schnell anfangen, beliebige Rechenergebnisse in beliebige Einheiten zu konvertieren - und schon ist dein Typsystem im Eimer.
Du entschuldigst, dass ich Dich auslache?
Programmierung funktioniert in Ermangelung eines Typsystems zur Zeit genauso, falls es Dir noch nicht aufgefallen ist. Integers stehen für alles, ohne einen Typ zu haben und man kann damit machen, was man will. Addiert man Kraft und Gewicht, erhält men die gleichen Typen raus, die man reingesteckt hat => legale Operation, ohne den Hinweis, dass man grade vermutlich etwas sehr blödes gemacht hat.
Ich zeige durch das Fehlen des Datentyps, dass hier grade etwas passiert, worüber man mal nachdenken soll.Was ist die Antwort? Es ist nicht typsicher, weil es auch typlose Größen zuläßt.
Genau... lassen wir alles typlos, dann ist alles viel besser.
CStoll schrieb:
Da lobe ich mir doch die (oben erwähnte) Template-Variante - ich kann "Kraft k = g*s/(t*t);" schreiben und der Compiler wird mich darauf aufmerksam machen, wenn ich irgendwo in dieser Rechnung eine Einheit durcheinandergeworfen habe. Keine Probleme mit impliziten oder expliziten Umwandlungen nach int in Sichtweite.
Mein Held. Dann setz das mal um.
CStoll schrieb:
Falls du es noch nicht bemerkt hast, wir sprechen hier nicht von Fehlern im Sinne von "syntaktisch falsch", sondern von Fehlern im Design - aber die hast du ja bisher erfolgreich ignoriert.
Genau, ich ignoriere euch grundsätzlich, solange ich nicht zustimme und die einzigen, die das Recht haben über Design und Designfehler zu urteilen, seid Ihr, werter CStoll, der als Moderator selbstverständlich für die ganze Welt der C++-Programmierer spricht.
Die Tatsache, dass wir unterschiedliche Ansichten auf einen Sourcecode haben, macht aus mir keinen schlechten Menschen, es ist also nicht notwendig, mir vorzuwerfen, dass ich Dich oder Deine Templates ignoriere.
Selbiges könnte ich von Dir behaupten, schließlich schreibe ich auch nicht zum ersten mal, dass es einen Zugewinn von Typ-Information gibt und nur bei unbekannten Operationen die Größe genauso typlos rauskommt, wie zur Zeit mit Größen gerechnet wird. Guckt man sich noch dazu an, was Shade da konstruiert hat, um aufzuzeigen, wie schlecht mein Herangehen ist, dann stelle ich mir die Frage, warum ich eurem Vorwurf nicht entspreche.Ich kann nur Informationen gewinnen, egal wie schlecht ihr das redet, es ist besser als das was im Alltag verwendet wird und das ist der Punkt, den nicht ich ignoriere...
-
Xin schrieb:
Shade Of Mine schrieb:
Ansonsten darf gerechnet werden, aber der Entwickler bekommt eine typlose Information.
Problem ist aber:
Kraft k = gewicht * hoehe;Das wird ziemlich sicher klappen, da du eine Konvertierung von int zu Kraft haben willst - richtig?
Ich rede bei euch beiden echt gegen eine Wand, hmm? Ich schreibe die ganze Zeit, dass genau derartiger Unsinn nicht klappt. Zum einen direkt, zum anderen frage ich mich, ob Dir "expliziter Konstruktor" etwas sagt? Ich habe es (hoffentlich) oft genug geschrieben, auf jeden Fall mehr als einmal und das nicht grundlos.
Typsicherheit bedeutet bei mir im optimalen Fall, daß physikalisch korrekte Zuweisungen wie "geschwindigkeit = distanz / zeit;" anstandslos geschluckt werden und unsinnige wie "kraft = laenge * breite;" schon am Compiler hängen bleiben - mit deinem Design kannst du entweder alle zulassen oder alle verbieten (oder du schreibst einige Dutzend Überladungen für die (in deinen Augen) wichtigsten Operandenkombinationen.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
if (window & WindowFlags::UseFullscreen) // schlecht if (window.isFullscreen()) // besserVom Prinzip her habe ich da kein Problem mit, es lässt sich auch problemlos in eine Klasse WindowFlags einbrinen.
Was mir hier fehlt sind zusammenhängende Abfragen:if( window & ( WindowFlags::UseFullScreen | WindowFlags::HasFocus ) )
Und da sind wir wieder bei der semantischen Frage: Was bedeutet diese Abfrage? "Das Fenster hat beide Flags"? Oder doch "Das Fenster hat mindestens eins der Flags"? (Mit der für int üblichen Bedeutung, die du bisher als Rechengrundlage genommen hast, ist es letzteres)
Stimmt, für einen exakten Abgleich musst Du musst den Vergleich auf die Flags ziehen. Mea maxima culpa, dass ich einem Forumsbeitrag in einem kleinen Textarea nicht die Aufmerksamkeit widmen kann, wie einem Programm.
Du bist schon wieder auf die Flags zurückgekommen, also beschwer dich bitte nicht.
Xin schrieb:
CStoll schrieb:
Und wo steht in deiner Prioritätenliste die Typsicherheit? Soweit ich das überblicke, sehr weit unten.
CStoll, was soll der Müll? Der Thread wird aus x Seiten geführt, weil Typsicherheit weit oben steht, also was soll diese unsinnige Behauptung!?
Dann haben wir wohl ein anderes Verständnis von Typ-Sicherheit. Wäre nett zu erfahren, was du darunter verstehst.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Shade Of Mine schrieb:
Vielleicht ist es besser nicht ganz so schöne Syntax zu haben sondern lieber etwas mehr Sicherheit im Code zu haben
Mit Einheiten zu rechnen bietet a) mehr Sicherheit und b) sorgt für kompaktere und leichter lesbare Parameterlisten. Wenn dies nicht möglich ist, mache ich das selbe wie jeder andere.
Kommt man von höherer Typsicherheit also wieder auf das Normalmaß herunter, hat man keinen Verlust.Ja, solange man mit Einheiten rechnet und nicht nur mit aufbereiteten int's - indem du alle Einheiten von int ableitest, pulverisierst du dir deine heißgeliebte Typsicherheit wieder (Beispiel: Du hast eine Einheit Kraft und Weg - das Produkt davon wäre eigentlich eine Leistung, aber nun bekommst du plötzlich eine reine Zahl heraus, weil Leistung nicht in deiner Einheitensammlung erwähnt wird).
Und wo ist ads Problem!?
Der Compiler sichert mir keinen Typ zu, das tut er sonst auch nicht, also kein Verlust an Information und ich kann weiterarbeiten, in dem ich die Typsicherung notfalls selbst zusichern muss.
Bei allen bekannten Operatoren, kann er mir einen Typen zusichern, also ein Gewinn an Information.Um mit der Leistung (sinnvoll) weiterarbeiten zu können, mußt du dem Compiler klar machen, was er da vor sich hat (durch einen Cast) - und da kann er nicht mehr kontrollieren, ob sich hinter der übergebenen Zahl wirklich eine Leistung verbirgt oder nicht doch eine Stromstärke.
Xin schrieb:
CStoll schrieb:
btw, außerdem brauchst du praktisch unendlich viele Einheitenkombinationen, um alle möglichen Multiplikationen darstellen zu können - mit der bereits angerissenen Template-Klasse Measure<...> hast du die alle auf einen Haufen.
Du musst sie trotzdem aufführen.
Ich schreibe das Template genau einmal - die daraus benötigten Spezialisierungen liefert der Compiler dann auf Anforderung.
Xin schrieb:
CStoll schrieb:
Wenn du schon Maßeinheiten einführst, solltest du auch darauf achten, daß der Compiler sie zu schätzen weiß, andernfalls sind sie nutzlos.
Abgesehen davon, dass Du mir erzählst, dass ich keine Typsicherheit favorisiere, hast Du in der Richtung nichts gemacht. Also erzähl mir etwas von "nutzlos".
OK, ich geb's zu - das Template Measure<> dort oben habe ich nur im Netz entdeckt und dann im Hinterkopf behalten. Aber nichtsdestotrotz sorgt so eine Lösung dafür, daß die Basiseinheiten typsicher miteinander interagieren können.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Tellerrand schrieb:
Aber was nutzt eine Klasse Meter, wenn ich Werte daraus mit Gewicht addieren kann und das Resultat ein Integer ist?
Wozu dann die extra Klasse überhaupt?Wozu? Damit Du weißt, dass ein Meter plus ein Meter wieder ein Meter ergibt. Oder ein Meter * Meter einen Quadratmeter. Das ist ein Mehrwert und ein Mehrwert rechtfertigt eine Klasse.
Ja, das ist ein Mehrwert, der die Klasse rechtfertigt. Aber die implizite Behandlung des Meters als reinen int, die du durch deine (ich weiß: hypothetische) Ableitung nachgeworfen bekommst, rechtfertigst du damit noch lange nicht. Und außerdem mußt du dem Compiler noch zusätzlich sagen, daß "ein Meter plus ein Meter wieder ein Meter" bzw. "ein Meter * Meter einen Quadratmeter" ergibt - andernfalls stuft er beide als blanke int's ein.
Du hast selbst eine Möglichkeit angerissen, dass für grundlegende Operationen wie m*m=m² zu automatisieren...
Du lieferst die Lösung und beschwerst Dich, dass es ein Problem wäre?Ja, ich habe eine Lösung - aber ich frage mich (oder besser gesagt dich, da du ja der Experte für solche Fragen zu sein scheinst), inwieweit man diese Lösung noch verbessern könnte, wenn die Klassen von int erben würden.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Ich sehe mich nicht in der Lage alle mathematischen und physikalischen Formen, die existieren und in Zukunftexistieren werden, in meinen Klassen abzubilden. Deswegen darf ich aber nicht die Kreativität der Entwickler enschränken.
Und darum gibt es Templates - mit denen können alle Einheiten und -kombinationen des SI-Systems mit einem Schlag erfasst werden.
(aber gib's zu, du hast dir den Ansatz noch nicht einmal angesehen)Doch habe ich, ich sehe nur "alle Einheiten und -Kombinationen des SI-Systems mit einem Schlag erfasst werden", als etwas optimistisch an. Fehlt eins, eine Relation, die vielleicht so noch gar nicht so bewußt ist, bekommt der Entwickler erstmal ein No-Go.
Weiterhin sind die SI-Einheiten nur vier von tausenden Einheiten.Du weißt hoffentlich, daß ALLE physikalischen Größen aus diesen Grundeinheiten (btw, es sind sieben) abgeleitet werden können.
Xin schrieb:
Schrauben mit der Einheit Schrauben gemessen, Butterbrote in der Einheit Butterbrot. Möchte ich wissen, wieviele Teile in meiner Werkzeugkiste sind, kann ich das nicht einfach durchzählen und erhalte typsicher x Objekte (eben ein int) heraus.
Ich werde nicht verbieten unterschiedliche Einheiten zu addieren - ich werde lediglich keinen Typ dazu verkünden.
Und was für einen physikalischen/technischen/sonstigen Sinn würdest du dahinter sehen, Schrauben und Butterbrote miteinander zu multiplizieren?
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Shade Of Mine schrieb:
Ich sehe da absolut keine Sicherheit wenn ich Kilogramm + Meter addieren kann. Und du hast es selber gesagt, dass da quark rauskommt aber es kompiliert wird.
Hier wird wieder frei interpretiert. Ich sagte nicht "Quark". Ich sagte typlos. Das bedeutet, dass der Typ nicht aussagt, was man damit anfangen kann. Wenn der Compiler nicht weiß, was man damit anfangen kann, heißt das nicht, dass der Entwickler mit der Information damit nichts anfangen kann.
Dann solltest du dafür sorgen, daß der Compiler dein Einheitensystem versteht. Wenn ich gezwungen bin, die (typlosen) Rechenergebnisse von Hand in den richtigen Typ zu quetschen, bleibt von deiner Typsicherheit nicht mehr viel übrig.
Wenn ich den Programmierer nicht mehr an die Tastatur lassen darf, um Entscheidungen zu treffen, dann brauche ich auch keine Typsicherheit. Wenn niemand die Entscheidung treffen kann, was damit gemacht wird, dann wird es auch keine Software mehr geben.
Nochmal langsam: Typsicherheit bedeutet, daß alle relvanten Typ-Informationen erhalten bleiben - jemandem zu sagen "hier hast du ein Ergebnis, aber du mußt schon selber wissen, was es darstellt" ist nicht typsicher.
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Operatoren zu den Klassen kann ich problemlos aufzählen und dazu gehören nunmal auch die geerbten, da ich sie nicht verbieten würde, also die Möglichkeiten nicht einschränke.
Hast du schonmal daran gedacht, daß int zu viele Operatoren zur Verfügung stellt, um es als Ausgangsbasis für ein typsicheres Einheitensystem dienen zu können? Wenn ich sowas entwerfe, beginne ich lieber bei einer leeren Klasse und definiere mir genau die Operationen, die ich als nötig ansehe. Dann muß ich mir keinen Kopf darüber machen, welche geerbten Operatoren Sinn machen - bzw. wie ich ihr Ergebnis interpretieren soll.
Es stehen die gleichen Operatoren zur Verfügung wie jetzt auch. Ich schränke nicht ein, ich liefere Zusatzinformationen.
Und was nützen diese Zusatzinformationen, wenn sie sich bei der erstbesten Gelegenheit in Rauch auflösen?
Xin schrieb:
CStoll schrieb:
Xin schrieb:
Shade Of Mine schrieb:
Ich kann jederzeit operatoren definieren damit Gewicht*Strecke/Zeit ein Objekt der Klasse Kraft liefert. Das Problem ist, wenn du daraus reine integers machst, verlierst du die komplette Typsicherheit und du kannst dir die Klassen sparen - rechne gleich mit integern - ist deutlich simpler und weniger aufwendig.
Ich verliere die Typsicherheit nicht. Ein Typ ist nur dann gegeben, wenn es sicher ist, ihn zu benennen. Ansonsten darf gerechnet werden, aber der Entwickler bekommt eine typlose Information.
Nur ist es immer schlecht, wenn der Entwickler dem Compiler explizit sagen muß, was für ein Typ da auftritt. Wer in der Lage ist (oder sogar gezwungen wird), das Ergebnis von "Gewicht*Strecke/Zeit/Zeit" in eine Kraft umzucasten, nur weil der Compiler nicht selbst erkennt, womit er rechnet, wird genauso schnell anfangen, beliebige Rechenergebnisse in beliebige Einheiten zu konvertieren - und schon ist dein Typsystem im Eimer.
Du entschuldigst, dass ich Dich auslache?
Programmierung funktioniert in Ermangelung eines Typsystems zur Zeit genauso, falls es Dir noch nicht aufgefallen ist. Integers stehen für alles, ohne einen Typ zu haben und man kann damit machen, was man will. Addiert man Kraft und Gewicht, erhält men die gleichen Typen raus, die man reingesteckt hat => legale Operation, ohne den Hinweis, dass man grade vermutlich etwas sehr blödes gemacht hat.
Ich zeige durch das Fehlen des Datentyps, dass hier grade etwas passiert, worüber man mal nachdenken soll.Und du meinst, durch die Aussage "ich weiß nicht, was für ein Typ das ist" wird dein System in irgendeiner Weise sicherer? Nochmal: Die optimale Lösung ist, daß der Compiler erlaubte Operationen anstandslos zulässt und unsinnige Operationen abblockt.
(btw, wer unbedingt Längen und Gewichte addieren will, kann die Einheiten auch rauskürzen)Xin schrieb:
Was ist die Antwort? Es ist nicht typsicher, weil es auch typlose Größen zuläßt.
Genau... lassen wir alles typlos, dann ist alles viel besser.Nein: Es ist nicht typsicher, weil du bei der Rechnung deine Typ-Informationen in den Müll schmeißt - und der Entwickler anschließend raten kann, was nun für ein Typ vorliegen könnte.
Xin schrieb:
CStoll schrieb:
Da lobe ich mir doch die (oben erwähnte) Template-Variante - ich kann "Kraft k = g*s/(t*t);" schreiben und der Compiler wird mich darauf aufmerksam machen, wenn ich irgendwo in dieser Rechnung eine Einheit durcheinandergeworfen habe. Keine Probleme mit impliziten oder expliziten Umwandlungen nach int in Sichtweite.
Mein Held. Dann setz das mal um.
Wenn ich Zeit habe, gerne. Edit: Bis dahin kannst du dir ja mal das hier zu Gemüte führen.
Xin schrieb:
CStoll schrieb:
Falls du es noch nicht bemerkt hast, wir sprechen hier nicht von Fehlern im Sinne von "syntaktisch falsch", sondern von Fehlern im Design - aber die hast du ja bisher erfolgreich ignoriert.
Genau, ich ignoriere euch grundsätzlich, solange ich nicht zustimme und die einzigen, die das Recht haben über Design und Designfehler zu urteilen, seid Ihr, werter CStoll, der als Moderator selbstverständlich für die ganze Welt der C++-Programmierer spricht.
Nein, ich spreche hier nicht für alle C++ Programmierer. Aber selbst dir sollte nicht entgangen sein, daß du so ziemlich alleine auf weiter Flur stehst.
Xin schrieb:
Selbiges könnte ich von Dir behaupten, schließlich schreibe ich auch nicht zum ersten mal, dass es einen Zugewinn von Typ-Information gibt und nur bei unbekannten Operationen die Größe genauso typlos rauskommt, wie zur Zeit mit Größen gerechnet wird. Guckt man sich noch dazu an, was Shade da konstruiert hat, um aufzuzeigen, wie schlecht mein Herangehen ist, dann stelle ich mir die Frage, warum ich eurem Vorwurf nicht entspreche.
Ich kann nur Informationen gewinnen, egal wie schlecht ihr das redet, es ist besser als das was im Alltag verwendet wird und das ist der Punkt, den nicht ich ignoriere...
OK, dein Ansatz ist (etwas) besser als die Arbeit mit nackten int's - war es das, was du hören wolltest? Aber es ist immer noch meilenweit davon entfernt, wirklich typsicher zu sein (und ein "Zugewinn von Typ-Informationen", der sich beim ersten Anzeichen von Gefahr verflüchtigt, ist imho noch unsicherer als keine Typinformation).
-
CStoll schrieb:
Aber selbst dir sollte nicht entgangen sein, daß du so ziemlich alleine auf weiter Flur stehst.
naja, der eine von euch vertritt hier eine konservative 'scheuklappen-', der andere eine eher progressive sichtweise. dass sich viele an althergebrachtes klammern, ist doch normal, aber trotzdem glaube ich nicht, dass die meisten leser Xin für bekloppt halten.
-
Schön, dass auch Undertaker wieder seiner Hauptbeschäftigung, dem Dummschwätzen, nachkommt.
-
Unreg, der Xin Böses will schrieb:
Schön, dass auch Undertaker wieder seiner Hauptbeschäftigung, dem Dummschwätzen, nachkommt.
du bist doch gar kein unreg
-
Für was soll man jemanden halten, der Ausdrücke wie "Fenster sind Flags" oder "class DeppenWindow" benutzt? Das wäre schon eine Steilvorlage gewesen, diese Diskussion von vornherein abzubügeln, mit einem simplen "mit Leuten, die behaupten, daß Fenster Flags sind, diskutiere ich nicht". Warum CStoll hier immer noch weitermacht (nachdem nun wieder Unterstellungen ohne Ende gekommen sind), ist mir völlig schleierhaft.
Außerdem sagt Xin ja selbst, daß sein Weg eine Alternative ist (und er sagt auch, eine schlechtere). Nix progressiv.
-
Undertaker schrieb:
Unreg, der Xin Böses will schrieb:
Schön, dass auch Undertaker wieder seiner Hauptbeschäftigung, dem Dummschwätzen, nachkommt.
du bist doch gar kein unreg
Oh, ertappt. Ja du hast Recht, ich habe hier einen Account mit etwa 20 Posts, in den ich mich auf Arbeit jetzt aber nicht einloggen will. Außerdem wollte ich Xins Verfolgungswahn mit meinem Nick lächerlich machen.
Trotzdem reicht es, die zwei Threads mit Xin und einen beliebigen Thread mit dir zu kennen, um zu wissen, was für Menschen ihr seid.
-
scrub_ schrieb:
Außerdem sagt Xin ja selbst, daß sein Weg eine Alternative ist (und er sagt auch, eine schlechtere). Nix progressiv.
Xin ist wenigstens einer, der sich eigene gedanken macht, auch wenn dabei nicht unbedingt was gescheites rauskommt, aber allein der versuch ist schon was wert.
viele andere machen das nicht. sie haben das gelernte sehr verinnerlicht, wenden es immer und immer wieder an und können es nur in sehr engen, 'erlaubten' grenzen variieren.Unreg oder nicht Unreg? schrieb:
Trotzdem reicht es, die zwei Threads mit Xin und einen beliebigen Thread mit dir zu kennen, um zu wissen, was für Menschen ihr seid.
wolltest du 'trolle' sagen?
-
Undertaker schrieb:
scrub_ schrieb:
Außerdem sagt Xin ja selbst, daß sein Weg eine Alternative ist (und er sagt auch, eine schlechtere). Nix progressiv.
Xin ist wenigstens einer, der sich eigene gedanken macht, auch wenn dabei nicht unbedingt was gescheites rauskommt, aber allein der versuch ist schon was wert.
Ja, der Versuch wird auch lobenswert anerkannt - nur sollte er auch so weit gehen, zu reagieren, nachdem er auf die Schwächen seiner Lösung hingewiesen wurde (und nein, die Aussage "da sind keine Schwachstellen, das ist so beabsichtigt" ist damit nicht gemeint).
@scrub: Sowas nennt sich wohl "grenzenloser Optimismus"
