Fortschrittsanzeige

lol

Knuddlbaer

Hm,

ich hab mir den Source mal angeschaut, es gibt wirklich ne Handvoll Klassen die keine Member haben.

Ich darf also bei jedem Zugriff dieser Art prüfen ob es legal ist, auch bei jeder neuen Version der MFC (Microsoft is für alles gut

Ich fühle mich dabei dann unsicher vorallem weil ich bei jedem Control was mir über den Weg läuft prüfen darf ob das geht - und das bei jeder neuen Version.

@Shagy so pauschal wie Du es sagst würde ich sagen das die Kosten des einmaligen Casts bei der Sortierung der 1.000.000 Elemente nicht im verhältnis steht.

So eine Frage hab ich noch an Rene,

wann taucht das CWnd denn in der HandleMap nun auf ?!

thx @ll für die geduld - es hat einiges an Wissen mit sich gebracht

Shaggy

Also gehe ich recht in der Annahme (hoffentlich diesmal ), dass reinterpret_cast und der ()-cast genau das gleiche machen?

Und static_cast castet nur zwischen Zeigertypen die in einer Klassenhierarchie untereinanderstehen, aber ohne Runtime-Checking, während dynamic_cast das gleiche macht, nur mit Runtime-Checking?

Shaggy

@Knuddlbaer:

Wenn ich eine Sortierfunktion vom Typ

int CMyList::Sort(CBase* p1, CBase* p2)
{
}

habe und ich bei jedem Aufruf zweimal dynamic_cast machen muss, dann wird es sicherlich schon einen Unterschied geben. Zumal bei 1.000.000 Elementen diese Funktion wohl etwas häufiger aufgerufen werden wird. Allerdings kann es natürlich sein, dass das checken recht schnell geht. Keine Ahnung, war nur 'ne Idee.

Bei Standard-WinDoof-Controls gibt es - wie gesagt - grundsätzlich keine eigenen Member-Variablen, bei anderen normalerweise schon. Du musst ja nur in die Header-Datei schauen, ob es Member-Variablen gibt oder nicht. Und das geht schnell.

Wenn das Steuerelement von den MFC erstellt wurde, dann befindet sich auch ein Eintrag in der Handle-Map mit einem Zeiger auf das wirkliche Objekt. Dann ist ein Cast doch völlig legal. (static_cast<> )

RenéG

@Knuddelbaer

wann taucht das CWnd denn in der HandleMap nun auf ?!
Wenn das Fenster erstellt( Create) oder subclassed (SubclassWindow) wird!
@Shaggy
[quote]
während dynamic_cast das gleiche macht

Nicht ganz, bei Standardtypen int/char ... funzt dynamic_cast net.

wann taucht das CWnd denn in der HandleMap nun auf ?!

Nach dem es erstellt wurde.

RenéG

@cole
3x den gleichen Beitrag brauchen wir nicht

Doch

Knuddlbaer

wann taucht das CWnd denn in der HandleMap nun auf ?!
Wenn das Fenster erstellt( Create) oder subclassed (SubclassWindow) wird!

Ich glaub hier steh ich einfach nur auf'm schlauch und komm allein nich runter.

Über SubClass weiß ich nix. *gleich mal zugeb - ich kenn mich mit MFC kaum aus, da bin ich noch noob*

Aber create - wird das nicht generell aufgerufen wenn ein Control erstellt wird ?

@Shagy

Wenn ich eine Sortierfunktion vom Typ

int CMyList::Sort(CBase* p1, CBase* p2)
{
}

Der Sortieralgo arbeitet i.d.r. mit operatoren. Wenn die Klassen vererbt wurden und die RTTI an ist wird auch der passende operator aufgerufen. Wenn die RTTI nicht an ist kann es wieder zu undefinierten bzw. zu falschen sortierergebnissen kommen ?!

Ich kenne die sortierung der List nicht in der implementierung. Sie könnte z.B. durch den operator < realisiert sein. Und der könnte für CDerived das in der Liste gehalten wird anderst funktionieren als in CBase - eventuell virtual.

Bei eingeschalteter RTTI kein Problem , ohne RTTI schwer zu durchblicken ?!

[ Dieser Beitrag wurde am 31.03.2003 um 10:41 Uhr von Knuddlbaer editiert. ]

Immer wenn CWnd::Attach aufgerufen wird

HumeSikkins

Wo ist denn dann bitteschön der Unterschied zwischen den beiden Zeilen? Wo ist denn dann der Vorteil von static_cast gegenüber dem ()-cast? Mal abgesehen davon, das ersteres C++ ist?

Wenn es dich interessiert, lies doch bitte einfach mal den Artikel. Ich poste doch nicht einen Link aus purer langeweile. Und wenn ich schon einen Link poste, muss ich den Inhalt doch nicht auch noch vorkauen.

By the way, ich bin immer bereit Neues zu lernen und mich mit Neuen Dingen auseinanderzusetzen

Tatsächlich. Also den Eindruck machst du *in dieser* Situation nicht auf mich.
Ich sehe hier eigentlich nur verbohrtheit, was die neuen Casts angehet.

Hab mal einen Suchlauf über das VC98-Verzeichnis machen lassen. Kein einziges Mal dynamic_cast gefunden...

Du weißt aber sicher, dass die meisten Dateien im VC98-Verzeichnis älter als der C++-Standard sind. Und das es damals noch *gar keinen* dynamic_cast gab. Sicher, das weißt du.
Du weißt bestimmt auch, dass RTTI damals noch gar nicht standardisiert war und das deshlab z.B. die MFC ihre eigene Form des RTTIs mitbringt.

IEntweder der Pointer ist auch ein Zeiger auf die Klasse, in die ich Casten will, oder er ist NULL.

Das garantiert dir nur der dynamic_cast.

Und mich durch Klassenhierarchien durchwälzen tue ich auch nicht, dazu gibt's virtuelle Funktionen und ähnliches.

Ein großartiges Argument, vorallem wenn es in einem Atemzug mit den C-Casts genannt wird.

Wenn ich also mit dynamic_cast hier nicht weiterkomme, was macht dann der Ich-arbeite-strikt-nach-C++-Programmierer? Aufgeben? Oder muss er sich mit veralteten Funktionalitäten abfinden?

Sich genau informieren, warum es nicht geht wie es gehen *sollte*. Wenn es überhaupt nicht anders geht, den Vorschlaghammer rausholen. Einen Kommentar dranschreiben und sich bei MS beschweren, dass ihre Lib kaputt ist.

Wenn es geht, aber vielleicht Geschwindigkeitseinbußen mitsichbringt, *profilen* um zu schauen, ob diese relevant sind. Wenn es nicht anders geht, Vorschlaghammer rausholen und einen Kommentar dranschreiben.

Aber wie man es auch dreht und wendet. Ich würde sagen, man sollte erst *wissen* was man tut, bevor man den Vorschlaghammer rausholt und undefiniertes Verhalten heraufbeschwört. Einfach mal aus Verdacht alles kurz und kleinzuschlagen ist meiner Meinung nach keine gute Strategie.

B* b;
#ifdef _DEBUG
b = dynamic_cast<B*>( a);
#else
b = reinterpret_cast<B*>( a);
#endif

Und schon wieder falsch. Bei all dem Sarkasmus und der Ignoranz die ihr hier an den Tag legt, solltet ihr es wenigstens *richtig* machen.
Ein reinterpret_cast ist *nicht* für downcasts geeignet. Wenn du sicher bist, dass hinter dem a-Zeiger ein B-Objekt steckt heißt die Antwort
*static_cast*. Die Einschränkungen habe ich schon zwölf-mal geschrieben. Und sie gilt für alle casts außer dem dynamic_cast.
Der Code sollte also wenn so aussehen:

B* b;
#ifdef _DEBUG
  b = dynamic_cast<B*>( a);
#else
  b = static_cast<B*>( a);
#endif

Ähnlichen Code wirst du in vielen professionellen Programmen finden. Mal abgesehen davon, dass natürlich vernünftige Coding-Styles Präprozessor-ifs *innerhalb* von Methoden verbieten.

#ifdef _DEBUG
#define MYCAST( class, ptr) (dynamic_cast<class*>( ptr));
#else
#define MYCAST( class, ptr) (reinterpret_cast<class*>( ptr));
#endif

Oder einfach bei der bekannten Syntax bleiben:

// VC6-Workaround aus Gründen der Übersicht weggelassen.
#ifdef _DEBUG
template <class Dest, class Source>
inline Dest MyCast(Source p)
{
    return dynamic_cast<Dest>(p);
}
#else
template <class Dest, class Source>
inline Dest MyCast(Source p)
{
    return static_cast<Dest>(p);
}
#endif

Richtig, daran hab ich auch schon gedacht. Was würde ein Sortieralgorithmus für 1.000.000 Elemente mit Verwendung von dynamic_cast wohl länger brauchen?

Warum würde ich wohl ein dynamic_cast in einem Sortieralgorithmus anwenden? Da würde ich mir mal eher um mein kaputtes Design Gedanken machen.

Also gehe ich recht in der Annahme (hoffentlich diesmal ), dass reinterpret_cast und der ()-cast genau das gleiche machen?
Und static_cast castet nur zwischen Zeigertypen die in einer Klassenhierarchie untereinanderstehen, aber ohne Runtime-Checking, während dynamic_cast das gleiche macht, nur mit Runtime-Checking?

Nö. Der C-cast ist eine Mischung aus static_cast, reinterpret_cast, const_cast und in C++ eigentlich verbotenen Sachen.

Der static_cast macht kurz gesagt alle Konvertierungen zwischen S und T möglich, für die es eine umgekehrt implizite Konvertierung von T nach S gibt.
Dazu gehört unter anderem der downcast.

[ Dieser Beitrag wurde am 31.03.2003 um 11:20 Uhr von HumeSikkins editiert. ]

Shaggy

Das klingt ja alles sehr gut, hab mich gerade kurz mal informatiert und mein "Verdacht" hat sich bestätigt. Ein Informatik-Studi!

Da ich trotz meiner "Vorschlaghammer"-Programmierung bisher noch nie (und ich programmiere schon sehr lange) undefiniertes Verhalten hatte, wüsste ich nicht, was an meiner "Vorschlaghammer"-Programmierung grundlegend falsch ist. Oder warum was anderes verwenden sollte, wenn es auch weiterhin funktioniert.

Und zu meinem Satz

Entweder der Pointer ist auch ein Zeiger auf die Klasse, in die ich Casten will, oder er ist NULL.

der mit

Das garantiert dir nur der dynamic_cast.

beantwortet wurde, muss ich mich vielleicht deutlicher Ausdrücken:

Wenn ich eine Funktion habe, wie z.B.

void CMyWnd::OnNotify(WPARAM wParam, LPARAM lParam, LRESULT* pResult)
{
}

und ich weiß, dass lParam ein NHMDR* ist, dann kann ich mir hundertprozentig sicher sein, dass

NMHDR* pInf = (NMHDR*)lParam;

nicht zu undefiniertem Verhalten führt! Und wenn ein lParam NULL ist, dann ist auch pInf gleich NULL. Dann füge ich noch ein ASSERT(pInf != NULL) hinzu, und schon weiß ich, dass alles Ok ist. Hab noch nie das Problem mit falschen Zeigern gehabt. Entweder sie waren Ok oder NULL. Und wenn die nicht sein durften, dann hat mir das das ASSERT gesagt und der Fehler wurde bereinigt, nach mehrfachem Testen wurde die Release kompiliert. Irgendwann trat dann doch mal ein Fehler auf, dann hab ich die Debug-Version genommen, den Fehler nachvollzogen und das Problem beseitigt. Und alles ohne dynamic_cast, static_cast, reinterpret_cast und was es sonst noch so alles gibt.

HumeSikkins

Das klingt ja alles sehr gut, hab mich gerade kurz mal informatiert und mein "Verdacht" hat sich bestätigt. Ein Informatik-Studi!

Ja und? Was willst du damit sagen? Ich habe weder C++ entwickelt noch den C++ Standard geschrieben.
Ich kann dir aber in diesem Fall sagen, wie es ist und was im Standard steht. Wenn du ein Problem damit hast, dir etwas von einem "Informatik-Studi" sagen zu lassen, dann sag das. In diesem Fall werde ich selbstverständlich nicht mehr auf deine Postings eingehen.

Da ich trotz meiner "Vorschlaghammer"-Programmierung bisher noch nie (und ich programmiere schon sehr lange) undefiniertes Verhalten hatte

Wie willst du das beurteilen, wenn du an den Regeln die der C++ Standard aufstellt nicht interessiert bist? Schau dir doch den Verlauf des Threads einfach mal an. Ich behaupte mal, dass es keinen C++ Programmierer gibt, der nicht schonmal über undefiniertes Verhalten gestolpert ist. Ob er dies bemerkt hat steht auf einem ganz anderen Blatt.

Wenn ich eine Funktion habe, wie z.B.

void CMyWnd::OnNotify(WPARAM wParam, LPARAM lParam, LRESULT* pResult)
{
}
und ich weiß, dass lParam ein NHMDR* ist, dann kann ich mir hundertprozentig sicher sein, dass

NMHDR* pInf = (NMHDR*)lParam;
nicht zu undefiniertem Verhalten führt!

Richtig. Ich rede ja auch von Situationen wo du *nicht* hunderprozentig weißt, von welchem Typ das Objekt ist, auf das ein Basisklassenzeiger verweist. Es geht hier um Laufzeitpolymorphie und nicht um irgendwelche Krücken namens LPARAM. Hier könntest du überhaupt keinen dynamic_cast einsetzen, selbst wenn du es wolltest.

In Situationen wo du *vorher genau* weißt und *wissen musst*, von welchem Typ ein Objekt ist, du aber nur eine Basisklassenreferenz hast, stellt sich die Frage, warum du dieses Wissen überhaupt aufgibst. Wenn du auf den Cast angewiesen bist, verhält sich der Code nicht polymorph. In diesem Fall stellt sich die Frage, warum er dann so aufgebaut ist. Da gibt es zwei Möglichkeiten: Entweder man verwendet gleich den passenden Typ oder man packt die Funktionalität in virtuelle Methoden und kann damit auf den downcast verzichten.

Shaggy

Ich hab überhaupt kein Problem damit, dass Du ein Inf-Studi bist. Und dass Du den C++-Standard weder entwickelt noch geschrieben hast, ist mir auch klar. Sollte weder eine Anspielung sein noch eine Kritik. Da Du Dich aber so strikt nach dem C++-Standard richtest (was sicherlich auch lobenswert ist), hast Du Dich nunmal als Inf-Studi "verdächtig" gemacht. Mehr nicht.

Wie ich das beurteilen will? Ganz einfach: Undefiniertes Verhalten ist, wenn ein Programm nicht das macht, was es machen soll. Und - wie schon gesagt - meine Projekte laufen alle fehlerfrei und kleine MickeyMouse-Programme sind's auch nicht.
Und ich behaupte einfach mal, dass sich an meinen Programmen durch einsetzen der hier heiß diskutierten Operatoren nichts verbessern wird.

Mit den "Krücken" wie LPARAM muss man bei der Windows-Programmierung nun mal leben. Oder schickst Du dann MS auch eine eMail, wenn Du einen LPARAM in einen NMHDR* konvertieren musst?

In meinen Programmen vermeide ich grundsätzlich das casten von einer Basisklasse zu höheren Klassen, wenn ich mir NICHT sicher sein kann, was das für eine Klasse ist, die mir da über den Weg läuft (bei dem ursprünglichen Problem mit dem CProgressCtrl kann ich mir sicher sein). Dafür verwende ich virtuelle Funktionen.

Und wenn ich virtuelle Funktionen überschreibe und ihr wird eine Zeiger auf ein Objekt einer Basisklasse übergeben, dann schreibe ich auch nur Code, wo ich Funktionen der Basisklasse verwende.

dynamic_cast braucht man auch eigentlich fast nirgendwo, wenn man normale programme schreibt

Shaggy

Vorsicht @grins, solche Aussagen können Seitenlange Abhandlungen zur Folge haben...

Bashar

Original erstellt von Shaggy:
Wie ich das beurteilen will? Ganz einfach: Undefiniertes Verhalten ist, wenn ein Programm nicht das macht, was es machen soll.

sorry wenn ich mal dein Weltbild durcheinanderbringe

Undefiniertes Verhalten entsteht an den Stellen, an denen der Standard keine Aussage über das Verhalten macht, aber nicht von den Implementierern fordert, dass sie a) entweder das Verhalten dokumentieren (implementation-defined) oder b) aus einer Menge von möglichen sinnvollen Alternativen nach eigenem Gutdünken eine auswählen, ohne sie zu dokumentieren (unspecified). Das heißt nicht, dass undefiniertes Verhalten sich durch Abstürze oder falsche Ergebnisse oder sonstige äußerlich beobachtbare Effekte äußern muß, sondern lediglich, dass das Verhalten des Programms nicht mehr dem entspricht, das der Standard festschreibt.

Shaggy

Nö, mein Weltbild wankt nicht! Gut, das ist wahrscheinlich die Definition des "undefinierten Verhaltens" wie sie der C++-Standard macht. Alles eine Definitionssache. Dass ich mir undefiniertes Verhalten einfangen kann, wenn ich just-for-fun meine Klassen hin und her caste, und dann auf Speicher zugegriffen wird, der nicht initialisiert, etc. ist, ist mir auch bekannt. Ich betrachte dynamic_cast und Co. mal als zusätzliche Helferlein. Die Programmierer vor dieser Zeit sind auch gut ohne zurecht gekommen.

Bashar

Es läuft immer darauf hinaus, dass du keine Garantien hast, wenn du Spezifikationen verletzt. Egal ob es jetzt der C++-Standard ist oder sonstwas.