Methoden mit bool-Parametern und "Lesbarkeit" im Kontext

Shade Of Mine

Xin schrieb:

Das ist irgendwo witzlos, findest Du nicht?
Auf einmal kommt da irgendwo ein impliziter Konstruktor vom Himmel gefallen, oder wie darf ich mir das vorstellen?

Du willst mir doch nicht damit argumentieren, dass wenn etwas falsch programmiert ist, falsche Ergebnisse entstehen!? Wow. Wie gut, dass das ein Problem ist, dass ausschließlich auf die Entwicklung meiner Klassen zutrifft.

Das hat nichts mit falsch zu tun. Viele meiner CTors sind nicht explizit - weil es oft sinnvoll ist so eine Umwandlung zu haben.

Du scheinst sehr viel anders zu programmieren als die meisten Leute. Aber indem du non-explicit CTors verbietest - hast du schon wieder eine Restriktion mehr die man sehr leicht übersehen kann und die viele Leute auch nicht einsehen werden.

Man darf keinen non-explicit CTors verwenden weil sonst die Typsicherheit weg ist - das klingt in meinen Augen ziemlich verrückt. Wenn ich eine Klasse Gewicht oder ähnliches schreibe, dann würde ich ihr vermutlich einen non-explicit CTor für int geben.

Xin schrieb:

Natürlich möchte ich das Rechnen mit Maßeinheiten fördern. Aber natürlich möchte ich nicht viele Klassen für eine Einheit. Millimeter sind 1/1000 Meter, also möge man doch bitte möglichst in Metern rechnen.

Das Problem aber ist: was wenn ich eine Klasse Millimeter will? Weil ich halt im Millimeter bereich rechne. Es spricht absolut nichts dagegen eine Millimeter Klassen einzuführen. Und sobald ich es einmal mache - habe ich wieder massig Probleme wo es nie einen Compilerfehler gibt.

Es gibt in C++ kein Verfahren, um typsicher und gleichzeitig einfach zu sein.
Daher muss man sich irgendwo auch überlegen, an welchem Punkt man aussteigen muss (nicht will). Man kann nicht alles abbilden, es wird immer Beispiele geben, die man nicht abbilden konnte.
Aber man kann den Alltag abbilden. Typsicherheit im Alltag, das wäre ein gigantischer Schritt nach vorne.

Und genau da kommt der pragmatische Ansatz rein. Man nimmt einfach komplette Typsicherheit und erlaubt alle Operationen die man als nicht wichtig einstuft über typunsichere Methoden.

Wenn wir eine Klasse Meter machen die keine Konvertierung nach int erlaubt und eine Klasse Millimeter die es ebenfalls nicht erlaubt, sind die Typsicherheitsprobleme erledigt.

Ich kann

Meter m = Millimeter(1000);

vielleicht nicht schreiben, aber ich erkenne sofort dass bei

Meter m = Millimeter(1000).asInt();

ein Fehler sein kann.

Wenn ich nun

Meter m = Millimeter(1000).asInt() /1000;

schreibe kann ich jederzeit Problemlos einen CTor für Meter schreiben der Millimeter nimmt ohne dass es das Verhalten ändert.

Bei deinem Ansatz wäre das nicht möglich. Dann könnte ich

Meter m = Millimeter(1000) / 1000;

schreiben und es kommt das falsche raus sobald Meter einen CTor für Millimeter bekommt. Es sei denn der operator/ liefert einen Integer - dann kommt das richtig raus.

Dann hast du aber das Problem:

void foo(Millimeter m) {
}

Millimeter m=...;
foo(m/10);

Ich sehe einfach keinen Nachteil in der herkömmlichen Methode. Sie denkt einfach an alles.

PS:
statt dem asInt() hat mich MrN auf eine andere vermutlich elegantere Lösung gebracht die alle Einheiten Probleme komplett löst:

int meter = (Millimeter(1000)/Millimeter(1)) / 1000;

Da 1000mm / 1mm auf 1000/1 == 1000 rausläuft.

Dieser Ansatz ist mit der herkömmlichen Methode super leicht zu implementieren - denn Meter hat ja einen non-explicit CTor für int.

Bei Xins Ansatz ist sowas nur häßlich implementierbar - da Meter ja keinen non-explict CTor für int hat, muss man ihn jedesmal explizit aufrufen wenn man die Einheit weggerechnet hat...

Somit erlaubt dieser Ansatz problemlos mit allen Einheiten zu rechnen - die Einheiten die Fehlen kann man Problemlos dazu schreiben ohne auf eine besonderheit achten zu müssen. Denn wenn man vergisst dass Millimeter/Millimeter == int ist, dann beschwert sich der Compiler...

Xin

Ich habe mir Tellerrands und Shades Postings grade durchgelesen und wieder einiges gefunden und ich stimme Tellerand zu. Würde ich das nun wieder auseinander klamüsern und darauf antworten, drehen wir uns nur weiter im Kreis. Das kostet mir zuviel Zeit.

Shade schrieb:

Du scheinst sehr viel anders zu programmieren als die meisten Leute. Aber indem du non-explicit CTors verbietest - hast du schon wieder eine Restriktion mehr die man sehr leicht übersehen kann und die viele Leute auch nicht einsehen werden.

Ich programmiere nicht viel anders, als alle anderen auch. Sicherlich hier und da etwas anders, aber alles in allem sind bisher keine Klagen gekommen. Der Eindruck kommt sicherlich auf, weil ich hier auch Positionen beziehe, die nicht falsch, aber vollkommen unbesetzt sind. Daraus wurde schon geschlussfolgert, dass ich im Alltag keine Membervariablen benutze und was sonst noch alles für Vorstellungen in diversen Threads geäußert wurden.

Ich sage, dass die Einheiten nur auf explizite Aufforderung konvertiert werden dürfen. Das bedeutet aber nicht, dass ich irgendwem vorschreibe, wie er seine Konstruktoren zu schreiben hat.
Wer solche von mir geschriebenen Klassen von mir nutzt, bekommt explizite Konstruktoren geliefert und muss die nicht noch schreiben - er muss damit leben. Die expliziten Konstruktoren sind bei meinen Einheits-Klassen, die ich im Einsatz habe erforderlich, um dem Compiler zu selbstständiges Handeln zu verbieten, um Seiteneffekten vorzubeugen. Das ist keine Schwäche des Frameworks, sondern das Framework benutzt genau das in C++ vorhandene Schlüsselwort, um eben keine Schwachstelle zu bieten.

Es funktioniert gut.
Dass ihr es nicht mögt, habt ihr zum Ausdruck gebracht. Also benutzt ihr es nicht.
Kein Problem, schreibt ihr euch halt etwas anderes.

