Methoden mit bool-Parametern und "Lesbarkeit" im Kontext

[Xin]

Mr. N schrieb:

int i = m / Meter(1);

Xin schrieb:

Ich finde asInt() oder int() besser, weil asInt(), wie auch int(), inline zu nichts herrausoptimiert kann und m/Meter(1) eine Rechenoperation Operation verlangt, die nur sehr schwer rausoptimiert werden kann und vermutlich auch nicht rausoptimiert wird.
Trotzdem ist Deine Möglichkeit natürlich hier wie da möglich.

Ich denke, doch, sie wird herausoptimiert. Selbst wenn nicht, mit einer leichten Abwandlung könnte ich die Herausoptimierung geradezu erzwingen.

Die da wäre?

[Mr. N]

Xin schrieb:

Mr. N schrieb:

int i = m / Meter(1);

Xin schrieb:

Ich finde asInt() oder int() besser, weil asInt(), wie auch int(), inline zu nichts herrausoptimiert kann und m/Meter(1) eine Rechenoperation Operation verlangt, die nur sehr schwer rausoptimiert werden kann und vermutlich auch nicht rausoptimiert wird.
Trotzdem ist Deine Möglichkeit natürlich hier wie da möglich.

Ich denke, doch, sie wird herausoptimiert. Selbst wenn nicht, mit einer leichten Abwandlung könnte ich die Herausoptimierung geradezu erzwingen.

Die da wäre?

So in etwa:

class MeterEinheit {};

inline int Meter::operator/(MeterEinheit) const {
  return this->value;
}

Aber wie gesagt, das sollte nichtmal nötig sein.

[Undertaker]

CStoll schrieb:

[*]dich stufe ich als (vereinfacht formuliert) "gelegentlich nervtötend" ein - du magst zwar recht gut im Umgang mit C sein, aber wenn du versuchst, das auf C++ Probleme anzuwenden, landest du schnell auf der ***
[/list]

sowas würde ich niemals machen. wenn ich im C++ forrum code poste, dann nur solchen, der anstandslos durch einen stinknormalen C++ compiler geht.

[Xin]

Jester schrieb:

Xin schrieb:

Ansonsten reicht das Template alleine erstmal nur für SI-Einheiten. Es bietet im Alltag daher auch keinen Vorteil.

Naja, aber es bietet immerhin auch alle Kombinationen davon. Wie willst Du das mit Deinem Ansatz erreichen?

Und eine weitere Dimension des template-vectors als Butterbrote aufzufassen löst auch das Problem der Butterbrote.

btw: dass du mir vorher noch schnell erklärst was template sind kann ich auch in die Schublade effekthascherei stecken, gell?

Nein, denn offenbar fällt Dir nicht auf, dass das Template in meinem Ansatz genauso gut funktioniert, ergo ebenso alle Klassen in meinem Ansatz erzeugen kann, erscheint mir das notwendig. Die Frage ist schließlich nicht, wie woher die Klassen kommen, sondern wie sie aussehen.

Da Du das template aber nicht unendlich dimensional erzeugen kannst, jedenfalls nicht in der Realität, ist wohl eindeutig.
Daher kommst Du mit dem Template nicht weiter als ohne. Schon mit den 7 Einheiten wird das ganze vollkommen unverständlich.

unit< 1, 1,-2, 0, 0, 0, 0> Kraft;
unit< 1, 0, 0, 0, 0, 0, 0> Masse = unit< 1, 0, 0, 0, 0, 0, 0>( 10 );
unit< 0, 1, 0, 0, 0, 0, 0> Strecke = unit< 0, 1, 0, 0, 0, 0, 0>( 5 );
unit< 0, 0, 1, 0, 0, 0, 0> Zeit = unit< 0, 0, 1, 0, 0, 0, 0>( 2 );

Kraft = Masse * Strecke / Zeit / Zeit;

