Differenz von Variable bei der Platzierung von privatem Schlüsselwort in einer MFC-Klasse

Question

Mit dem folgenden Code-Schnipsel als Illustration zu meiner Frage:

// #includes and other macros 

class MyClass : public CFormView 
{ 
private: 
     DECLARE_DYNCREATE(MyClass) 

     bool privateContent; 

     ... 

public: 
     bool publicContent; 

     ... 
}; 

class MusicPlayer 
{ 
public: 
    AppClass *theApp;     // which has a pointer accessing the MyClass object instantiated in the program 

    ... 
} 

Wenn ich das Stichwort „privaten“ in MyClass Definition als solche zu platzieren, die privateContent Die Mitgliedsvariable scheint nicht privat zu sein, wenn ich versuche, in einer Methode der MusicPlayer-Klasse darauf zuzugreifen. Wenn ich jedoch das Schlüsselwort "private" nach der Zeile DECLARE_DYNCREATE (MyClass) platziere, wird das Verhalten der Membervariable privateContent auf die erwarteten Werte zurückgesetzt. Weiß jemand, warum das so ist? Danke im Voraus.

Answer 1

Wenn Sie bei der Definition von DECLARE_DYNCREATE anschauen, werden Sie sehen, dass es ein anderes Makro verwendet:

// not serializable, but dynamically constructable 
#define DECLARE_DYNCREATE(class_name) \ 
    DECLARE_DYNAMIC(class_name) \ 
    static CObject* PASCAL CreateObject(); 

Und wenn Sie in diesem Makro aussehen, DECLARE_DYNAMIC, werden Sie sehen, warum Ihre Klasse Öffentlichkeit wendet:

Wenn es erweitert wird, fügt es das Schlüsselwort public: hinzu und hinterlässt den Rest der Klassendefinition danach öffentlich.

Also wenn Sie sagen, private: nach DECLARE_DYNCREATE, dann ändern Sie es dann von öffentlich zu privat.

class MyClass : public CFormView 
{ 
     DECLARE_DYNCREATE(MyClass) 
private: 
     bool privateContent; 

     ... 

public: 
     bool publicContent; 

     ... 
}; 

Die Klasse wird implizit zu Beginn privat sein, so dass der Effekt ist das gleiche:

Die übliche Verwendung dieses Makro so sein würde.

Außerdem werden die meisten C++ - Programmierer zustimmen, dass Sie versuchen sollten, sich daran zu gewöhnen, Ihre privaten Variablen ganz unten zu platzieren. Die Berechtigung ist, dass wenn Leute, einschließlich Sie selbst, die Klasse lesen, sie sehen wollen, was Sie mit der Klasse tun können, die in der öffentlichen Schnittstelle ist, anstatt wie die Klasse arbeiten wird, welche ist privat.

Indem Sie die öffentliche Schnittstelle zuerst setzen, müssen Sie nicht von all den privaten Dingen belästigt werden.

Ich habe meine privaten Sachen auch an die Spitze gelegt (weil ich aus Visual Basic 6 kam, vor C++), und hasste es, dass meine Gehilfen unten sein sollten, aber wenn man sich einmal daran gewöhnt hat Ich wünschte, du würdest dich früher ändern.

Answer 2

DECLARE_DYNCREATE ist ein Makro, das public Schlüsselwort enthält. Eigentlich enthält es Makro DECLARE_DYNAMIC und es gibt public Schlüsselwort.

Answer 3

Ich denke, das DECLARE_DYNCREATE-Makro muss das public: identifier intern verwenden. Warum? Wenn Sie den obigen Code so ändern, dass privateContent über dem DECLARE_DYNCREATE-Makro deklariert wird, hat es das erwartete Verhalten. Daraus folge ich, dass das Makro eine "Öffentlichkeit" darstellt. Sie müssen also erneut den entsprechenden Bezeichner nach dem Makro deklarieren.