Und das würde ich auch als Fazit sehen: Jeder schreibt, was er für seine Anforderungen als optimal schreibt. Wir haben unterschiedliche Anforderungen und wir haben unterschiedliche Klassen geschrieben, um Einheiten zu beschreiben und typsicher zu verwenden.
Jeder benutzt, was er geschrieben hat und wir werden alle glücklich. Belassen wir's dabei, sonst verschwenden wir hier noch mehr Zeit, nur um uns weiter im Kreis zu drehen.

Shade Of Mine

Xin schrieb:

Ich sage, dass die Einheiten nur auf explizite Aufforderung konvertiert werden dürfen. Das bedeutet aber nicht, dass ich irgendwem vorschreibe, wie er seine Konstruktoren zu schreiben hat.

Doch, genau das bedeutet es. Man kann deine Klassen nicht verwenden ohne Typsicherheit zu verlieren wenn man non-explizite CTors hat.

CStoll

Xin schrieb:

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Xin schrieb:

Das Dumme ist halt nur, dass die Informatik sich auch mit Einheiten beschäftigt, die sich durch SI Einheiten nur ganz schlecht ausdrücken lassen, mit denen man aber auch rechnen können muss: Butterbrot, Teppichboden, Krieger.

Ein "Butterbrot" ist keine Einheit, sondern eine Größe - die dazugehörige Einheit wäre "Anzahl".

*lach* Okay... Und wenn ich an die Steckdose packe durchströhmt mich 230 Stück Volts, richtig. Volt ist eine physikalische Größe und Größen werden in "Anzahl" gerechnet.

Du hattest Physik Leistungskurs und kennst nicht den Unterschied zwischen "Größe" und "Einheit"? Die Größe "Butterbrote" wird in "Stück" gemessen, die Größe "Spannung" in "Volt".

Der Unterschied zwischen "Größe" und "Einheit" ist also dass Butterbrote in Stück gemessen wird und Spannung Volt?
Aha. Verstehst Du die Bedeutung von dem, was Du da schreibst?

Du begreifst's nicht, oder wie? "Butterbrote" ist eine Größe und wird in "Stück" gemessen, "Spannung" ist auch eine Größe und wird in "Volt" gemessen.

Xin schrieb:

CStoll schrieb:

Eine implizite Umwandlung kann dir an den unpassendsten Stellen entgegenkommen und deine komplette Rechnung kaputtmachen. Über eine explizite Umwandlung mußt du dem Compiler informieren, sonst verwendet er sie auch nicht.

Sowas ist vollkommen ohne Aussage, pures Geblubber. Ich verlange explizite int-Konstruktoren, Typsicherheit ist durch den Copy-Construktor gegeben. Also passt. Und dass man explizite Konstruktoren explizit aufrufen muss, ist wohl klar, sonst würde ich sie nicht explizit verlangen. Also was willst Du damit jetzt eigentlich ausdrücken!?
Wenn ich ehrlich bin, halte ich das für die Verkomplizierung von Blah: Wer's nur überfliegt, sieht tolle Worte und "deine Rechnung kaputtmachen". Dann muss das wohl'n Argument sein...
Dass Du mit impliziten int-Konstruktoren einfach nicht landen kannst, ist ein wichtiges - aber weggelassenes Detail, weil ich nur explizite erlaube. Ergo das ganze Geblubber einen Wert von exakt 0 hat, wenn Du Dich auf meine Klassen beziehen willst.

Du hast keine implizite Umwandlung von int in irgendeine physikalische Größe - aber du hast sehr wohl eine implizite Umwandlung von physikalischen Größen nach int (die würde dir C++ schon durch/wegen der Ableitung zur Verfügung stellen).

Xin schrieb:

Tellerrand schrieb:

Xin schrieb:

Die Reihenfolge kann eine Rolle spielen, wenn Du Verwandschaftsbeziehungen in operatoren herstellst, statt expliziter Umrechnungen.

Die Verwandschaftsbeziehung durch Operatoren hast du selber rausgehauen mit dem Satz:

Oder ein Meter * Meter einen Quadratmeter. Das ist ein Mehrwert und ein Mehrwert rechtfertigt eine Klasse.

Oookay... Aber dass zwischen Meter und Meter^2 eine andere Beziehung besteht als zwischen Meter und Millimetern, ist nachvollziehbar?

Flächen (m²) und Längen (m) sind etwas völlig unterschiedliches, Längen (m) und Längen (mm) unterscheiden sich nur in der Größenordnung.

Xin schrieb:

Tellerrand schrieb:

Aber mein Problem bezieht sich nicht nur auf die Reihenfolge und lässt sich genauso auf die Umwandlung über den Konstruktor übertragen.

Meter m = Meter( Millimeter( 1000 ) ) + Meter( 1 )

Bzw. wenn es die Umrechnung nicht gäbe, die Umrechnung selbst festlegen. In dem Fall hat er hier das Warnschild bekommen, dass er genau an der Stelle denken muss, damit er Millimeter und Meter nicht einfach addiert.

Das Warnschild erhält er durchaus, denn den expliziten Konstruktor vor Meter muss er schließlich aufrufen, damit er das Warnschild aus dem Weg bekommt und er sich damit absichtlich über die Vorstellungen des Compilers hinwegsetzt.

Tellerrand schrieb:

Meter m = Meter( Millimeter( 1000 ) / 1000 ) + Meter( 1 )

Der Programmierer muss wissen ob die Umrechnung so existiert.

Wenn nicht er... wer dann?
Ich mache mir das einfacher: Ich rechne nicht ohne Aufforderung um.

Du hast selber zwei Möglichkeiten genannt, Meter und Millimeter ineinander umzuwandeln - beide sind syntaktisch korrekt. Allerdings mußt du als Bibliotheksentwickler dokumentieren, welche Möglichkeit semantisch korrekt ist. Das heißt, wenn du nach längerer Überzeugungsarbeit der Anwender tatsächlich eingesehen hast, eine Umrechnung von Millimetern nach Metern zur Verfügung zu stellen, müssten alle Stellen, wo das bisher von Hand erledigt wurde, geändert werden - und kein mir bekannter Compiler wird dich darauf hinweisen, daß die manuelle Umrechnung semantisch nicht mehr nötig ist.

Xin schrieb:

Tellerrand schrieb:

Ok, dein Satz sagt ja aus, dass er an der Stelle ein Warnschild bekommen würde, warum und wie sieht das aus?
In beiden Fällen bekommt der Compiler zu einem Ausdruck Meter(Millimeter).
Als Meter(Integer) behandelt er es nur, wenn der Konstruktor Meter(Millimeter) nicht existiert.
Warnt der Compiler einen, wenn er Millimeter als Integer behandelt?

