C-Style Cast vs static_cast

Eisflamme schrieb:

Aufgeblähter Code und mehr Tipparbeit sind die Nachteile der langen Schreibweise und für native Datentypen gibt es keinen Nachteil am (int)7.5 -Cast. Stimmt das?

Nicht ganz. static_cast/reinterpret_cast etc. funktionieren mit den eingebauten Typen manchmal nicht richtig. Da will man immer den C-Cast um auf der sicheren Seite zu sein. Beispiele siehst du im SO-Link.

Eisflamme

So toll ist der Link nicht, um alle Beiträge nur darauf basierend zu schreiben.

Und etwas spezifischere Zitate wären auch hilfreich. Mein Lesen führte hierzu:

your readers will scratch their heads and wonder if there's something they don't know about static_cast that makes it different from the C-style cast when applied to a number. (In fact, they are identical, but I had to read the relevant C++ spec section a couple times to be sure they were identical, and I still have the "something weird must be going on here" reaction.)

also einem Widerspruch zu Deiner Aussage, dass static_cast sich anders als C-Cast verhält.

Eisflamme

Hierzu noch etwas?

functional style cast vs C-Style wäre jetzt noch zu überlegen. Gibt es da Unterschiede? Soweit ich im Kopf habe, können die ja dasselbe. functional style hat für mich den optischen Vorteil, dass man deutlicher sieht, worauf sich der Cast bezieht.

Columbo

Wie ich bereits gesagt habe, ich bevorzuge functional-style-cast.

Stackoverflow ist da uebrigens falsch.

The conversions performed by
— a const_cast (5.2.11),
— a static_cast (5.2.9),
— a static_cast followed by a const_cast,
— a reinterpret_cast (5.2.10), or
— a reinterpret_cast followed by a const_cast,
can be performed using the cast notation of explicit type conversion. The same semantic restrictions and behaviors apply, with the exception that in performing a static_cast in the following situations the conversion is valid even if the base class is inaccessible:
— a pointer to an object of derived class type or an lvalue or rvalue of derived class type may be explicitly converted to a pointer or reference to an unambiguous base class type, respectively;
— a pointer to member of derived class type may be explicitly converted to a pointer to member of an unambiguous non-virtual base class type;
— a pointer to an object of an unambiguous non-virtual base class type, a glvalue of an unambiguous non-virtual base class type, or a pointer to member of an unambiguous non-virtual base class type may be explicitly converted to a pointer, a reference, or a pointer to member of a derived class type,
respectively.

functional-style-cast hingegen...

A simple-type-specifier (7.1.6.2) or typename-specifier (14.6) followed by a parenthesized expression-list constructs a value of the specified type given the expression list.

If the expression list is a single expression, the type conversion expression is equivalent (in definedness, and if defined in meaning) to the corresponding cast expression (5.4).

[...]If the expression list specifies more than a single value, the type shall be a class with a suitably declared constructor (8.5, 12.1), and the
expression T(x1, x2, ...) is equivalent in effect to the declaration T t(x1, x2, ...); for some invented temporary variable t, with the result being the value of t as a prvalue.

Eisflamme

Bitte immer mit Begründung, sonst hat das für mich keinen Wert: Wieso bevorzugst Du es?

Columbo

Einheitlichkeit. Temporaries und Casts (und dazu gehoeren eigentlich auch Variablen-Definitionen) sollten gleich aussehen: Typ links, initializer rechts in Klammern.

Shade Of Mine

Ich verwende immer static_cast weil es der sichere ist. Es gibt viele Situationen wo functional- und c-style cast sich gleich verhalten wie static_cast aber man kann mit den beiden sehr einfach auch reinterpret_cast oder const_cast machen ohne es zu wollen.

Bei static_cast checkt der compiler für mich ob ich eh das tue was ich tun wollte.

Nexus

Ebenfalls static_cast .

Um einiges sicherer (gerade bei generischem Code)
Casts im Code deutlich erkennbar und allenfalls suchbar
Wenn der Code zu unübersichtlich wird wegen zu vieler Casts, überdenke ich eher, warum ich so viel caste

Eisflamme

Hi,

eine Nachfrage, die hier zu gut passt.

Ich habe oft ein unsigned int, was ich aber dann mit einem int summieren möchte. Die Logik ist einfach: Variable a kann nur in einem positiven Wertebereich liegen, die andere Variable möglicherweise auch. Das Ergebnis kann jedoch durchaus negativ sein.

Beispielsweise bei einer Differenz von positiven ganzzahligen Zahlen.

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?

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

SoneScheisse schrieb:

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

100 Punkte, ein und die selbe Person.

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)

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

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

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

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.