welche programmiersprache für Programme benutzen?

[ms fanboy]

asc schrieb:

ms fanboy schrieb:

Unsinn. Du kannst wohl auch nur nachplappern, hast aber noch nie mit den MFC gearbeitet.

Ich habe schon vor längeren mit der MFC arbeiten müssen, und man sieht dem Framework an, das es schon lange veraltet ist

Was findest Du so schlecht an den MFC? Ich finde sie sehr praktisch, nicht nur durch die Integration in VS. Man kann mit den MFC sehr einfach und schnell Windows-Programme entwickeln und sogar mit WinAPI-Aufrufen mischen. Ja, die Datenbankanbindung ist Mist, aber sonst habe ich nichts daran auszusetzen.

[Shade Of Mine]

ms fanboy schrieb:

Was findest Du so schlecht an den MFC? Ich finde sie sehr praktisch, nicht nur durch die Integration in VS. Man kann mit den MFC sehr einfach und schnell Windows-Programme entwickeln und sogar mit WinAPI-Aufrufen mischen. Ja, die Datenbankanbindung ist Mist, aber sonst habe ich nichts daran auszusetzen.

Ich denke dazu muss man nur sagen: wer einmal mit MFC und einmal mit Swing gearbeitet hat, der stellt solche Fragen nicht.

Wobei Swing natürlich sehr schön ist, aber auch Qt oder gtkmm sind gute Toolkits.

[nwp2]

Dravere schrieb:

nwp2 schrieb:

Ich nehme das über die Doku von QT zurück. Hab QT mit GTK verwechselt. QT hatte ich aufgegeben wegen c++. Das war wohl etwas vorschnell.

Seltsame Augen hast du:
http://www.gtk.org/documentation.html

Die habe ich gefunden und viele Stunden versucht damit was zu machen. Er zwingt einem ständig GTK+ auf. Abgesehen davon gibt es pro Funktion eine Zeile Kommentar, wenn überhaupt.
Ich bin wahrscheinlich nur von der WinAPI verwöhnt, da gibts eine Zeile Funktion und eine Seite Erklärung der Parameter, Hinweise, übliche Fehler, Beispiele, welche Header und Libs man braucht und eine Referenz zu ähnlichen Funktionen.

Aber naja, wer GTK mag soll es benutzen. Ich komme aber weiterhin mit C-Bibliotheken und vor allem mit der WinAPI recht gut klar, mit QT und GTK garnicht.

[rapso]

Shade Of Mine schrieb:

ms fanboy schrieb:

Was findest Du so schlecht an den MFC? Ich finde sie sehr praktisch, nicht nur durch die Integration in VS. Man kann mit den MFC sehr einfach und schnell Windows-Programme entwickeln und sogar mit WinAPI-Aufrufen mischen. Ja, die Datenbankanbindung ist Mist, aber sonst habe ich nichts daran auszusetzen.

Ich denke dazu muss man nur sagen: wer einmal mit MFC und einmal mit Swing gearbeitet hat, der stellt solche Fragen nicht.

Wobei Swing natürlich sehr schön ist,

ist das sarkasmus? Swing war der grund fuer mich meine schlechte meinung ueber MFC zu ueberdenken, spaetestens als ich sah wie die einzelnen bildelementes von swing einzeln aufgebaut wurden war das ding fuer mich gestorben.

aber auch Qt oder gtkmm sind gute Toolkits.

wxWidget :FTW:

[Dravere]

nwp2 schrieb:

Die habe ich gefunden und viele Stunden versucht damit was zu machen. Er zwingt einem ständig GTK+ auf.

ROFL, das wird ja immer wie lächerlicher. Logisch wenn du mit GTK arbeitest, zwingt er dich zu GTK+, weil GTK+ ist GTK. Da gibt es keinen Unterschied. Man schreibt nur ungern immer noch das '+' hin, weshalb man oft einfach nur GTK schreibt.

nwp2 schrieb:

Abgesehen davon gibt es pro Funktion eine Zeile Kommentar, wenn überhaupt.

Im allgemein sind es eher mehr als eine Zeile. Zudem kommen noch allgemeine Informationen zu einem Bereich und eine Menge an Tutorials und Anleitungen. Jedenfalls hat es sicher genügend Dokumentation, um damit vernünftig und angenehm entwickeln zu können.

nwp2 schrieb:

Ich bin wahrscheinlich nur von der WinAPI verwöhnt, ...

Ich habe eher das Gefühl, dass du zu faul bist, mal etwas neues zu probieren. Und wenn mal etwas nicht so ist, wie man es sich gewohnt ist, meckert man gleich rum und schreibt die Sache ab, statt dass man gegen seine Gewohnheiten angeht und was neues lernt.
Aber ich stimme dir zu, dass es wirklich jedem sein Bier ist, mit welcher Bibliothek er lieber entwickelt. Solange du nicht solchen Unsinn über die anderen Bibliothek schreibst, ist alles in Ordnung

rapso schrieb:

wxWidget :FTW:

Wenn sie mal die Bibliothek durchputzen und die oberen Entwickler durch frisches Gemüse ablösen würden. Ihre krankhafte Angst vor neuer Technologie ist einfach nur nervend. Unbedingt wollen sie noch UR-UR-UR-UR-Alt Kompiler unterstützen, statt diese endlich fallen zu lassen. Auch ihre Angst vor der Standardbibliothek ist einfach nur lächerlich. Dann auch die riesige Menge an Makros, wo man mindestens 90% durch Templates ablösen könnte, was sie aber unbedingt auch nicht einsetzen wollen. Dann die automatische und nicht kontrollierbare Referenzzählung, wodurch man gewzungen wird alles auf den Heap zu setzen und überall mit Zeiger hantieren muss.
Oder dann solche Dinge wie wxTextValidator. Geht man in den Source Code schauen, findet man dies hier in der Validate Funktion:

wxTextCtrl *control = (wxTextCtrl *) m_validatorWindow;

Es steht aber nirgends in der Dokumentation, dass man ihn ausschliesslich für wxTextCtrl verwenden darf. Wenn du ihn für etwas anderes verwendest, hast du hier wunderbares undefiniertes Verhalten, wo du eine halbe Ewigkeit dran suchst. Aber die C++ Casts wollen sie ja auch nicht einsetzen.

usw. usf.
Die Biblothek wird älter und älter und älter und sie machen nichts dagegen.

Grüssli

[asc]

ms fanboy schrieb:

Was findest Du so schlecht an den MFC? Ich finde sie sehr praktisch, nicht nur durch die Integration in VS. Man kann mit den MFC sehr einfach und schnell Windows-Programme entwickeln...

Genau das letztere geht mit vielen Alternativen deutlich besser (einfacher und schneller).

ms fanboy schrieb:

und sogar mit WinAPI-Aufrufen mischen.

Ich habe bisher in jedem Windowsprogramm WinAPI-Funktionen verwendet, unabhängig vom restlichen Framework. Okay, nur im seltensten Fall wegen UI.

Gleichzeitig ärgert mich die Verwendung der Makros in der MFC (führte in der Vergangenheit schon häufiger in meinen Projekten zu Konflikten), bestimmte Voreinstellungen die man vornehmen muss (um bestimmtes Standard-C++ Verhalten zu unterbinden - ich hoffe sie haben wenigstens dies inzwischen geändert), die (logischerweise, ist ja auch älter) Ignoranz moderner C++ Programmierung...

[Shade Of Mine]

rapso schrieb:

ist das sarkasmus? Swing war der grund fuer mich meine schlechte meinung ueber MFC zu ueberdenken, spaetestens als ich sah wie die einzelnen bildelementes von swing einzeln aufgebaut wurden war das ding fuer mich gestorben.

Reden wir jetzt über Performance oder API Design?