Meter ist wohl eindeutig eine Größe, die auch als gebrochene Zahl vorkommt. Es von int abzuleiten ist also suboptimal. Das es sich um Beispielcharakter handelt und um keine Produktivlösung, ist wohl eindeutig.

Und wieso verkaufst du uns dann deinen Ansatz bisher als Produktivlösung?

Xin schrieb:

Tellerrand schrieb:

Meine Kritik basiert ja hauptsächlich darauf, dass der Programmierer an einigen Stellen nicht mitbekommt ob nun ein Meter(1) als Integer behandelt wird oder nicht.

Ein Meter ist entweder ein Meter oder ein Integer. Wenn er sich nicht als Meter verhalten kann, wird er ein Integer. Konvertierungsoperatoren gibt es ausschließlich explizit. Rechnen kannst Du, was immer Du willst, aber du kannst nur zuweisen, wenn die Sache sicher ist oder vom Entwickler abgesegnet.

Und woher weißt du als Bibliotheksentwickler, was für den Anwender sinnvoll ist?

Kommen wir mal zurück zur Addition "1 Schraubenschüssel + 1 Werkzeugkasten":

der Handwerker will wissen, wieviele Werkzeuge er insgesamt hat
ein Spediteur interessiert sich für das Gewicht
ein Händler benötigt den Preis
...
ich als Programmierer sehe nur die Objekte als digitale Repräsentation - und weiß überhaupt nichts über die erwartete Semantik der Addition

Meine Antwort darauf lautet "Ich weiß nicht, was ich hier addieren soll - also erkläre es mir bitte", du sagst "Ich weiß zwar nicht, was ich hier mache, aber hier hast du ein Ergebnis, das möglicherweise sinnvoll ist".

Xin schrieb:

Tellerrand schrieb:

Xin schrieb:

Oookay... Aber dass zwischen Meter und Meter^2 eine andere Beziehung besteht als zwischen Meter und Millimetern, ist nachvollziehbar?

Ja, die Beziehung ist in beiden Fällen aber durch einen Operator hergestellt.
Mehr wollte ich nicht sagen, dachte eher du willst solche Ausdrücke wie Meter(3) + Millimeter(7) fördern.
Denn irgendwie geht es doch darum etwas zu schaffen was einem erlaubt mit Maßeinheiten zu rechnen

Natürlich möchte ich das Rechnen mit Maßeinheiten fördern. Aber natürlich möchte ich nicht viele Klassen für eine Einheit. Millimeter sind 1/1000 Meter, also möge man doch bitte möglichst in Metern rechnen.

Du brauchst auch nicht für jede Einheit eine eigene Klasse, sondern für jede Größe - das heißt es gibt eine Klasse "Laenge" (die intern den Wert in Metern speichert) und Hilfsfunktionen Meter(), Millimeter(), Kilometer() etc, die alle ihren Parameter passend skalieren und in ein Laenge-Objekt packen.

Xin schrieb:

Tellerrand schrieb:

Zum Rest:

Da hast du glaub ich was falsch verstanden.

Ich schreibe folgendes:
Meter m = Meter( Millimeter( 1000 ) ) + Meter( 1 )

Wenn der explizite Konstruktor Meter(Millimeter) mit der passenden Umrechnung existiert, dann kommt da als Ergebnis 2 Meter raus.

Ich schreibe keine Konvertierungskonstruktoren, damit sind Millimeter und Meter unabhängige Größen.

Es wird auch keine geben. Wenn Du in Millimetern rechnen möchtest, dann rechne in Meter um.
Meter Millimeter( int i ) { return Meter( i / 1000 ); }
int Meter::AsMilli() { return MeterValue * 1000; }   

Meter meter = Millimeter( 2000 );

printf( "als Millimetern: %d\n", meter.AsMilli() );
Damit entspricht
Meter m = Millimeter( 1000 ) + Meter( 1 );
dem, was Du erwartest, ohne dass es eine konkurrierende Meterklasse gibt.
Es gibt nur die Basiseinheit, das lässt man sich leicht merken.
int i = Millimeter( 1000 ) * Butterbrot( 7 );
ganz logisch 7 Unit.

Tellerrand schrieb:

Existiert der explizite Konstruktor nicht, so wird Milimeter(1000) einfach als Integer Wert 1000 an den Konstruktor Meter(Integer) übergeben und das Ergebnis ist 1001 Meter.

Aufgrund der fehlenden Beziehung zwischen Millimeter und Meter ist das Ergebnis 1001. Die Einheit ist aber nicht Meter, sondern nicht festgelegt, bzw. "Unit". Eine Zuweisung auf Meter wird also abgelehnt, womit der Programmierer weiß, dass er hier überlegen muss, was er tun muss, um hier zwei kompatible Einheiten zu addieren.

Falsch - du hast den expliziten Konstruktoraufruf schon angegeben, indem du "m = Meter(Millimeter(1000)) + Meter(1);" geschrieben hast - 1000mm werden als int aufgefasst und umgerechnet zu 1000m - und die können klaglos mit 1m addiert werden.

Xin schrieb:

Tellerrand schrieb:

Der Programmierer muss also höllisch aufpassen, welcher Konstruktor nun mit welcher Umwandlung auch funktioniert.
Und das Beispiel zielte darauf ab, dass eine Implementation wie:
Meter m = Meter(Millimeter(1000) / 1000) + Meter(1)
eine potentielle Fehlerquelle ist, da ja jemand auf die Idee kommen könnte und den expliziten Konstruktor Meter(Millimeter) inklusive Umrechnung implementiert.
Und da hast du dann Recht, es kommt ein Wert raus Meter(1,0001), der einfach viel zu klein ist.

Auf die Idee hat niemand zu kommen, denn die Typverwaltung wird einmalig geschrieben.
Wenn ein funktionierendes Konstrukt durch fehlerhafte Erweiterungen zu Fehlern neigt, so ist das nicht in der Verantwortung desjenigen, der das funktionierende Konstrukt erstellt hat.
Wer mal eben so unüberlegt "erweitert", ohne das Konzept verstanden zu haben, hat's auch nicht besser verdient.
Das ist kein Problem meiner Klassen, sondern ein ganz allgemeines.

Nein, das ist ein Problem für diejenigen, die deine Klassen verwenden wollen - und damit letztlich auch dein Problem.

Xin schrieb:

Tellerrand schrieb:

Fakt ist für mich, dass der Programmierer bei jedem Konstruktoraufruf darauf achten muss welche Umwandlung gemacht wird.
Das Beispiel von Shade of Mine hat durch asInt nunmal den Vorteil, dass der Entwickler diese Arbeit nicht hat. Wenn der Konstruktor Meter(Millimeter) nicht existiert, dann bekommt man das vom Compiler gesagt und man implementiert Meter(Millimeter.asInt())