Wenn das jemand kapieren soll, brauchst Du also jede Menge Typedefs oder Ableitungen oder sonst irgendwas, um brauchbare Namen in den Code zu bekommen. Oder halt viel Spaß beim Knobeln.
Und da möchtest Du weitere Dimensionen für Butterbrote hinzufügen?
Die Realität ist also offenbar schwierig zu beschreiben, also müssen wir uns hier und da wohl etwas einschränken, also könnte es passieren, das man für die extremeren Fälle wie kg*Butterbrot einen Typverlust riskieren müssen.

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Ich denke, doch, sie wird herausoptimiert. Selbst wenn nicht, mit einer leichten Abwandlung könnte ich die Herausoptimierung geradezu erzwingen.

Die da wäre?

So in etwa:

class MeterEinheit {};

inline int Meter::operator/(MeterEinheit) const {
  return this->value;
}

Aber wie gesagt, das sollte nichtmal nötig sein.

Das will ich hoffen, ansonsten frage ich mich ernsthaft, wofür operator int() wohl gut sein sollte...

[Mr. N]

Dann will ich mal hoffen, dass ich mich an der Diskussion beteiligen kann, ohne Beleidigungen zu ernten.

Xin schrieb:

Jester schrieb:

Xin schrieb:

Ansonsten reicht das Template alleine erstmal nur für SI-Einheiten. Es bietet im Alltag daher auch keinen Vorteil.

Naja, aber es bietet immerhin auch alle Kombinationen davon. Wie willst Du das mit Deinem Ansatz erreichen?

Und eine weitere Dimension des template-vectors als Butterbrote aufzufassen löst auch das Problem der Butterbrote.

btw: dass du mir vorher noch schnell erklärst was template sind kann ich auch in die Schublade effekthascherei stecken, gell?

Nein, denn offenbar fällt Dir nicht auf, dass das Template in meinem Ansatz genauso gut funktioniert, ergo ebenso alle Klassen in meinem Ansatz erzeugen kann, erscheint mir das notwendig. Die Frage ist schließlich nicht, wie woher die Klassen kommen, sondern wie sie aussehen.

Da Du das template aber nicht unendlich dimensional erzeugen kannst, jedenfalls nicht in der Realität, ist wohl eindeutig.
Daher kommst Du mit dem Template nicht weiter als ohne. Schon mit den 7 Einheiten wird das ganze vollkommen unverständlich.

unit< 1, 1,-2, 0, 0, 0, 0> Kraft;
unit< 1, 0, 0, 0, 0, 0, 0> Masse = unit< 1, 0, 0, 0, 0, 0, 0>( 10 );
unit< 0, 1, 0, 0, 0, 0, 0> Strecke = unit< 0, 1, 0, 0, 0, 0, 0>( 5 );
unit< 0, 0, 1, 0, 0, 0, 0> Zeit = unit< 0, 0, 1, 0, 0, 0, 0>( 2 );

Kraft = Masse * Strecke / Zeit / Zeit;

Wenn das jemand kapieren soll, brauchst Du also jede Menge Typedefs oder Ableitungen oder sonst irgendwas, um brauchbare Namen in den Code zu bekommen. Oder halt viel Spaß beim Knobeln.
Und da möchtest Du weitere Dimensionen für Butterbrote hinzufügen?

In der Praxis würde man sicherlich nicht template<int, int, ...> class unit; nutzen sondern eher etwas basierend auf der MPL.

Ich denke da an sowas:

struct meter_tag {};
struct second_tag {};
struct kilogram_tag {};

typedef unit<
    mpl::map1<
      mpl::pair<meter_tag, mpl::int_<1> >
    > 
  > meter;
typedef unit<
    mpl::map3<
      mpl::pair<kilogram_tag, mpl::int_<1> >,
      mpl::pair<meter_tag, mpl::int_<1> >,
      mpl::pair<second_tag, mpl::int_<-2>
    >
  > newton;

Oder falls dir das zuviel Syntax ist:

typedef unit<
   UNIT_TYPEMAP((kilogram, 1)(meter, 1)(second, -2))
  > newton;

Das wäre aber MrN-typisch eine ziemlich komplexe API, wie ich gerne zugebe.

