Professionelle GUI erstellen.

vllt auf wikipedia. haste da mal geschaut?

wieso willst du die GUI unbedingt in c++ machen? das ist doch nur unnötige arbeit. da bietet sich irgendwas wie c# oder vb.net jawohl besser für an. das backend kannste ja trotzdem in c++ machen, wenn es sein muss. wobei es auch dafür keinen grund gibt. net wird bald schneller sein als nativ kompilierter code unter wind00f.

ps. bin auch nicht viel jünger als du und ich hab den inet slang bestens drauf, alles eine frage der einstellung.

Icematix

Ich benutze wxWidgets und C++.
Ich denke mit dem wxFormBuilder ist es garantiert nicht schwerer als irgendwelche .NET-Lösungen. Von wegen "GUI in C++ ist Scheißarbeit".

Student83

Wenn C# in Windows-Anwendungen in Zukunft sowieso "Standard" wird, werde ich mich dann wohl mal in C# und DirectX einarbeiten.

Icematix schrieb:

Ich benutze wxWidgets und C++.
Ich denke mit dem wxFormBuilder ist es garantiert nicht schwerer als irgendwelche .NET-Lösungen. Von wegen "GUI in C++ ist Scheißarbeit".

Professionell und wxWidget ist jawohl ein kleiner Widerspruch.

hack0r schrieb:

Icematix schrieb:

Ich benutze wxWidgets und C++.
Ich denke mit dem wxFormBuilder ist es garantiert nicht schwerer als irgendwelche .NET-Lösungen. Von wegen "GUI in C++ ist Scheißarbeit".

Professionell und wxWidget ist jawohl ein kleiner Widerspruch.

Nein, aber "hack0r" und "Ahnung" ist ein Widerspruch.

Es sind mittlerweile dermaßen viele (professionelle) Applikationen, die ehemals MFC waren mittels wxWidgets auf OSX/Linux/Win/WinCE portiert worden, dass es mich wundert, dass MS dieses Framework noch nicht als Bedrohung identifiziert hat.

Jochen Kalmbach

B.Larg schrieb:

Es sind mittlerweile dermaßen viele (professionelle) Applikationen, die ehemals MFC waren mittels wxWidgets auf OSX/Linux/Win/WinCE portiert worden, dass es mich wundert, dass MS dieses Framework noch nicht als Bedrohung identifiziert hat.

Da hast Du nicht ganz unrecht... und ich glaube manchmal, das MS in so einem Turm lebt, wo sie nichts anderes sehen und schon gar nicht auf andere Leute hören... es gibt einige MVPs die schon seit langem (>8 Jahre) dies sagen, aber es scheint als ob niemand zuhört...

Es wird auch gerade eine "hitzige" Debatte zwischen einigen MVPs und der Prudugtgruppe geführt. Hieraus nur mal ein Satz (der wohl nicht gegen NDA verstöst) (es geht um MFC):

In short that it has become the equivalent of Cobol in our industry in the year of 2010

Was soll das bedeuten Jochen? Warum sollte sich M$ mit wxWidget beschäftigen? Solche Frameworks sind doch völlig irrelevant. Erläutere doch mal bitte eingehender wie du das meinst.

Jochen Kalmbach

Wir reden hier von C++. (Punkt) also nicht von C# oder anderen (angeblich portablen) Sprachen.

Und hier gibt es nun mal nur drei große Frameworks: MFC, QT, wx

MFC wurde entwickelt als es noch gar kein "richtiges" C++ gab... deshalb sind die ganzen Klassen auch nicht so toll.
QT/wx ist hier schon viel konsequenter.

Wenn man nicht so sehr viel auf prortabilität achten muss, sollte man heute klar C# nehmen... wobei sich hier auch die Frage stellt: WinForms oder WPF! Diese Frage ist leider auch nicht so einfach zu beantworten.

Mit WinForms kann man zumindest nichts verkehrt machen. Das würde ich ja benutzen @Op.

