welche programmiersprache für Programme benutzen?
-
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.
-
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
-
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.
-
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++.
-
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?
-
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üssliMoin,
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 ^^
-
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 stattUpdateData(TRUE|FALSE)
nichts intuitiveres eingefallen ist, ist mir immernoch schleierhaft
-
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.
-
Das sich alle immer hinter Jit-Compiler verstecken ... Und dann staendig im Konjunktiv reden. Nichts als Luftschloesser!
-
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).
-
asc schrieb:
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.
Sagt jemand, der sich oben noch über Inkompatibilitäten in VS2003 aufregt. Wir haben mittlerweile 2010. Ich meine sogar, dass es die meisten Inkompatibilitäten nur noch in VS 6 gab und danach gab es bloß noch einen Compilerswitch für die deprecated-Sachen, die in alten Projekten benutzt wurden.
-
Hallo
Wenn man eh nur Windows als Target hat, sollte man IMHO c# mit Forms oder gleich WPF verwenden. Geschwindigkeit ist doch eh kein wirkliches Problem.
chrische
-
rapso schrieb:
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.
Dann hast du die LayoutManager nicht wirklich verwendet. Denn die übernehmen das ganze Layouting und du setzt keine größen mehr sondern sagst nur welches Layout und wo was liegt, der Rest wird vom LayoutManager gemacht.
vermutlich hat wxWidgets sowas auch mittlerweile, aber gerade was dynamische Layouts betrifft ist sowas halt schon genial.
-
mdmr schrieb:
Die wenigsten wissen das MS früher einer der größten UNIX entwickler war, Xenix aus dem über Umwegen System 5 entstanden ist.
das ist ja interessant
bei wikipedia lese ich aber erstaunt, daß Xenix ursprünglich eine Portierung von System 7 mit einigen BSD-Erweiterungen war.
-
oops: ich meinte "Version 7", nicht "System 7"
-
Walli schrieb:
asc schrieb:
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.
Sagt jemand, der sich oben noch über Inkompatibilitäten in VS2003 aufregt.
Die letzte Version in der ich (wenn auch nur kurz) was mit der MFC machen musste. Logisch das ich nicht für neuere sprechen kann (Da ich nur die Express Versionen nutze, die kein MFC haben).
-
[url]
zum Beispiel schrieb:
mdmr schrieb:
Die wenigsten wissen das MS früher einer der größten UNIX entwickler war, Xenix aus dem über Umwegen System 5 entstanden ist.
das ist ja interessant
bei wikipedia lese ich aber erstaunt, daß Xenix ursprünglich eine Portierung von System 7 mit einigen BSD-Erweiterungen war.
Stimmt [/url]http://de.wikipedia.org/wiki/Xenix[url]
Was aber nix damit zu tun hat das aus MS Xenix laut Timeline System V entstanden ist.
Versionsübersicht [Bearbeiten]
Version Datum Beschreibung / Änderungen
MS Xenix 1980 Erstes Unix von Microsoft unter Lizenz von AT&TSCO XENIX 1983 Unterstützung für IBM XT
SCO XENIX System V 1984 Weiterentwicklung auf Basis von Unix System V
SCO XENIX 286 1985 Weiterentwicklung für Intel 80286
SCO XENIX 386 Release 2.2 1986 Portierung von Unix System V auf i386, damit ist XENIX System V/386 das erste 32-Bit-Betriebssystem für x86-Computer [1]
SCO XENIX 386 Release 2.3 1989 Verbesserte Hardwareunterstützung
SCO XENIX 386 Release 2.3.4 April 1991 Letzte veröffentlichte Version
-
mdmr schrieb:
Was aber nix damit zu tun hat das aus MS Xenix laut Timeline System V entstanden ist.
wo kann man das nachlesen ?
-
Laut wiki ist die C/C++/Java Sprachfamilie die einzige, in der man keine
Ko-Routinen verwenden kann. Es gibt deshalb einige Probleme, die mit diesen Sprachen prinzipiell unlösbar sind. Deshalb nimmt man lieber eine gescheite Sprache, mit der man prinzipiell jede Aufgabenstellung lösen kann, also z.B. Ruby. Man ist mit C/C++/Java total aufgeschmissen, wenn man mehrere User-Threads gleichzeitig (kooperativ) in einem Programm verwenden möchte. Einfach nicht möglich. Also lieber Ruby verwenden!
-
Korutine schrieb:
Es gibt deshalb einige Probleme, die mit diesen Sprachen prinzipiell unlösbar sind.
Welche wären das?