Xin schrieb:

Die Realität ist also offenbar schwierig zu beschreiben, also müssen wir uns hier und da wohl etwas einschränken, also könnte es passieren, das man für die extremeren Fälle wie kg*Butterbrot einen Typverlust riskieren müssen.

Butterbrot ist kein relevanter Typ, aber ich denke, ich habe ein erweiterbares Typsystem skizziert.

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Ich denke, doch, sie wird herausoptimiert. Selbst wenn nicht, mit einer leichten Abwandlung könnte ich die Herausoptimierung geradezu erzwingen.

Die da wäre?

So in etwa:

class MeterEinheit {};

inline int Meter::operator/(MeterEinheit) const {
  return this->value;
}

Aber wie gesagt, das sollte nichtmal nötig sein.

Das will ich hoffen, ansonsten frage ich mich ernsthaft, wofür operator int() wohl gut sein sollte...

Wozu operator int()? Division ist viel kohärenter zum physikalischen Vorbild.

[Xin]

Mr. N schrieb:

Dann will ich mal hoffen, dass ich mich an der Diskussion beteiligen kann, ohne Beleidigungen zu ernten.

Ich garantiere für nichts, ich habe einen Ruf zu verlieren. ;->

Mr. N schrieb:

Das wäre aber MrN-typisch eine ziemlich komplexe API, wie ich gerne zugebe.

Wenn's funktioniert, wunderbar. Unabhängig davon musst Du dennoch alle Namen beschreiben. Je besser Du das automatisierst, desto besser. CStoll rechnete mal aus, dass bis zur 5. Potenz was um die 100000 Namen zu definieren wären.
Das artet auch mit dem besten Template immernoch in Arbeit aus.

Für die grundlegenden Größen, sieht's interessant aus, aber unterm Strich bist Du auch noch keinen Schritt weiter als ich.
Ich bilde die perfekte Welt schließlich nicht ab, weil ich zu blöd dafür wäre, sondern weil es zu aufwendig wird.

Mr. N schrieb:

Xin schrieb:

Die Realität ist also offenbar schwierig zu beschreiben, also müssen wir uns hier und da wohl etwas einschränken, also könnte es passieren, das man für die extremeren Fälle wie kg*Butterbrot einen Typverlust riskieren müssen.

Butterbrot ist kein relevanter Typ, aber ich denke, ich habe ein erweiterbares Typsystem skizziert.

"Butterbrot ist kein Relevanter Typ"?
Ob Butterbrot ein relevanter Typ ist, hängt vielleicht etwas von der zu schreibenden Anwendung ab.

Xin schrieb:

Mr. N schrieb:

Ich denke, doch, sie wird herausoptimiert. Selbst wenn nicht, mit einer leichten Aber wie gesagt, das sollte nichtmal nötig sein.

Das will ich hoffen, ansonsten frage ich mich ernsthaft, wofür operator int() wohl gut sein sollte...

Wozu operator int()? Division ist viel kohärenter zum physikalischen Vorbild.[/quote]
Hmm... operator int() ist viel kohärenter zur C++-Programmierung?
operator int() ist leicht zu optimieren und kostet keine Rechenzeit.
Und es verbietet die Division ja nicht.

Also wozu nicht operator int()?

[Mr. N]

Xin schrieb:

Mr. N schrieb:

Dann will ich mal hoffen, dass ich mich an der Diskussion beteiligen kann, ohne Beleidigungen zu ernten.

Ich garantiere für nichts, ich habe einen Ruf zu verlieren. ;->

...

Xin schrieb:

Mr. N schrieb:

Das wäre aber MrN-typisch eine ziemlich komplexe API, wie ich gerne zugebe.

Wenn's funktioniert, wunderbar. Unabhängig davon musst Du dennoch alle Namen beschreiben. Je besser Du das automatisierst, desto besser. CStoll rechnete mal aus, dass bis zur 5. Potenz was um die 100000 Namen zu definieren wären.
Das artet auch mit dem besten Template immernoch in Arbeit aus.

