Einstieg Windows-Programmierung (MSVS C++) zum Vergleich zu Qt

[Guy (Gast)]

Ich bin in die Windowsprogrammierung reingerutscht, habe bislang aber 
nur ein bißchen mit Qt gearbeitet. Ich kann nichts dagegen sagen, kenne 
aber bislang nichts anderes (und bin kein Informatiker).
Deswegen wollte ich mir mal ein Video-Tutorial zum aktuellen, 
"offiziellen" Windows-GUI-Programmierungs-Weg ansehen, damit ich einen 
Überblick und einen Ansatz zum Vergleich habe - aber habe nicht wirklich 
was gefunden.
Evtl. kennt ja jemand was.

MFC, Windows Forms etc. - was ist da der aktuelle Stand?
Sollte man sich bei der Gelegenheit auch Alternativen zu C++ ansehen 
oder ist das alles neumodischer Kram?

[Rufus Τ. F. (rufus)]

Guy schrieb:
> MFC, Windows Forms etc. - was ist da der aktuelle Stand?

"Windows Forms" ist nicht C++, sondern erfordert den .Net-Unterbau.

Natives C++ ist nur mit der MFC (oder anderen, nicht von MS stammenden 
GUI-Toolkits) möglich, und die MFC würde ich Anfängern in der 
Windows-Programmierung definitiv nicht empfehlen.

Wenn man nicht darauf festgelegt ist, natives C++ zu verwenden, dann 
kann man sich auch mit .Net beschäftigen (von mir nicht liebevoll 
".Net-Geraffel" genannt), aber damit gräbt man sich halt auch eine 
gewisse Abhängigkeitengrube.

Ich würde ein plattformunabhängiges GUI-Toolkit nutzen, wie eben das von 
Dir erwähnte Qt oder wxWidgets.

[HutHut (Gast)]

Wie der Vorredner schon sagte, wenn du nicht zwanghaft an die MFC 
gebunden bist dann nutzen es aus und suche dir etwas anderes. MFC ist 
die Ausgeburt des Bösen.

[Guy (Gast)]

Hi und Danke.
Also ist der aktuelle Weg immer noch die MFC? Dann suche ich noch mal 
nach einer Einführung.
Plattformunabhängigkeit muss nicht sein, es wird eh Windows.

[Sharping (Gast)]

Für GUI Programmierung ist C++ aber auch nicht mehr ganz Zeitgemäß. Da 
solltest du dir überlegen, ob du dir nicht den Luxus gönnen könntest, 
auf etwas high-leveligeres umzusteigen (z.B. C#). Da kommst du u.U. 
deutlich schneller und einfacher zum Ziel...

[Sebastian L. (Gast)]

Also der aller neuste schrei sind WinRT Anwendungen für Win 8, sowas 
willst du sicher nicht.

WPF ist dann das nächst neuerste. Das ist aber nicht ganz so einfach für 
Einsteiger.

Winforms sind eigentlich schon "ewig alt" aber die am meisten 
verbreiteste Form der Anwendungsentwicklung im Windowsbereich.

MFC wird nur noch für sehr wenige alte Projekte verwendet und für neue 
Projekte eher ungeeignet.

Ich rate dir zu Winforms

[Philip (Gast)]

Also ich persönlich will seitdem ich Qt kenne mit nichts anderem mehr 
arbeiten:-) Verstehe nicht, warum man da freiwillig auf MFC oder 
Winforms wechseln sollte, wenn einem nicht vorgeschrieben wird.

[Marco M. (marco_m)]

MFC ist echte Qualitätssoftware, solide wie ein Fels. Z.B.  OBJCORE.CPP:

void CObject::AssertValid() const
{
  ASSERT(this != NULL);
}

und wie ist AssertValid deklariert? In AFX.H:

virtual void AssertValid() const;

O_o

[Sharping (Gast)]

Philip schrieb:
> Verstehe nicht, warum man da freiwillig auf MFC oder
> Winforms wechseln sollte,

Weil man damit für gewöhnlich deutlich schneller eine Anwendung 
hochziehen kann.

[Rufus Τ. F. (rufus)]

Marco M. schrieb:
> MFC ist echte Qualitätssoftware, solide wie ein Fels. Z.B.  OBJCORE.CPP:

Und was genau willst Du da als Problem ansehen?

[Marco M. (marco_m)]

