Fortschrittsanzeige

[RenéG]

@Hume...

Womit wir ganz vom eigentlichen Thema abgewichen sind.
Mir ging es eigentlich von Anfang an darum, warum der Cast von GetDlgItem mit der MFC und Visual C++ funktioniert. Denn schliesslich sind wir ja hier nicht im Standard-C++-Forum.
Leider hab ich mich auch selber auf diese Diskussion eingelassen

[PI]

Jaja, jetzt ausweichen...wenn man eine Diskussion anfängt, führt man sie auch zu Ende.

[HumeSikkins]

Womit wir ganz vom eigentlichen Thema abgewichen sind.

Da dies meine Schuld ist, muss ich mich dafür entschuldigen.
Ich habe von dem eigentlichen Thema überhaupt keine Ahnung (muss gestehen, dass ich den Thread nicht mal wirklich gelesen habe) sondern bin ja nur über den Email-Verkehr mit Knuddlbaer darauf gekommen.

Insofern: Sorry für jedwedige Irritation die durch meine Beiträge ausgelöst wurde

Jaja, jetzt ausweichen...wenn man eine Diskussion anfängt, führt man sie auch zu Ende

Die Diskussion ist am Ende.
Die Standard-Sicht wurde von mir vertreten und spielt hier im *VC-Forum* nur eine untergeordnete Rolle. Die VC-Sicht wurde von René vertreten, sie ist für das *VC-Forum* entscheidend.

Aus Standard-Sicht kann nach undefiniert nichts mehr folgen. Und aus VC-Sicht funktioniert alles.

Über was willst du also noch diskutieren?

[Knuddlbaer]

Ok soweit thx, ich habe das nun verstanden, das wenn die Routinen so implementiert sind das sie auf keine Member oder auf kein this zugreifen einfach gecastet werden können (und zwar nur auf MFC + VC)

Daraus resultiert sich aber nun die Frage:

Ist es denn garantiert das die MFCControls das eben nicht tun ? bzw. wie bekomme
ich das raus ?

Und die Frage, warum die Laufzeitinformation verloren geht wenn es denn das CWnd aus der HandleMap ist ist noch offen. Das hab ich noch nicht verstanden.

[Shaggy]

Aus AFXCMN.h:

/////////////////////////////////////////////////////////////////////////////
// CProgressCtrl

class CProgressCtrl : public CWnd
{
    DECLARE_DYNAMIC(CProgressCtrl)

// Constructors
public:
    CProgressCtrl();
    BOOL Create(DWORD dwStyle, const RECT& rect, CWnd* pParentWnd, UINT nID);

// Attributes
    void SetRange(short nLower, short nUpper);
    void SetRange32(int nLower, int nUpper);
    void GetRange(int& nLower, int& nUpper);
    int GetPos();
    int SetPos(int nPos);
    int OffsetPos(int nPos);
    int SetStep(int nStep);

// Operations
    int StepIt();

// Implementation
public:
    virtual ~CProgressCtrl();
};

-> keine eigenen Membervariablen, mit Ausnahme von DECLARE_DYNAMIC, aber die sind eh static und damit nicht von belang

Aus WINCTRL2.CPP:

/////////////////////////////////////////////////////////////////////////////
// CProgressCtrl

BOOL CProgressCtrl::Create(DWORD dwStyle, const RECT& rect, CWnd* pParentWnd,
    UINT nID)
{
    // initialize common controls
    VERIFY(AfxDeferRegisterClass(AFX_WNDCOMMCTL_PROGRESS_REG));

    CWnd* pWnd = this;
    return pWnd->Create(PROGRESS_CLASS, NULL, dwStyle, rect, pParentWnd, nID);
}

CProgressCtrl::~CProgressCtrl()
{
    DestroyWindow();
}

Aus AFXCMN.INL:

_AFXCMN_INLINE CProgressCtrl::CProgressCtrl()
    { }
_AFXCMN_INLINE void CProgressCtrl::SetRange(short nLower, short nUpper)
    { ASSERT(::IsWindow(m_hWnd)); ::SendMessage(m_hWnd, PBM_SETRANGE, 0, MAKELPARAM(nLower, nUpper)); }
_AFXCMN_INLINE void CProgressCtrl::SetRange32(int nLower, int nUpper)
    { ASSERT(::IsWindow(m_hWnd)); ::SendMessage(m_hWnd, PBM_SETRANGE32, (WPARAM) nLower, (LPARAM) nUpper); }