Ich definiere nur die Namen, für die es auch einen Physikalischen Namen gibt. Ansonsten überlege ich mir vielleicht eine Kurzsyntax für zusammengesetzte Einheiten - oder ich benutze C++0x auto / decltype bzw. schon jetzt BOOST_AUTO / BOOST_TYPEOF / typeof.

Xin schrieb:

Für die grundlegenden Größen, sieht's interessant aus, aber unterm Strich bist Du auch noch keinen Schritt weiter als ich.
Ich bilde die perfekte Welt schließlich nicht ab, weil ich zu blöd dafür wäre, sondern weil es zu aufwendig wird.

Und ich denke, mittelfristig würde es sich durchaus lohnen, das sauber abzubilden.

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Die Realität ist also offenbar schwierig zu beschreiben, also müssen wir uns hier und da wohl etwas einschränken, also könnte es passieren, das man für die extremeren Fälle wie kg*Butterbrot einen Typverlust riskieren müssen.

Butterbrot ist kein relevanter Typ, aber ich denke, ich habe ein erweiterbares Typsystem skizziert.

"Butterbrot ist kein Relevanter Typ"?
Ob Butterbrot ein relevanter Typ ist, hängt vielleicht etwas von der zu schreibenden Anwendung ab.

Butterbrote kann man ganz toll in "Stück" messen, finde ich.

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Ich denke, doch, sie wird herausoptimiert. Selbst wenn nicht, mit einer leichten Aber wie gesagt, das sollte nichtmal nötig sein.

Das will ich hoffen, ansonsten frage ich mich ernsthaft, wofür operator int() wohl gut sein sollte...

Wozu operator int()? Division ist viel kohärenter zum physikalischen Vorbild.

Hmm... operator int() ist viel kohärenter zur C++-Programmierung?

Finde ich nicht.

Xin schrieb:

operator int() ist leicht zu optimieren und kostet keine Rechenzeit.

operator/ ist genauso gut optimierbar. Du solltest dir vielleicht mal die Optimierfähigkeiten von modernen C++-Compilern genauer anschauen.

Xin schrieb:

Und es verbietet die Division ja nicht.

Also wozu nicht operator int()?

Nun ja, meinetwegen könnte man auch asInt() und operator/ parallel erlauben. Warum operator int() schlecht ist, haben CStoll und Shade IMHO sehr schön erklärt.

[Xin]

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Dann will ich mal hoffen, dass ich mich an der Diskussion beteiligen kann, ohne Beleidigungen zu ernten.

Ich garantiere für nichts, ich habe einen Ruf zu verlieren. ;->

...

Auch kein Humor... :-\

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Die Realität ist also offenbar schwierig zu beschreiben, also müssen wir uns hier und da wohl etwas einschränken, also könnte es passieren, das man für die extremeren Fälle wie kg*Butterbrot einen Typverlust riskieren müssen.

Butterbrot ist kein relevanter Typ, aber ich denke, ich habe ein erweiterbares Typsystem skizziert.

"Butterbrot ist kein Relevanter Typ"?
Ob Butterbrot ein relevanter Typ ist, hängt vielleicht etwas von der zu schreibenden Anwendung ab.

Butterbrote kann man ganz toll in "Stück" messen, finde ich.

Häuser auch.
Also sind 4 Stück Häuser == 4 Stück Butterbrote und kein Stück Typsicher.

Mr. N schrieb:

Xin schrieb:

operator int() ist leicht zu optimieren und kostet keine Rechenzeit.

operator/ ist genauso gut optimierbar. Du solltest dir vielleicht mal die Optimierfähigkeiten von modernen C++-Compilern genauer anschauen.

Vielleicht solltest Du überlegen, dass operator / () ein Argument hat, was sich Beachtung wünscht und operator int() nicht.
Wenn Du durch Metereinheit teilst, passt das, aber das ist ein billiges Hilfskonstrukt.
Teilst Du durch Meter(1) hast Du ein Argument, dass Du beachten musst und das lässt sich nicht gut rausoptimieren.