Weil von der Performance her ist Swing sicher eine der schlechtesten Lösungen, aber das API Design finde ich wunderschön.

Mit wxWidgets habe ich nie etwas größeres gemacht, deshalb sage ich dazu lieber nichts - aber Qt und gtkmm finde ich vom API Design her nicht so schön wie Swing, natürlich von der Performance her sind die Swing um längen voraus.

[nwp2]

Dravere schrieb:

nwp2 schrieb:

Die habe ich gefunden und viele Stunden versucht damit was zu machen. Er zwingt einem ständig GTK+ auf.

ROFL, das wird ja immer wie lächerlicher. Logisch wenn du mit GTK arbeitest, zwingt er dich zu GTK+, weil GTK+ ist GTK. Da gibt es keinen Unterschied. Man schreibt nur ungern immer noch das '+' hin, weshalb man oft einfach nur GTK schreibt.

Irgendwie dachte ich GTK+ wäre das C++-Binding von GTK der C-Bibliothek. Was ich damit eigentlich sagen wollte war, dass er seine C-Bibliotheken versteckt und ich das C++-Binding nicht will.

Ich habe jetzt allerdings einen Index aller C-Symbole für jedes der GTK-Teile gefunden. Damit kann ich arbeiten. Mal sehen was draus wird.

[mdmr]

Da fühlen sich einige gleich auf den Schlips getreten, bzw werden gleich Glaubenskriege losgetreten, weil ich sagte das ich MFC spitze finde.^^

Ich kann nur meine Meinung schreiben und würde mir nie herausnehmen den Stein der Weisen zu besitzen.

Was ich auch geschrieben hatte war, das man am besten schaut mit was man zurecht kommt, alles mal ausprobieren an kleinen Projekten und sich eine eigene Meinung bildet.

Nachdem ich hier im Forum viel über "altes MFC", "sollte man gar nicht mehr mit anfangen" und und und gelesen hatte , versuchte ich auch erst andere Toolsets.

Hab mich in QT ein Stück reingepfimelt, mit Doku besorgt ( in Buchform ). Auch WXWidgets hab ich probiert sowie noch andere.

Nachdem ich dann aber doch mal die MFC probiert hatte, war ich nur begeistert. Vom Umfang , Ribbon Design , Doku und und und.
MS SQL ist in QT um einiges komplexer als in MFC, schwierig in allen Toolsets ist es mit LDap Auth in MS AD Umgebungen am MS SQL zu Authen. MSSQL begegnet einem aber doch recht häufig.
Generell scheinen die meisten Toolsets eher auf Linux ausgelegt zu seien.

Ich kann mir auch nicht vorstellen das die Plattformunabhängigkeit nicht zu lasten der Performance geht, bzw in jedem Fall unnötiges mit sich schleppt.

Mir kommt die "Hetze" und die Empfehlung zu Alternativen eher vor wie Anti MS und Pro Linux. Was auch subjektiv seien kann.

Könnte allerdings auch seien das einige hier nicht den aktuellen Stand bei MFC kennen.

[Dravere]

mdmr schrieb:

Ich kann mir auch nicht vorstellen das die Plattformunabhängigkeit nicht zu lasten der Performance geht, bzw in jedem Fall unnötiges mit sich schleppt.

Nein. Sowas erledigt man mit bedingter Kompilierung. Also pseudomässig:

#if defined(WINDOWS)
// tue x
#elif defined(LINUX)
// tue y
#elif defined(MAC)
// tue z
#else
#error not supported
#endif

In das Kompilat kommt somit immer nur das, was auf der Plattforum vorhanden ist.

mdmr schrieb:

Mir kommt die "Hetze" und die Empfehlung zu Alternativen eher vor wie Anti MS und Pro Linux. Was auch subjektiv seien kann.

Tja, damit rennst du zumindest bei mir voll neben durch. Ich verwende aktiv Windows und habe eher so meine Probleme mit Linux. Ich bin auch mit verschiedenen MS Produkten sehr zufrieden. Aber die MFC gehört da nicht dazu.

