C++/MFC: Zugriff trotz Protected

[Bernhard Geyer]

Code:

class CTestPrivateView : public CView
{
protected: // Nur aus Serialisierung erzeugen
   CTestPrivateView();
   DECLARE_DYNCREATE(CTestPrivateView)

   CString m_Test; // <- um diese Variable gehts
// Attribute
public:
   CTestPrivateDoc* GetDocument();

// Operationen
public:
....
};


void TestFunc( CTestPrivateView* pt)
{
   pt->m_Test = "Herbert";
}

void CTestPrivateView::OnDraw(CDC* pDC)
{
   TestFunc( this);
   CTestPrivateDoc* pDoc = GetDocument();
   ASSERT_VALID(pDoc);
   // ZU ERLEDIGEN: Hier Code zum Zeichnen der ursprünglichen Daten hinzufügen
}

Wieso ist der Zugriff auf m_Test erlaubt? Sollte doch Protected sein!
Für die Lösung gibt es Extra-Respekt

[Christian Seehase]

Moin Bernhard,

das ist jetzt zwar nur Vermutung, und kein Wissen, aber...

Wenn sich die beiden Abschnitte in der gleichen Datei befinden, kann der Protected Bereich auch "gesehen" werden.
(gilt zumindest für Delphi)

[Eisenherz]

Zitat von Christian Seehase:

Wenn sich die beiden Abschnitte in der gleichen Datei befinden, kann der Protected Bereich auch "gesehen" werden.
(gilt zumindest für Delphi)

Das ist bei C++ nicht so. Das private und protected aus C++ dürfte in etwa dem strictly private und strictly protected aus Delphi 8 entsprechen.

Das von Berhard Geyer gezeigte dürfte nur funktionieren, wenn die Klassendeklaration folgede Zeile enthält:

Code:

friend void TestFunc( CTestPrivateView* );

[Bernhard Geyer]

Es hat nichts mit dem Friends-Konzept zu tun. Eher mit einem der "großen Features" von C++ zu tun, welches sich auch als große Fehlerquelle herausstellen können.

[NicoDE]

Zitat von Bernhard Geyer:

Wieso ist der Zugriff auf m_Test erlaubt?

Handelt es sich zufällig um MSVC 6.0?

ps: wie sieht das Makro DECLARE_DYNCREATE aus... (Semikolon vergessen?)

[Bernhard Geyer]

Zitat von NicoDE:

Zitat von Bernhard Geyer:

Wieso ist der Zugriff auf m_Test erlaubt?

Handelt es sich zufällig um MSVC 6.0?

ps: wie sieht das Makro DECLARE_DYNCREATE aus... (Semikolon vergessen?)

Kein Semikollon vergessen, aber folgendes (DECLARE_DYNCREATE = DECLARE_DYNAMIC + Etwas Erweiterung):

Code:

#define DECLARE_DYNAMIC(class_name) \
public: \
   static const CRuntimeClass class##class_name; \
   static CRuntimeClass* PASCAL GetThisClass(); \
   virtual CRuntimeClass* GetRuntimeClass() const; \

D.h. nach dem Makro steht alle folgenden Einträge erst mal auf public!
Gut das Borland bei der VCL nicht auf solche verwirrenten Konstrukte zurückgegriffen hat.