_AFXCMN_INLINE int CProgressCtrl::GetPos()
    { ASSERT(::IsWindow(m_hWnd)); return (int) ::SendMessage(m_hWnd, PBM_GETPOS, 0, 0); }
_AFXCMN_INLINE int CProgressCtrl::OffsetPos(int nPos)
    { ASSERT(::IsWindow(m_hWnd)); return (int) ::SendMessage(m_hWnd, PBM_DELTAPOS, nPos, 0L); }
_AFXCMN_INLINE int CProgressCtrl::SetStep(int nStep)
    { ASSERT(::IsWindow(m_hWnd)); return (int) ::SendMessage(m_hWnd, PBM_SETSTEP, nStep, 0L); }
_AFXCMN_INLINE int CProgressCtrl::StepIt()
    { ASSERT(::IsWindow(m_hWnd)); return (int) ::SendMessage(m_hWnd, PBM_STEPIT, 0, 0L); }

-> Wenn Du z.B. weißt ein CWnd* pWnd ist ein ProgressCtrl, dann geht folgendes definitiv:

CWnd* pWnd = ...
 CProgressCtrl* pCtrl = (CProgressCtrl*)pWnd;

Nach Fragen?

[Knuddlbaer]

Jepp

Das ich den cast machen kann hab ich ja gesehen. Rene und Hume haben sich ja ausführlich darüber unterhalten.

Was ich aber nicht verstehe ist warum der dynamic_cast nicht geht.
Denn das CWnd das ich von GetDlgItem bekomme ist doch das CWnd das im MFC Control steckt ?!

[Shaggy]

Tja, hab mal kurz in die MSDN geschaut, scheint wohl extra so gewollt zu sein, dass das mit dynamic_cast nicht geht. Da ich aber auch nicht wirklich erkennen kann, wozu dynamic_cast wirklich gut sein soll, bzw. ob an dem Ausdruck

A* pA = dynamic_cast<A*>(pB);

irgendetwas besser ist, als bei

A* pA = (A*)pB;

wüsste ich nicht warum ich ersteren verwenden sollte. Zumal die zweite Form deutlich kürzer ist.

[Korinna]

Tja, hab mal kurz in die MSDN geschaut, scheint wohl extra so gewollt zu sein, dass das mit dynamic_cast nicht geht

Steht das irgendwo in der MSDN? Wenn ja, wo?

[Shaggy]

Geh in den Index und gib "dynamic_cast" ein.

[Knuddlbaer]

dynamic_cast -> definiertes verhalten

lässt sich auch besser lesen als c Style casts

Ich denke ich werd mich da selbst mal durchackern müssen.
Wenn ich das genau weiß poste ich das mal, ich arbeite zu nahe am C++
Standard als das wir auf einen Nenner kommen können

Eventuell weiß Rene noch die Antwort darauf, wieso die laufzeit nicht vorhanden ist.... Schaut nach größerer Quelltextsucherei aus .

thx @ll

[member]

warum funktioniert dynamic_cast denn nicht. ist der zeiger dannach NULL oder wird eine bad_cast Exception geworfen?

[HumeSikkins]

Da ich aber auch nicht wirklich erkennen kann, wozu dynamic_cast wirklich gut sein soll, bzw. ob an dem Ausdruck

A* pA = dynamic_cast<A*>(pB);
irgendetwas besser ist, als bei

A* pA = (A*)pB;
wüsste ich nicht warum ich ersteren verwenden sollte. Zumal die zweite Form deutlich kürzer ist

Oha. Das du die Eigenschaften und Vorteile von dynamic_cast nicht kennst ist aber schade (und für mich auch etwas errschreckend).

dynamic_cast ist der *einzige* geprüfte Laufzeitcast in C++. dynamic_cast ist der *einzige* cast in C++ der ein sicheres Navigieren in komplexen Klassen-Hierarchien erlaubt (also Hierarchien mit mehrfacher und virtueller Vererbung).

Prinzipiell wird der dynamic_cast benutzt um Basisklassen-Referenzen/Zeiger in Referenzen (Zeiger) auf eine abgeleitete Klasse zu casten (down-cast). Um den umgekehrten Weg zu gehen (up-cast) oder um zwischen Referenzen/Zeigern zweier benachbarten abgeleiteter Klassen hin un her zu casten (sibling-cast)