Im übrigen hiess wxWidgets früher wxWindows und war nur auf der Windows-Plattform verfügbar

mdmr schrieb:

Könnte allerdings auch seien das einige hier nicht den aktuellen Stand bei MFC kennen.

Die Bibliothek hat sich zwar erweitert vom Funktionsumfang, ja, aber das Design ist immer noch schrecklich. Es ist ein uraltes C++ mit einer riesigen Masse an unnötiger und gefährlicher Makros. Auch ist das Design alles andere als sauber und schön aufgebaut. Zum Beispiel so Dinge wie MVC fehlen komplett. Obwohl man zum Beispiel ein CDocument und CView hätte, aber CDocument ist leider nicht das Modell, wie man es erwarten würde, sondern eher sowas wie der Controller, allerdings nicht wirklich gut und schön gelöst.
Auch das Fehlen von Namenräumen oder der Verwendung der Standardbibliothek sind Minuspunkte bei der MFC.
Am meisten hat mich mit der Zeit aber vor allem die WinAPI genervt. Du schreibst wie toll es ist, dass man MFC und WinAPI mischen kann. Sowas kann normalerweise jedes Framework. Bei der MFC ist das Schlimme, dass man darum oft nicht herumkommt, weil die MFC extrem schlecht kapselt und abstrahiert. Wie alt ist CProgressCtrl? Und erst im Jahr 2010 bekommt dieses Control ENDLICH die Funktion SetBarColor . Für diese simple Funktion musste man vorhin immer die WinAPI nehmen. Und das ist nur ein kleines Beispiel von vielen.

Man darf aber natürlich hier auch nicht einfach nur die Leute von der MFC anschwärzen. Die Bibliothek ist uralt! Sie entstand noch vor dem ersten C++ Standard. Es ist grundsätzlich daher ähnlich wie mit wxWidgets. Allerdings wäre es langsam an der Zeit, dass man eine Generalüberholung von diesen Bibliotheken macht. Der erste C++ Standard ist immerhin nun schon älter als 10 Jahre und der nächste steht vor der Tür.

Grüssli

[MFC rocks!]

asc schrieb:

ms fanboy schrieb:

Was findest Du so schlecht an den MFC? Ich finde sie sehr praktisch, nicht nur durch die Integration in VS. Man kann mit den MFC sehr einfach und schnell Windows-Programme entwickeln...

Genau das letztere geht mit vielen Alternativen deutlich besser (einfacher und schneller).

Das ist eine grundlose und unbewiesene Behauptung.

mdmr schrieb:

Generell scheinen die meisten Toolsets eher auf Linux ausgelegt zu seien.
Ich kann mir auch nicht vorstellen das die Plattformunabhängigkeit nicht zu lasten der Performance geht, bzw in jedem Fall unnötiges mit sich schleppt.

So ist es auch. Schau Dir z.B. Wireshark an. Man könnte meinen, es wäre ein Java-Programm, so träge ist die GUI (GTK). Träge GUIs sind unter Linux was ganz normales, aber unter Windows fällt sowas einfach negativ auf. Hätten sie die MFC statt GTK genommen, wäre Wireshark optisch eine Rakete, aber dann würde es nicht mehr unter Linux laufen.

mdmr schrieb:

Mir kommt die "Hetze" und die Empfehlung zu Alternativen eher vor wie Anti MS und Pro Linux.

Scheint mir auch fast so. Die Linux-Gemeinde hat den C++ Programmierern eingeredet, daß die MFC schlechter sind als andere C++ Frameworks (was definitiv falsch ist!) und sie glauben es.

[zwutz]

MFC rocks! schrieb:

[...] daß die MFC schlechter sind als andere C++ Frameworks (was definitiv falsch ist!) und sie glauben es.

Das ist eine grundlose und unbewiesene Behauptung.

