Public-Variablen in MFC

[TheBigW]

Zurück zum Ausgangspunkt:

Die Variablen, die dort public sind sind doch IMHO in den meisten Fällen, die, die das "normale" API Obkekt repräsentieren, was hinter der Klasse steht. Das finde ich eigentlich auch ziemlich sinnvoll, da ich ja z.B., bei jedem Wnd, was ich mit einer API FKT. bearbeitenm möchte jedesmal erst das Fenster suchen müßte.
Stilistisch nicht unbedingt toll, aber bequem :).

[Marc++us]

Nun ja, ein getHWND() hätte es vielleicht auch getan wenn es um den reinen Zugriff ginge... die wollten wohl hier das letzte Quäntchen Performance rausquetschen.

[rüdiger]

@Marc++us

class A
{
  int i;
public:
  A(int x) : i(x) { }
  inline int geti(void) const { return i; }
};

struct B
{
  int i;
  B(int x) : i(x) { }
};

int main(void)
{
  A a(1);
  B b(1);
  a.geti();
  b.i;
}

dürfte doch theoretisch keinen Unterschied geben, von der Performance

[Gerard]

nicht zu der zeit als die mfc desing wurde, oder?

[Marc++us]

Das ist der Punkt.

Wie gesagt, die MFC 1.0 wurde noch auf dem alten 16Bit-Compiler übersetzt...

[Shade Of Mine]

HWND ist doch ein Zeiger.
insofern ist es auch schon fast egal ob man das kapselt, oder nicht (Meyers: returne keine handles auf interne daten)

[Marc++us]

Naja... Zeiger... hm. Darüber kann man hier streiten, da der Zeiger ja nicht wirklich von dem Objekt angelegt wird, sondern aus der WinAPI kommt. Nach Meyer dürfte man damit dann eigentlich überhaupt nicht damit arbeiten...

Meyer ist ja schön und gut, aber ich kann die Vorgehensweise nachvollziehen - hätten die auf die Rückgabe verzichtet, so hätten in den MFC-Klassen sämtliche API-Funktionen gekapselt werden müssen. So wurden die häufigsten reingenommen und man kann seltene Funktionen weiterhin nutzen.

Wer mal vom Konzept darüber nachdenkt, wird da einen Gedanken wiederfinden, der aus Sutters Ecke kommt: set-Methoden einmal implementieren und dann außerhalb der Klassen nutzen:

class Something
{
private:
   double m_Value;
public: 
   void setVal(double value) {m_Value = value;}
};

void setSomethingValue(Something& something, std::string str)
{
   double doub = ... aus str; 
   something.setVal(doub);
}

Also Klassen schlank halten und kleine Schnittfläche des Interface realisieren. Die Idee hier ist nicht so unähnlich.

Man muß es so sagen: die MFC ist alt - softwaretechnisch eindeutig veraltet. Aber sie ist nicht dumm. Denkt man an schlecht optimierende C++-Compiler und eine fehlende STL zurück, so ist die MFC unter diesen Randbedingungen gar nicht so schlecht. Wer noch die OWL kennt, wird die gleichen Rahmenbedingungen und gleiche Lösungswege auch von Borland finden.

Dumm nur, daß man eben diese Altlasten immer noch mitschleppt. Das ist aber eine politische Entscheidung - will man das tun oder nicht. Das ist aber eine andere Diskussion.

[xroads42]

Wie schaut dass eigentlich bei den .Net APIs und C# aus? Sind die hier konsequenter als bei der MFC?

[Marc++us]

Die würde ich als State of the Art bezeichnen. Ich denke mal das Design der .NET-API ist der Hauptgrund, warum überhaupt Leute versuchen das Ding unter Linux zum laufen zu bekommen - wg. der VM sicherlich nicht. Und wg. C# alleine auch nicht.

Wenn Du die VCL von Borland kennst, werden Dir gerade bei den GUI-Klassen (wobei .NET ja noch mehr hat außer GUI) die Klassen und Methoden relativ bekannt vorkommen.

Wer VCL kennt, wird .NET lieben... oder so ähnlich.

[WebFritzi]

Original erstellt von Marc++us:
Wer VCL kennt, wird .NET lieben... oder so ähnlich.

Hört sich gut an.