Der Konstruktor Meter( varOfClassMillimeter ) existiert grundsätzlich nicht, also wird varOfClassMillimeter als Int aufgefasst. Wenn Dir das nicht explizit genug ist, ist das okay. Aber fraglich ist mein Vorgehen nicht.

Die Verwandschaft zwischen Metern und Millimetern wirst auch du nicht leugnen können - und die ist imho so eng, daß noch nichtmal eine eigenständige Klasse "Millimeter" gerechtfertigt ist. Also wird dich jeder Nutzer fragen, warum er eine Umrechnung zwischen beidem nicht mitgeliefert bekommt.

Xin schrieb:

Tellerrand schrieb:

Das bringt dann auch den Vorteil mit sich, dass eine spätere Implementation des Konstruktors Meter(Millimeter) keine Auswirkungen auf den schon vorhandenen Code hat.

Ich halte es für falsch und für einen Designfehler, zwei Klassen für eine Einheitenklasse zu implementieren.

Schön, wenn du einsiehst, daß es ein Designfehler ist, aber es ist dein Designfehler.

Xin schrieb:

Tellerrand schrieb:

Was ich mich mittlerweile auch frage:
Was passiert bei einfachen Rechnungen wie Meter(3) * KG(5), welcher Typ kommt da raus. Und wenn da nur ein typloser Wert retuniert, was bringt mir das Framework?
Weil irgendwie sehe ich schon unmengen von verschiedenen TypKlassen und unmengen von unterschiedlichen Operatoren vor mir.

Wenn Du Meter*Kilogramm nicht klassifizierst, was Du in der Physik ja durch die Beschreibung "kg*m" tust, wie möchtest Du es sonst ausdrücken, dass es etwas anderes als eine typlose Größe ist? Schau Dir das Template an, dass CStoll im INet gefunden hat. Es ist aufwendig, weil die physikalische Schreibweise in C++ nunmal nicht 'nicht aufwendig' zu beschreiben ist.
Es gibt in C++ kein Verfahren, um typsicher und gleichzeitig einfach zu sein.
Daher muss man sich irgendwo auch überlegen, an welchem Punkt man aussteigen muss (nicht will). Man kann nicht alles abbilden, es wird immer Beispiele geben, die man nicht abbilden konnte.
Aber man kann den Alltag abbilden. Typsicherheit im Alltag, das wäre ein gigantischer Schritt nach vorne.

Nochmal: Das Template dort ist womöglich aufwendig umzusetzen - aber einmal erstellt bestimmt nicht aufwendig zu verwenden. Und auf der Basis dieses Templates kann mir der Compiler eine Klasse für jede physikalische Größe anlegen, die ich benötige - und selbständig kontrollieren, ob ich diese Klassen auch korrekt zusammenarbeiten lasse. Du baust dir einen Haufen (fast) identischer Klassen, um ausgewählte Größen damit darstellen zu können - und egal wie weit du gehst, findet sich bestimmt jemand, der über die Grenzen dieser Sammlung hinausgeht (um alle Kombinationen der sieben SI-Basiseinheiten bis zur fünften Potenz zu bilden, benötigst du 7⁶=117649 Klassen - viel Spaß beim Tippen).

Xin

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Xin schrieb:

Das Dumme ist halt nur, dass die Informatik sich auch mit Einheiten beschäftigt, die sich durch SI Einheiten nur ganz schlecht ausdrücken lassen, mit denen man aber auch rechnen können muss: Butterbrot, Teppichboden, Krieger.

Ein "Butterbrot" ist keine Einheit, sondern eine Größe - die dazugehörige Einheit wäre "Anzahl".

*lach* Okay... Und wenn ich an die Steckdose packe durchströhmt mich 230 Stück Volts, richtig. Volt ist eine physikalische Größe und Größen werden in "Anzahl" gerechnet.

Du hattest Physik Leistungskurs und kennst nicht den Unterschied zwischen "Größe" und "Einheit"? Die Größe "Butterbrote" wird in "Stück" gemessen, die Größe "Spannung" in "Volt".

Der Unterschied zwischen "Größe" und "Einheit" ist also dass Butterbrote in Stück gemessen wird und Spannung Volt?
Aha. Verstehst Du die Bedeutung von dem, was Du da schreibst?

Du begreifst's nicht, oder wie? "Butterbrote" ist eine Größe und wird in "Stück" gemessen, "Spannung" ist auch eine Größe und wird in "Volt" gemessen.

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.

Ob die Klasse jetzt StückButterbrote heißt, damit auch der Nussallergiker weiß, dass Butterbrote abzählbar sind
oder nur Butterbrot, da ist mir wirklich jede Diskussion zu blöd für.

Und der Rest von Deinem seitenlangen Posting wiederholt nur Sachen, die grade Du schon längst beantwortet wissen müsstest, schließlich schreibst Du auf alles eine Antwort, müsstest theoretisch meine Antworten gelesen haben.
Scheinbar nicht. Ergo ist es Zeitverschwendung für Dich Antworten erneut hinzuschreiben.

CStoll schrieb:

Xin schrieb:

Meter ist wohl eindeutig eine Größe, die auch als gebrochene Zahl vorkommt. Es von int abzuleiten ist also suboptimal. Das es sich um Beispielcharakter handelt und um keine Produktivlösung, ist wohl eindeutig.

Und wieso verkaufst du uns dann deinen Ansatz bisher als Produktivlösung?

...?
Du entschuldigst, wenn ich Dich auslache? Und zwar lauthals...

Erstens... Ich schrieb bereits mehrfach, dass ich einen vergleichbaren (!= identisch) Anzatz für Punkte (Pixelkoordinaten), Distanzen, Flächen und Felder verwende - produktiv. Ich schrieb genauso, dass (bisher) keine Klassen für physikalische Einheiten habe. Das kann man lesen und verstehen. Muss man natürlich nicht.

Zweitens... das ganze ist als Beispiel einer Ableitung von Primitiven gestartet. Ergo ist das ganze in C++ so nicht möglich. Ergo kann dieser Ansatz keine Produktivlösung sein, weil er in C++ nicht kompilierbar ist. Ergo ist es auch überhaupt nicht möglich einem halbwegs denkenden Menschen das als Produktivlösung zu verkaufen. Wenn Du schon überliest, dass die Ableitung von int ein theoretisches Konstrukt auf eine Deiner Fragen ist, dann darf man von einem Moderator in einem C++ Forum wohl erwarten, dass er sich sowas nicht als Produktivlösung versteht.