MFC ist kein C++-Framework, sondern ein WinAPI-Wrapper, der irgendwo ein paar "class" statt "struct" stehen hat. Mit C++ hat das "Ding" aber nicht viel zu tun

[asc]

MFC rocks! schrieb:

asc schrieb:

ms fanboy schrieb:

Was findest Du so schlecht an den MFC? Ich finde sie sehr praktisch, nicht nur durch die Integration in VS. Man kann mit den MFC sehr einfach und schnell Windows-Programme entwickeln...

Genau das letztere geht mit vielen Alternativen deutlich besser (einfacher und schneller).

Das ist eine grundlose und unbewiesene Behauptung.

Auch wenn ich den C++ Builder und die VCL nicht mag: Schneller ans Ziel kommt man damit allemal (Und wenn man will, kommt man auch mit sehr wenig Code dabei aus). In der ersten Firma, in der ich war, wurde die MFC ausschließlich in einem sehr alten (und sehr lange gewarteten) Projekt verwendet, weil man mit dem C++ Builder Projekte um mindestens Faktor 2-3 schneller fertig stellen konnte, selbst wenn man nicht auf DB-Sensitive Komponenten zurückgegriffen hatte, und eine Mehrschichtenarchitektur verwendet hat.

Das Design der VCL mag ich zwar auch nicht, im Vergleich zu der MFC ist es mir aber wesentlich lieber. Zum einen, nimmt sie einen deutlich mehr Arbeitsaufwand ab, zum anderen kann der Designer mehr.

Wenn es nur um einfache und schnelle Entwicklung von Windowsprogrammen geht, würde ich aber ohnehin eher C# empfehlen.

[MFC rock!]

zwutz schrieb:

MFC ist kein C++-Framework, sondern ein WinAPI-Wrapper, der irgendwo ein paar "class" statt "struct" stehen hat.

Das stimmt nicht. Die MFC enthalten sehr wohl auch Klassen, welche zusätzliche Funktionalitäten anbieten, die die WinAPI nicht kennt.

zwutz schrieb:

Mit C++ hat das "Ding" aber nicht viel zu tun

Du hast scheinbar nicht viel Ahnung von C++, sonst würdest Du nicht solchen Unsinn schreiben.

asc schrieb:

Wenn es nur um einfache und schnelle Entwicklung von Windowsprogrammen geht, würde ich aber ohnehin eher C# empfehlen.

Wenn Dir langsame GUIs und Geschwindigkeit generell egal sind, kannst Du gern C# nehmen. Warum nicht gleich Java? Java ist ebenso eine schnarchlahme Geschichte, aber läuft zumindestens auf verschiedenen Plattformen.

Für mich ist jedenfalls dieser ganze interpretierte, langsame, speicher- und prozessorleistungfressende VirtuelleMaschinen-Krampf keine Alternative zum guten alten C++.

[rapso]

Shade Of Mine schrieb:

rapso schrieb:

ist das sarkasmus? Swing war der grund fuer mich meine schlechte meinung ueber MFC zu ueberdenken, spaetestens als ich sah wie die einzelnen bildelementes von swing einzeln aufgebaut wurden war das ding fuer mich gestorben.

Reden wir jetzt über Performance oder API Design?

useability und design der ganzen bibliothek dachte ich (also nicht nur api).
bestes api-design bringt ja nichts wenn das resultat am anderen ende nicht stimmt.
Und ich denke, dass es nicht an java oder VM oder ... liegt wie das resultat ist, sondern dass da beim design von zumindestens der "output"-stage etwas schief ging.

Weil von der Performance her ist Swing sicher eine der schlechtesten Lösungen, aber das API Design finde ich wunderschön.

Mit wxWidgets habe ich nie etwas größeres gemacht, deshalb sage ich dazu lieber nichts - aber Qt und gtkmm finde ich vom API Design her nicht so schön wie Swing, natürlich von der Performance her sind die Swing um längen voraus.

