C++ cast Operatoren

blurry333

warum ist z.B. static_cast besser als (int) cast in c ?

Weil diese einen rückgabewert haben ? so z.B. dynamic_cast ?

soll man immer static_cast, dynamic_cast und die anderen 2 halt
benutzen anstatt dem C cast Operator () ???

Hab bisher immer den C Cast benutzt und nie Probleme gehabt.

z.B. double x= (double) 3/4;

wozu double x= static_cast <double> 3/4 ;

drakon

Die C++ Casts sind besser zu erkennen (im Code) und drücken auch klarer das aus, was man damit erreichen will. (dynamic_cast hat einen anderen Zweck als ein static_cast usw.)

Ich persönlich bevorzuge die C++ Casts, wegen den genannten Gründen. Was du nehmen sollst musst du selbst entscheiden!

volkard

drakon schrieb:

Ich persönlich bevorzuge die C++ Casts

Bei "C++ Casts" weiß ich nie, was Ihr meint.

d=(double)3;//C-Cast
d=double(3);//C++-Cast
d=static_cast<double>(3);//auch C++-Cast

Ich schlage vor, "C++-Cast" nicht mehr zu verwenden. Vielleicht

d=(double)3;//C-Cast
d=double(3);//Functional-Style-Cast
d=static_cast<double>(3);//Pain-Cast

drakon

Mit C++ Casts meinte ich natürlich diejenigen, welche "neu" in C++ sind im Gegensatz zu C.

hustbaer

@drakon:
Der "function style" Cast ist ebenfalls neu in C++, allerdings genauso schlecht zu finden und genauso unsicher wie der gute alte C-Style Cast.

drakon

hustbaer schrieb:

@drakon:
Der "function style" Cast ist ebenfalls neu in C++, allerdings genauso schlecht zu finden und genauso unsicher wie der gute alte C-Style Cast.

Das war mir nicht bewusst, da ich mich nicht so lange mit C beschäftigt habe.

Aber ist das so unintuitiv dynamic_cast , static_cast und reinterpet_cast als die C++ Casts abzukürzen?

unskilled

z.B. double x= (double) 3/4;

wozu double x= static_cast <double> 3/4 ;

Dir ist bewusst, dass eins nicht seinen zweck erzielt und das andere nicht kompiliert?!

vorteile sind, dass man casts mit strg+f "_cast" suchen kann und der wohl wichtigere grund: es wird nur das gecastet, was man auch wirklich braucht.
ein C-cast ist ein dynamic_cast und static_cast und const_cast in einem - sollte logisch sein, dass da einiges unabsichtlich falsch gecastet wird.

allerdings muss ich zugeben, bei PODs auch fast nie den "Pain-cast"(c by volkard) zu verwenden - da gefällt mir der function-style cast wesentlich besser.

bb

volkard

drakon schrieb:

Aber ist das so unintuitiv dynamic_cast , static_cast und reinterpet_cast als die C++ Casts abzukürzen?

Ja, absolut. Der Functional-Style-Cast war zuerst da. Und war damals der C++-Cast im Gegensatz zum C-Cast. Die anderen Casts wurden später zu C++ hinzugefügt.

TyRoXx

unskilled schrieb:

ein C-cast ist ein dynamic_cast und static_cast und const_cast in einem

dynamic_cast ist wirklich neu, C kennt nicht einmal Vererbung.
Da sich die "C++ casts" in der Benutzung wie Template-Funktionen anfühlen, kann man sich leicht eigene Casts bauen, die optisch den spracheigenen ähneln. Ein bekanntes Beispiel dafür ist boost::dynamic_pointer_cast , der einen dynamic_cast speziell für Smart Pointer darstellt.

Man könnte auch solchen Blödsinn damit machen:

template <class T>
std::list<T> list_cast(const std::vector<T> &);

Hilfreich kann ein eigener Cast bei folgendem Beispiel sein:

template <class T>
struct vector2d
{
	T x, y;
	//...
};

template <class T, class U>
vector2d<T> vector_cast(const vector2d<U> &v)
{
	return vector2d<T>(static_cast<T>(v.x), static_cast<T>(v.y));
}

int main()
{
	vector2d<float> calculatedPoint = ...;
	DrawPixel(vector_cast<int>(calculatedPoint), ...);
}

hustbaer

@TyRoXx:

TyRoXx schrieb:

Man könnte auch solchen Blödsinn damit machen:
template <class T>
std::list<T> list_cast(const std::vector<T> &);

Wenn du die Funktionen jetzt statt xxx_cast noch make_xxx nennst, also make_list oder make_vector, oder von mir aus to_vector oder to_list, dann würde ich das nichtmal mehr blödsinnig nennen

__Stefan__

Also wenn die IDE regex-Suche hat, sollte man die C-Casts problemlos finden. Da ist die Schreibweise kein Argument.

Und das hier ist doch wohl ein Konstruktor-Aufruf und kein cast:

double(3);

Tachyon

