class A { void funkA(); };
class B { void funkB(); };
A * a = new A;
B * b = reinterpret_cast<B*>(a);

b->funkA();   // Geht das

ein reinterpret_cast führt ja einen total unsinnigen Cast durch. Die beiden Klassen haben ja nichts miteinander zu tun.
Kann man nun sowas hier durchführen b->funkA();

total unsinnigen

Was folgt wohl aus Unsinn?

b->funkA();   // Geht das
b->funkB();   // Geht das

Was davon geht nun ?

Merkste selbst, dass das nicht geht, wa?

Reinterprete macht wohl auch nur bei derived und base Sinn ?
Oder schreib mir mal nen Code bei dem reinterpret_cast funktioniert .

Reinterprete macht wohl auch nur bei derived und base Sinn ?

Nein, da erst recht nicht. Die Typen sind dann doch schon kompatibel.

Oder schreib mir mal nen Code bei dem reinterpret_cast funktioniert .

reinterpret_cast brauchst du, wenn vorher etwas mächtig schief ging und durch falsche/schlechte Interfaces Typinformation verloren gegangen ist. Das heißt, um dir ein Beispiel zu zeigen, wo man reinterpret_cast wirklich braucht, müssen wir dir ein Beispiel zeigen für etwas, wie man es nicht richtig macht. Das heißt, den reinterpret_cast brauchst du, wenn du es mit fremdem, schlechten Code zu tun hast. Ein Beispiel wäre ein C-Interface für Callbacks, welches aus irgendwelchen Gründen keine void*, sondern irgendwelchen eigenen Datentypen einsetzt.

Ein anderes Beispiel wäre, wenn du wirklich Tricksen möchtest und wirklich einen Typen mit einem fremden Interface ansprechen möchtest. Ein berühmtes Beispiel ist die Quake3 inverse Wurzel, bei der ein float durch die Integereinheit des Prozessors gejagt wird. Das Original ist in C geschrieben, aber so könnte es in C++ aussehen:

float Q_rsqrt( float number )
{
    long i;
    float x2, y;
    const float threehalfs = 1.5F;

    x2 = number * 0.5F;
    y  = number;
    i  = * reinterpret_cast<long *>(&y);      
    i  = 0x5f3759df - ( i >> 1 );        
    y  = * reinterpret_cast<float *>(&i);
    y  = y * ( threehalfs - ( x2 * y * y ) );  

    return y;
}

Weiters kann man reinterpret_cast verwenden um z.B. einen T* in einen char* oder unsigned char* zu verwandeln. Um dann z.B. byteweise zu kopieren. Das ist auch OK -- vorausgesetzt T ist dafür geeignet (memcpy-movable bzw. memcpy-copyable). Ebenfalls OK und vom Standard abgedeckt.

Code wie in dem Beispiel von SeppJ sieht man auch oft. Der verletzt aber blöderweise die "strict aliasing" Regel, ist also nicht standardkonform, und kann zu UB führen. Also dazu dass das Programm nicht das macht was man erreichen wollte. Je nach Compiler geht das oft bis immer gut (MSVC) oder auch eher nicht (GCC, Clang).

Die standardkonforme Variante davon wäre den float mittels eines char* oder unsigned char* in eine long Variable zu kopieren -- oder auch einfach per memcpy (und dann ebenso wieder zurück). Dummerweise kann man sich nicht darauf verlassen dass der jeweils verwendete Compiler sowas immer perfekt wegoptimiert, und daher wird oft die "verbotene" Variante mit reinterpret_cast verwendet.

using func_t = int WINAPI (*)(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType);
std::size_t start_addr = reinterpret_cast<std::size_t>(GetModuleHandle("Kernel.dll"));
func_t MessageBox = reinterpret_cast<func_t>(start_addr + offset)

Derived* ptr_derived = dynamic_cast<Derived*>(ptr_base);

gegenüber

Derived*  ptr_derived = (Derived) ptr_base;

welchen Vorteil bringt mir eigentlich

Derived* ptr_derived = dynamic_cast<Derived*>(ptr_base);

gegenüber

Derived*  ptr_derived = (Derived) ptr_base;