hm, rein vom API her fand ich das nicht so wirklich besser als andere gui libs. zumindestens als ich es damals ausprobiert habe musste man fuer viele dinge selbst klassen anlegen und ueberall mit SetSize Set.. aufrufen anpassen.
Das finde ich nicht wirklich besser als was WxWidget macht und das ist wie schon jemand schrieb aaaalt.
Wobei, wie gesagt, ewig ist es her, wurde das besser mit der zeit?

[mdmr]

Dravere schrieb:

Die Bibliothek hat sich zwar erweitert vom Funktionsumfang, ja, aber das Design ist immer noch schrecklich. Es ist ein uraltes C++ mit einer riesigen Masse an unnötiger und gefährlicher Makros. Auch ist das Design alles andere als sauber und schön aufgebaut. Zum Beispiel so Dinge wie MVC fehlen komplett.
Grüssli

Moin,

das Makros gefährlich seien sollen erinnert mich, an die Hetzte des C# Dozenten meines Bruders, über Nativ Code und ganz gefähliche Zeiger^^.

Mal abgesehen davon wird MVC auch von MFC umgesetzt. http://books.google.de/books?id=EBrj61SEZqQC&pg=PA34&lpg=PA34&dq=mvc+mfc&source=bl&ots=ti5hd-ylln&sig=WEojtiVsfva4FiLB_qKaM5JY19c&hl=de&ei=EyDQS9aOMZrsmwPauOEq&sa=X&oi=book_result&ct=result&resnum=1&ved=0CAUQ6AEwADgK#v=onepage&q=mvc%20mfc&f=false

Wie schon erwähnt kann ich da wenn ich solche Topics wie dieses ( und viele andere ) lese kann ich jedem nur empfehlen sich seine eigene Meinung zu bilden und zu probieren.

Sry aber umso weiter ich zu dem Thema Google, um so mehr treffe ich auf Begriffe wie Windof und co, Dinge werden behauptet die nicht stimmen : MFC kein C++ , grausammer Code, MVC wird nicht unterstützt, gefährliche Makros.......

Makros gehören nunmal nicht nur zum C++ , sonder in jede Gui Bibiothek und sind keine MFC eigenart.

Also das klingt für mich alles andere als sachlich, eher polistisierend.

Mal ein paar off Topic Dinge:
Ich fühle mich in der Linux sowie MS Welt zu hause, mit jeweiliger Certifizierung. Mit der Politisierung kann ich da nix anfangen , wichtig ist das die Kisten laufen wenn ich damit fertig bin.

Aber wenn ich da an einige Diskusionen die Sachlich begonnen haben denke , O Ton :" Linux braucht keinen Kerb Auth, Linux ist so sicher das du das in die DMZ stellen kannst" <- von einem gestandenem Admin.
Sowas muß mann sich ständig anhören, durch solch eine Kom wird einem ein eigentlich Sympatisches OS nur nervig gemacht.
Die wenigsten wissen das MS früher einer der größten UNIX entwickler war, Xenix aus dem über Umwegen System 5 entstanden ist. Noch viel mehr schlackern die anti MS pro Linux Leute mit den Ohren wenn mann ihnen Vi , Grep und Dif in der System 5 Korn Shell auf dem MS Server zeigt. Unglaublich , da gibts sogar UNIX FHS , X Client und Lib und und und . Nebenbei auch die IEE Posix Certifizierung wenn das UNIX Subsystem installiert ist.

Muß mich da mal rannsetzten und ein MS Server Spaßenhalber mit KDE zu betreiben

So ab zum Frühstückskaffee ^^

[zwutz]

MFC rock! schrieb:

zwutz schrieb:

Mit C++ hat das "Ding" aber nicht viel zu tun

Du hast scheinbar nicht viel Ahnung von C++, sonst würdest Du nicht solchen Unsinn schreiben.

ich weiß genug um zu merken, dass die MFC davon nicht viel enthält. Viele Konstrukte erinnern eher an ein "C mit Klassen" als an C++, als hätte die MFC ein C-Entwickler mit 2 Wochen C++-Crashkurs entworfen

