Jetzt mal Klartext: Warum ist die Winapi tot und wo ist die Alternative?!
-
OK:
Was wird denn als Ersatz kommen?
.NET
Womit in Zukunft programmieren?
.NET
Was gibts als Ersatz für die Winapi, wieso steht fest das sie ein Auslaufmodell ist?
.NET, weil MS zukünftig auf .NET setzt, und nicht mehr auf die Winapi, welche zukünftig nurnoch über .NET emuliert wird.
Was ist mit Longhorn?
Hat .NET schon eingebaut.
Wie lange werde ich C++ noch verwenden können oder muss man in ein paar Jahren evt. umsteigen?!
Es gibt eine .NET-version von C++, die mit Version 2.0 sogar verwendbar sein wird. Brauchst dir also keine Sorgen machen.
Wie ihr seht bin ich echt ein wenig verschreckt was die ganzen Entwicklungen angeht
-
M$ wirds auf alle versuchen, aber obs das so durchbekommen ... keine ahnung.
1. treiber und SW auf low level ebene werden uber ne Objektorientierte schnittstelle nicht gluecklich sein :p
2. cross plattform tools, ala QT, werden auch ned begeistert sein, wenn sie statt ihr Objektmodell auf ne flache C-Schicht umzusetzen, ihr Objektmodell mit nem total anders designten Objektmodell verheiraten muessen. Glaub ned, das man das so performant hinbekommen wuerde.
3. Bis C++ oder andere Objektorientiert arbeitende compiler in der lage sind, geschwindigkeitsmaessig so aufzuholen, das sie die nichtobjektorientierten schnittstellen überfluessig machen koennen, vergeht noch ne weile. Glaubst du, das Longhorn komplett objektorientiert geschrieben wird ? ich nicht. Ne menge wird sicher, aber niemals alles. Meine meinung ...
Fazit:
Ich denk mal ne "Art" WinAPI wird es noch weiterhin geben, aber nicht mehr so fuer den Otto Normal Programmierer publiziert wie bisher ....
MFC wird sterben, dafuer das es eh nur nen wrapper um die winapi war, war sie eh zu aufgeblaeht. Naja, und der Runtime mechanismus ist an ner schwelle, wo er durch was besseres ersetzt werden soellte. Aber dafuer wird ne andere Bibo kommen, die auf .Net (oder .Net direkt auch heisst) aufsetzt und alle gluecklich macht :p hoffen wirs mal.
Standard c++ wird weiterhin unterstuetzt werden. Wenn man den Proggern die STL usw nimmt, und dafuer Garbage Collectors usw vor die fuesse knallt, wuerden viele ihr heil bei nem anderen BS suchen. Ausserdem gaebs dann null plattformuebergreifende bibos mehr. Oder glaub ihr, das es bald nen .Net fuer die gaengigsten Unix derivate geben wird ? Und ned jeder will nur wegen plattformunabhaengigkeit nur Java nutzen wollen.Nur meine Sicht der DInge, am ende kommt eh alles anders ... !
Ciao ...
-
das sind doch alles nur zukunftsprognosen
ich streite nich ab, dass .net einiges ersetzen wird aber im moment siehts doch so ausMFC is das am besten funktionierende framework für umfangreiche windows-only projekte
Winapi is ganz ok für kleineres zeuch (ich mag reines winapi ned... is wohl geschmacksache)
-
M$ wirds auf alle versuchen, aber obs das so durchbekommen ... keine ahnung.
Wie versuchen? Wenn MS das machen will, dann macht es das auch. Da gegen hat man leider keine Chance.
1. treiber und SW auf low level ebene werden uber ne Objektorientierte schnittstelle nicht gluecklich sein
Da hab ich keine Ahnung von. Ich hab noch nie einen Treiber geschriebn.
2. cross plattform tools, ala QT, werden auch ned begeistert sein, wenn sie statt ihr Objektmodell auf ne flache C-Schicht umzusetzen, ihr Objektmodell mit nem total anders designten Objektmodell verheiraten muessen. Glaub ned, das man das so performant hinbekommen wuerde.
Ich glaube MS ist es scheiß egal, ob QT Probleme hat.
3. Bis C++ oder andere Objektorientiert arbeitende compiler in der lage sind, geschwindigkeitsmaessig so aufzuholen, das sie die nichtobjektorientierten schnittstellen überfluessig machen koennen, vergeht noch ne weile. Glaubst du, das Longhorn komplett objektorientiert geschrieben wird ? ich nicht. Ne menge wird sicher, aber niemals alles. Meine meinung ...
Seit wann ist oo-code langsam?
Fazit:
Ich denk mal ne "Art" WinAPI wird es noch weiterhin geben, aber nicht mehr so fuer den Otto Normal Programmierer publiziert wie bisher ....Wie geasgt, die normale WinAPI soll es weiter geben, nur dass Sie auf .Net zurückgreift und deshalb vergleichsweise langsam sein wird.
Standard c++ wird weiterhin unterstuetzt werden. Wenn man den Proggern die STL usw nimmt, und dafuer Garbage Collectors usw vor die fuesse knallt, wuerden viele ihr heil bei nem anderen BS suchen.
Schonmal die Pläne für's nächste Microsoft'sche C++ gesehen. Das ist einfach ISO-C++ mit erweiterungen. z.B. gibt's dann handles:
Typ ^ ein_handle = gcnew Typ();Wenn man will kann man den GC und andere Dinge nutzen, muss aber nicht, wenn man nicht will. Wenn das wirklich alles so klappt fänd ich das gar nicht mal so schlecht.
BTW, ich habe mich bisher in diesem Thread weder für, noch gegen .Net oder MS ausgesprochen.
-
Hach immer diese Auswahl an Möglichkeiten ^^ Am liebsten wär mir wenn Longhorn schon aufm Markt wäre und man wüsste was sich so tut.
Ich finde diese Ungewissheit wie es weitergehen wird echt ....
-
MFC is das am besten funktionierende framework für umfangreiche windows-only projekte
Wieso?
-
der_held schrieb:
MFC is das am besten funktionierende framework für umfangreiche windows-only projekte
Wieso?
vergiss es. Mit Sovok kannst du nicht reden. siehe
Welches Framework(?) ist für mich geeignet
-
weil man mit wenigen zeilen viel erreicht und alles übersichtlich und geordnet bleibt
@shade die alternativen aus dem anderen post sind echt ziemlich lächerlich
-
Sovok schrieb:
weil man mit wenigen zeilen viel erreicht und alles übersichtlich und geordnet bleibt
*g*, geordnet? Das ist ja wohl ein Witz. Die MFC sind alleine schon veraltet weil sie in vorsintflutlichem C++ (aber eher C mit Klassen) geschrieben sind. Alleine schon das Modell, dass 80% der Klassen von CObject abgeleitet sind, stört. Dazu kommt noch, dass man heute wohl eher einige Sachen in Namespaces kategorisieren würde anstatt so ein blödes C als Prefix zu nehmen und, dass die Klassen voll mit Präprozessor-Müll sind. Ich benutze auf der Arbeit auch die MFC, aber ich denke, dass wir mit den Projekten langsam umsteigen werden sobald eine gute Alternative besteht bei der es möglich ist einige vorhandene MFC-Codes mitzunehmen. Den ganzen Mist neu schreiben würde einen immernsen Zeitaufwand bedeuten den sich eine Softwarefirma idR nicht erlauben kann.
-
Wie versuchen? Wenn MS das machen will, dann macht es das auch. Da gegen hat man leider keine Chance.
Naja, soo einfach isses nu auch wieder nich.
Ok, M$ ist quasi Monopolist, die koennen sich schon viel erlauben, aber alles geht auch ned. Siehe Kartell-Verfahren (auch wenn die ned veil gebracht haben, zumindest war ja die Zerschlagung mal im Gespraech). Und am ENde jagt auch M$ den kunden hinterher. Wenn China jtzt rote Buttons haben woellte, und dafuer die M$ Patentrechte anerkennen wuerde inklusive ihr selbst entwickeltes Linux-Derivat zu kicken, was glaubst wie schnell M$ ...Seit wann ist oo-code langsam?
der code ist nicht langsam, sondern ... anders. Der Code selber, der normale lieneare code unterscheidet sich eh kaum . Aber, die Funktionsaufrufe usw. Wenn du 25000 mal inner sekunde ne Callbackroutine aufrufen muesstest, und die Callback waer nu ploetzlich an nem Object .... und die funktion, die den richtigen Callback raussucht ist nu keine plain C funktion mehr sondern ne eine virtuelle, udn wenn dann noch nen 08/15 GC seine finger im spiel hat, und kein auf den anwendungsfall optimierter container ..... Sicher, man kann mit c++ auch C schreiben, aber das ist nicht sinn der sache. Wenn man freie hand haette, koennt man die Aufrufe optimieren, dann gaengs vielleicht wieder richtig objectorientiert, aber meist kann man das ned ...
Wie geasgt, die normale WinAPI soll es weiter geben, nur dass Sie auf .Net zurückgreift und deshalb vergleichsweise langsam sein wird.
Naja, ich glaub immer noch dran, das man um performant zu bleiben, ne flache schnittstelle brauch ... und man ned alles hirarisch abschiessen kann ... Naja, vielleicht bin ich auch nur der zeit hinterher
CIao ...
-
@MaSTaH ich seh in deine post nur ne ansamlung von behauptungen ohne eine einzige begründung
namespaces... lol
-
Die MFC sind alleine schon veraltet
Das ist die Behauptung
weil sie in vorsintflutlichem C++ (aber eher C mit Klassen) geschrieben sind.
das ist die Begründung.
Dazu kommt noch, dass man heute wohl eher einige Sachen in Namespaces kategorisieren würde anstatt so ein blödes C als Prefix zu nehmen
Das ist nur ne Behauptung, aber brauchst du da wirklich noch eine Begründung. Heutzutage würde man Namespaces verwenden statt einen Präfixes. Das ist eine Tatsache.
und, dass die Klassen voll mit Präprozessor-Müll sind
Bedarf die Behauptung einer Begründung? Guck es dir doch selber einfach an.
namespaces... lol
Was soll das? Namenskonflikte werden in C++ heutzutage durch Namensräume gelöst, statt durch Präfixe. Was gibt's da zu lachen?
-
Sovok schrieb:
@MaSTaH ich seh in deine post nur ne ansamlung von behauptungen ohne eine einzige begründung
Wo habe ich etwas behauptet? IMHO waren das alles Fakten.
Sovok schrieb:
namespaces... lol
War mir irgendwie klar, dass du so etwas nicht kennst.
-
Sovok schrieb:
@shade die alternativen aus dem anderen post sind echt ziemlich lächerlich
cool. Borland setzt auf eine laecherliche Technologie und Microsoft laesst das Non-Plus-Ultra-GUI-Toolkit fallen?
Irgendwie scheinen die Microsoft, Borland und Linux-Leute alles deppen zu sein.
-
hört bitte auf mit dem MFC geflame und macht das in dem anderen Thread. Im Endeffekt werdet ihr Sovok eh nicht überzeugen können, weil der viel zu fanatisch ist.
-
Oder seit ihr das, die anderen bekehren wollt?
-
-
Sovok schrieb:
namespaces... lol
Gibt's für dieses unqualifizierte "lol" auch eine Begründung?
Vielleicht lassen wir mal einen Experten sprechen - Jeff Prosise sagt Dir als Anhänger der MFC ja hoffentlich etwas:
http://www.codeproject.com/interview/jeffprosise17aug2000.asp
Abgesehen davon würde ich mir schon meine Gedanken machen, wenn Anders Hejlsberg, Jeff Prosise und Charles Petzold zusammen an und mit .NET arbeiten... :o
-
ok letzter kommentar zu mastah... wird mir langsam zu blöd
"*g*, geordnet? Das ist ja wohl ein Witz."
er findet sich in der mfc ned zurecht?"Die MFC sind alleine schon veraltet weil sie in vorsintflutlichem C++ (aber eher C mit Klassen) geschrieben sind."
aha es is alt... also isses schlecht und man kann nich gut damit programmiern?"Alleine schon das Modell, dass 80% der Klassen von CObject abgeleitet sind, stört."
ahhh es is von cobjekt abgeleitet... davon bekomm ich pickel?"Dazu kommt noch, dass man heute wohl eher einige Sachen in Namespaces kategorisieren würde anstatt so ein blödes C als Prefix zu nehmen"
er hat namenskonflikte weil die mfc klassen ein präfix haben? wie hat er das nur angestellt...und, dass die Klassen voll mit Präprozessor-Müll sind.
"...und? wen stört das bitte wenns funktioniert?"es is leicht zu sagen etwas is tot... aber trotzdem habt ihr keine gleichwertige windows-alternative zu bieten
die seltsame logik blick ich ned...
-
Sovok schrieb:
"*g*, geordnet? Das ist ja wohl ein Witz."
er findet sich in der mfc ned zurecht?Zurecht finden hin oder her, sie ist deshalb trotzdem nicht vernünftig geordnet. Wenn du wissen willst, wie sowas geordnet ausschaut, dann schau dir mal den .Net Object Browser an.
Sovok schrieb:
"Die MFC sind alleine schon veraltet weil sie in vorsintflutlichem C++ (aber eher C mit Klassen) geschrieben sind."
aha es is alt... also isses schlecht und man kann nich gut damit programmiern?Ja, weil sich die Programmiermodelle weiterentwickeln.
Sovok schrieb:
"Alleine schon das Modell, dass 80% der Klassen von CObject abgeleitet sind, stört."
ahhh es is von cobjekt abgeleitet... davon bekomm ich pickel?Ne, das find ich nicht schlecht, solange Object sinnvolle Basismethoden und Datenelemente zur Verfügung stellt.
Sovok schrieb:
"Dazu kommt noch, dass man heute wohl eher einige Sachen in Namespaces kategorisieren würde anstatt so ein blödes C als Prefix zu nehmen"
er hat namenskonflikte weil die mfc klassen ein präfix haben? wie hat er das nur angestellt...Er hat nicht gesagt, dass er Namenskonflikte hat, sondern, dass man Namenskonflikte heute nicht mit C-Prefixen vermeidet, sondern mit namespaces.
Sovok schrieb:
und, dass die Klassen voll mit Präprozessor-Müll sind.
"...und? wen stört das bitte wenns funktioniert?"Mich, weil #defines nicht typensicher sind.
Sovok schrieb:
es is leicht zu sagen etwas is tot... aber trotzdem habt ihr keine gleichwertige windows-alternative zu bieten
die seltsame logik blick ich ned...Die Alternativen wurden bereits genannt. Ich denke nicht, dass MFC schon tot ist, aber irgendwann eben schon. Deshalb schadet es bestimmt nicht, sich mal was anderes anzuschauen...