Stefan schrieb:

Also wenn die IDE regex-Suche hat, sollte man die C-Casts problemlos finden. Da ist die Schreibweise kein Argument.

Klar, wenn man direkt nach Casts sucht, wunderbar. Wenn man aber einen Fehler (durch einen Cast) hat, bei dem man die Ursache nicht so genau kennt, ist es schwierig danach zu suchen.

Bashar

@__Stefan__:
double hat aber keinen Konstruktor.

Die Notation T(x) ist im Standard explizit als äquivalent zum Cast-Ausdruck (T)x definiert. Dass da manchmal ein Konstruktor aufgerufen wird, ist klar, weil man nur so Objekte von Klassentypen erzeugen kann. Das macht aus dem ganzen aber noch keinen "Konstruktoraufruf".

TyRoXx

Stefan schrieb:

Und das hier ist doch wohl ein Konstruktor-Aufruf und kein cast:
double(3);

Dann ist static_cast<std::string>("") auch kein Cast.

Jockelx

Hast du das denn wirklich mal gebraucht?
Für mich hört sich dieses Wiederfindbarkeits-Feature irgendwie konstruiert an.
Ich hab's zumindest niemals nutzen müssen und daran wird sich auch ziemlich sicher nichts ändern.

TyRoXx

Jockelx schrieb:

Hast du das denn wirklich mal gebraucht?
Für mich hört sich dieses Wiederfindbarkeits-Feature irgendwie konstruiert an.
Ich hab's zumindest niemals nutzen müssen und daran wird sich auch ziemlich sicher nichts ändern.

Es geht eher darum, dass man den Cast leichter erkennt. Ein static_cast geht nicht so leicht im Code unter wie irgendein Typname mit Klammern dahinter.

Tachyon

Jockelx schrieb:

Hast du das denn wirklich mal gebraucht?
Für mich hört sich dieses Wiederfindbarkeits-Feature irgendwie konstruiert an.
Ich hab's zumindest niemals nutzen müssen und daran wird sich auch ziemlich sicher nichts ändern.

Es geht nicht nur um Wiederfindbarkeit. Zum Einen sind die C++-Casts sicherer, weil es keine impliziten Reinterpretierungen gibt. Wenn man versucht, mit static_cast etwas zu reinterpretieren, gibt es einen Fehler.
Zum anderen erhöht es die Konsistenz. Um dynamic_cast kommt man nicht herum. Wenn man die C++-Syntax konsequent benutzt, ist es im Code durchgängig, und man keinen Mix von unterschiedlichen Casts.
Das es auch Bibliotheks-Template-Casts gibt, wurde ja bereits erwähnt. Auch hiermit bleibt man konsistent, wenn man C++-Casts benutzt.

Jockelx

Tachyon schrieb:

Es geht nicht nur um Wiederfindbarkeit.

Doch, offenbar schon. Ich hab nicht die C++-Casts hinterfragt, sondern dieses komische Wiederfind-Argument.

hustbaer

Stefan schrieb:

Also wenn die IDE regex-Suche hat, sollte man die C-Casts problemlos finden. Da ist die Schreibweise kein Argument.

Dann poste doch bitte mal ne Regex mit der man alle C-Style Casts finden kann. Natürlich ohne massiv viele false-positives zu bekommen. Ich wäre dir sehr dankbar dafür. Wäre ein nützliches Werkzeug beim Refactoring von altem Code.
Ich kenne auf jeden Fall keine solche Regex. Ich wüsste auch nicht wie man eine schreiben sollte.

Und das hier ist doch wohl ein Konstruktor-Aufruf und kein cast:
double(3);

Nope, das ist ein Cast. Lies es im Standard nach wenn du es nicht glaubst.

Damit kann man auch ganz böse Dinge machen:

typedef int* pint;
char const* str = "lala";
int* i = pint(str); // castet const weg + char* nach int*

Gerade weil er so harmlos aussieht, wie ein ganz unschuldiger ctor Aufruf eben, finde ich den "function style" Cast auch so schlimm.

hustbaer

Jockelx schrieb:

Hast du das denn wirklich mal gebraucht?
Für mich hört sich dieses Wiederfindbarkeits-Feature irgendwie konstruiert an.
Ich hab's zumindest niemals nutzen müssen und daran wird sich auch ziemlich sicher nichts ändern.

Ich hatte schon öfters Fälle, in denen ich gerne nach Casts gesucht hätte.
Speziell reinterpret_cast und const_cast.

Nach C-Style Casts und Function-Style Casts würde ich deswegen gerne suchen können, damit ich sie als xxx_cast umschreiben kann. Damit sichtbarer ist was passiert, und damit ich in weiterer Folge dann nach den potentiell problematischen Casts wie eben reinterpret_cast und const_cast suchen kann.

Und zur Frage warum man nach Casts suchen wollen würde: z.B. einfach um beim Bug-Hunting gewisse Dinge vorab kontrollieren und idealerweise ausschliessen zu können.