ständig das rumgecaste mit GetDlgItem , weil Controls nicht wirklich als Objekt vorliegen und als Folge davon ständiges rumgehacke mit ddx-Makros, damit man überhaupt an die Daten eines Steuerelements kommt.
Und warum ihnen statt UpdateData(TRUE|FALSE) nichts intuitiveres eingefallen ist, ist mir immernoch schleierhaft

[asc]

MFC rock! schrieb:

asc schrieb:

Wenn es nur um einfache und schnelle Entwicklung von Windowsprogrammen geht, würde ich aber ohnehin eher C# empfehlen.

Wenn Dir langsame GUIs und Geschwindigkeit generell egal sind,...

Lies bitte was ich schreibe, und interpretiere nicht beliebigen Mist hinein. Ich habe von einer einfachen und schnellen Entwicklung gesprochen.

Ganz davon abgesehen das man sehr wohl auch mit Sprachen wie C# und Java performante Programme schreiben kann (Auch mit UI). Es mag zwar mit nativen Sprachen noch performanter gehen, meine Erfahrung ist aber: Performance liegt gar nicht so sehr auf die Sprache, sondern dem Design und dem Wissen der Programmierer.

Und ich kenne einige Projekte die in C++ geschrieben wurden, die locker von einer C# oder Java Entsprechung geschlagen werden könnten. Nicht weil C# schneller wäre (das ist zwar in bestimmten Bereichen möglich, auf eine Gesamtanwendung gerechnet aber eher Unsinn), sondern weil man in Sprachen wie C# und Java häufig das Design überschaulicher halten kann (Alleine schon weil vieles das in C++ mehrere Zeilen Code erfordert sich mit einem Aufruf erledigen lässt), und man dadurch auch eher die Probleme einer Anwendung entdeckt.

Um so leichter man den Code lesen kann, um so eher kann man Fehler und Probleme beseitigen. Und häufig stellt sich wartbarer Code als durchaus performanter in einer Gesamtanwendung heraus, als Code wo man auf biegen und brechen meinte alles performant zu halten, dabei den Code mit der Zeit aber immer unüberschaulicher bekommen hat, was im Endeffekt mehr Performance gekostet hat (So schon in realen Projekten erlebt). Und auch das Halbwissen einiger ewig gestriger hat schon sehr viel Performance gekostet ("die C++ Standardbibliothek ist langsam, verwende meine Containerklasse" => Durch einen passenden Container der STL ausgetauscht, und schon war die Programmstelle um Faktor 2 schneller).

MFC rock! schrieb:

Für mich ist jedenfalls dieser ganze interpretierte, langsame, speicher- und prozessorleistungfressende VirtuelleMaschinen-Krampf keine Alternative zum guten alten C++.

Weder Java noch C# sind heutzutage rein interpretierte Sprachen. Ich spreche jetzt für C#, da ich es besser kenne, aber ich weiß das es bei Java nicht viel anders ist: C# arbeitet mit einem Just-In-Time Compiler. Sprich: Code wird compiliert wenn er das erste mal aufgerufen wird, und liegt anschließend compiliert vor. Dieses Compilieren kostet natürlich Zeit, was sich aber relativiert, wenn der Code häufig aufgerufen wird.

Und im Gegensatz zu C++ wo man in der Regel für den kleinsten gemeinsamen Nenner compiliert (Sprich z.B. für Pentium) kann der JIT Optimierungen vornehmen die an der konkreten Plattform hängen. Daher ist es durchaus möglich, das Code - sofern er häufig genügend aufgerufen wird - durchaus unter C# schneller ist. Genauso kann ein GC durchaus auch positive Auswirkungen auf die performance haben - aber auch hier gilt: Es ist Fallabhängig (Nicht jeder Programmiert in C++, falls viele kleine Objekte auf dem Heap alloziert werden, einen passenden Mechanismus um die vielen new/delete Aufrufe zu reduzieren).