Ob sich dieses WPF Zeug durchsetzt, bleibt erstmal abzuwarten. Würde mich nicht wundern, wenn M$ in 2 Jahren schon wieder mit was neuem ankommt, oder WinForms wieder verstärkt pushed und WPF wieder im stillen Kämmerlein verschwindet. Wäre ja nicht das erste mal.

hack0r schrieb:

.net wird bald schneller sein als nativ kompilierter code unter wind00f

wie kommt ihr alle auf so nen schmarn da geht mir ja die galle hoch das ist wie jeder benchmark der mir zeigt dass java schneller als c oder c++ ist, das kann doch keiner glauben...

weil der .net jitter laufzeitinformationen berücksichtigen kann.

weil der .net jitter laufzeitinformationen berücksichtigen kann.

so wie das java teil oder;)

kA mit java kenn ich mich nicht aus

C#, naja ich denke die Hälfte der User könnte meine Application dann nicht ausführen, weil sie nicht die C# restributables haben (zumindest nicht die neuesten^^)
aber egal, was wäre denn wenn M$ hören würde und wx als bedrohung einstufen würde? Gibt es dann eine Rundmeldung "Achtung bitte kein wx auf windows verwenden" oder was?

afaik ist es doch so das am ende alles über die cpu muß und die braucht maschienencode wer den generiert ist mir gleich, obs nun java c# (.net xyz) oder sonst was ist wenn ich mir nun anschau wielang größere software für die erstellung eben diesen codes braucht dann kann ich mir nicht vorstellen dass die laufzeitinformationen das noch umbiegen können evtl. zeigst mir mal ne große software die besser ist statt nen spezialisierten benchmark wo man immer die eine oder andere sprache besser aussehen lassen kann...

sry für offtopic

Jochen Kalmbach

hack0r schrieb:

weil der .net jitter laufzeitinformationen berücksichtigen kann.

Noch nie was von "Profile-Guided Optimization" gehört?

Jochen Kalmbach

wtff? schrieb:

C#, naja ich denke die Hälfte der User könnte meine Application dann nicht ausführen, weil sie nicht die C# restributables haben (zumindest nicht die neuesten^^)
aber egal, was wäre denn wenn M$ hören würde und wx als bedrohung einstufen würde? Gibt es dann eine Rundmeldung "Achtung bitte kein wx auf windows verwenden" oder was?

Nee... dann würden sie entweder was besseres rausbringen oder zumindest die MFC komplett überarbeiten...

Jochen Kalmbach schrieb:

hack0r schrieb:

weil der .net jitter laufzeitinformationen berücksichtigen kann.

Noch nie was von "Profile-Guided Optimization" gehört?

nö hatte ich ned. ist aber auch nicht so flexibel.

hack0r schrieb:

Warum sollte sich M$ mit wxWidget beschäftigen? Solche Frameworks sind doch völlig irrelevant.

Irrelevant? Wenn sie MS das Wasser abgraben, weil die ganzen schönen Windows-Applikationen plötzlich auch ganz ohne MFC und vor allem ohne Windows funktionieren?

MS hat ja auch sehr viel für wxWidgets getan: justament als wxWidgets einen Status erreicht hat, in dem es eine vollwertige und zu dem noch leicht zu portierende Alternative für die MFC war, wurde selbige quasi abgekündigt.

Und was macht eine Firma, wenn sie eine Riesenapplikation auf Basis der MFC hat? Bestimmt nicht der neuesten Sau folgen, die MS durchs Dorf jagt und alles auf Basis von .NET von Grund auf neu implementieren. Speziell dann nicht, wenn es eben eine Alternative gibt, bei der die Portierung zu über 90% ein reines Text-Replace ist.

Auf die Art hat MS sehr viele Firmen ins wxWidgets-Lager getrieben. Da hilft es ihnen jetzt auch nichts mehr, wenn sie die MFC nun doch wieder weiterentwickeln. Da wird nicht eine der Applikationen mehr zurück portiert - zumal die jetzt auch ganz sauber auf anderen Plattformen laufen.