C-Style Cast vs static_cast

[Nexus]

Eisflamme schrieb:

Da muss ich dann ja casten. Oder wählt ihr statt unsigned int dann int, wenn ihr wisst, dass damit später solche Berechnungen gemacht werden, obwohl die Variable selbst nicht negativ werden kann?

Tendenziell ja, ich würde dann int nehmen. Einfach weil es mir wichtiger ist, den Code nicht mit Casts zu überfüllen oder dauernd vom Compiler genervt zu werden, als den theoretischen Grundsatz "wenns positiv ist, nimm unsigned int " zu befolgen.

Kommt halt ein wenig drauf an, wie häufig die negativen Resultate vorkommen.

[Columbo]

Oder wählt ihr statt unsigned int dann int, wenn ihr wisst, dass damit später solche Berechnungen gemacht werden, obwohl die Variable selbst nicht negativ werden kann?

Ja, das. Vorzeichenlose Typen zu nehmen, weil nur positive Werte gespeichert werden sollen, ist nicht wirklich ein Argument.

[hustbaer]

Punktemeister schrieb:

SoneScheisse schrieb:

Kann es sein dass dieser Arcoth was mit dem Antientwickler Sone zu tun hat?

100 Punkte, ein und die selbe Person.

Der wiederrum der selbe ist wie unser allerliebster Hacker.
Ob's davon noch andere Nicknames weiss ich nicht.
(Vermutlich aber nicht, is ja noch recht jung das Balg)

[DerChauffeur]

Wer in so kurzer Zeit, so viele Beiträge schreibt, der programmiert aber nicht viel. Die Antworten klingen auch immer sehr nach Chauffeur-Wissen.

[Columbo]

Wer in so kurzer Zeit, so viele Beiträge schreibt, der programmiert aber nicht viel.

Hast du im Kindergarten gelernt, so zu argumentieren? SeppJs taegliche Postzahl ist durchschnittlich mehr als eineinhalb mal so gross.

Die Antworten klingen auch immer sehr nach Chauffeur-Wissen.

Deine Antwort klingt nach einem Troll.

aber man kann mit den beiden sehr einfach auch reinterpret_cast oder const_cast machen ohne es zu wollen.

Da ist wieder dieses "Ich habe Angst, einen gefaehrlichen Cast zu machen". Ist doch ganz einfach: Bei arithmetischen Typen ist functional-style/C-cast voellig in Ordnung. Und bei arithmetischen Typen muss ein Cast auch nicht aus dem Code herausragen. (Ich kann mich nicht erinnern, wann ich allerdings das letzte mal einen arithmetischen Typ explizit casten musste...)

[Arcotz]

@Arcoth: Bitte verschone die Leser mit deinem Halbwissen. Dagegen ist Jürgen Wolf ja der Petzold für die WinAPI.

[BitteSchnellTherapie]

SeppJ ist auch wer mit Fachwissen und nicht so ein Niemand der sich künstlich auf plustert und dies immer und immer wieder tut obwohl er fast immer auf den Deckel bekommt. Das schreit ja schon nach Therapie(Wenn er nicht schon längst in einer ist).

[sepperl]

Auch unser Seppi weiss nicht alles, aber der weiss, wann er still sein sollte (im Gegensatz zum Arcoth).

[Nexus]

Arcoth schrieb:

Ist doch ganz einfach: Bei arithmetischen Typen ist functional-style/C-cast voellig in Ordnung.

Ja genau, so einfach ist es. Die Kontroverse hier im Thread bekräftigt die Einfachheit umso mehr.

[Eisflamme]

Die Trollbeiträge ignorierend

Ja genau, so einfach ist es. Die Kontroverse hier im Thread bekräftigt die Einfachheit umso mehr.

Ach, also doch! Perfekt.

Bleibt noch Shade of Mine.

Tendenziell ja, ich würde dann int nehmen. Einfach weil es mir wichtiger ist, den Code nicht mit Casts zu überfüllen oder dauernd vom Compiler genervt zu werden, als den theoretischen Grundsatz "wenns positiv ist, nimm unsigned int" zu befolgen.

Okay, super, dadurch reduzieren sich meine Casts erheblich.

Gilt selbiges bei euch auch für int und float? Wenn man irgendwo klar ne Ganzzahl hat, aber die später mit einer float-Zahl verhuddeln möchte, wählt ihr dann, falls das klar absehbar ständig passieren wird, auch float vorher?