Im ersten Fall macht es genau das was dort steht oder meldet einen Fehler. Im zweiten Fall würde irgendetwas ausgeführt (vermutlich würde es sogar ohne den vergessenen * übersetzen). Welcher cast ausgeführt wird, lässt sich nur anhand der Zeilen nicht vorhersagen.

(2)Base* ptr_base = dynamic_cast<Base*>(ptr_derived);

Macht das 2.nicht mehr Sinn ? In einer derived klasse sind doch meistens viel mehr Methoden verfügbar. ptr_derived kann aber im 1.Fall nur die base methoden aufrufen. Das Intellisense der IDE würde wahrscheinlich aber alle Methoden (Base + Derived) anzeigen oder.

Base_Class * ptr_b = new Base_Class;
Derived_Class * ptr_c = dynamic_cast< Derived_Class *>(ptr_b);

Das hier geht schief , da ptr_c auf ein unvollständiges Objekt zeigen würde.Ein derived pointer kann nie auf eine Base adresse zeigen.

Das hier geht schief , da ptr_c auf ein unvollständiges Objekt zeigen würde.Ein derived pointer kann nie auf eine Base adresse zeigen.

nichts "geht schief", da dynamic_cast hier einen nullptr zurückgibt. ein dynamic_cast überprüft zur laufzeit, welchen typ ein objekt, auf das ein zeiger oder eine referenz verweist, tatsächlich hat, sofern das vorgesehen ist (das ist es nur, wenn das objekt eine instanz einer polymorphen klasse ist, und das ist eine klasse dann, wenn sie zumindest eine virtuelle funktion deklariert), und kann einen "downcast" dann sicher ausführen. kein anderer cast kann das. das umgekehrte beispiel löst man in der regel implizit oder mit einem static_cast .

Base* a = new Derived;

Base* b = static_cast<Base*>(new Derived);
//ist äquivalent und besser als
Base* b = dynamic_cast<Base*>(new Derived)

solltest du als programmierer aber schon ganz sicher wissen, dass ein zeiger auf Base eigentlich auf ein Derived zeigt, dann kannst du auch in diesem fall static_cast verwenden:

namespace {

   void dumb (Base* b) {
     Derived* d = static_cast<Derived*>(b);
   }

}

void foo (Derived*d) { dumb(d); }

dumm, weil unnötig, nicht erweiterbar, etc.
[/cpp]

Aber welche Vorteile habe ich mit static_cast,reinterpret_cast oder const_cast gegenüber einem regulären C cast.

Der reguläre C cast vereint ja alle 3 sachen. Man kann halt das Casten noch verfeinern. Man sagt dem Compiler noch genauer was man vorhat oder ?

Man sagt dem Compiler noch genauer was man vorhat oder ?

Genau. Und das hilft, um Fehler früher aufzudecken.

ps: Das was Braunstein geschrieben hat ist mir persönlich auch wichtig. Also Syntax-Highlighting und Suchbarkeit.

@Ibinda100
Bei vielen Sachen ist es ein Vorteil wenn man so wenig wie möglich explizit hinschreiben muss, und der Compiler macht es einfach so dass es passt/geht. Wie z.B. bei auto .

ich bin mir sicher, dass du das auch so siehst: die logik dahinter, die casts so kompliziert zu machen ist die gleiche, die dazu führt, so etwas wie auto zu verwenden: so lange es (typ-)sicher ist, so wenig denkarbeit wie möglich zu verlangen - und dann kann der compiler es einfach so machen, dass es passt/geht. wenn etwas, was der programmierer will, aber unsicher, gefährlich, unüberlegt oder dumm ist, dann (nicht verbieten, wie in anderen sprachen) zumindest hässlich und aufwändig machen (" reinterpret_cast ")

das prinzip ist: je mehr tippen man muss, desto länger kann man sich die frage stellen "will ich das wirklich? gibt es nicht eine bessere alternative?"

Mir geht z.B. sogar noch ein Cast ab: implicit_cast .
Ala

implicit_cast<MyInterface*>(p)->MyInterfaceFunction();

// statt

MyInterface* pmi = p;
pmi->MyInterfaceFunction();

Also einen Cast der nur Konvertierungen erlaubt die als implizite Konvertierungen erlaubt wären. static_cast würde hier zu viel erlauben. implicit_cast wäre hier mMn. also nicht besser weil es länger zu tippen ist als static_cast , sondern weil es mehr unerwünschte Casts verbietet.