Xin schrieb:

Nun ja, meinetwegen könnte man auch asInt() und operator/ parallel erlauben. Warum operator int() schlecht ist, haben CStoll und Shade IMHO sehr schön erklärt.

IYHO.
Belassen wir es bei Geschmackssache, bevor wir hier noch eine Runde im Kreis drehen.

[Shade Of Mine]

Xin schrieb:

Jester schrieb:

Was meinst Du dazu? Welche Vorteile sind mir entgangen? Wie fängst Du diese Nachteile auf?

Dir sind keine Vorteile entgangen, aber Dir ist entgangen, dass es auch keine Nachteile/Unterschiede gibt.
Es ist gleichwertig.

Es werden massig Nachteile aufgezählt - du lässt nur keine gelten.

Das sollte zu denken geben. Denn auch wenn nicht jeder genannte Punkt ein kritischer Nachteil ist, so ist allein die Summe der Potenziellen-Nachteile bedenklich.

Was das Framework betrifft: du behauptest dass jeder mit dem Framework programmieren kann wie er will und du keine Restriktionen haben willst - deshalb ja auch die freie Mischung von Einheiten wie der Programmierer lustig ist -> aber im Endeffekt hast du sehr strikte Vorschriften an den Programmierer was er alles machen darf. Denn ein Fehler und es kommt nur noch blödsinn raus -> OHNE Compiler Fehler.

Weiters ist es halt auch wahnsinnig unpraktisch, dass man nicht:

void display(Kilogramm k) { ... }

Kilogramm k = ...;
display(k / 10);

schreiben kann.

Da ja k/10 ein int ist, aber ein int nicht in Kilogramm konvertierbar ist.

Die Idee von Mr.N mit dem Kürzen der Einheiten ist übrigens die perfekte Lösung für die meisten Probleme hier.

Wenn wir intern mit Metern rechnen - dann gibt es Rundungsfehler wenn wir im Millimeter Bereich oder Pikometer oder wie tief wir wollen. Deshalb ist eine interne fixe Einheit problematisch. Mit dem Einheiten Kürzen wird das gelöst und auch das Problem was 1000 Millimeter als integer ist.

[Mr. N]

Xin schrieb:

Häuser auch.
Also sind 4 Stück Häuser == 4 Stück Butterbrote und kein Stück Typsicher.

Meinetwegen kannst du auch je einen Typen für Butterbrote und Häuser verwenden, ich glaube nur nicht, dass man das benötigt (subjektive Einschätzung). Das Framework sollte trotzdem damit umgehen können.

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

operator int() ist leicht zu optimieren und kostet keine Rechenzeit.

operator/ ist genauso gut optimierbar. Du solltest dir vielleicht mal die Optimierfähigkeiten von modernen C++-Compilern genauer anschauen.

Vielleicht solltest Du überlegen, dass operator / () ein Argument hat, was sich Beachtung wünscht und operator int() nicht.

Das schadet nicht, zumindest GCC kann sowas wegoptimieren. Das habe ich getestet. Andere Compiler können es sicher genauso, aber bei denen habe ich es nicht getestet.

Xin schrieb:

Wenn Du durch Metereinheit teilst, passt das, aber das ist ein billiges Hilfskonstrukt.
Teilst Du durch Meter(1) hast Du ein Argument, dass Du beachten musst und das lässt sich nicht gut rausoptimieren.

Doch, lässt sich rausoptimieren. Siehe oben.

Xin schrieb:

Mr. N schrieb:

Nun ja, meinetwegen könnte man auch asInt() und operator/ parallel erlauben. Warum operator int() schlecht ist, haben CStoll und Shade IMHO sehr schön erklärt.

IYHO.
Belassen wir es bei Geschmackssache, bevor wir hier noch eine Runde im Kreis drehen.

Wie auch immer.

[Gut]

So viele Geisterfahrer wieder auf Xins Autobahn.

[Shade Of Mine]

Xin schrieb:

Mr. N schrieb:

Nun ja, meinetwegen könnte man auch asInt() und operator/ parallel erlauben. Warum operator int() schlecht ist, haben CStoll und Shade IMHO sehr schön erklärt.

IYHO.
Belassen wir es bei Geschmackssache, bevor wir hier noch eine Runde im Kreis drehen.

Kommen wir da doch mal auf Typsicherheit zu sprechen von der ich ja keine Ahnung habe. Es gibt 2 Arten um int und Meter miteinander zu verbinden: über einen non-explicit CTor und über operator int.

operator int erlaubt Typenverlust, CTor erlaubt Typengewinn. Generell verwendet man deshalb operator int sehr sehr selten. Denn viele Typen wie zB std::string sind kein char*, wohl kann aber ein char* problemlos in einen std::string umgewandelt werden.

Ähnlich ist es mit Meter. Meter ist kein int - er ist mehr als ein int. Er ist ein int mit Typ-Information. Wenn wir einen operator int implementieren dann erlauben wir impliziten Typverlust. Das ist zB deswegen doof, weil es keine Compilerwarnungen gibt:

Meter m(7);
cout<<m;

Es sollte "7 Meter" ausgegeben werden, aber leider haben wir den op<< vergessen zu implementieren. Es wird 7 ausgegeben. Ohne Warnung. Das ist dann ein Problem wenn der int Wert keinen direkten Sinn macht: zB bei dem Umrechnungsproblem Millimeter <-> Meter wo wir nicht wissen ob das jetzt Millimeter oder Meter sind.

Compiler warnt nicht.

Bei einem non-explicit CTor gibt es nur ein Risiko: dass der Programmierer in einen Typenlosen Wert zuviel reininterpretiert.

m=getRandomInt();

Das ist natürlich auch ein Problem - aber der Programmierer kann das kaum aus versehen machen. Denn wenn er einen falschen integer zuweist, dann kann er das auch explizit machen:

m=Meter(getRandomInt());

[Beispiele]

Meter = { komplexe physikalische Formel }

Bei { komplexe physikalische Formel } ist irgendwas faul, es kommt int raus. Der Compiler verweigert es, aber was genau ist nun faul? Bei CStolls Templatesystem kommt eine prägnante Fehlermeldung à la "Keine Überladung für Sekunde * Haus". Alles ist sofort klar. DAS ist Typsicherheit.

Anderes Beispiel: In der Physik gibt es durchaus typlose Konstanten oder Ergebnisse, z.B. Brechzahl, oder Winkel, insbesondere trigonometrische Funktionen davon. Du weißt also ein int einem int zu, aber ist das int nun richtig entstanden? Man kann es nicht nachvollziehen.

[Xin]

Shade Of Mine schrieb:

Xin schrieb:

Belassen wir es bei Geschmackssache, bevor wir hier noch eine Runde im Kreis drehen.

Kommen wir da doch mal auf Typsicherheit zu sprechen von der ich ja keine Ahnung habe.

Das lasse ich mal unkommentiert so stehen... das hast Du gesagt.

Shade Of Mine schrieb:

Es gibt 2 Arten um int und Meter miteinander zu verbinden: über einen non-explicit CTor und über operator int.

operator int erlaubt Typenverlust, CTor erlaubt Typengewinn. Generell verwendet man deshalb operator int sehr sehr selten. Denn viele Typen wie zB std::string sind kein char*, wohl kann aber ein char* problemlos in einen std::string umgewandelt werden.

Ähnlich ist es mit Meter. Meter ist kein int - er ist mehr als ein int. Er ist ein int mit Typ-Information. Wenn wir einen operator int implementieren dann erlauben wir impliziten Typverlust.

Richtig, und zwar dann, wenn der Meter als typlose Größe benötigt wird.

Shade Of Mine schrieb:

Das ist zB deswegen doof, weil es keine Compilerwarnungen gibt:

Meter m(7);
cout<<m;