Drittens... Wer würde bitte schön Meter und Kilogramm als diskrete Größe in einem int speichern und das auch noch öffentlich als Produktivlösung verkaufen wollen?

Ein bißchen Mitdenken, um das offensichtliche zu sehen, könnte nicht schaden. Und wenn man es nicht als offensichtlich genug versteht, erstmal freundlich nachfragen, statt 'hätte ich Dir soviel Intelligenz zugetraut...'-Blabla in Deine Texte zu integrieren.

Sorry, aber sich mit Dir zu unterhalten hat überhaupt keinen Wert. Du suchst nicht weder nach Verbesserungen noch kommst Du Deiner Aufgabe als Moderator eine Diskussion moderat zu gestalten, ausgesprochen gut nach.
Jedenfalls empfinde ich in Fragen eingestreute Sticheleien und allgemein ausschließlich auf Lehrbuchmeinungen zu beharren nicht als moderat, im Gegenteil, statt eine Diskussion zu führen und zu leiten, stellst Du eine Blockade auf, was richtig zu sein hat und alles andere darf nicht.
Es ist in meinen Augen einfach nur dumm, gewonnene Typsicherheit damit schlecht zu reden, dass man sie in Ausnahmen verlieren könnte und trotzdem besser darsteht als zuvor, weil man mitgeteilt bekommt, dass man den Typ verloren hat.
Du beschreibst eine extreme Einstellung und ein extremes Vorgehen gegen andere Überlegungen.

Und darum setze ich keine Unterhaltung mit Dir fort.

Shade Of Mine schrieb:

Xin schrieb:

Ich sage, dass die Einheiten nur auf explizite Aufforderung konvertiert werden dürfen. Das bedeutet aber nicht, dass ich irgendwem vorschreibe, wie er seine Konstruktoren zu schreiben hat.

Doch, genau das bedeutet es. Man kann deine Klassen nicht verwenden ohne Typsicherheit zu verlieren wenn man non-explizite CTors hat.

Selbstverständlich kannst Du in Deinen Klassen implizite Konstruktoren benutzen und dennoch meine Klassen verwenden. Meine produktiv eingesetzten Typ-Klassen (Bildschirmkoordinaten usw.) sind so ziemlich die einzigen, die explizite Konstruktoren haben.

Du kannst lediglich meine Klassen nicht ohne explizite Konstruktoren verwenden.
Wenn Du also in Deiner Klasse die Klasse Meter verwendest, ruft Dein impliziter Konstruktor ja explizit meinen Konstruktor auf und alles ist im Reinen.
Schließlich kannst Du Deine Klasse nicht ungefragt auf einen Meter zuweisen.

Das einzige, was Du halt nicht machen darfst, ist meinen Klassen implizite Konstruktoren verpassen. Aber wieso solltest Du auf diese Idee kommen - schließlich baust Du in andererleuts Klassen auch nicht ohne Prüfung der Konsequenzen neue Funktionen ein, die das Verhalten der Klasse verändern könnte oder wie oft hast Du schon GTK oder ähnliche Frameworks verändert, weil Du einen neuen Konstruktor hinzufügen wolltest?
Das Hinzufügen von impliziten Konstruktoren zu einer Klasse mit (mindestens einem) expliziten Konstruktor ist ein Schritt, der genau zu überprüfen ist, wenn Du die Prüfung weglässt und es schief geht, dann sehe ich mich den ursprünglichen Entwickler, der seine Klassen mit explicit abgesichert hat, nicht in der Verantwortung, wenn Du seine Absicherung kaputt machst.

Xin schrieb:

Du entschuldigst, wenn ich Dich auslache? Und zwar lauthals...

Xin, hau ab, und komm nicht wieder.

Da gibts noch ein Zitat zu:
[quote]
Verschwinde und komm nie wieder!
Verschwinde und komm nie wieder!
Verschwinde und komm nie wieder!
Huch haha er ist weg! wir habens geschafft
wir haben ihm gesagt er soll gehen und weg ist er...
[/qoute]
Ob das wirklich so sinnvoll ist(Diese "Antwort")???

Erzähl doch bitte noch ein paar Gechichten aus deinem Leben, Xin, wie dus Professoren und anderen ordentlich gegeben hast!

Jester

Xin schrieb:

Wo da der Unterschied zwischen Einheit und Größe liegt, zwei synonymen Begriffen, das weißt vermutlich nur Du.

Könntest Du das bei Wikipedia gleich noch mitkorrigieren? Die haben vermutlich aus Versehen eine Seite für "physikalische Größe" und eine für "Maßeinheit". Da das das gleiche ist sollte man die Artikel zusammenführen, oder?

CStoll

Xin schrieb:

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Xin schrieb:

Das Dumme ist halt nur, dass die Informatik sich auch mit Einheiten beschäftigt, die sich durch SI Einheiten nur ganz schlecht ausdrücken lassen, mit denen man aber auch rechnen können muss: Butterbrot, Teppichboden, Krieger.

Ein "Butterbrot" ist keine Einheit, sondern eine Größe - die dazugehörige Einheit wäre "Anzahl".

*lach* Okay... Und wenn ich an die Steckdose packe durchströhmt mich 230 Stück Volts, richtig. Volt ist eine physikalische Größe und Größen werden in "Anzahl" gerechnet.

Du hattest Physik Leistungskurs und kennst nicht den Unterschied zwischen "Größe" und "Einheit"? Die Größe "Butterbrote" wird in "Stück" gemessen, die Größe "Spannung" in "Volt".

Der Unterschied zwischen "Größe" und "Einheit" ist also dass Butterbrote in Stück gemessen wird und Spannung Volt?
Aha. Verstehst Du die Bedeutung von dem, was Du da schreibst?

Du begreifst's nicht, oder wie? "Butterbrote" ist eine Größe und wird in "Stück" gemessen, "Spannung" ist auch eine Größe und wird in "Volt" gemessen.

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.

Bitte lies meinen Beitrag nochmal langsam - zur Not auch mehrfach. Vielleicht wird dir der Unterschied beim Zehnten Mal ja endlich klar.

Spannung ist eine Größe, Volt ist eine (Maß)Einheit - und wenn du so clever bist, in die Steckdose zu greifen, erwischt dich eine Spannung mit dem Wert "230 Volt".

Xin schrieb:

Und der Rest von Deinem seitenlangen Posting wiederholt nur Sachen, die grade Du schon längst beantwortet wissen müsstest, schließlich schreibst Du auf alles eine Antwort, müsstest theoretisch meine Antworten gelesen haben.
Scheinbar nicht. Ergo ist es Zeitverschwendung für Dich Antworten erneut hinzuschreiben.