Beispiel wäre wieder Mal das Berechnen irgendeiner Kennzahl: Nehmen wir zwei Ganzzahlen und bilden den Quotienten, z.B.

[Nexus]

Eisflamme schrieb:

Gilt selbiges bei euch auch für int und float? Wenn man irgendwo klar ne Ganzzahl hat, aber die später mit einer float-Zahl verhuddeln möchte, wählt ihr dann, falls das klar absehbar ständig passieren wird, auch float vorher?

Eher nicht, da man hier Genauigkeit verliert und Rundungsfehler in Kauf nimmt.

[Eisflamme]

Stimmt. Alles klar, dankeschön

[Nexus]

Übrigens:

Eisflamme schrieb:

Ja genau, so einfach ist es. Die Kontroverse hier im Thread bekräftigt die Einfachheit umso mehr.

Ach, also doch! Perfekt.

Bleibt noch Shade of Mine.

Mein Post war sarkastisch gemeint
Arcoth ist halt nicht auf Gegenargumente eingegangen und hat wieder mal ohne Begründung seine Vorgehensweise als die einzige richtige dargestellt.

Ich bin nach wie vor für static_cast . Argumente wurden ja inzwischen genügend genannt... Also lies am besten nochmals Shades und meine Posts (sowie die Argumente der anderen Seite) und bild dir deine Meinung.

[Eisflamme]

Ich kenne die Argumente, finde sie aber schwach, wenn man functional-style-cast strikt nur bei arithmetischen Typen einsetzt. Da kann man nicht aus Versehen const_casten oder reinterpret_casten.

Das einzige Argument, was dann noch bleibt, ist, dass Casts unschön sind und daher, wenn sie vorkommen, herausstechen sollten.

Wenn ich mit vielen Kennzahlen obiger Art rechne, habe ich dann aber häufig:

kennzahl = static_cast<float>(teiler) / nenner;

statt

kennzahl = float(teiler) / nenner;

und darin sehe ich keinen wirklichen Vorteil außer dass es mehr Tipparbeit ist.

Habe ich ein Argument übersehen, was hier greift?

[Fytch]

Eisflamme schrieb:

Habe ich ein Argument übersehen, was hier greift?

dass - wie du schon sagtest - es sofort ersichtlich ist und dass man die expliziten casts auch mit der suchfunktion finden kann (nach float suchen wird keinen erfolg zeigen, nach static_cast<float> hingegen schon). sind aber sehr spezifische bedürfnisse, denn viele brauchen diese beiden vorteile gar nicht.

ich finde, die ganze frage ob man c-casten oder static_casten soll ist sehr vom geschmack des programmierers und vom einsatzort abhängig. wenn du - wie du berichtetest - viele solcher berechnungen und konvertierungen beieinander hast, dann sehe ich den vorteil des static_casts auch nicht, da es da ja einfach zu erkennen ist (heisst nicht, dass ich es nicht schreiben würde, konsistenz und so).

[Eisflamme]

Wenn ich so überlege, finde ich die Ersichtlichkeit von float(...) aber genau so gut. Das sticht für mich heraus, schließlich benutzt man in einem Ausdruck nicht einfach so native Typnamen. Außer, es ist als Templateargument vorhanden, aber das lässt sich wiederum gut durch <> unterscheiden.

Die Suche klappt auch für float(, mir fällt gerade jedenfalls kein Ausdruck ein, bei dem float( sonst vorkommen könnte. Die einzige Situation ist, wenn man generell nach Casts suchen möchte. Habe ich noch nie getan.

[Fytch]

Eisflamme schrieb:

Die Suche klappt auch für float(, mir fällt gerade jedenfalls kein Ausdruck ein, bei dem float( sonst vorkommen könnte. Die einzige Situation ist, wenn man generell nach Casts suchen möchte. Habe ich noch nie getan.

function- / method-pointers.

[Eisflamme]

Ne, schreib ich:

typedef float (*returns_float)(float, float, float);

[volkard]

asdfdasf schrieb:

um explizite konstruktoren von klassen aufzurufen verwende ich aber diese syntax:

MyInst = MyClass(42);

in so einem fall finde ich, dass es den konstrukoraufruf eher verdeutlicht als es ein static_cast tun würde.

Jo. Und für mich fühlt sich float fast wie eine Klasse an, ich mag float(...).