Man kann in jeder Sprache langsame und schnelle Programme schreiben. Genauso wie es langsame und schnelle Bibliotheken gibt.

[knivil]

Das sich alle immer hinter Jit-Compiler verstecken ... Und dann staendig im Konjunktiv reden. Nichts als Luftschloesser!

[asc]

mdmr schrieb:

das Makros gefährlich seien sollen erinnert mich, an die Hetzte des C# Dozenten meines Bruders, über Nativ Code und ganz gefähliche Zeiger^^.

Makros sind durchaus gefährlich, gerade wenn sie zu intensiv und ohne sinnvolle Namenskonventionen verwendet, oder als Funktionsersatz verwendet werden. Dazu kannst du dir gerne viele Fachbücher anschauen, oder google benutzen. Ich rate hierbei beispielsweise zur "Effectiv-C++" oder "Exceptional-C++" Bücherreihe, aber auch jedes etwas modernere C++ Buch (teilweise selbst in Einsteigerliteratur) gibt hierzu schöne Beispiele.

Besonders ärgerlich ist es wenn Funktionen von Makros überschrieben werden, weil es halt zufälligerweise ein Makro mit diesem Namen gibt. Auch ist es schön das Makros sich nur schlecht debuggen lassen, und Namensräume etc. unterwandern.

mdmr schrieb:

Wie schon erwähnt kann ich da wenn ich solche Topics wie dieses ( und viele andere ) lese kann ich jedem nur empfehlen sich seine eigene Meinung zu bilden und zu probieren.

Aber bitte auch mit mehr Argumenten als "MFC ist das beste das es gibt".

mdmr schrieb:

...um so mehr treffe ich auf Begriffe wie Windof und co, Dinge werden behauptet die nicht stimmen : MFC kein C++ , grausammer Code, MVC wird nicht unterstützt, gefährliche Makros...

1. MFC und Standard C++ sind inkompatibel (zumindest waren sie es noch im Visual Studio 2003 mussten bestimmte Einstellungen im Projekt gemacht sein - was in MFC-Projekten natürlich still schweigend voreingestellt wurde).

2. MFC ist an vielen Stellen typunsicher (Ich sage nur void*), was in der Praxis schon zu vielen Stunden Fehlersuche geführt hat.

mdmr schrieb:

Makros gehören nunmal nicht nur zum C++ , sonder in jede Gui Bibiothek und sind keine MFC eigenart.

Es gibt einige UI-Bibliotheken die Makros nur minimal einsetzen (Sei es für Includeguards, wo es keine Alternative gibt, oder um etwas Tipaufwand zu verringern), oder wenigstens Makros nur mit einer festen Notation (ZUM_BEISPIEL_NUR_GROSS) einsetzen. Davon abgesehen sind Makros zwar C++, aber nichts was vom Compiler interpretiert werden kann (sondern nur von einem vorgeschalteten Präprozessor), und wie schon erwähnt zu schwer debugbaren Problemen führen kann.

mdmr schrieb:

Also das klingt für mich alles andere als sachlich, eher polistisierend.

Also sind die C++ Gurus für dich allesamt unsachlich und polarisierend (Zu den C++ Gurus zähle ich Leute wie Stroustrup, Herb Sutter, Scott Meyers, Andrei Alexandrescu...).

Und das sich Programmiertechniken im Laufe der Zeit ändern, sollte jedem bekannt sein. Was vor 15 Jahren noch als gut empfunden wurde, ist heute in der Regel schon überholt.

Es ist natürlich einfacher, alle neueren Erkenntnisse als unsachlich zu bezeichnen, als selbst auf dem Laufenden zu bleiben. Ich werde niemanden von der MFC-Programmierung abhalten, aber sie ist weder modern, noch entspricht sie der modernen C++ Programmierung (wie übrigens auch viele andere Bibliotheken, die vor der C++ Standardisierung heraus gekommen sind).