Kann man mit normalem C++ irgendwann keine Windows-Programme mehr schreiben?
-
Wer sagt das? Sind QT und wxWidgets wohl nicht portabel?
Die Rede war doch von WinAPI. Ich sehe gerade, dass ich dich vielleicht misverstanden habe.
Sorry, dachte es wäre von Wrappern/APIs im Allgemeinen die Rede gewesen.
Ich sehe jetzt zwei Möglichkeiten:
- du trauerst der WinAPI-Programmierung nach. So habe ich es erst verstanden. Dann verstehe ich nicht, warum du mit wxWidgets jetzt kommst.
- du trauerst der MFC nach...Nachtrauern tue ich in gewisserweise der MFC und zwar weil ich sie gerne weiterverwenden möchte, aber sie aus bestimmten Gründen irgendwo einfach nicht abkann (Stilfragen, zu überladen, veraltetes GUI, etc). Außerdem bin ich aus geschäftlichen Gründen zusätzlich gebunden, sie zu benutzen.
Irgendwas scheinst du gegen high-level GUIs zu haben, obwohl es gerade bei GUIs so egal ist.
In Bezug auf GUIs fühle ich mich eben von den MFC (gegen die ich grundsätzlich nichts habe) verarscht. Microsoft bietet hier standardmäßiges GUI-Design, wie es vielleicht zu Win95-Zeiten aktuell war. Wie ich bereits erwähnte, kommt man also um die Verwendung von Unmengen (-> Fehlerquelle Third-Party-Freeware-Programmierer; nicht falsch verstehen, die Leute verdienen Respekt. Der Code ist leider aber oft buggy.) fremden Codes nicht herum, den man mühevoll anpassen muss.
Inwiefern schaust du in die Röhre? Ich verstehe dein Problem nicht.
In die Röhre schaut momentan finde ich derjenige der unter C++ reine Windows-Anwendungen schreiben möchte, eben aus o.g. Gründen. Und ich denke aufgrund der Verbreitung von Windows gerade im Client-Bereich ist dieser Gedanke nicht aus der Luft gegriffen.
-
simon.phoenix schrieb:
In die Röhre schaut momentan finde ich derjenige der unter C++ reine Windows-Anwendungen schreiben möchte, eben aus o.g. Gründen. Und ich denke aufgrund der Verbreitung von Windows gerade im Client-Bereich ist dieser Gedanke nicht aus der Luft gegriffen.
Wieso?
wxWidgets ist fein, Qt ist auch OK. Und C++/CLI ist sogar sehr fein.also so schlimm sieht es nicht aus.
aber klar, das einstellen der MFC und der VCL zeigt sicher wirkung.
-
Also nach dem Einstellen der MFC siehts noch lange nicht aus. Bis jetzt wird sie immer weiterentwickelt. Jedenfalls erhöhen sie die Versionsnummer bei jeder Visual C++ Version.
(Visual C++ 2005 => MFC 8.0)
-
8.0 schrieb:
Also nach dem Einstellen der MFC siehts noch lange nicht aus. Bis jetzt wird sie immer weiterentwickelt. Jedenfalls erhöhen sie die Versionsnummer bei jeder Visual C++ Version.
(Visual C++ 2005 => MFC 8.0)aber es tut sich nix.
die MFC beim vc++8 kenne ich zwar nicht, aber von 6er auf 7.1er hat sich nicht viel getan...das problem ist aber avalon - wenn MFC dafuer nicht angepasst wird, schaut es traurig aus.
-
Hallo,
von Arbeit her komme ich auch mit Visual FoxPro in Kontakt die RuntimeDlls
VFP[Version].dll sind gegen die MSVC[Version].dll gelinkt.Von MS aus besteht für VFP Support bis 2012. In der Version 9.0, erscheint
dieses Jahr wird es erstmals möglich sein auf Windowsereignisse WM_HasteNichtGesehen und Co. zuzugreifen.VFP ist und wird definitiv nicht Bestandteil von .Net, weil man hat es mir mal erklärt beim Techtalk ( MS - Veranstaltung ) es einfach nicht möglich ist, weiß der Geier warum.
MfG
RB
-
...das einstellen der MFC und der VCL zeigt sicher wirkung.
Die VCL wird noch lange nicht eingestellt. Warum die Leute immer dieses Gerücht umbedingt am Leben halten wollen.
-
MFC IMHO auch nicht. MFC ist mit Sicherheit nicht so schwer, auf Winforms oder Avalon zu portieren, wie das WinAPI.
-
Ich würde mal sagen das ist genauso schwer. MFC abstrahiert nicht weit genug von der WinAPI. Und das ist auch gut so. :xmas1:
-
hmmmm schrieb:
Ich würde mal sagen das ist genauso schwer. MFC abstrahiert nicht weit genug von der WinAPI. Und das ist auch gut so. :xmas1:
full ack. Das Abstraktionslevel ist oft sehr gering. Ich kenne eine eventuelle Avalon-API zwar nicht, aber eine Umstellung der MFC auf diese dürfte womöglich kein leichtes sein.
Deshalb bin ich der Meinung, dass MFC in der jetzigen Form am Leben erhalten wird und der Support erst in vielen Jahren fallen wird, auch wenn Microsoft anderweitiges behauptet um vielleicht jeden dazu zu bringen dotnet zu benutzen... (kommerzieller Grund)
-
die MFC beim vc++8 kenne ich zwar nicht, aber von 6er auf 7.1er hat sich nicht viel getan...
Naja, wenigstens hat Microsoft versucht mit Compiler und auch den MFC standardkonformer zu werden. Auch wenn das nicht gerade der große Wurf war, wie du schon sagtest.
-
MFC wurde bisher in 7.0 und 7.1 zumindest gepflegt. Es ist zwar nicht großartiges passiert, aber viel wichtiger ist, das MS wenigstens die MFC pflegt und jeder neuen VC++-Version beilegt. Das wird sicherlich in Zukunft erstmal so bleiben, da zu viele Programme die MFC benutzen. Und sollte MS mal wirklich mit der MFC nichts zu tun haben wollen, kann ich mir gut vorstellen, das sie es ähnlich wie WiX und die WTL als OpenSource frei geben.
Also, alles paletti und blos keine Panik!
-
Artchi schrieb:
Also, alles paletti und blos keine Panik!
Es geht aber um Avalon - also Longhorn.
Wenn MFC die neuen Longhorn Features nicht kann (sie also nicht gewrapt werden, dann wird man MFC nicht mehr fuer neue projekte verwenden und die MFC wird sich somit langsam aufloesen) dass MS nicht von heute auf morgen die MFC wegwirft ist klar.
-
Es gibt ja aber noch die möglichkeit auf QT oder wxWidgets umzusteigen. Diese (hoffe ich doch mal) werden diese funktionen irgendwann Wrappen
-
guenni81 schrieb:
Es gibt ja aber noch die möglichkeit auf QT oder wxWidgets umzusteigen. Diese (hoffe ich doch mal) werden diese funktionen irgendwann Wrappen
Also wenn die Freizeit-Programmierer (mal wieder nicht falsch verstehen, habe großen Respekt vor denen, finde wxWidgets auch sehr gelungen!) von wxWidgets das fertigbringen, sollte es Microsoft wohl auch gelingen die MFC umzuschreiben?
-
simon.phoenix schrieb:
Also wenn die Freizeit-Programmierer (mal wieder nicht falsch verstehen, habe großen Respekt vor denen, finde wxWidgets auch sehr gelungen!) von wxWidgets das fertigbringen, sollte es Microsoft wohl auch gelingen die MFC umzuschreiben?
Das mag sein das dann M$ die MFC vielleicht umschreiben könnte. Aber die habe dafür ja das ganze .NET Zeug geschaffen und deshalb wird mit sicherheit an der MFC nix mehr groartig gemacht. Die Leute von wxWidgets wollen aber ja das Ihr Framework weiterverwendet wird und deshalb denke ich mal das dies auch weiterentwickelt wird. Außerdem weisst du ja nicht ob dies wirklich nur Freizeitprogrammierer sind. Vielleicht sind diese ja auch als Programmierer im Arbeitsleben tätig.
-
simon.phoenix schrieb:
Die Einführung von Sprachen wie C# impliziert das doch bereits.
Und die Arbeit, die in CLI/C++ ging und geht, impliziert das Gegenteil. In der MSDN heißt es "Visual C++ [...] typically takes longer to master but can offer more horsepower and a finer degree of control [...]". Nur weil mit VB und C# Sprachen für Otto Normalcoder eingeführt wurden, muss C++ seine Position als Programmiersprache für die /richtige/ Arbeit nicht verlieren - und wenn die Idee hinter CLI/C++ aufgeht, wird C++ zu einer extrem mächtigen Rundum-Sprache.
Davon abgesehen war mir die WinAPI lieber als Windows Forms weil man sie IMHO wesentlich besser wrappen konnte, um sie anderen Sprachen (z.B. C++) anzupassen...
Edit: So früh kann doch kein Mensch tippen
-
guenni81 schrieb:
Aber die habe dafür ja das ganze .NET Zeug geschaffen und deshalb wird mit sicherheit an der MFC nix mehr groartig gemacht. Die Leute von wxWidgets wollen aber ja das Ihr Framework weiterverwendet wird und deshalb denke ich mal das dies auch weiterentwickelt wird.
Also ich denke aufgrund des vorhandenden MFC-Codes werden die MFC vielleicht schmalspurartig weiterentwickelt (hier und da mal ein Fix und eine neue Klasse).
Außerdem weisst du ja nicht ob dies wirklich nur Freizeitprogrammierer sind. Vielleicht sind diese ja auch als Programmierer im Arbeitsleben tätig.
Sie programmieren wohl aber in ihrer Freizeit
Mir stellt sich insgesamt eine Frage:
Wenn sich die, wie wir uns bereits einig waren, teilweise wenig abstrahierten MFC auf irgendeine Weise Avalon-kompatibel machen lassen würden, so dürfte Avalon von der Struktur her ja nichts grundlegend neues bieten. Somit könnte doch eigentlich gleich der WinAPI-Support fortbestehen?
-
simon.phoenix schrieb:
Wenn sich die, wie wir uns bereits einig waren, teilweise wenig abstrahierten MFC auf irgendeine Weise Avalon-kompatibel machen lassen würden, so dürfte Avalon von der Struktur her ja nichts grundlegend neues bieten. Somit könnte doch eigentlich gleich der WinAPI-Support fortbestehen?
WinAPI/MFC-Programme werden selbstverständlich auch auf Longhorn laufen. Der Support "besteht also fort".
Ich verstehe euer Problem nicht, es ist doch offensichtlich, dass ein Unterschied zwischen technischer Realisierbarkeit und kommerziellem Marketinginteresse besteht. Natürlich könnte MS die MFC anpassen. Das technische Wissen und die finanziellen Ressourcen sind zweifelsohne vorhanden. Der Punkt ist doch nur der, dass MS es nicht will.
-
WinAPI/MFC-Programme werden selbstverständlich auch auf Longhorn laufen. Der Support "besteht also fort".
Das war nicht der Punkt. Der Punkt war, ob MFC auf Avalon laufen wird. Und das kann man denke ich, mit gutem Gewissen verneinen, da es die Winforms auch nicht werden.
Daher besteht also echt die Möglichkeit, dass Avalon etwas komplett neues bringt.
Allerdings werden Winforms noch ne ganze Zeit lang emuliert, z.B. werden GDI-Funktionen über lock & copy emuliert. Das könnte für die MFC auch möglich sein. Ein Anpassung der MFC für Avalon halte ich für extrem unwahrscheinlich, wenn dann könnte ich es mir noch für die Winforms vorstellen. Die MFC hat ihre besten Tage hinter sich.
-
Optimizer schrieb:
WinAPI/MFC-Programme werden selbstverständlich auch auf Longhorn laufen. Der Support "besteht also fort".
Das war nicht der Punkt. Der Punkt war, ob MFC auf Avalon laufen wird. Und das kann man denke ich, mit gutem Gewissen verneinen, da es die Winforms auch nicht werden.
Ja eben, und ich sagte, dass das eine "politische" Entscheidung Microsofts ist und keine technische Unmöglichkeit.