Ja, mir kommt auch langsam in den Sinn, daß es sinnlos ist, dir etwas erklären zu wollen. Aber ich bin nunmal Optimist - und deshalb hoffe ich immer noch, daß du irgendwann meine Beiträge verstehst (und nicht nur als unsinnig abtust).

Du bist in der Lage, kreativ zu denken (das deuten zumindest deine Lösungen an), du bist in der Lage, "Schwachstellen zu entdecken und zu thematisieren" (hat dir zumindest dein Prof bescheinigt) - also versuch mal, beides zusammenzunehmen und die Schwachstellen in deinem Design zu thematisieren.

Xin schrieb:

CStoll schrieb:

Xin schrieb:

Meter ist wohl eindeutig eine Größe, die auch als gebrochene Zahl vorkommt. Es von int abzuleiten ist also suboptimal. Das es sich um Beispielcharakter handelt und um keine Produktivlösung, ist wohl eindeutig.

Und wieso verkaufst du uns dann deinen Ansatz bisher als Produktivlösung?

...?
Du entschuldigst, wenn ich Dich auslache? Und zwar lauthals...

Erstens... Ich schrieb bereits mehrfach, dass ich einen vergleichbaren (!= identisch) Anzatz für Punkte (Pixelkoordinaten), Distanzen, Flächen und Felder verwende - produktiv. Ich schrieb genauso, dass (bisher) keine Klassen für physikalische Einheiten habe. Das kann man lesen und verstehen. Muss man natürlich nicht.

Lachen kannst du gerne, aber dann entschuldige bitte, wenn ich DICH auslache. Aber nur weil die Einheiten in deinem System nicht "Meter" und "Kilogramm" heißen, stehen die Probleme dort genauso wie in dem physikalischen Einheitensystem, das du hier so vehement verteidigst.

Xin schrieb:

Zweitens... das ganze ist als Beispiel einer Ableitung von Primitiven gestartet. Ergo ist das ganze in C++ so nicht möglich. Ergo kann dieser Ansatz keine Produktivlösung sein, weil er in C++ nicht kompilierbar ist. Ergo ist es auch überhaupt nicht möglich einem halbwegs denkenden Menschen das als Produktivlösung zu verkaufen. Wenn Du schon überliest, dass die Ableitung von int ein theoretisches Konstrukt auf eine Deiner Fragen ist, dann darf man von einem Moderator in einem C++ Forum wohl erwarten, dass er sich sowas nicht als Produktivlösung versteht.

OK, du hast dir etwas überlegt auf einer "was wäre wenn"-Basis. Aber du hast damit immer noch nicht erklärt, warum die Ableitung von int in der Praxis notwendig (oder zumindest nützlicher als die bestehende Sprache) sein sollte.

Xin schrieb:

Drittens... Wer würde bitte schön Meter und Kilogramm als diskrete Größe in einem int speichern und das auch noch öffentlich als Produktivlösung verkaufen wollen?

Du ganz offensichtlich (wobei sich am Grundproblem auch nichts ändern würde, wenn du double als Grundlage verwendest).

Xin schrieb:

Ein bißchen Mitdenken, um das offensichtliche zu sehen, könnte nicht schaden. Und wenn man es nicht als offensichtlich genug versteht, erstmal freundlich nachfragen, statt 'hätte ich Dir soviel Intelligenz zugetraut...'-Blabla in Deine Texte zu integrieren.

Ich bin ein geduldiger Mensch - aber wenn mein Gesprächspartner mich wiederholt beleidigt, schieße ich auch irgendwann dezent zurück.

Xin schrieb:

Sorry, aber sich mit Dir zu unterhalten hat überhaupt keinen Wert. Du suchst nicht weder nach Verbesserungen noch kommst Du Deiner Aufgabe als Moderator eine Diskussion moderat zu gestalten, ausgesprochen gut nach.
Jedenfalls empfinde ich in Fragen eingestreute Sticheleien und allgemein ausschließlich auf Lehrbuchmeinungen zu beharren nicht als moderat, im Gegenteil, statt eine Diskussion zu führen und zu leiten, stellst Du eine Blockade auf, was richtig zu sein hat und alles andere darf nicht.

Falls es dir entgangen ist - ich beteilige mich nicht als "Moderator" an diesem Thema (ich sollte Marcus mal darauf ansprechen, ob man den Status Board-spezifisch anzeigen könnte), sondern als Programmierer.

Xin schrieb:

Es ist in meinen Augen einfach nur dumm, gewonnene Typsicherheit damit schlecht zu reden, dass man sie in Ausnahmen verlieren könnte und trotzdem besser darsteht als zuvor, weil man mitgeteilt bekommt, dass man den Typ verloren hat.
Du beschreibst eine extreme Einstellung und ein extremes Vorgehen gegen andere Überlegungen.

Du stufst mich als "dumm" ein und wunderst dich umgekehrt darüber, wenn andere deine Intelligenz anzweifeln? Was soll man da noch erwarten?

Ein typloses System ist schlecht.
Ein System, das einen auf verlorene Typinformationen aufmerksam macht, ist etwas besser
Ein System, das Typinformationen gar nicht erst verliert, ist am besten

Du präsentierst hier eine hypothetische Lösung für Stufe 2 - die solltest du jetzt auch gegenüber einer Stufe-3-Lösung verteidigen können (und das geht nicht, indem du alle unpassenden Argumente ignorierst).

Xin schrieb:

Und darum setze ich keine Unterhaltung mit Dir fort.

Auch gut - soll ich einen Kollegen bitten, hier dichtzumachen? (abgesehen von einigen kürzeren Einwürfen besteht der Thread hauptsächlich aus der Unterhaltung zwischen uns beiden)

Xin schrieb:

erstmal freundlich nachfragen, statt 'hätte ich Dir soviel Intelligenz zugetraut...'-Blabla in Deine Texte zu integrieren.

ROFL

Xin

Jester schrieb:

Xin schrieb:

Wo da der Unterschied zwischen Einheit und Größe liegt, zwei synonymen Begriffen, das weißt vermutlich nur Du.

Könntest Du das bei Wikipedia gleich noch mitkorrigieren? Die haben vermutlich aus Versehen eine Seite für "physikalische Größe" und eine für "Maßeinheit". Da das das gleiche ist sollte man die Artikel zusammenführen, oder?

Wie schon gesagt... (den Text brauche ich wohl auf einer F-Taste) es ist absolut obsolete darüber zu debatieren, ob wir die Klassen nun Butterbrot oder StückButterbrot nennen oder Du nun den Typ sicherst, indem Du Spannung( 5 ) oder Volt( 5 ) schreibst, spielt keine Rolle.

Es interessiert sich hier keiner ernsthaft für Typsicherung, um das Thema zu verbessern.
Es lohnt sich also nicht darüber hier zu diskutieren.