Außerdem kann jeder Pointer nach void* gecastet werden.
Ein solcher Cast liefert einen void-Zeiger auf das am weitesten abgeleitete Objekt der Hierarchy.

Der dynamic_cast kann dabei nur auf Pointer/Referenzen die Objekte von polymorphen Klassen verweisen angewendet werden. Als Teil des C++ RTTI Systems
prüft der cast zur Laufzeit die Gültigkeit des Ausdrucks.
Wird z.B. eine Basisklassenreferenz in eine Referenz vom Typ abgeleitete Klasse gecastet, obwohl das referenzierte Objekt nicht von diesem Typ (oder spezieller) ist, so wird eine bad_cast-Exception geworfen.
Für Pointer wird der Nullpointer geliefert. Das ist ein sehr wichtiger Unterschied zum C-Cast. Dieser bietet keine Möglichkeit einen ungültigen Cast zu erkennen.

Du solltest dir am Besten generell noch mal die vier neuen C++ Cast-Operatoren anschauen. Diese bieten erhebliche Vorteile gegenüber dem alten one-size-fits-all C-Cast (auch als Vorschlaghammer bekannt). Jeder einzelne C++ Cast hat sein wohldefiniertes Einsatzgebiet. Und nur diese Casts halten sich z.B. auch an die in C++ definierten Access-Level.

Der einzige Nachteil der C++ Casts im Gegensatz zum C-Cast ist die Länge. Ich sehe das aber nicht als Nachteil. Erstens lassen sie sich dadurch besser finden und zweitens hast du in der Zeit in der du den Cast-Operator eintippst nochmal die Zeit darüber nachzudenken, ob ein Cast wirklich der richtige Weg ist.

Einen kleinen Einführungsartikel zum Thema C++ Casts findest du hier: http://www.acm.org/crossroads/xrds3-1/ovp3-1.html

[Shaggy]

Also ich find's weder schade noch erschreckend. Es gibt sicherlich Anwendungen wo dynamic_cast etc. notwendig/ sinnvoll sind. Aber ebenso gibt es genug Anwendungen wo die "billige" Version ebenso sinnvoll ist. Wenn ich definitiv weiß, dass ein per CWnd* pWnd gelieferter Zeiger eigentlich vom Typ CMyView* ist, dann brauche ich das nicht noch während der Laufzeit zu überprüfen. Und ich hab bisher nie, während irgendeiner Programmentwicklung, beim debuggen feststellen müssen, das irgendein "gecasteter" Pointer gar nicht das passende Objekt ist.

[cole]

Wenn ich definitiv weiß, dass ein per CWnd* pWnd gelieferter Zeiger eigentlich vom Typ CMyView* ist

Aber CWnd::GetDlgItem liefert einen CWnd-Zeiger zurück und keinen z.B. CMyView*. Der CMyView Konstruktor würde nie aufgerufen und wenn CMyView noch irgendwelche zusätzlichen Variablen hat, werden diese nicht vernünftig initialisiert.

[Knuddlbaer]

Die Diskusion haben wir weiter oben schon durch

Bei dem GetDlgItem sehe ich zwei möglichkeiten:

1. es gibt ein CWnd das ein HWND zugewiesen bekommt. Somit war das CWnd NIE ein MFC Control. Das der Aufruf für Methoden ohne zugriff auf this oder membervariablen funktioniert hat Rene für den VC weiter oben gezeigt. Dem C++ Standard nach gibt das undefiniertes verhalten. (s.o.)

2. Das CWnd was zurück gegeben wird aus der HandleMap ist das CWnd was in der Vererbungslinie des MFCControls steht. Und da sollte dann der dynamic_cast funktionieren. Ich sehe den Grund nicht warum die RTTI versagen sollte oder fehlen sollte.

[med]

Die MFC wurde vielleicht nicht mit RTTI Unterstützung kompiliert?

[Knuddlbaer]