Rufus Τ. Firefly schrieb:
> Marco M. schrieb:
>> MFC ist echte Qualitätssoftware, solide wie ein Fels. Z.B.  OBJCORE.CPP:
>
> Und was genau willst Du da als Problem ansehen?

Eine virtuelle Memberfunktion testet ob this!=NULL ist?

[Rufus Τ. F. (rufus)]

Erklärs mir: Warum soll sie das nicht dürfen?

[Marco M. (marco_m)]

Das ist aus mehreren Gründen Quatsch:

In praktisch jeder Implementation muss der Code den this-Pointer 
dereferenzieren, damit der an die vtable für den virtual call kommt. Das 
geht natürlich nicht, wenn this NULL ist. Also ist der Test Unfug.

Wenn der Compiler aber immerhin garantieren sollte, daß  nicht 
virtuelle Methoden mit this==NULL aufgerufen werden können (und der Test 
nicht etwa wegoptimiert wird), dann funktioniert es nicht, sobald 
Multiple Inheritance ins Spiel kommt. Wenn ich also also z.B:

class MyGadget: public MyBase, public CWnd { ... };

mache und MyBase nicht leer ist, dann haben MyGadget NULL Pointer einen 
von NULL verschiedenen Wert, wenn man eine Methode aus CWnd aufruft. So 
ein Test ist natürlich für die Katz.

Solche this==NULL Tests lassen mich immer aufhorchen, weil die oftmals 
ein Zeichen von Voodoo-Programmierung sind. Da werden böse NULL Zeiger 
mit wirkungslosen Tests beschworen, weil der Entwickler keinen Schimmer 
hat, was er da überhaupt macht. Diese Implementation von AssertValid() 
ist übrigens mindestens seit der in Visual Studio 6.0 mitgelieferten 
Version von MFC drin und auch in der Version von Visual Studio 2010 
unverändert drin und ist demzufolge in zwölf Jahren nicht angerührt 
worden.

[Rufus Τ. F. (rufus)]

Marco M. schrieb:
> Das geht natürlich nicht, wenn this NULL ist.

OK, akzeptiert.

[Sven P. (Gast)]

Ich 'versuche' das zu verfolgen, seit ich damals(tm) mit VB6.0 aufgehört 
hab. Seitdem ist Windows irgendwie etliche Male in Sackgassen gerannt. 
MFC/WinAPI war schon immer und ist weiterhin einfach nur eine Zumutung. 
Mach irgendwie einen Bogen drum wenn du kannst, alles ist besser, 
wirklich.

Ansonsten fliegt für mich schonmal alles raus, wo die Oberfläche 
irgendwie in festen Maßen gebaut wird ('Knopf 150 pixel breit'), sprich 
alles ohne gescheite Layout-Manager. Denn ohne Layout-Manager geht es 
spätestens bei mehrsprachigen Anwendungen garantiert in die Hose. Das 
ist an sich schon ein Kriterium, anhand dessen du etliche Techniken 
aussortieren kannst.


Marco M. schrieb:
>

> virtual void AssertValid() const;
>

Ich stehe ja zugegebenermaßen nicht sonderlich feste in C++: Aber wie 
ruft man denn eine nicht-statische Methode eines Objekts auf, ohne ein 
Objekt zu haben?

[Εrnst B. (ernst)]

Sven P. schrieb:
> ruft man denn eine nicht-statische Methode eines Objekts auf, ohne ein
> Objekt zu haben?

Mit casts ;)

(CObject *)(NULL)->assertValid(); // assertion fails.

Im normalen Programmlauf: Objekt gelöscht, danach Pointer auf NULL 
gesetzt, später trotzdem weiterverwendet.
d.H. Wenn du immer "delete obj; obj=NULL;" schreibts, dann macht 
dieser Check evtl. auch Sinn.

[Sven P. (Gast)]

Εrnst B✶ schrieb:
> Sven P. schrieb:
>> ruft man denn eine nicht-statische Methode eines Objekts auf, ohne ein
>> Objekt zu haben?
>
> Mit casts ;)
Aha, das fällt also in die gleiche Schublade wie

uint8_t i;
if (i > 255)
        i = 255;

Dachte ich mir doch.

[Marco M. (marco_m)]

Εrnst B✶ schrieb:

> Im normalen Programmlauf: Objekt gelöscht, danach Pointer auf NULL
> gesetzt, später trotzdem weiterverwendet.
> d.H. Wenn du immer "delete obj; obj=NULL;" schreibts, dann macht
> dieser Check evtl. auch Sinn.