CStoll schrieb:

Xin schrieb:

Du beschreibst eine extreme Einstellung und ein extremes Vorgehen gegen andere Überlegungen.

Du stufst mich als "dumm" ein und wunderst dich umgekehrt darüber, wenn andere deine Intelligenz anzweifeln? Was soll man da noch erwarten?

Ein typloses System ist schlecht.

Ein System, das einen auf verlorene Typinformationen aufmerksam macht, ist etwas besser

Ein System, das Typinformationen gar nicht erst verliert, ist am besten

Du präsentierst hier eine hypothetische Lösung für Stufe 2 - die solltest du jetzt auch gegenüber einer Stufe-3-Lösung verteidigen können (und das geht nicht, indem du alle unpassenden Argumente ignorierst).

Warum sollte ich unpassende Argumente nicht ignorieren? Ob Du nun Spannung von Leistung unterscheidest oder Volt von Watt, ist absolut unpassend und damit kein Argument. Was Du Dir da zusammenerklärt hast, lässt sich besser mit "Draußen ist es dunkler als Nachts" zusammenfassen. Weder die Temperatur der Nacht, noch ob Du Spannung als "Spannung" oder als "in Volt" beschreibst trägt es weder zur Typsicherheit bei, noch wäre es ein Argument gegen was auch immer. Es ist kein Argument - es ist ausschließlich unpassend.

Und derart Unpassendes zieht sich durch alle größeren Diskussionen hier im Forum. Ich habe mir jetzt einige Diskussionen nebenher durchgelesen und sehe, dass hier nicht nur wild gegen mich geschrieen wird, wie hier unsere drei Unregistrierten mal wieder, sondern sobald es den Hauch einer Kritik gibt, schlägt hier jeder auf den anderen und jeder Versuch von einzelnen ein Gespräch wieder auf ein konstruktives Normalmaß runterzuholen, wird übergangen.
Das meinte ich in dem anderen Thread mit Kindergarten.
Interessanterweise finden sich auch dort immer wieder die gleichen Namen. Es ist also sogar möglich, den Forum-Kindergarten auf eine Gruppe von Mitgliedern einzugrenzen.

Und der Forumskindergarten will mich aus dem Forum entfernen? Nein, viele wollen hier nur ein Angriffsziel und ich habe ja auch ein gutes Ziel abgegeben. Es geht hier nicht darum, etwas voran zu bringen, sondern es geht darum Dinge kaputt zu machen. Ich sehe wenig Grund, hier noch nach konstruktiven Diskussionen zu suchen oder mehr als beläufig hier und da mal mitzulesen und ggfs. eine kurze Antwort zu schreiben. Alles, was darüber hinausgeht, erweist sich als Zeitverschwendung.
CStoll, das ist ehrlich nicht als Beleidigung gemeint, auch wenn es kaum anders aufzufassen wäre, es ist meine subjektive Meinung: ich sehe Dich als Mitglied des Forumskindergarten. Moderator ist man und verhält sich im diesem Forum, wie auch in allen anderen Foren entsprechend oder man ist es nicht. Alleine auf die Idee zu kommen, sich nur in Subforen dieses Forums als Moderator verhalten zu müssen, kann ich absolut nicht nachvollziehen.

Ich stimme Dir (hier nicht zum ersten Mal) zu, dass ein System, dass keine Typinformationen verliert, besser ist, als meins.
Aber ich habe noch keins. Und Du hast auch keins.
Du hast ein unfertiges Template aus dem Internet für SI-Einheiten, dass aber kein Argument ist, denn (wie bereits gesagt) auch dieses kannst Du mit meinen Klassen verwenden. Du widerlegst Deine "Argumente" mit hundertausenden Klassen also selbst - warum muss ich Dir das alles immer wieder vorkauen? Auch das ist Zeitverwendung.

Dein Template kann ein Butterbrot nicht von einem Haus unterscheiden.
Und die Realität in der Informatik rechnet nunmal nicht ausschließlich mit SI-Einheiten.
Dein Template nutzt im Alltag also bei 7 von unendlich vielen Einheiten etwas. Es löst eben nicht alle Probleme.
In der Realität kommst Du keinen Schritt weiter als ich.

Ich habe nicht versprochen, mit den Klassen alles perfekt zu machen. Ich habe gesagt, ich verbessere etwas. Und das ich das das tue, siehst Du hier ja auch ein. Und es gefällt Dir nicht, weil ich nicht die ganze Welt beschreiben kann.
Du hast nichts, was besser ist und Du bist vehement gegen Typsicherheit im Alltag verbunden mit der Notwendigkeit von denkenden Entwicklern, die die Typsicherheit in Grenzfällen festlegen. Die Alternative ist, dem Entwickler überhaupt keine Hilfe an die Hand zu geben.
Ich bin realistisch und in die Realität ist nicht perfekt.

Du hast gar nichts.
Du bist nur dagegen.

Wenn hier jemand an meiner Intelligenz zu zweifeln hat, dann ich, denn ich diskutiere mit Dir seit x Seiten, obwohl Du nichts Konstruktives zu bieten hast. Und daher lasse ich beides.

Jester

Xin schrieb:

Jester schrieb:

Xin schrieb:

Wo da der Unterschied zwischen Einheit und Größe liegt, zwei synonymen Begriffen, das weißt vermutlich nur Du.

Könntest Du das bei Wikipedia gleich noch mitkorrigieren? Die haben vermutlich aus Versehen eine Seite für "physikalische Größe" und eine für "Maßeinheit". Da das das gleiche ist sollte man die Artikel zusammenführen, oder?

Wie schon gesagt... (den Text brauche ich wohl auf einer F-Taste) es ist absolut obsolete darüber zu debatieren, ob wir die Klassen nun Butterbrot oder StückButterbrot nennen oder Du nun den Typ sicherst, indem Du Spannung( 5 ) oder Volt( 5 ) schreibst, spielt keine Rolle.

Heißt das jetzt Du gibst zu, dass Du Unsinn geredet hast als Du behauptet hast Größe und Einheit seien Synonyme? Wenn Du nicht darüber diskutieren willst, wieso stellst Du dann falsche Behauptungen auf? Ich sehe auch nicht, wo Du hier Typen und Klassen ins Spiel bringst. Die sind für die Frage ob Größen und Einheiten das gleiche sind oder nicht völlig unerheblich.

Größen und Einheiten sind nicht das gleiche und damit nicht synonym. Darüber müssen wir hoffentlich garnicht diskutieren (siehe Wikipedia). (Oder sind sie in Wirklichkeit doch synonym und dass sie verschieden sind ist nur die -- natürlich falsche -- Lehrbuchmeinung?).

