welche programmiersprache für Programme benutzen?
-
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?
-
Korutine schrieb:
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!Das es weiß Gott genug Thread-Bibliotheken für C++ gibt, angefangen bei WinAPI (auch für C) bis hin zu boost::thread, ist dir bewusst? Für Java gibts die mit Sicherheit auch.
Ganz davon abgesehen fällt mir jetzt auch kein Problem ein, dass man nur mit Threads lösen kann. Und trotzdem muss man sehr blind sein, um bei der Fülle an C/C++/Java-Anwendungen der Meinung zu sein, dass keine davon mit Threads arbeitet. Außerdem würde ich nur wegen der Tatsache, dass diese nicht im Sprachkern enthalten, sondern über Bibliotheken benutzt werden müssen, vorsichtig sein, C/C++/Java als keine "gescheiten" Sprachen zu bezeichnen.
-
Korutine schrieb:
...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...
hab mich sicher grad verschaut als ich mir das ding (ruby) mal runter geladen hab und mir die *.c dateien förmlich entgegengesprungen sind;)
lg lolo
-
ipsec schrieb:
Das es weiß Gott genug Thread-Bibliotheken für C++ gibt, angefangen bei WinAPI (auch für C) bis hin zu boost::thread, ist dir bewusst? Für Java gibts die mit Sicherheit auch.
Ganz davon abgesehen fällt mir jetzt auch kein Problem ein, dass man nur mit Threads lösen kann. Und trotzdem muss man sehr blind sein, um bei der Fülle an C/C++/Java-Anwendungen der Meinung zu sein, dass keine davon mit Threads arbeitet. Außerdem würde ich nur wegen der Tatsache, dass diese nicht im Sprachkern enthalten, sondern über Bibliotheken benutzt werden müssen, vorsichtig sein, C/C++/Java als keine "gescheiten" Sprachen zu bezeichnen.Wer gerne komplexe Scheduler bastelt, um einer unüberschaubaren Anzahl der unterschiedlichsten (simultan ablaufenden) Teilprozesse z.B. einer 3D-Szene mit 5 computergesteuerten und 3 spielergesteuerten Akteuren + GUI-Layer (auf drei verschiedenen Rechnern in jeweils unterschiedlichem Zustand) die notwendigen Scheibchen an Rechenzeit zuzuweisen, der kann auch mit C/C++/Java das Rad neu erfinden. Ist aber viel praktischer, wenn man den einzelnen Elementen einer solchen Szene 'ihre eigenen' Ruby-Skripts anhängen kann, und die Programmiersprache von sich aus dazu in der Lage ist, die entsprechenden Scheibchen Rechenzeit geeignet zu verteilen. Ohne dass man einen komplizierten Scheduler basteln müsste, bei dem man mit der dubiosen C/C++/Java-Syntax sowieso total den Überblick verliert.
Tja, aber weiß man, auf welchem Level manche Leute gerne programmieren?
Ko-Routinen sind das Um- und Auf. Also am besten: Ruby verwenden!
-
Korutine schrieb:
ipsec schrieb:
Das es weiß Gott genug Thread-Bibliotheken für C++ gibt, angefangen bei WinAPI (auch für C) bis hin zu boost::thread, ist dir bewusst? Für Java gibts die mit Sicherheit auch.
Ganz davon abgesehen fällt mir jetzt auch kein Problem ein, dass man nur mit Threads lösen kann. Und trotzdem muss man sehr blind sein, um bei der Fülle an C/C++/Java-Anwendungen der Meinung zu sein, dass keine davon mit Threads arbeitet. Außerdem würde ich nur wegen der Tatsache, dass diese nicht im Sprachkern enthalten, sondern über Bibliotheken benutzt werden müssen, vorsichtig sein, C/C++/Java als keine "gescheiten" Sprachen zu bezeichnen.Wer gerne komplexe Scheduler bastelt, um einer unüberschaubaren Anzahl der unterschiedlichsten (simultan ablaufenden) Teilprozesse z.B. einer 3D-Szene mit 5 computergesteuerten und 3 spielergesteuerten Akteuren + GUI-Layer (auf drei verschiedenen Rechnern in jeweils unterschiedlichem Zustand) die notwendigen Scheibchen an Rechenzeit zuzuweisen, der kann auch mit C/C++/Java das Rad neu erfinden. Ist aber viel praktischer, wenn man den einzelnen Elementen einer solchen Szene 'ihre eigenen' Ruby-Skripts anhängen kann, und die Programmiersprache von sich aus dazu in der Lage ist, die entsprechenden Scheibchen Rechenzeit geeignet zu verteilen. Ohne dass man einen komplizierten Scheduler basteln müsste, bei dem man mit der dubiosen C/C++/Java-Syntax sowieso total den Überblick verliert.
Tja, aber weiß man, auf welchem Level manche Leute gerne programmieren?
Ko-Routinen sind das Um- und Auf. Also am besten: Ruby verwenden!Was ist das Problem, solchen Szenen 'ihre eigenen' C++-Funktionen (in einem Thread) zu geben? Und was hat es mit Rad neu erfinden zu tun, wenn man eine Bibliothek benutzt? Die Verteilung der Rechenzeit überlasse ich übrigens am liebsten meinem OS
-
Korutine schrieb:
Ko-Routinen sind das Um- und Auf. Also am besten: Ruby verwenden!
Klar, weil's die ja nur in Ruby gibt.