3. Public-Variablen in MFC

Public-Variablen in MFC

  • P

    Ja, hab ich schon gemacht. Bin aber auch dran gescheitert, weil mir dort noch ein paar Libs fehlen. Mit ein bisschen Geduld sollte das aber gelingen ;).
    Ich hab mir gerade die aktuelle Version 2.0 von fltk aus dem CVS geholt und compiliert. Ging ganz problemlos. Ich teste das gleich mal unter Windows.
    ---
    Fertig ;). Zwar funktioniert bei mir die CVS-Version nicht unter Windows, aber die aktuelle stabile Version 1.1 geht wirklich gut mit dem MSVC++. Mein MingW meckert beim Linken. Auch wenns ein bisschen komisch klingt: ich glaub, dem ist die Kommandozeile zu lang :D. Ich hab mich auch nicht direkt an die Readme gehalten, da steht nämlich, dass man noch ein paar Tools aus Cygwin braucht. Das dauert mir aber jetzt zu lange mit meinem 56k-Modem.

    [ Dieser Beitrag wurde am 12.03.2003 um 15:55 Uhr von palm-man editiert. ]

    0
  • R

    ja, gtkmm ist wirklich mal was schönes! (ich muss mal wieder was damit machen, bevor ich wieder alles verlerne :))

    gtk++ soll ja auch sehr schönes OO haben, gtk++ ist aber komplett in C!

    0
  • T

    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 :).

    0
  • M

    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.

    0
  • R

    @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

    0
  • G

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

    0
  • M

    Das ist der Punkt.

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

    0
  • S

    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)

    0
  • M

    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.

    0
  • X

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

    0
  • M

    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. 😉

    0
  • W

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

    Hört sich gut an. 🙂

    0
Anmelden zum Antworten