Xin schrieb:

Ob Du nun Spannung von Leistung unterscheidest oder Volt von Watt, ist absolut unpassend und damit kein Argument.

Was auch immer das bedeuten soll...

Xin schrieb:

Moderator ist man und verhält sich im diesem Forum, wie auch in allen anderen Foren entsprechend oder man ist es nicht. Alleine auf die Idee zu kommen, sich nur in Subforen dieses Forums als Moderator verhalten zu müssen, kann ich absolut nicht nachvollziehen.

Gut, daß Du keine Ahnung hast. Nein, das werde ich jetzt nicht begründen.

Xin schrieb:

Du hast gar nichts.
Du bist nur dagegen.

Hier haben alle etwas, aber Du weigerst Dich, es zu verstehen. Das ist aber auch nicht schlimm, da Du ja bereits selbst gesagt hast, daß Deine Lösung eine schlechtere ist.

Grüße, scrub

PS: Du magst zwar Ahnung von "proggen" haben, aber bitte philosophiere nicht über technische Dinge.

Xin

Jester schrieb:

Xin schrieb:

Jester schrieb:

Xin schrieb:

Wo da der Unterschied zwischen Einheit und Größe liegt, zwei synonymen Begriffen, das weißt vermutlich nur Du.

Könntest Du das bei Wikipedia gleich noch mitkorrigieren? Die haben vermutlich aus Versehen eine Seite für "physikalische Größe" und eine für "Maßeinheit". Da das das gleiche ist sollte man die Artikel zusammenführen, oder?

Wie schon gesagt... (den Text brauche ich wohl auf einer F-Taste) es ist absolut obsolete darüber zu debatieren, ob wir die Klassen nun Butterbrot oder StückButterbrot nennen oder Du nun den Typ sicherst, indem Du Spannung( 5 ) oder Volt( 5 ) schreibst, spielt keine Rolle.

Heißt das jetzt Du gibst zu, dass Du Unsinn geredet hast als Du behauptet hast Größe und Einheit seien Synonyme? Wenn Du nicht darüber diskutieren willst, wieso stellst Du dann falsche Behauptungen auf?

Ich habe aus CStolls "Formulierungen" nicht rausgelesen können (und kann es immernoch nicht), dass er da auf einen Unterschied zwischen z.B. Spannung und Volt rauswill, ich suchte ein Argument. Ich ging davon aus, dass er zählbar und unzählbar unterscheiden wollte - was aber auch kein Argument darstellt.

Ob ich die Klasse, in der ich Spannung messe nun "class Spannung" nenne oder "class Volt", weil Spannung in Volt gemessen wird. Es ist so oder so typsicher, es ist also auch kein Argument für oder gegen etwas.
Auf die Idee, dass er hier Spannung und Volt unterscheiden will, kam ich erst durch Dein Posting.

Dass Spannung in Volt gemessen wird und somit Spannung != Volt ist, ist semantisch klar, sogesehen ist "synonym" Unsinn. Zwischen Spannung und Volt besteht aber eine klare Beziehung. Man kann Spannung nicht mal eben in Meter messen. Die Unterscheidung in zwei Klassen/Begriffe hat also keinen Sinn. Man legt sich einmal fest, welchen Begriff man verwenden will und gut ist's.

otze

Das Problem ist eher, dass das Wort "Spannung" Kontextsensitiv ist. Spannung gibts in der Elektrizitätslehre, aber auch in der Mechanik. Im ersten Fall wird die Spannung in Volt gemessen, im zweiten Fall in N/mm². Also ist die Beziehung nicht klar.

Undertaker

Xin schrieb:

Nein, viele wollen hier nur ein Angriffsziel und ich habe ja auch ein gutes Ziel abgegeben. Es geht hier nicht darum, etwas voran zu bringen, sondern es geht darum Dinge kaputt zu machen. Ich sehe wenig Grund, hier noch nach konstruktiven Diskussionen zu suchen oder mehr als beläufig hier und da mal mitzulesen und ggfs. eine kurze Antwort zu schreiben. Alles, was darüber hinausgeht, erweist sich als Zeitverschwendung.

oberstes gebot lautet: immer cool bleiben. sobald man auf provokationen und beleidigungen einsteigt und selber sauer reagiert, macht man sich am niedergang der diskussion mitschuldig. es funktioniert - konzentrier dich das nächste mal nur auf die für das thema relevanten aussagen/textstellen und alles wird gut

Xin schrieb:

Moderator ist man und verhält sich im diesem Forum, wie auch in allen anderen Foren entsprechend oder man ist es nicht. Alleine auf die Idee zu kommen, sich nur in Subforen dieses Forums als Moderator verhalten zu müssen, kann ich absolut nicht nachvollziehen.

ein moderator in einem (diesem) internet-forum ist leider nicht das gleiche, wie z.b. ein (gesprächs)moderator in einer talk show. nur wenige hier 'moderieren' wirklich diskussionen, sondern setzen nur die forenregeln durch (oder ihre eigene version davon). damit musste leben, meckern hilft leider nichts.

Xin hat seinen ersten Fan

Undertaker schrieb:

oberstes gebot lautet: immer cool bleiben. sobald man auf provokationen und beleidigungen einsteigt und selber sauer reagiert, macht man sich am niedergang der diskussion mitschuldig. es funktioniert - konzentrier dich das nächste mal nur auf die für das thema relevanten aussagen/textstellen und alles wird gut

Das ist natürlich insbesondere dann als groteks einzuschätzen, wenn man bedenkt, dass es Xin ist, der hier seitenweise Beleidigungen raushaut!

Xin schrieb:

CStoll, das ist ehrlich nicht als Beleidigung gemeint, auch wenn es kaum anders aufzufassen wäre, es ist meine subjektive Meinung: ich sehe Dich als Mitglied des Forumskindergarten.

So oft wie du hier Kindergarten oder ähnliches herumproletest kann man das gar nicht ernst nehmen. Das nur so nebenbei.

Xin schrieb:

Moderator ist man und verhält sich im diesem Forum, wie auch in allen anderen Foren entsprechend oder man ist es nicht.

Dass das nicht möglich ist sieht man daran, dass Mods einer bestimmten Kategorie dort nur Mod werden konnten, weil sie auf eben diesem Gebiet eine gewisse Kompetenz haben. Gleichzeitig kann praktisch keiner diese Kompetenz in allen Kategorien dieses Forums haben. So kann ich mich im MFC-Forum gar nicht als Mod verhalten weil mir dort schlicht die Kompetenz fehlt.

Methoden mit bool-Parametern und &quot;Lesbarkeit&quot; im Kontext

Methoden mit bool-Parametern und "Lesbarkeit" im Kontext