Nope, extra noch mal überprüft. RTTI is aktiv:(

[HumeSikkins]

Also ich find's weder schade noch erschreckend

Schade, da *nur* dynamic_cast dir ermöglicht sicher durch jede Form von Hierarchie zu navigieren und man als Programmierer irgendwann in seinem Leben jede Form von Hierarchie sehen wird. Es wäre also schade, wenn du später an eine komplizierte Hierarchie kommst und den dynamic_cast nicht kennst.
Erschreckend, da *nur* dynamic_cast dir ermöglicht sicher durch jede Form von Hierarchie zu navigieren und du offenbar C++ mit Vererbung einsetzt. Erschreckend also einfach aus Sicherheitsgründen. Erschreckend ist aber zugegebenermaßen ein zu hartes Wort.

Aber ebenso gibt es genug Anwendungen wo die "billige" Version ebenso sinnvoll ist.

Nenn mir außer der Sache mit dem geringeren Tippaufwand bitte einen.

Wenn ich definitiv weiß, dass ein per CWnd* pWnd gelieferter Zeiger eigentlich vom Typ CMyView* ist, dann brauche ich das nicht noch während der Laufzeit zu überprüfen.

Wenn ich das definitiv weiß und wenn ich eine Hierarchie ohne multiple und virtuelle Vererbung habe, dann nehme ich natürlich static_cast. Dazu ist dieser Cast-Operator schließlich u.A. da.

Beinhaltet meine Hierarchie mehrfache bzw. virtuelle Vererbung, dann ist der C-Cast genauso undefiniert wie der static_cast und es bleibt einem *nichts* anderes als ein dynamic_cast.

[ Dieser Beitrag wurde am 30.03.2003 um 19:43 Uhr von HumeSikkins editiert. ]

[Shaggy]

@cole:

Wenn ich in meinem Programm ein Objekt von CMyView erzeugt habe und es über CWnd::GetDlgCtrl() mir liefern lasse, dann kann ich ohne Probleme folgendes machen:

CMyView* pView = (CMyView*)(GetDlgCtrl(ID_MYVIEWID));

Das gibt weder Probleme, noch sonst irgendetwas, denn hinter dem Zeiger verbirgt sich ja schliesslich ein Objekt vom Typ CMyView. Und da ich das ja mal erzeugt habe, wurden auch alle Member-Variablen initialisiert.

Wenn ich eine Klasse von CWnd abgeleitet habe, aber keine zusätzlichen Member-Variablen hinzugekommen sind, dann ich ohne Probleme jeden Zeiger auf ein CWnd in einen Zeiger dieser abgeleiteten Klasse umwandeln. Zwar nicht wirklich die feine Art, aber im Falle des CProgressCtrl (und darum geht es in dieser Diskussion ja ursprünglich) kann ich das guten Gewissens machen. Denn das CProgressCtrl fügt KEINE neuen Member-Variablen hinzu, es muss also nichts initialisiert werden, ich kann aber die Member-Funktionen verwenden, um die Nachrichten an das Control schicken (was ja nun auch ein ProgressCtrl ist), um Eigenschaften zu lesen bzw. zu setzen. Für den Fall, dass das Fenster doch kein CProgressCtrl ist, ist das auch nicht schlimm, da die Nachrichten halt einfach nicht verarbeitet werden.

@Knuddlbaer, @HumeSikkins:

Wenn man der Meinung ist, strikt nach C++-Standard programmieren zu müssen, dann bitte - ist jedem selbst überlassen. Da ich static_cast bisher (ebenso wie dynamic_cast) nicht kannte, hätte ich einige Beispiele nennen können, aber offensichtlich sind diese beiden Zeilen identisch!?:

BOOL CMyWnd::OnNotify(WPARAM wParam, LPARAM lParam, LRESULT* pResult)
{
  NMHDR* pInf = (NMHDR*)lParam;

  // oder

  NMHDR* pInf = static_cast<NMHDR*>(lParam);
}

Also ich bin mit meinen Feld-Wald-und-Wiesen-Cast bisher gut über die Runden gekommen, alle Programme laufen problemlos schnell und zuverlässig. Nichts für ungut, aber sollte ich den dynamic_cast benötigen werde ich eine www.c-plusplus.net-Gedenkminute einlegen.

[Knuddlbaer]

Also bevor ich gesteinigt werde: Hab einiges gelernt in diesem TOpic

Das gibt weder Probleme, noch sonst irgendetwas, denn hinter dem Zeiger verbirgt sich ja schliesslich ein Objekt vom Typ CMyView. Und da ich das ja mal erzeugt habe, wurden auch alle Member-Variablen initialisiert.

Ja das dachte ich auch, das es sich um das CWnd handelt. Das schrieb Rene auch ziemlich am Anfang als ich mit dem Standard anfing. Aber ich verstehe nicht warum es dann nicht mit dynamic_cast klappt ?!

Das würd ich gern noch verstehen.

[ Dieser Beitrag wurde am 30.03.2003 um 23:06 Uhr von Knuddlbaer editiert. ]