Es sollte "7 Meter" ausgegeben werden, aber leider haben wir den op<< vergessen zu implementieren. Es wird 7 ausgegeben. Ohne Warnung. Das ist dann ein Problem wenn der int Wert keinen direkten Sinn macht: zB bei dem Umrechnungsproblem Millimeter <-> Meter wo wir nicht wissen ob das jetzt Millimeter oder Meter sind.

Jow...
Und wenn Du mit einem Auto gegen einen Baum fährst, wird es auch implizit in einen Haufen Schrott umgewandelt.
Ohne Warnung. Schlussfolgerung: der Autohersteller hat nicht typsicher gearbeitet, weil er die Verbindung Baum + Auto nicht unterbindet und es so zu unerwarteten Ergebnissen kommt, wenn der Nutzer sich nicht an das hält, was er in seiner Ausbildung gelernt haben sollte.

Wenn man vergisst, dass man einen Wert anders ausgeben möchte, dann braucht man sich nicht zu wundern, wenn der Wert eben nicht anders ausgegeben wird.
Ansonsten gucke ich mir meine Software an, ob sie tut, was ich will. Das ist kein Problem von Typsicherheit, sondern von Abgleich von "Was sollte ich programmieren?" und "Was habe ich programmiert?"

Shade Of Mine schrieb:

Bei einem non-explicit CTor gibt es nur ein Risiko: dass der Programmierer in einen Typenlosen Wert zuviel reininterpretiert.

m=getRandomInt();

Das ist natürlich auch ein Problem - aber der Programmierer kann das kaum aus versehen machen.

Schon wieder eine Kritik an den expliziten int-Konstruktoren?!? Wenn man keine Ahnung hat, einfach mal Fragen stellen. ^^

Es gibt viele Möglichkeiten mal eben irgendwie an ein int zu kommen, nicht nur die versehendliche, direkte Zuweisung.
C++ erlaubt hier die implizite Konstruktion eines Meters, um das int durch den Meter-Operator zu jagen.

Folgendes wird somit zu validem Code:

Meter m = Meter( 4 );
Meter result = m + 5;

Man stelle sich hier den kleinen Roboter aus "FoolProof" vor: "Fehler... Fehler... Fehler..."

Den Typ bei Bedarf implizit zu entfernen ist ungefährlich, ihn hinzuzufügen hingegen ist gefährlich, inbesondere dann, wenn man mit den Regeln zur Operator-Wahl nicht vertraut ist.

Und damit sind wir wieder am Anfang Deines Postings:

Shade Of Mine schrieb:

Kommen wir da doch mal auf Typsicherheit zu sprechen von der ich ja keine Ahnung habe.

(wer auf's eigene Tor schießt, muss damit rechnen, dass er ein Eigentor schießt)

[sag mal]

Was macht ihr jetzt? 10 Seiten diskutieren wie man 4 Meter + 5 Meter rechnet? Wollt ihr immer so lang rumtrödeln, wenn ihr ein Programm schreib?

[Mr. N]

Xin schrieb:

Und wenn Du mit einem Auto gegen einen Baum fährst, wird es auch implizit in einen Haufen Schrott umgewandelt.

Wir müssen ja nicht die Fehler der realen Welt implementieren. In meiner schönen C++-Welt ist auto.auffahren(baum) einfach nicht legal.

[scrub]

Eben, und zur Zulassung von Crashtests mit Bäumen kann man immer noch explizit das Auto in ein Testauto umwandeln.

[camper]

scrub schrieb:

Eben, und zur Zulassung von Crashtests mit Bäumen kann man immer noch explizit das Auto in ein Testauto umwandeln.

Ich würde casten - es geht ja sowieso um einen Unfall

[also...]

...ich würd sagen xin hat mal wieder verloren, was meint ihr?

[dfggfg]

ach red doch keinen verbalen dünschiss...
es habt sich gezeigt, dass die vorteile xins methode im detail stecken,
und man sie eigentlich mit dem bloßem auge nicht erkennen kann,
die nachteile zwar manchmal erkennbar sind, aber dies nur sind, wenn man die
nachteile als solche definiert, und das nur, wenn es nachts kälter als draußen ist.

Also ist doch alles eindeutig oder?