Nicht wenn der Check eine virtuelle Methode ist.

[Εrnst B. (ernst)]

Marco M. schrieb:
> Nicht wenn der Check eine virtuelle Methode ist.

Stimmt natürlich, soweit hab ich nicht mitgedacht...

Der Compiler könnte zwar den VTable-Lookup einsparen, wenn die Klasse 
zur Compile-Time bekannt ist, aber da wirds dann schon sehr Akademisch, 
und "undefined behavior" bleibts so oder so...

[Karl H. (kbuchegg)]

Marco M. schrieb:
> Εrnst B✶ schrieb:
>
>> Im normalen Programmlauf: Objekt gelöscht, danach Pointer auf NULL
>> gesetzt, später trotzdem weiterverwendet.
>> d.H. Wenn du immer "delete obj; obj=NULL;" schreibts, dann macht
>> dieser Check evtl. auch Sinn.
>
> Nicht wenn der Check eine virtuelle Methode ist.


OK. Sagen wir mal so: Der Test ist so gesehen reichlich sinnlos, weil er 
im Grunde nichts bewirkt oder abfängt.

Allerdings haben die Mannen bei MS in der MFC noch ganz andere logische 
Böcke geschossen, die tatsächlich Schwachsinn sind.

Beispiel?

BOOL CSplitterWnd::OnMouseWheel(UINT fFlags, short zDelta, CPoint point)
{
  BOOL bRetVal = FALSE;
  int row;
  int col;

  BOOL bHasVert = FALSE;

  // determine if any of the panes have a vertical scroll bar
  for (row = 0; row < m_nRows; row++)
  {
    for (col = 0; col < m_nCols; col++)
    {
      CWnd* pPane = GetPane(row, col);
      CScrollView* pView = DYNAMIC_DOWNCAST(CScrollView, pPane);
      if (pView != NULL)
      {
        CScrollBar* pBar = pView->GetScrollBarCtrl(SB_VERT);
        if (pBar != NULL && pBar->IsWindowEnabled())
        {
          bHasVert = TRUE;
          break;
        }
      }
    }
    if (bHasVert)
      break;
  }    

  // find panes in the splitter that have scroll bars
  // and have them do their scrolling
  for (row = 0; row < m_nRows; row++)
  {
    for (col = 0; col < m_nCols; col++)
    {
      // only do the scrolling if the window is-a CScrollView
      CWnd* pPane = GetPane(row, col);
      CScrollView* pView = DYNAMIC_DOWNCAST(CScrollView, pPane);
      if (pView != NULL)
      {
        // prefer to scroll vertically if available
        CScrollBar* pBar = NULL;
        if (bHasVert)
          pBar = pView->GetScrollBarCtrl(SB_VERT);
        else
          pBar = pView->GetScrollBarCtrl(SB_HORZ);
        if (pBar == NULL || !pBar->IsWindowEnabled())
        {
          continue;
        }

        // get the old position, do the scrolling, and
        // then trigger the repaint

        int nOldPos = pBar->GetScrollPos();

        if (pView->DoMouseWheel(fFlags, zDelta, point))
          bRetVal = TRUE;

        if (bHasVert && col < m_nCols -1)
          pBar->SetScrollPos(nOldPos, FALSE);
        else if (!bHasVert && row < m_nRows -1)
          pBar->SetScrollPos(nOldPos, FALSE);

      }
    }
  }

  return TRUE;
}

Was, zum Teufel, geht das ein CSplitterWnd an, welchen View ich in 
welche Pane lege? Der soll einfach nur den Pane raussuchen, an den die 
Message zu senden ist und die Message weitergeben. Und ansonsten soll er 
sich da raushalten! Nicht alle Views benutzen das Mousewheel zum 
Scrollen. Manche, zb Grafikprogramme hängen an das Mouserad zb die 
Zoom-Steuerung - selbst dann wenn sie Scrollbars im View haben. Und das 
die Message überhaupt nicht weitergeroutet wird, wenn der View nicht von 
CScrollView abgeleitet ist, ist überhaupt nicht zu akzeptieren - was 
haben die Leute damals blos geraucht um auf so eine Schwachsinnsidee zu 
kommen?

Von solchen logischen Böcken gibt es in der MFC einige.


(Und nachdem ich das gesagt habe, out ich mich: Ich programmier immer 
noch gerne mit der MFC.)