Hi! Um mit meinen µCs auf eine elegante Art und Weise zu kommunizieren möchte ich nun auch in die Windowsprogrammierung einsteigen. Meien Vorhaben sind zunächstmal vergleichsweise einfach. Ich möchte ein bisschen mit graphischer Oberfläche Arbeiten und dann meine µCgeräte per RS232 oder USB steuern können. D.h. verschiedene Steueranwendungen wie z.b. Farbauswahl für RGB beleuchtungen, Lightshows usw.. Anwendungen die ich aus der Trayleiste über ein kleines Icon und Kontextmenü steuern kann (z.B. einfach so eine einblendende, fensterlose Fläche wo verschiedene Schieberegler drauf sind usw..). Verschiedene Grafikfunktionen sollten auch möglich sein um sowas wie ein Oszilloskopprogramm oder einen logic Analyzer realisieren zu können. Mehr möchte ich zunächst nicht machen, ich denke, dass ich niemals großartig über solche Steuerungsanwendungen hinauskommen werde. Die Grafische Oberfläche soll hübsch werden, jedoch reicht es, wenn ich nur standardmäßige Windowskomponenten benutze. Also keine Programme mit selbstentworfenem GUI, höchtens sowas wie eine Bildergallery um verschiedene Programmabläufe schnell auswählen zu können oder sowas, sollte drin sein. Ich bin inzwischen schon in die C-Programmierung eingestiegen, bei µCs und habe auch ein allgemeines C-Buch für PCs, ist ja kaum ein Unterschied. Empfehlt ihr mir, auf meiner vorhandenen Programmiererfahrung mit C aufzubauen oder soll ich für solche Zwecke lieber eine geeignetere Programmiersprache nehmen, mit besserer Programmierumgebung, die mir es ermöglicht, leichter und schnelle solche entsprechenden Programme zu entwickeln? lg PoWl
Für Einsteiger ist es recht schwer in C/C++ Programme mit Benutzeroberfläche zu erstellen (man denke da an MFC, Qt, GTK oder gar nur Win32 per Hand). Der C++ Builder von Borland ist ja auch fast ausgestorben, sonst aber schon ganz gut. Ich würde Dir daher Delphi oder C# empfehlen. Das "Umlernen" ist nicht sehr schwierig und es gibt gute Bücher. Und bevor jetzt die Leute kommen mit Qt ist einfach oder MFC ist einfach... aus Erfahrung kann ich sagen, für den durchschnittlichen Einsteiger ist es das definitiv nicht.
Wenns Windows ist, kann man C# empfehlen. Sehr an C angelehnt, schnelle Entwicklung, kostenlose, gute IDE. Und mittlerweile gibt's seit .NET 2.0 auch eine Komponente/Klasse, mit der man schön einfach und gekapselt auf die serielle Schnittstelle zugreifen kann. GUI's machen geht auch kaum noch leichter. Die IDE gibt's hier: http://www.microsoft.com/germany/Express/product/visualcsharpexpress.aspx Tutorials usw. sollte Google ausspucken, empfehlenswert sind hier Anlaufstellen wie codeproject.
Ich hab da im Moment keinen Überblick, was bedeutet "schwierig"? Schwierig zu verstehen, man muss vieles beachten und nachdenken, wie man programmiert. Oder einfach nur aufwändig da man für jede anklickbare Schaltfläche 5-10 Zeilen Code braucht? Am liebsten wär mir übrigens die Kommunikation via USB, damit ich nicht für jeden Mist einen Comport brauche. Bis ich aber in USBprogrammierung fit bin und auch den AVR damit zum kommunizieren gebracht habe, reichen ja USB -> RS232 converter. Man kann doch theoretisch zur automatischen Erkennung alle Comports durchscannen und gucken an welchem das entsprechende Gerät hängt indem man eine bestimmte Codesequenz sendet? lg PoWl
C ist dafür ungeeigned, die Lib ist auch sehr beschränkt. Die Investition eine passende Sprache zu lernen macht sich schnell bezahlbar. meistens ist es sowieso nur eine etwas andere syntax, ich würde dir zu python mit pyqt (+qtdesinger), mit python kanns du auch einfach guis mit tkinter machen. eclipse und java würden sich auch noch anbieten, es wird aber etwas länger dauern bis man damit produktiv ist c++ mit qt ist auch eine brauchbare kombination ich würde einen bogen machen um .NET (C++.NET, C# usw) machen, obwohl microsoft mit visual studio eine sehr gute (auch kostenlose) entwicklungs umgebung hat (ich glaube man kann das visual studio aber auch für normales c++ und qt nutzen)
Ich empfehle C++. Es stehen kostenlose IDEs/Compiler zur Verfügung und nach etwas Einarbeitungszeit hat man unbegrenzte Möglichkeiten. Im Gegensatz zu .NET kann man jederzeit auf einem anderen Rechnersystem programmieren (es gibt ja auch schon C++ für den AVR) und dank einiger Tools können Benutzeroberflächen mit C+ auch problemlos "zusammengeklickt" werden. Darüber hinaus erzeugt der C++ Compiler echten Maschinencode der Unabhängig von Interpretern (wie bei Java oder .Net) ausgeführt werden kann.
Also ich muss sagen, es wäre schon nicht schlecht wenn ich in der Entwicklungsumgebung mein GUI designen könnte ohne alles per Hand zu programmieren. Mit Delphi habe ich die schlechte Erfahrung gemacht, dass ich hinterher keine Ahnung.. 10 Dateien hatte und überhaupt keinen Überblick hatte wo nun was drin stehen soll, keinen Code gesehen der die Erstellung dieser Fenster darstellt. Ist das bei C/C#/C++ auch so schlimm? Im Moment fällt mein Augenmerk auf diese drei Programmiersprachen. Auf das NET Framework wollte ich allerdings möglichst auch verzichten. C oder C++, ihr werdet mir wohl zu C++ raten. Gibts dafür Entwicklungsumgebungen die das Designen für GUIs unterstützen? lg PoWl
Wenn du C++ lernen willst, schau dir QT (http://www.trolltech.com/) an. Gibts unter der GPL, Graphischer Oberflächen-Designer ist dabei, und man kann mit sehr wenig Code viel erreichen. Und als (für dich vielleicht nicht so interresanter) Bonus kannst du denselben Quelltext auch gleich für MacOS und Linux verwenden. Allerdings braucht man da schon solide C++ - Kentnisse, da gehts gleich mit Mehrfachvererbung, Templates usw. zur Sache.
Wenn du Ahnung von objektorientierter Programmierung in C++ hast kann ich nur qt empfehlen. Da brauchste auch für ein par slider keinen gui builder (obwohl es den auch gibt) denn so ein Programm ist vll. mal 20 zeilen lang. EDIT: Ich lese gerade kein C++. Wenns dich interessiert lern es aber BEVOR du dich an qt setzt alles andere frustet nur.
Keine Ahnung was ihr macht .. aber ich lerne Haskell :)
Martin wrote:
> Keine Ahnung was ihr macht .. aber ich lerne Haskell :)
Aber sicher nicht für die GUI-Windows-Programmierung :D
in den .net Zeug gibt es noch C++/CLI. Das ist deutlich näher an C/C++ es ist leichter damit C bibleotheken einzubinden. Und es gibt eine kostenlose Visual-Studio version. Hab gelesen das du einen Bogen um das .net Zeug machen wolltest. war nur als Ergänzung gedacht.
Also ich würde dir raten, dass du dir erst einmal Code::Blocks holst (kostenlose IDE + GNU C++ Compiler) (www.codeblocks.org) und dann arbeitest du dich erst einmal durch das Buch C++ in 21 Tagen (http://www.informit.de/books/c++21/data/start.htm). Danach solltest du die Grundlagen von C++ und OOP drauf und kannst dich dann mit der GUI Programmierung beschäftigen... Ja nach GUI Paket ist dann eventuell eine andere IDE besser geeignet ( Visual Studio bietet sich halt bei einer MS GUI an, Code::Blocks unterstützt recht gut wxWidgets oder eben was anderes, je nachdem, was dir dann lieber ist). Viel Erfolg!
Ich würde (werde demnächst) mit dem Erlernen einer weiteren Programmiersprache anfangen. Und zwar eine Skriptsprache (interpretierte Sprache), auf die man einfach ein halbwegs passable Grafikoberfläche aufsetzen kann. Ich sehe den Vorteil einer Skriptsprache darin, dass man quasi interaktiv sein Programm entwickeln kann. die Performanceeinbußen gegenüber kompilierten Sprachen ist IMHO bei einfachen Steuerprogrammen und/oder den modernen PCs erträglich. http://de.wikipedia.org/wiki/Liste_von_Hallo-Welt-Programmen gibt eine nette Übersicht, was nötig ist, um ein einfaches "hello world" auf den Bildschirm zu bringen. Da gibt es je nach Sprache mehr oder weniger komplexe Quellcodes. Schick finde ich Python oder Ruby oder BASIC oder Tcl oder Lua oder Javascript oder Perl oder PHP oder R oder REXX oder ... Welche genau, würde (werde) ich davon abhängig machen, ob sie auf mehreren Plattformen läuft und ob es Grafikanbindungen gibt. Im Moment bin ich Python am ehesten zugeneigt. Ein Buch dazu kommt in den Urlaubskoffer ;-)
Stefan "stefb" B. wrote: > Welche genau, würde (werde) ich davon abhängig machen, ob sie auf > mehreren Plattformen läuft und ob es Grafikanbindungen gibt. Im Moment > bin ich Python am ehesten zugeneigt. Ein Buch dazu kommt in den > Urlaubskoffer ;-) Dann schau dir mal PyQT (besser gleich PyQT4) an. z.B. hier ein Tutorial: http://zetcode.com/tutorials/pyqt4/
www.wxwidgets.org. Das ist das einfachst und umfangreichste, was ich kenne. Was ich gerade bei CodeBlocks gesehen habe : "The GCC toolchain for the Texas Instruments MSP430 MCUs" Hat das jemand im Gebrauch ?
Python + GUI, kann ich mir immer besser vorstellen. Welche GUI ist nebensächlich, denn es gibt Wrapper für die gängigsten z.B. Twilight GUI (http://students.ceid.upatras.gr/~sxanth/twgui/) als "SuperWrapper" für PyGTK (GTK), PyQT (QT), wxPython (wxWidgets) und Tkinter (Tcl/Tk)
Dir wird hier nun jeder etwas anderes erzählen :-) Mein Tipp: Nimm erst einmal eines von den genannten Sachen und arbeite dich da hinein. Nach einiger Zeit wirst du schon merken ob du damit gut klar kommst oder nicht. Ich z.B. habe (musste) mit MFC angefangen (anfangen), bin aber mittlerweile bei wxWidgets & C++ (für GUI) gelandet, bzw. C# wenns mal ganz quick and dirty gehen muss. C++ benutze ich auch mal gerne für kleine Konsolenprogrämmchen. Als GUI benutze ich für alle 3 Sachen Visual Studio Express von Microsoft. PS: Aber in einem werden mir wohl alle zustimmen: MFC ist einfach nur alt. Zumindest mit der Version, mit der ich gearbeitet habe (Ich habe gehört es gibt da wohl schon aktuelle Versionen wieder, mitgeliefert beim Visual Studio Professional oder so). Und mit Hinblick darauf, dass Qt oder wxWidgets und wie sie alle heißen open-source sind, sind diese eindeutig mehr zu empfehlen als MFC.
Falls Du evtl. auch im Berufsleben mal in der Softwareentwicklung arbeiten möchtest, würde ich auf jeden Fall etwas nehmen, das verbreitet ist. Z.B. Visual Studio. Die Programmiersprache ist dabei weniger entscheidend, aber ich denke C# oder Visual Basic wären sicher nicht schlecht. Selber verwende ich Privat das kostenlose Visual Studio .NET C# Express Edition. Da ist alles dabei was man so braucht und kommt schnell zum Ziel. Die Syntax von C# ist zudem sehr ähnlich wie C, so kann man auch gut mal in sich geschlossene C Codeblöcke vom Microcontroller in ein C# Projekt kopieren um sie dort elegant testen und debuggen zu können.
XPROFAN http://www.profan.de wäre auch eine Überlegung wert. Einfache, leistungstarke Befehle, keine speziellen Windows-Kenntnisse nötig, keine Objektorientierung und Recourcenverwaltung erforderlich. Benutze diese Software auch zur µC Kommunikation. Bis Version 6.6 kostenlos.
Ganz persönliche Erfahrung: Spring ins kalte Wasser und versuchs einfach mal mit nacktem C -- ohne Windoof, ohne Fenster und ohne Klickibunti. Das was dich bei Delphi verwirrt hat, wird dich auch bei Borland-C++-Builder verwirren, der arbeitet identisch. Schreib erstmal Programme für die Konsole, das ist einfach und du lernst, wodraufs ankommt (nämlich nicht auf bunte Klickerei, sondern auf praktikable Funktion). Hast du dich dann mal mit der Standardbibliothek, Dateien und all so nem Zeugs vertraut gemacht, stehen dir alle Wege offen. Natürlich kannst du dir jeden Knopf von Hand programmieren, kein Ding. Aber du kannst auch einen "Designer" benutzen. Wie in Delphi oder QT. Da malst du dir deine Fenster quasi mit Drag'n'Drop und der Designer erstellt dir dann (je nach dem) den passenden Quelltext (QT) oder eine spezielle Resourcendatei (Delphi, BC++B) oder sowas und du füllst das nur noch mit deinen Funktionen auf. Und ganz ehrlich: Boote mit Linux (Knoppix) und fang damit an. Im Gegensatz zu Windows brauchts da so gut wie keine Spezialfunktionen, um z.B. auf Schnittstellen (seriell, Drucker...) zuzugreifen. C ist puristisch, dadran wirste bestimmt Gefallen finden. Und wie gesagt: hastus mal gerafft, ists auch egal ob du nu "{ ... }" schreibst oder "begin ... end". Viel Spaß und viel Erfolg ;-)
Matthias wrote:
> keine Objektorientierung [...] erforderlich.
Und ich dachte immer Objektorientierung wäre ein Konzept, was dem
Programmier entgegenkommt ;)
> ...Und ich dachte immer Objektorientierung wäre ein Konzept, was dem > Programmier entgegenkommt ;)... Ist auch so. Wenn man verstanden hat, um was es dabei geht... ;-) Markus
Kurz und bündig kann ich empfehlen: -Delphi (müsste es auch eine freie Personal- oder Expressversion geben) -Visual Studio 2008 (Express) -wxwidgets am besten zusammen mit Bloodshed DevC++ >Mit Delphi habe ich die schlechte Erfahrung gemacht, dass ich hinterher >keine Ahnung.. 10 Dateien hatte und überhaupt keinen Überblick hatte wo >nun was drin stehen soll, keinen Code gesehen der die Erstellung dieser >Fenster darstellt. Ist das bei C/C#/C++ auch so schlimm? Hm, drück mal F12, dann siehst du Deine Fensterklasse. Wenn du wissen willst wie ein Fenster (also z.B: die Form-Klasse) intern aussieht, öffne einfach die Unit Forms.pas. In welcher Datei was drinstehen soll kann Dir eigentlich erstmal egal sein, dafür hast du die IDE, im Gegensatz zu nackten Toolchains, wo man sich um jeden Furz selber kümmern muss (bevor das jetzt wieder so ein beleidigter Korintenkacker in den falschen Hals bekommt: Ich arbeite auch genauso oft und gerne mit solchen Toolschains, hat aber miteinander einfach nichts zu tun). Delphi ist ein RAD (rapid application development) System. Das Konzept geht davon aus dass Dir zunächst mal kackegal ist, wie die internen Klassen die Windows-API überreden ein Fenster auf den Schirm zu pinseln, vielmehr willst du möglichst schnell Deine Aufgabe (z.B. "Hallo Welt" in einer Messagebox ausgeben) bewerkstelligen.
Objektorientierung war vor einigen Jahren das Lieblingsthema der Akademiker. Wie die Praxis gezeigt hat ist das zwar ganz nett und erleichtert viele Sachen, aber es ist keine eierlegende Wollmilchsau, und fehlenden Grips/Erfahrung beim Programmierer kann's auch nicht wettmachen. C ist zum Einstieg sicherlich schwieriger als Java oder das ganze andere Geraffel, und wenn man nur ein bisschen nebenher programmieren will gibt es sicher besseres (zB. die ganzen Skriptsprachen, oder von miraus auch Java). Wenn man aber wirklich richtig programmieren will ist C/C++ nach wie vor die beste Lösung. Sieht man auch daran, dass die meisten Programme in C++ geschrieben werden. @Threadersteller Deine Probleme haben aber nix mit Delphi als Sprache zu tun, sondern mit der IDE von Borland. Die macht viel und zeigt dir davon garnix. Fang mit C auf der Konsole an, oder mit Java auf der Konsole.
Eine GUI Anwendung macht doch für den Einstieg viel mehr Spass als eine Konsolenanwendung. Und mit Visual Studio oder Delphi kommt man sehr schnell zu was lauffähigem. Mit genügend Motivation kommt dann der Rest von alleine...
> Mit genügend Motivation kommt dann der Rest von alleine...
Oder auch nicht, und er macht irgendwelche Sachen ohne zu verstehen
wieso das funktioniert. Das ist zwar ganz nett wenn man mal was sehen
will, aber wenn man später wirklich selber neue Sachen machen will,
nutzt es garnix.
Also ich kann Dir auch nur C/C++ empfehlen, alternativ noch Java oder dann als Nachfolger von beiden die Programmiersprache D. Java hat halt den Vorteil, dass es Plattformunabhängig ist aber auch den Nachteil, dass immer ein Interpreter benötigt wird.
tom wrote: > Java hat halt > den Vorteil, dass es Plattformunabhängig ist aber auch den Nachteil, > dass immer ein Interpreter benötigt wird. Naja, da gibt es z.B. den "GCJ", Gnu Java Compiler. Der propft ein Java-Frontend auf das normale GCC-Backend auf, d.H. übersetzt Java-Sourcecode (Mit Einschränkungen, IIRC geht Swing nicht) direkt in nativen Maschinencode, der dann ohne JRE läuft. Hat halt dann den Nachteil, dass es nicht mehr Platformunabhängig ist, und den Vorteil dass kein Interpreter/VM mehr gebraucht wird...
Mit Java wollte ich jetzt nicht unbedingt anfangen. Um die Serielle Schnittstelle zu nutzen muss ich sowieso Plattformabhängig programmieren. Windoof XP wird ja noch eine Weile durchhalten. Die Programme sind vorerst sowieso nur mal für mich. Ehrlich gesagt ist es wirklich Tatsache, dass ich recht wenig Freizeit hab (zum Programmieren) und eher eine Sprache erlenen möchte, mit der ich schnell zu einem Ansehlichen Ergebnis komme. Schön wäre es, wenn mir diese Sprache es trotzdem ermöglichen könnte, gescheite Programme damit zu schreiben die auch schnell laufen (also keine Scripts?). Ich muss übrigens sagen dass mir die C-Syntax recht gut gefällt. lg PoWl
Ja wie gesagt, da du eh aus der C Welt kommst ist der Umstieg auf C++ nicht mehr schwer. Klar es steckt eben ein anderes Denken dahinter, aber dich zwingt ja keiner OO zu programmieren. Im Grunde ist nahezu jedes C Programm auch ein gültiges C++ Programm. Daher kannst du mit deiner C Erfahrung sehr schnell in C++ einsteigen und dann Stück für Stück das obejektorientierte Design kennen und schätzen lernen. Ich finde das Buch C++ in 21 Tagen eben ganz gut für Umsteiger, da hier völlig losgelöst von irgendwelchen Bibliotheken das Wesen von C++ vermittelt wird. Viele Kapitel wirst du mit deinen Kenntnissen dann leicht überspringen können und dich eben auf die OOP konzentrieren können. Sobald du dann problemlos Klassen anlegen, vererben und Operatoren überladen kannst, dann guckst du weiter hinten im Buch nach Template und der Einführung in die STL und mit ein paar HowTos aus dem Netz hast du auch ganz schnell deine erste Benutzeroberfläche realisiert. Ich glaube wenn man schon gut C kann, dann ist der Umstieg auf C++ sehr leicht. Man muss ja keine neue Sprache erlernen sondern nur eine neue Denkweise. Die paar syntaktischen Neuerungen hat man auch schnell verinnerlicht.
ja, nunja was heißt "gut C". Ich programmiere damit mittlerweile relativ erfolgreich µCs, hab das Prinzip von Structs, Zeigern,.. usw. ganz passabel verstanden (an der Umsetzung haperts vll teilweise noch etwas). Viel am PC mit C programmieren konnte ich nicht, da ich mir angenehmeres Vorstellen kann als Warenverwaltungsprogramme vor mich hinzutexten, die so gut wie nix machen können. Das bringt zwar routine und übung, aber da lern ich lieber noch etwas dazu und probiere dann ein wenig rum. Dabei kommt dann auch ein Programm raus, das die ersten Hebel in Bewegung setzen und mehr als nur Text ausgeben kann :-)
War schon klar, dass da jetzt viele mit Ihrer "Lieblings-"Sprache / Entwicklungsumgebung kommen. Darum gehts aber nicht , sondern um was Einsteiger-freundliches . Und das ist, ich kanns nur wiederholen, MFC, Qt, Win32 nativ, wxWidgets nicht. Ich persönlich mag Qt auch sehr und genauso MFC. Hab aber genauso viele Einsteiger mit halbwegs-guten C-Kenntnissen an Qt-Vererbung und MFC-Klassen-Müll verzweifeln sehen. Und da das hier ein Hobby ist, dh Spass machen soll, bietet sich ein zusammen-klick GUI-Ersteller an. Wenns ein bischen wie C sein soll, nimm C#, auch wenns nicht GPL ist oder Delphi, auch wenns viele Sachen zunächst vor dem Programmierer verbirgt. Macht aber trotzdem/gerade deswegen mehr Spass für den Einstieg.
Ganz interessant können Simulationen von irgendwelchen Sachen sein. Bei der heute üblichen Rechenpower kann man viele Probleme ganz banal umsetzen, und es kommt trotzdem in brauchbarer Zeit ein gutes Ergebnis raus. Zb. Spielereien mit neuronalen Netzen, Wärmeausbreitung in irgendwelchen Sachen simulieren, der eintausendunderste Sonnensystemsimulator, der jede einzelne Sekunde simuliert (ok, da braucht's schon etwas Grips, aber jede Minute ist gut machbar), Fraktale, (um mal auf das Thema Elektronik zurückzukommen) nichtideales Verhalten von C und L, und lauter solche Sachen. Übrigens läuft nicht jedes C Programm durch einen C++ Compiler. Zum einen gibt's oft Probleme bei Zeigern ("int* a=malloc(sizeof(int)*1234);" funktioniert unter C++ so NICHT), und zum anderen kennt C seit ISOC99 Sachen, die C++ nicht kennt (zB. "int a[variable];"); ähm .
In Delphi hab ich mal reingeschnuppert, aber da.. nunja, bitte nicht schlagen, da gefällt mir die Syntax einfach nicht :-D Notfalls lass ich aber gerne mit mir Verhandeln. Ich bin denke ich nicht in der Position große Ansprüche zu stellen. Aber C# werde ich mir mal anschauen.
@Stefan python ist eine weise Entscheidung nach Jahren von C++ staunt man wie einfach sich manche Dinge auch schreiben lassen. Besonders stringmanipulationen, re, listen, maps herausfiltern aus listen und und und. Das liest sich alles wie pseudocode vom feinsten. Ich lerne Haskell im Moment weil ich mich mit Rekusion(beweisen) an sich beschäftige, currying verstehen will und einfach meine Denkweise etwas erweitern will. grüsse
Hi Ich bevorzuge Delphi. Eine gestandene Entwicklungsumgebung. Nichts für Leute, die mehr auf 'Modesprachen' fliegen. Und wird mit Sicherheit eine ganze Reihe der 'Eintagsfliegen'-Programmiersprachen überleben. MfG Spess
Ich mag ganz normales c. Das hat aber sicher damit zu tun, daß ich keine ganz riesigen Softwareprojekte mache, sondern immer mal ne Insellösung. Der Resourceneditor vom develop studio reicht mir da für normale guis. Vorteil von c mit win32 ist für mich - ich kann die Sprache, die win32 lernt man immer besser kennen und so habe ich die Möglichkeit den einen oder anderen Algorithmus schon mal in c auszuprogrammieren. Dazu kommt daß ich c++ nicht so wirklich gut kann (den oop Aspekt, der sich dann natürlich durch quasi alle Sprachen zieht und jede objektorienterte Sprache mehr Mittel zum Zweck werden lässt. Bei wirklich schwerer Windows Kost und größeren Projekten ist c aber sicher tot.
Ich hab auch ein wenig das Gefühl, dass jeder seine Lieblingssprache hat und sie mir natürlich auch empfehlen möchte. Die einen sagen, es wäre sinnvoll gleich mit größeren Geschützen anzufahren, die anderen sagen, ich soll erstmal eine einfacherere Sprache nehmen um schneller ans Ziel zu kommen. Ich denke C++ wäre für die Anwendung Overkill. C#, Delphi scheinen ja praktisch das gleiche zu sein. Brauchen die noch einen Interpreter oder sind die Programme überall lauffähig? Sich das GUI fürs Programm in der Entwicklungsumgebung zusammenzuklicken und dann mit Funktionen zu bestücken find ich ganz gut. Sieht zu mindest nach schnellem Erfolg aus. Welche Programmiersprachen eignen sich für sowas? lg PoWl
GUI zusammenklicken hat nix mit der Programmiersprache zu tun. Mit Glade oder QTDesigner bekommst du sowas auch für C++ und GTK bzw. Qt, und eigentlich gibt es da für jede halbwegs sinnvolle Sprache was.
OK in diesem Falle hole ich mir jetzt einfach gerne noch ein paar Meinungen ein und entscheide mich dann endlich für etwas: Ist es besser in C++ einzusteigen? Oder eher C#, Delphi zu nehmen? Nochmal meine Anwendungsgebiete: - Steuer- und Regelanwendungen (d.h. der Umgang mit Dateien und generell mit Strings soll nicht allzu schwierig sein (ich denke da an C, bei dem es gar keine echten "Strings" gibt, oder ist das wo anders auch so?)) - Verschiedene Formen von Fenstern - Tray-Icon Progrämmchen - Kommunikation mit der seriellen Schnittstelle - diverse Grafikfunktionen (Oszilloskop, Logicanalyzer, multifunktionelle Bildergallery) lg PoWl
Wenn du eh unter Windows bleiben willst, kann ich C# mit .NET empfehlen. Erleichtert im Vergleich zu C++ mit MFC vieles wesentlich. Serielle Schnittstelle ist gleich dabei, die grafischen Oberflächen sind nett und lassen sich zur Laufzeit total einfach anpassen usw. Oszi und Logic-Analyser sind schon recht aufwendige Sachen. Da gibts aber PlotLab. Tray-Icon geht eigentlich immer...egal ob C++ oder C#
Nun wie gesagt. Alle drei Sprachen erfüllen Deine Anforderungen. Aber bedanke, dass zumindest bei C# und C++ der Syntax deinem bekannten C schon recht ähnlich ist. Delphi hingegen baut auf Pascal auf, also andere Syntax, andere Befehle als C => mehr lernen. Aber grundsätzlich ist Delphi schon ne ganz nette Sprache. C# ist eben eine reine Microsoft Geschichte und soweit ich weiß vollständig an .net gebunden. Daher muss wohl im Hintergrund ein Interpreter laufen. Ich persönlich lehne solch ein Konzept bei einer Programmiersprache grundsätzlich ab. Ein weitere Nachteil ist halt, dass du damit auch nur auf Microsoft Betriebssystemen programmieren kannst. Ich glaube auch nicht, dass der Einstieg schneller ist als bei C++, denn in beiden Fällen musst du erst einmal Umdenken können (bei Delphi halt auch). C ist eine prozeduale Programmiersprache, Delphi, C++, C# sind eben objektorientiert. Man kann sicher darin programmieren ohne dieses Konzept verstanden zu haben, aber ob man dann weit kommt? Daher: Egal für welche Sprache du dich entscheidest. Auch für ein bloßes Hobby sollte man genügend Zeit aufbringen das Konzept dahinter zu verstehen. Also noch einmal klein anfangen ohne bunte Fenster, sondern nur auf der Kommandozeile. Lerne das objektorientierte Konzept und der Einstieg in die verschiedenen Bibliotheken für GUIs wird dann mit Sicherheit schneller gehen und mehr Spaß machen, weil du dann eben auch verstanden hast, was sich hinter einem Befehl, einem Operator oder einer Klasse so alles verbirgt. Diese Hürde musst du bei allen drei Programmiersprachen nehmen um damit was ordentliches auf die Beine zu stellen, der Unterschied ist nur, dass es dir die eine Programmiersprache eben etwas leichter macht ohne solch ein Hintergrundwissen ein Fenster anzuzeigen und Buttons zu definieren. Des ist wie mit C für µCs: Man kann sicher problemlso für µCs ein paar Programme zusammenschreiben ohne sich mit der Architektur der Controller auszukennen. Kennt man diese, dann geht aber vieles viel leichter und man erspart sich ne Menge arbeit, Zeit und Nerven um Fehler zu suchen oder Lösungevorschläge zu ergooglen.
Hi Da ich mich eh schon als Delphi-Fan geoutet habe kann ich auch weitermachen. Delphi ist das Produkt einer jahrzehntelanger Entwicklung (Turbo Pascal(Dos) -Turbo Pascal für Windows-Delphi). Auch wenn der Syntax manchen etwas komisch vorkommt (Pascal) ist er eigentlich weniger kryptisch als C... Die freie Version von Turbo Delphi beinhaltet eine ausgereifte IDE, ein komfortables GUI, Komponenten für Datenbank- Net-,Internet-, ActiveX-Unterstützung und ... Für mich persönlich mehr als ich brauche. MfG Spess
Ich habe es zwar selber nicht getestet, aber C#-Programme sollen auch unter Linux lauffähig sein. Stichwort "Mono". Dabei ist aber wohl nicht gewährleistet dass alle neuesten .Net Funktionen kurzfristig in Mono umgesetzt werden. Ich habe die letzten Tage das erste mal (zwangsweise) etwas mit Visual Studio 2005 in C# programmiert. Der IDE ist wirklich Klasse, und das MSDN lässt eigentlich selten Fragen unbeantwortet. Die Sprache an sich ist eigentlich auch nicht verkehrt, aber wenn man in C++ viel mit Zeigern gearbeitet hat muss die alten Vorgehensweisen doch etwas umstellen. An die automatische Speicherverwaltung muss man sich auch erst gewöhnen. In C++ habe ich viele Sachen im Destruktor einer Klasse erledigt, der bei C# aber nicht aufgerufen wird (erst wenn der GC das Objekt wirklich löscht).
OO ist ein netter Zusatz, aber keine grundlegend neue Programmierphilosophie. Verstanden haben sollte man es früher oder später aber schon. @powl Wenn du nur mal ein kleines bisschen Zeugs zusammenprogrammieren willst, ist C++ sicher nicht die beste Wahl. Da würde ich an deiner Stelle eher zu Java gehen, keinesfalls C#. Je mehr Leute diesen Mist benutzen, desto länger müssen wird damit leben. Für Java gibt es auch nette IDEs wie zB. Eclipse, es ist etabliert und unter praktisch allen OS lauffähig. Das JRE ist etwas nervig, aber was entsprechendes hast du unter .net auch. Und GUI in Java ist auch kein Problem. Wenn du später mal richtig mit Programmieren anfangen willst, führt eigentlich (früher oder später) kein Weg an C++ vorbei. C++ ist viel mächtiger als Java, und viel mächtiger als C# (mal abgesehen davon, dass es in den richtigen Händen auch deutlich schneller ist). Allerdings ist die Sprache schon deutlich komplizierter, und wahrscheinlich haben Anfänger gerade desswegen Probleme mit C++, weil es dir keinen Weg aufzwingt (mal abgesehen davon, dass es auch einiges an Disziplin verlangt, weil es auch Sachen erlaubt die unsauber sein können). Java, C# usw. lassen dir bei der Implementierung dagegen recht wenig Spielraum. Und auch wenn du ein paar Jahre C++ programmiert hast, wirst du bei weitem nicht die ganze Sprache können. Es ist eine Sache ein Programm irgendwie in C++ realisieren zu können, eine andere ist es ein Programm wirklich schön und elegant in C++ realisieren zu können, unter Ausnutzung aller sinnvollen Sprachmittel. Um seinen Horizont zu erweitern ist C++ in jedem Fall deutlich besser als Java oder c#.
Das Optimum scheint es für mich leider wirklich nicht zu geben. C# sieht verlockend aus, aber davon wird mir teilweise mehrfach abgeraten. Die Syntax von Delphi gefällt mir leider überhaupt nicht. C scheint nicht gerade komfortabel für Windowsprogrammierung und C++ scheint zu kompliziert für mein Vorhaben zu sein. Java braucht ebenso einen Interpreter und die Vorteile der Platformunabhängigkeit mache ich mir damit zunichte, dass ich die Windowsoberfläche nutzen möchte. Sicher bring ich euch mit meiner Unschlüssigkeit hier zum verzweifeln aber ich komm grad wirklich nicht zu einem Entschluss, alles hat seine Vor- und Nachteile. lg PoWl
> C# sieht verlockend aus, aber davon wird mir teilweise mehrfach abgeraten.
Also, ich verwende mittlerweile C# und bin sehr zufrieden damit.
Oberfläche ist schnell erstellt, gute Foren gibts auch (wie für alle
Sprachen), IDE ist gut, und es macht richtig Spass.
Ich find es halt gut, weil ich meine µC-Programme in C schreibe, also
nicht viel umdenken. Wenn man das generelle Vorgehen in C# mal
verstanden hat, läufts echt super. Sicher gibts am Anfang wie bei jeder
Sprache auch mal Stolperstellen, aber jeder beginnt so :)
Ich habe einige Behauptungen gelesen, dass bei C# ein Interpreter im
Hintergrund läuft, dass ist soweit ich weiss nicht ganz richtig. Zwar
ist die MSIL (Microsoft Intermediate Language) tatsächlich eine
Zwischensprache, aber das Programm wird nur einmal in Maschinencode
übersetzt. Zu .NET ist zu sagen, dass aufgrund der MSIL erstmal eine
einheitliche Struktur in den Datentypen usw. ALLER .NET-Sprachen gegeben
ist, d.h. ein INT in VB ist genauso groß wie in C#. Solche Sachen
empfinde ich halt als einen Vorteil, zumal es viele weiteren Sachen
gibt, die aufgrund dieser Kompatiblität der .NET-Sprachen einfach besser
flutschen.
Also kurz gesagt: Ich kann C# empfehlen.
Ralf
Ich denke ich werde mich wohl nun auch mal mit C# befassen. Scheint ja wirklich vielversprechend. Wenn ich ein Programm in C# schreibe, ist es so ohne weiteres auf anderen Windowsrechnern lauffähig oder müssen die sich dann erst das .NET runtime environment framework bla blub runterladen? lg PoWl
Im jetzigen Moment ist es eine weise Entscheidung, C# mit .NET für Dein Vorhaben zu nehmen, zumal Du bereits C Kenntnisse hast. Das .NET Framework ist normalerweise (ab windows XP) bereits auf dem PC installiert. Falls nicht, kann man es sich sehr einfach per normalem Windows Update besorgen. Wie bereits gesagt gibt es keinen Interpreter, denn wenn Du die EXE das erste mal startest, dann wird es per "just in time compiler" optimal für Deine Platform kompiliert und läuft dann rel. schnell. Der ehemalige Chefentwickler von Delphi wurde ja von Microsoft übernommen und seit da hat sich das Visual Studio sehr gemausert! Vor dem .NET Zeitalter fand ich das Visual Studio zum kotzen, aber nun ist es super. Ich denke, installier doch mal die kostenlose Express Version und mach mal die ersten Schritte. Falls es Deine Bedürfnisse nicht befriedigt, kannst Du es wieder deinstallieren und was anderes versuchen.
> C# ist eben eine reine Microsoft Geschichte und soweit ich weiß > vollständig an .net gebunden. Daher muss wohl im Hintergrund ein > Interpreter laufen. Ich persönlich lehne solch ein Konzept bei einer > Programmiersprache grundsätzlich ab. Weder C#, noch Java, genauer gesagt, jede ernst zunehmende Implementation, benutzt einen Interpreter. Alle benutzen entweder JIT und/oder AOT (bei .Net wären die Stichworte GAC und ngen, wenn man die Applikation z.B. während der Installation in nativen Code übersetzen lassen will). Das Konzept an sich, ist das einzig vernünftige, um den "Durchschnittsprogrammierer" zu halbwegs brauchbaren > Auch beim .NET-Framework soll einen deutlich besseren Toolkit als die MFC > dabei sein, aber da kenne ich mich nicht aus. Ich kann deswegen nicht > sagen, welche Programmiersprachen unterstützt werden, aber wahrschein- > lich sind es nur die spziellen .NET-Sprachen C#, VisualBasic und evtl. > dieser neue C++-ähnliche Verschnitt. Das gesamte Framework ist wesentlich besser. Angefangen z.B. mit dem älteren WinForms, über WPF, WCF, WF etc. Plattformunabhängig ist das ganze mittlerweile auch. Zumindest wenn man sich auf .NET 2.0 beschränkt. Unterstützte Sprachen: Z.B. F# für OCaml/ML Liebhaber, Python, Ruby (als IronRuby bzw. IronPython), div. Haskell, Lisp, Scheme oder Smalltalk-Implementationen oder auch ADA (GNAT Pro) etc. Wenns Eiffel - mit Mehrfachvererbung (im Gegensatz zu C++/CLI) - sein darf: EiffelEnvision > OO ist ein netter Zusatz, aber keine grundlegend neue > Programmierphilosophie. Dann hat man's nicht verstanden. > Da würde ich an deiner Stelle eher zu Java gehen, keinesfalls C#. Je > mehr Leute diesen Mist benutzen, desto länger müssen wird damit leben. Argumente? > Für Java gibt es auch nette IDEs wie zB. Eclipse, es ist etabliert und > unter praktisch allen OS lauffähig. Das JRE ist etwas nervig, aber was > entsprechendes hast du unter .net auch. Und GUI in Java ist auch kein > Problem. Kein Problem, wenn's auf jeder Plattform eindeutig als Java-App zu erkennen sein soll, umständlich zu erweitern u.a. sein soll. > Wenn du später mal richtig mit Programmieren anfangen willst, führt > eigentlich (früher oder später) kein Weg an C++ vorbei. C++ ist viel > mächtiger als Java, und viel mächtiger als C# (mal abgesehen davon, dass > es in den richtigen Händen auch deutlich schneller ist). Mächtiger als Turing-vollständig? Mehrfachvererbung: Ist nur in einer einzigen statisch getypten Sprachen brauchbar umgesetzt (Eiffel), alle anderen Sprachen brauchen dieses "Feature" schlicht und ergreifend nicht. Operatorüberladung: Gibt's z.B. in C# auch Templates / Generics: auch Dynamische Codegenerierung (zur Laufzeit kein Template-Metagefrickel zur Compile-Zeit): In C++ genauso wenig möglich wie: Dynamische Typen/Klassen, Lambda-Ausdrücke/Closures, Linq, DLR, Reflection/Introspection etc. > Um seinen Horizont zu erweitern ist C++ in jedem Fall deutlich besser > als Java oder c#. Wenn's nur um den Horizont geht, sind Smalltalk, Eiffel, Haskell oder Scheme die richtigen Kandidaten. "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." Alan Kay
Windows-Programmierung geht übrigens auch mit Basic. RealBasic beispielsweise erlaubt sogar plattformübergreifende Programmierung für MacOS X und Linux. Ein anderer Kandidat ist TrueBasic und, so man dem .Net-Geraffel doch nicht entgehen möchte, Visual Basic.Net. Letzteres ist in einer kostenfreien Version als Visual Basic Express verfügbar. Ist zwar alles nicht mein Ding, ich arbeite seit über zehn Jahren mit der MFC, aber das mache ich auch praktisch täglich. Für Einsteiger oder Gelegenheitsprogrammierer ist das definitiv nicht zu empfehlen. Gerade RealBasic wird von einigen bekannten Entwicklern aber durchaus geschätzt, da damit schnell lauffähige Programme erstellt werden können, die vor allem ohne Runtime-DLLs und der damit verbundenen "DLL Hell" auskommen. Die Cross-Platform-Aspekte sind sicherlich noch ein nettes Schmankerl.
Arc Net wrote: >> OO ist ein netter Zusatz, aber keine grundlegend neue >> Programmierphilosophie. > > Dann hat man's nicht verstanden. Nein, du hast es nicht verstanden (ok, das ist 'ner sachlichen Diskussion nicht gerade dienlich). Ich nehme mal an du kommst aus der C# / Java Ecke. Da ist es üblich, sich durch endlos verschachtelte Klassenbäume zu arbeiten, weil dir eigentlich garnix anderes übrig bleibt. Früher dachten die Akademiker mal das wäre das tollste überhaupt, inzwischen ist da aber ernüchterung eingekehrt. Es gibt aber auch die Möglichkeit OO etwas zurückhaltender einzusetzen. C++ bietet dir zB. namespaces, die mit OO direkt erstmal nix zu tun haben. Und auch wenn du massiv OO benutzt - es bleibt in der Praxis ein ähnliches programmieren. Du kannst dem Kind einen neuen Namen geben, aber im Endeffekt setzt du dich trotzdem hin und schreibst Zeile für Zeile Code, benutzt Schleifen, rufst Funktionen in anderen Klassen auf, etc. pp. Ein bisschen Automatisierung kommt dazu, ja. Aber ich kann dir das komplette OO Konzept auch in C umsetzen. OO ist eine Denkweise, unabhängig von der Programmiersprache. >> Da würde ich an deiner Stelle eher zu Java gehen, keinesfalls C#. Je >> mehr Leute diesen Mist benutzen, desto länger müssen wird damit leben. > > Argumente? Es ist propritär. Das reicht als Argument völlig aus. Und es kommt von einem Anbieter, der zurecht auf >1Mrd wegen Monopolmissbrauch verklagt wurde - was kein Problem wär, wenn's nicht propritär wäre. >> Für Java gibt es auch nette IDEs wie zB. Eclipse, es ist etabliert und >> unter praktisch allen OS lauffähig. Das JRE ist etwas nervig, aber was >> entsprechendes hast du unter .net auch. Und GUI in Java ist auch kein >> Problem. > > Kein Problem, wenn's auf jeder Plattform eindeutig als Java-App zu > erkennen sein soll, umständlich zu erweitern u.a. sein soll. Das "umständlich zu erweitern" liegt ja wohl nicht an der Sprache, sondern am Programmierer. Wenn du unfähig bist ein erweiterbares Konzept auf die Beine zu stellen... Du scheinst dich mit Java auch nicht besonders auszukennen - SWT benutzt die nativen Widgets. >> Wenn du später mal richtig mit Programmieren anfangen willst, führt >> eigentlich (früher oder später) kein Weg an C++ vorbei. C++ ist viel >> mächtiger als Java, und viel mächtiger als C# (mal abgesehen davon, dass >> es in den richtigen Händen auch deutlich schneller ist). > > Mächtiger als Turing-vollständig? Lass mich raten: Akademiker? Das sind die einzigen, die mit dem "Argument" ankommen. C++ ist neben Java die am weitesten verbreitete Sprache überhaupt. Damit ist das Thema ob du C++ brauchst oder nicht erledigt. > Mehrfachvererbung: Ist nur in einer einzigen statisch getypten Sprachen > brauchbar umgesetzt (Eiffel), alle anderen Sprachen brauchen dieses > "Feature" schlicht und ergreifend nicht. Weil du es nicht einsetzen kannst? > Operatorüberladung: Gibt's z.B. in C# auch > Templates / Generics: auch Und nun rate mal, was das Potenzial zu höherer Performance bei gleichzeitig sauberem Code liefert. C# sicher nicht. An Vista siehst du doch ganz deutlich, wohin "Perfomance ist mir sch***egal!" führt. > Dynamische Codegenerierung (zur Laufzeit kein Template-Metagefrickel zur > Compile-Zeit): In C++ genauso wenig möglich wie: > Dynamische Typen/Klassen, Lambda-Ausdrücke/Closures, Linq, DLR, > Reflection/Introspection etc. Vieles davon lässt sich in C++ viel eleganter und schneller als in C# mit Templates erschlagen. Die Dinger richtig einzusetzen ist ein Kapitel für sich. Nur mal so als Denkanstoß: Wann immer du einen vector<int> benutzt, wird neuer Code generiert. >> Um seinen Horizont zu erweitern ist C++ in jedem Fall deutlich besser >> als Java oder c#. > > Wenn's nur um den Horizont geht, sind Smalltalk, Eiffel, Haskell oder > Scheme die richtigen Kandidaten. > "I invented the term Object-Oriented, and I can tell you I did not have > C++ in mind." Alan Kay Im Gegensatz zu Smalltalk, Eiffel und Kaskell hat C++ aber auch einen echten praktischen Wert ;). Ich bleibe dabei: C++ ist zwar deutlich schwieriger als Java oder C# (und min. 50% der Leute die meinen C++ zu können können es nicht wirklich), aber es bietet sehr viel Mehrwert.
Der Paul will doch nur mit seinem uC kommunizieren können und per GUI ein paar Daten herumschicken und visualisieren können. Er will ja nicht PC Programmierer werden, wenigstens soweit ich das verstanden habe. Von da her kommt doch erst mal was in Frage, was dem C - das er schon kennt - relativ naher kommt und ihm noch erlaubt, rel. schnell ein GUI zu machen. Mit C# und dem .NET Framework ist doch dies recht gut abgedeckt. Für die serielle Schnittstelle gibts eine fixfertige Komponente, die einfach per drag & drop ins Projekt reingenommen werden kann. Im Visual Studio kann er sein GUI zusammenklicken und danach den Code dazu ausprogrammieren. Mit F5 builden und starten. Der in die Entwicklungsumgebung eingebaute Debugger ist nicht schlecht. Es gibt Hilfe im Internet, seien es Foren, Newsgroups, MSDN oder sonstige Sites. Klar kann (muss aber nicht) man mit C++ und MFC (nicht managed C++ von Microsoft) effizienteren Code programmieren, doch was kümmert es einen, wenn der uC, der am Programm hängt eh nur mit 19200 Baud kommuniziert? Um nur die paar Daten zu visualisieren würde auch eine Scriptsprache ausreichen. Aber meistens sind dort die Debuggingmöglichkeiten ein wenig beschränkt und die Syntax ist dann doch sehr anders als C.
I_ H. wrote: > @powl > > Wenn du nur mal ein kleines bisschen Zeugs zusammenprogrammieren willst, > ist C++ sicher nicht die beste Wahl. Da würde ich an deiner Stelle eher > zu Java gehen, keinesfalls C#. Je mehr Leute diesen Mist benutzen, desto > länger müssen wird damit leben. Hab doch nie geschrieben er solle unbedingt C++ benutzen. Java tut's auch, GUI kann man auch zusammenklickern, serieller Port geht auch.
Auf der Seite http://www.haiq.info gibt es einen kompletten (kostenlosen) Lehrgang mit allem Drum und Dran (learning by doing in 10 Lektionen) für Anfänger, die (noch) keine PC-Programmier-Ahnung haben. Im Grundlehrgang geht es um den Einstieg in die C++ Programmierung mit graphischer Oberfläche auf Basis der OpenSource Entwicklungsumgebung von Trolltech (Qt4) mit der OpenSource IDE HaiQ. Die fertigen Programme sind somit auf Linux-, Windows- und Mac- Rechnern lauffähig. Ich selbst bin gerade dabei, ein DMX-System mit dem Mega16 und 168 zu entwickeln und verwende diese Entwicklungsumgebung um vom Pc die Rs232 - Steuerung zu realisieren. (Funktioniert schon hervorragend.) Wer durch den Lehrgang durch ist, kann von mir das funktionsfähige Testprogramm (mit der dazugehörigen RS232 Library) bekommen. Geht aber nur im Zusammenhang mit der installierten Entwicklungsumgebung (Wegen der dazugehörigen Qt4-Libraries). In diesem Sinne ... happy coding ... G. Bremer
@Paul Hamacher: Was machst du, wenn du einen Schraubendreher brauchst, du dich aber nicht entscheiden kannst, ob du einen kleinen, mittleren oder großen kaufen sollst? Richtig, du kaufst einfach alle drei :) Bei Softwarewerkzeugen ist es nicht anders als bei mechanischen. Lerne einfach nach und nach mehrere Programmiersprachen und auch andere Softwarewerkzeuge zu beherrschen, dann hast du irgendwann eine Profiwerkzeugkiste zusammen. Natürlich kannst du auch nur den kleinsten Schraubendreher kaufen, damit kann man auch größere Schrauben drehen. Aber wenn's auf's Drehmoment ankommt, stößt du damit bald an Grenzen. Und wenn du das Gefühl hast, eine Programmiersprache zuviel gelernt zu haben: Vergessen ist sie schnell, sie bleibt dir nicht an der Backe kleben :) In meiner Wrkzeugkiste liegt ein C-, ein C++ und ein Python-Schrauben- dreher. C ist für Mikrocontroller und kleinere schnelle PC-Programme, C++ für große PC-Programme (teilweise mit GUI, dann nehme ich GTK+/GTKmm mit hinzu) und Python (mit PyGTK für GUIs) für Programme, die ganz schnell fertig sein müssen und die Ausführungsgschwindigkeit nicht so wichtig ist. Daneben gibt es noch den Fortran-Schraubendreher, den ich aber nicht mehr gerne anfasse, weil er schon rostet, und den Java-Schraubendre- her, dessen Größe so dicht am C++- und Python-Schraubendreher liegt, so dass er eigentlich fast überflüssig ist. Deswegen kaufe ich auch keine weiteren Schraubendreher in dieser Größenklasse, wie bspw. einen C#-Schraubendreher. Dann liegen es in der Kiste noch ein paar verstaubte Schraubendreher mit ganz exotisch geformten Spitzen für Spezialschrauben. Die sind schön anzusehen, werden aber so gut wie nie benutzt :) In der Zeit, in der dieser Thread schon läuft, hättest du von einer der schon am Anfang vorgeschlagenen Sprachen (z.B. C++ oder C#) ein Tutorial mindestens bis zur Hälfte durcharbeiteten können, könntest dir selbst schon ein vages Bild von ihr machen und wärst durch die kontroverse Diskussion jetzt nicht so stark hin- und hergerissen. Letztendlich musst du diejenige Sprache finden, die dir gefällt und zu deiner Denkweise passt, und nicht die, die andere zufälligerweise gerade megacool finden (in einem Jar vielleicht nicht mehr). Deswegen soll auch meine Werkzeugkiste von oben kein Vorschlag, sondern nur ein Beispiel sein.
I_ H. wrote: > Arc Net wrote: >>> OO ist ein netter Zusatz, aber keine grundlegend neue >>> Programmierphilosophie. >> >> Dann hat man's nicht verstanden. > > Nein, du hast es nicht verstanden (ok, das ist 'ner sachlichen > Diskussion nicht gerade dienlich). > Ich nehme mal an du kommst aus der C# / Java Ecke. Da ist es üblich, > sich durch endlos verschachtelte Klassenbäume zu arbeiten, weil dir > eigentlich garnix anderes übrig bleibt. Falsch geraten... Angefangen vom C64 und Basic/Assembler, über ST/Amiga: Assembler/C/Pascal(Schule), ging's weiter mit Smalltalk, C++, Ada, Scheme, Cobol, div. Assembler, Delphi, Java, C#. Wobei die ersten C++-Sachen mit Cfront 2.0 "kompatiblen" Compilern gemacht wurden. > Früher dachten die Akademiker mal das wäre das tollste überhaupt, > inzwischen ist da aber ernüchterung eingekehrt. > > Es gibt aber auch die Möglichkeit OO etwas zurückhaltender einzusetzen. > C++ bietet dir zB. namespaces, die mit OO direkt erstmal nix zu tun > haben. > Und auch wenn du massiv OO benutzt - es bleibt in der Praxis ein > ähnliches programmieren. Du kannst dem Kind einen neuen Namen geben, > aber im Endeffekt setzt du dich trotzdem hin und schreibst Zeile für > Zeile Code, benutzt Schleifen, rufst Funktionen in anderen Klassen auf, > etc. pp. > > Ein bisschen Automatisierung kommt dazu, ja. Aber ich kann dir das > komplette OO Konzept auch in C umsetzen. OO ist eine Denkweise, > unabhängig von der Programmiersprache. Jein, wenn man's in einer ungeeigneten Sprache macht, wird's nur extrem umständlich und hilft nicht. Einige Konzepte lassen sich in C ohne Hilfsmittel erst gar nicht abbilden. >> >> Argumente? > > Es ist propritär. Das reicht als Argument völlig aus. Und es kommt von > einem Anbieter, der zurecht auf >1Mrd wegen Monopolmissbrauch verklagt > wurde - was kein Problem wär, wenn's nicht propritär wäre. C# + CLI sind offene ISO/ECMA-Standards >> Kein Problem, wenn's auf jeder Plattform eindeutig als Java-App zu >> erkennen sein soll, umständlich zu erweitern u.a. sein soll. > > Das "umständlich zu erweitern" liegt ja wohl nicht an der Sprache, > sondern am Programmierer. Wenn du unfähig bist ein erweiterbares Konzept > auf die Beine zu stellen... > > Du scheinst dich mit Java auch nicht besonders auszukennen - SWT benutzt > die nativen Widgets. > Erweitern bezog sich z.B. auf neue Komponenten (Widgets), nicht auf den internen Unterbau. Und selbst mit SWT merkt man den Unterschied zu nativen Applikationen. >> Mächtiger als Turing-vollständig? > > Lass mich raten: Akademiker? Das sind die einzigen, die mit dem > "Argument" ankommen. C++ ist neben Java die am weitesten verbreitete > Sprache überhaupt. Damit ist das Thema ob du C++ brauchst oder nicht > erledigt. Nur wird sowohl C++, als auch Java seit Jahren immer weniger gebraucht und nachgefragt. >> Mehrfachvererbung: Ist nur in einer einzigen statisch getypten Sprachen >> brauchbar umgesetzt (Eiffel), alle anderen Sprachen brauchen dieses >> "Feature" schlicht und ergreifend nicht. > > Weil du es nicht einsetzen kannst? Das war eigentlich schon abschließend beantwortet. Ansonsten hilft es vielleicht an den theoretischen Grundlagen zu arbeiten oder vllt. auch ein Zitat 1) > >> Operatorüberladung: Gibt's z.B. in C# auch >> Templates / Generics: auch > > Und nun rate mal, was das Potenzial zu höherer Performance bei > gleichzeitig sauberem Code liefert. C# sicher nicht. C++ Syntax und sauber, widerspricht sich wie Hummer und Spritsparen. > An Vista siehst du > doch ganz deutlich, wohin "Perfomance ist mir sch***egal!" führt. Was hat Vista mit C# oder dem .Net Framework zu tun. Den einzigen Zusammenhang den man herstellen könnte ist: Man kann in jeder Sprache langsame Programme schreiben. >> Dynamische Codegenerierung (zur Laufzeit kein Template-Metagefrickel zur >> Compile-Zeit): In C++ genauso wenig möglich wie: >> Dynamische Typen/Klassen, Lambda-Ausdrücke/Closures, Linq, DLR, >> Reflection/Introspection etc. > > Vieles davon lässt sich in C++ viel eleganter und schneller als in C# > mit Templates erschlagen. Die Dinger richtig einzusetzen ist ein Kapitel > für sich. Vieles? Genau gar nichts! C++ unterstützt keine dynamische Codegenerierung, Templates/Generics sind nur schwach typisiert (die Boost-Lib zählt hier nicht, da sie zwar vieles besser macht, aber nicht die grundlegenden C++-Probleme behebt), Templates werden zur Compile-Zeit generiert und sind somit alles andere als dynamisch zur Laufzeit erzeugbar etc. pp. 1) "I would still say use multiple inheritance judiciously, because if you have a choice between a single inheritance based design and a multiple inheritance based design, I think most of the time the single inheritance based design will be simpler." Scott Meyers oder deutlicher gesagt: Wer Mehrfachvererbung braucht, hat in 99.99% der Fälle kein vernünftiges Design zustandebekommen.
Arc Net wrote: > Falsch geraten... > Angefangen vom C64 und Basic/Assembler, über ST/Amiga: > Assembler/C/Pascal(Schule), ging's weiter mit Smalltalk, C++, Ada, > Scheme, Cobol, div. Assembler, Delphi, Java, C#. Wobei die ersten > C++-Sachen mit Cfront 2.0 "kompatiblen" Compilern gemacht wurden. Zu dem eigentlichen Thema, nämlich das OOP nicht so viel anders ist, hast du aber nix gesagt ;) > Jein, wenn man's in einer ungeeigneten Sprache macht, wird's nur extrem > umständlich und hilft nicht. Einige Konzepte lassen sich in C ohne > Hilfsmittel erst gar nicht abbilden. In C lassen sich sogar Sachen umsetzen, die in C++ nicht gehen. Und in Assembler kann man ja sowieso alles machen, also auch OOP (mit ein paar Makros kein Problem). Es ist nicht nur das OOP was "Klasse" heist. > C# + CLI sind offene ISO/ECMA-Standards OOXML auch... > Erweitern bezog sich z.B. auf neue Komponenten (Widgets), nicht auf den > internen Unterbau. Und selbst mit SWT merkt man den Unterschied zu > nativen Applikationen. Bis zu einem gewissen Grad. Aber das macht dann auch keinen Unterschied mehr. Es gibt übrigens nicht den richtigen Weg wie ein Programm aufgebaut sein muss, damit man damit effizient arbeiten kann. Und (viele) Windowsprogramme sind in punkto Bedieneffizienz eh unterirdisch. > Nur wird sowohl C++, als auch Java seit Jahren immer weniger gebraucht > und nachgefragt. Schon klar. Quelle? Das sagen alle gern, aber belegen kann es dann niemand. m$ hat gerade erst ein neues wandelndes Ungetüm bestehend aus abermillionen widersprüchlichen Codezeilen auf die Menschheit losgelassen - hauptsächlich C++. Neben den windowsern gibt es aber auch noch eine sehr umfangreiche Unix-Welt, und da ist C++ der Standard schlechthin. Und da geht's um richtige Software, und nich um das 3. Buchhaltungsprogramm. >> Weil du es nicht einsetzen kannst? > > Das war eigentlich schon abschließend beantwortet. Ansonsten hilft es > vielleicht an den theoretischen Grundlagen zu arbeiten oder vllt. auch > ein Zitat 1) Es gibt auch Leute die meinen Gotos wären gefährlich. Sicher ist es nicht das Feature das man in jeder 2. Codezeile benutzt, aber so ganz sinnlos ist es auch nicht. Das "weil du es nicht einsetzen kannst" bezog sich übrigens darauf, dass dir die Phantasie fehlt das Feature nützlich einzusetzen ;). Ich find es aber immer wieder erheiternd, wenn die C++ Gegner ankommen und meinen C++ sei schlecht, weil es lauter böse Sachen unterstütze (was du jetzt nicht getan hast, sonst aber oft - gerade beim Thema Mehrfachvererbung - passiert). >> Und nun rate mal, was das Potenzial zu höherer Performance bei >> gleichzeitig sauberem Code liefert. C# sicher nicht. > > C++ Syntax und sauber, widerspricht sich wie Hummer und Spritsparen. C++ Syntax ist leistungsfähig, und trotzdem noch recht sauber. Klar ist zB. Java Syntax deutlich sauberer, kann aber auch viel weniger. > Was hat Vista mit C# oder dem .Net Framework zu tun. Den einzigen > Zusammenhang den man herstellen könnte ist: Man kann in jeder Sprache > langsame Programme schreiben. Bestimmte Sprachen sind aber schon von Haus aus langsam, teils wegen den Compiler, teils wegen dem Sprachkonzept, und teils wegen dem von der Sprache vorgegebenem Programmierstiel. >>> Dynamische Codegenerierung (zur Laufzeit kein Template-Metagefrickel zur >>> Compile-Zeit): In C++ genauso wenig möglich wie: >>> Dynamische Typen/Klassen, Lambda-Ausdrücke/Closures, Linq, DLR, >>> Reflection/Introspection etc. >> >> Vieles davon lässt sich in C++ viel eleganter und schneller als in C# >> mit Templates erschlagen. Die Dinger richtig einzusetzen ist ein Kapitel >> für sich. > > Vieles? Genau gar nichts! C++ unterstützt keine dynamische > Codegenerierung, Templates/Generics sind nur schwach typisiert (die > Boost-Lib zählt hier nicht, da sie zwar vieles besser macht, aber nicht > die grundlegenden C++-Probleme behebt), Templates werden zur > Compile-Zeit generiert und sind somit alles andere als dynamisch zur > Laufzeit erzeugbar etc. pp. Ich hab dir mal ein keines C++ Programm angehängt. Das Ding erzeugt in etwa diese Ausgabe:
1 | foo |
2 | |-int: 123 |
3 | |-float: 456 |
4 | |-vector (3) |
5 | |- |-vector (3) |
6 | |- |- |-int: 0 |
7 | |- |- |-int: 1 |
8 | |- |- |-int: 2 |
9 | |- |-vector (4) |
10 | |- |- |-int: 0 |
11 | |- |- |-int: 1 |
12 | |- |- |-int: 2 |
13 | |- |- |-int: 3 |
14 | |- |-vector (5) |
15 | |- |- |-int: 0 |
16 | |- |- |-int: 1 |
17 | |- |- |-int: 2 |
18 | |- |- |-int: 3 |
19 | |- |- |-int: 4 |
Wie du siehst kann das Programm (statisch) in gewissem Maße über sich selbst reflektieren. Das tolle an dem Programm ist aber, dass der Compiler schon alles weis - er könnte den Code sogar soweit zusammenoptimieren, dass das Programm garnix mehr machen muss, nur noch den Text von oben ausgibt. Wenn du sowas gezielt einsetzt, bist du performancemäßig jedem C# oder Java Programm weit überlegen. Sogar C Programme kannst du damit überholen (außer man schreibt in C alles aus, aber das ist kein wirklich guter Stil). Hier an der Stelle ist das natürlich nicht so besonders sinnvoll (den Funktor hab ich auch nur reingemacht damit ein Funktor drinnen ist), aber wenn es auf Geschwindigkeit ankommt sind Templates ein ganz tolles Feature. In wie weit man die ganzen Features die du aufgezählt hast wirklich braucht ist eine andere Sache. Wie gesagt, es gibt noch mehr als RAD und das 1231. Buchhaltungsprogramm. Ich erinnere mich da zB. an Objective-C, das auch ein Nischendasein fristet, obwohl die Objektorientierung wirklich leistungsfähig ist. Bei mir liegen in /usr/portage/distfiles mehrere Gigabytes gepackter Source - >90% davon C++.
Mein Gott schreibt ihr hier einen Mist zusammen! Glaubenskriege um Programmiersprachen; Geschwindigkeitsfanatik; unleserlichen "Expertencode"; Fachausdrücke noch und nöcher die keiner versteht der gerade beginnen möchte @Paul Hamacher (powl) Ein guter Einstieg in die Windows Programmierung geht mit dem Buch von Charles Petzold - Programming Windows, der die Win32 API (die Windows eigene Programmierschnittstelle) nutzt und dazu auf die bereits vorhandenen Kenntnissen in C baut. Lass dich nicht von diesem OOP Mist verführen. Du brauchst keine Klassen um ein paar Fenster oder einen Dialog auf den Screen zu bringen. Weniger ist mehr. Erzeuge einfach native EXE-Dateien (lass den Java-Quark beiseite). Eine schöne und zugleich einfache IDE für die ersten Erfolge gibt es hier http://www.smorgasbordet.com/pellesc/ Fang mit Konsolenprogrammen an und versuche dabei Win32 Funktionen zu verwenden. Später dann Ein/Ausgabe in einem "echten" Fenster oder Dialog. Lass die Finger von den Assistenten, die dir ratzfatz vollständige Programme zusammenklicken 8da lernst du nix bei!). Baue stattdessen dein eigenes Programm schrittweise auf, indem du ein Gerüst verwendest, das du verstehst (lies die Kapitel dazu im Petzold, es ist nicht schwer und macht Spass). alternativ zur pellesc IDE geht auch die Express-Edition von MS (mit den entsprechend vielen Megabytes ;)). C# ist bestimmt auch eine Überlegung wert, aber dann musst du (besonders als Anfänger) geistig immer "umschalten" zwischen der Controller-Programierung in C auf der einen und C# für Windows Progrämmchen auf der anderen Seite. Für Gelegenheitsprogrammierer (wie mich ;)) ist das eher hinderlich und doppelte Denkarbeit (bewirkt Unsicherheit und Fehleranfälligkeit). Keep it simple!
@yalu Ich glaube ich habe meine Werkzeugkiste ausm selben Laden wie Du^^
Windows api direkt würd ich nicht anfangen. Das Wissen darüber kann man später in den Mülleimer verfrachten, und darf nochmal neu lernen. @Gelegenheitsprogrammierer Du scheinst ja kräftig mitzumischen bei dem, was du im ersten Absatz kritisierst ;).
> Windows api direkt würd ich nicht anfangen. Das Wissen darüber kann man > später in den Mülleimer verfrachten, und darf nochmal neu lernen. Das ist doch Unsinn, die API zu verwenden ist ein einfacher direkter Weg zur Windows-Programmierung. Was das spätere Hinzulernen anbetrifft sehe ich keinen Widerspruch. Es gibt viele interessante Sprachen und die Skriptsprachen sind auf dem Vormarsch, aber C gibt es schon sehr lange und wird es auch weiterhin geben. Und auch wenn man später auf C# erweitert, ist das gewonnene Wissen nicht umsonst gewesen. > @Gelegenheitsprogrammierer > Du scheinst ja kräftig mitzumischen bei dem, was du im ersten Absatz > kritisierst ;). Glaube ich nicht. Ich halte es nur für wenig sinnvoll hier einem Einsteiger Sprachen schmackhaft zu machen mit Sätzen wie "ist zu langsam" oder "ist viel schneller" oder "ist stark typisiert" usw. Wichtig ist einzig nicht gleich beim Einstieg die Lust durch Frust zu verlieren, weil man sich mehr den Kopf darüber zerbricht, was die "verquasten Programmzeilen" eigentlich bewirken als das man etwas brauchbares zustande bekommt. Für nicht allzu lange Progrämmchen braucht man weder Klassen noch Frameworks, die beide ihrerseits doch nur wieder die Windows API aufrufen. Also nochmal, halte es einfach und fange einfach mal an ein paar kurze Programme zu compilieren. Wichtig ist genügend kurze Beispiele und vor allem eine gute Online-Hilfe zu haben. Programmieren muss Spass machen.
>> Windows api direkt würd ich nicht anfangen. Das Wissen darüber kann man >> später in den Mülleimer verfrachten, und darf nochmal neu lernen. > >Das ist doch Unsinn, die API zu verwenden ist ein einfacher direkter Weg >zur Windows-Programmierung. Es gibt viele interessante Sprachen und die >Skriptsprachen sind auf dem Vormarsch, aber C gibt es schon sehr lange >und wird es auch weiterhin geben. Die WINAPI ist nicht einfach, sondern unnötig kompliziert und total veraltet. Sie wird nicht mehr weiterentwickelt und früher oder später komplett durch .NET ersetzt werden. Das heißt aber nicht, dass man nicht C oder besser C++ lernen sollte. C++ ist eine sehr gute Programmiersprache, die sich noch sehr lange halten wird, auch wenn Skriptsprachen wie Ruby immer beliebter werden. Entgegen vieler Meinungen hier ist C++ auch wunderbar als erste Sprache geeignet. C++ ist zwar wesentlich komplizierter als C, BASIC, Pascal & Co, aber davon merkt man am Anfang nicht viel, da man ja nicht gleich mit templates und Polymorphie anfängt. Wenn man dann später C++ vernünftig beherrscht kann man sich der GUI-Programmierung widmen. Wesentlich einfacher und portabler als die WINAPI sind hier moderne GUI-Frameworks wie Qt oder gtkmm.
> Die WINAPI ist nicht einfach, sondern unnötig kompliziert Quatsch! > und total > veraltet. Ja, so veraltet wie Windows XP. Das wird irgendwann auch mal komplett durch Vista und "New Vista" ersetzt sein, aber bis dahin ist auch die API noch brauchbar. > Sie wird nicht mehr weiterentwickelt und früher oder später > komplett durch .NET ersetzt werden. Sie braucht auch nicht mehr weiterentwickelt zu werden. Für das was der Threadstarter machen möchte und jemals machen wird genügt sie. Und ob dot net in 15 Jahren so noch da sein wird? Wer will das wissen? > Wenn man dann später C++ vernünftig beherrscht kann > man sich der GUI-Programmierung widmen. Glaubst du im ernst der Threadstarter möchte erst mal "C++ vernünftig beherrschen" und sich dann (irgend wann mal) der GUI-Programmierung zu widmen? > Wesentlich einfacher und > portabler als die WINAPI sind hier moderne GUI-Frameworks wie Qt oder > gtkmm. Es scheint nur einfacher, für den der es bereits kann und Portabilität braucht der Threadstarter vermutlich gar nicht.
>> Die WINAPI ist nicht einfach, sondern unnötig kompliziert > >Quatsch! Schau die doch einfach mal ein Fenster Beispiel in WinAPI und Qt an: http://de.wikipedia.org/wiki/Liste_von_Hallo-Welt-Programmen#Windows_API_.28in_C.29 http://de.wikipedia.org/wiki/Liste_von_Hallo-Welt-Programmen#C.2B.2B_mit_Qt Was einfacher ist, ist offensichtlich. >> Wenn man dann später C++ vernünftig beherrscht kann >> man sich der GUI-Programmierung widmen. > >Glaubst du im ernst der Threadstarter möchte erst mal "C++ vernünftig >beherrschen" und sich dann (irgend wann mal) der GUI-Programmierung zu >widmen? Wenn man kein Script-Kiddie, sondern eine richtiger Programmierer werden möchte, ist das der normale Weg.
Also wenn gui unter windows und das noch möglichst einfach dann schon eines der Toolkits wie GTK oder wxwindows. Die werden weiterentwickelt, die gibt es für sehr viele OS, sind vom Aufbau deutlich moderner als das windows gedöns (ein einfaches kleines GTK Programm mit einem Fenster braucht glaub 2 oder 3 Zeilen, Button dazu macht nochmal 3 Zeilen + Funktion für button_clicked), und es wird sie auch für viele kommende OS geben. Und zu guter letzt sind das erprobte und viel benutzte Toolkits mit guter Dokumentation, die auch häufig von Leuten, die nicht so viel programmieren, benutzt werden. Zum Thema Qt: Ich hab mir gestern aus Spaß nochmal KDevelop angeguckt, nachdem ich von den GUI Entwicklungsmöglichkeiten vergangener Versionen nicht so begeistert war. Inzwischen hat sich da wirklich was getan, und vom Komfort her steht das einem Visual Basic eigentlich in nix mehr nach. Mit KDesigner kann man die Gui zusammenklickern/umändern und der fügt in eine beliebige Klasse auch gleich die Signal-Handler ein, und alles innerhalb von KDevelop. Die C++ Kentnisse sollten aber schon etwas fundierter sein. Und KDevelop gibt's natürlich nur für KDE/X11.
I_ H. wrote: > Also wenn gui unter windows und das noch möglichst einfach dann schon > eines der Toolkits wie GTK oder wxwindows. Die werden weiterentwickelt, > die gibt es für sehr viele OS, sind vom Aufbau deutlich moderner als das > windows gedöns (ein einfaches kleines GTK Programm mit einem Fenster > braucht glaub 2 oder 3 Zeilen, Button dazu macht nochmal 3 Zeilen + > Funktion für button_clicked), und es wird sie auch für viele kommende OS > geben. > Und zu guter letzt sind das erprobte und viel benutzte Toolkits mit > guter Dokumentation, die auch häufig von Leuten, die nicht so viel > programmieren, benutzt werden. Absolut. wxWindows heißt aber schon länger wxWidgets. Ansonsten sehe ich das absolut genau so, und der Wikipedia Vergleich der Hello-World Programme zwischen WinAPI und einem GUI Toolkit sagt eigentlich alles. Achja: Die WinAPI ist nicht veraltet. Bzw, sie ist genau so alt wie das letzte Update des Betriebssystem, das an der API etwas geändert hat. Alle GUI Toolkits basieren auf dieser WinAPI, zwangsläufig. Aber OOP ist der beste Grund schlechthin, weswegen man ein C++ GUI Toolkit benutzen sollte, statt der WinAPI. Mit den ganzen Sprachmöglichkeiten von C++ gibt es da EINIGES an Erleichterung!
irgendwann zerreiße ich mich noch slebst, die eine hälfte lernt c#, die andere lernt c++. nun bin ich wieder ins stutzen gekommen obwohl ich mir bei meiner entscheidung zu c# schon einigermaßen sicher war. lg PoWl
> irgendwann zerreiße ich mich noch slebst, die eine hälfte [...]
Je früher du das lernst, desto besser. Das ist ungemein praktisch ;)
Paul Hamacher wrote: > irgendwann zerreiße ich mich noch slebst, die eine hälfte lernt c#, die > andere lernt c++. > > nun bin ich wieder ins stutzen gekommen obwohl ich mir bei meiner > entscheidung zu c# schon einigermaßen sicher war. > > lg PoWl Lern beides, erst das Eine. Ein paar Jahre später (evtl. aus gegebenem Anlass) das Andere. Fertig. So hab ich es auch gemacht. Erst C (Privat), dann C++ mit MFC (Schule), dann C++ mit wxWidgets (Privat), dann C# (Schule). Wobei ich in C# auch nicht der Überflieger bin ;) Brauche es auch nur sehr selten eigentlich, da ich kaum grafische Anwendungen programmiere.. Wenn überhaupt mache ich sowas gerne mit wxWidgets, aber das lohnt auch nur bei größeren Projekten. Ich hab mir aber auch locker 5 Jahren Zeit gelassen um alles ein wenig zu lernen ;)
> Was einfacher ist, ist offensichtlich. Das sagt rein gar nichts. Genau so gut kannst du dir mit Hilfe eines Assistenten dein Programm zusammenklicken und dann behaupten, schau mal, wie einfach oder du kannst Visual Basic verwenden, irgendeinen Spaghetticode dahintippen und dich über dein einfaches Fenster freuen. Dann nimm doch gleich eine Skriptsprache, da haste dein Fenster noch einfacher. Die Hürde kommt spätestens dann, wenn du damit deine eigenen speziellen Wünsche in ein Programm umsetzen möchtest. Dann wirst du schnell merken wie angenehm dagegen C war und wie schön es ist ein paar gut dokumentierte Win32 Funktionen einzubauen. >> Glaubst du im ernst der Threadstarter möchte erst mal "C++ vernünftig >> beherrschen" und sich dann (irgend wann mal) der GUI-Programmierung zu >> widmen? > Wenn man kein Script-Kiddie, sondern eine richtiger Programmierer werden > möchte, ist das der normale Weg. Ich glaube du hast nicht mitbekommen, was der Threadstarter eigentlich wollte?! Zitat "Meien Vorhaben sind zunächstmal vergleichsweise einfach. Ich möchte ein bisschen mit graphischer Oberfläche Arbeiten und dann meine µCgeräte per RS232 oder USB steuern können." Was glaubst du wohl wie lange es dauert ein sog. "richtiger Programmierer" zu werden? Mal ganz abgesehen davon, dass du erst mal definieren müsstest was das eigentlich ist, wer nicht nahezu täglich programmiert, sondern gelegentlich (wie ich), der wird wohl nie ein "richtiger Programmierer" werden. Der Gelegenheitsprogrammierer nutzt nämlich die gute alte und oft verschmähte Trial-end-Error Methode, während der sog. "richtige Programmierer" erst mal endlos viel Papier produziert, bevor er auch nur eine einzige Zeile Code geschrieben hat. > Ich hab mir aber auch locker 5 Jahren Zeit gelassen um alles ein wenig > zu lernen ;) DAS sagt alles! :) Simon hat das richtig beschrieben, es dauert elendig lange bevor man auch nur einigermaßen das Gefühl hat zurechtzukommen. Darum rate ich dem Threadstarter, überlasse das lieber den Anderen, die damit ihr Geld verdienen, ein sog. "richtiger Programmierer" werden zu wollen. :)) (letztlich kannst aber nur du selber das entscheiden; nur lass dich nicht von ein paar kurzen Codezeilen blenden, die helfen dir nicht deine Vorstellung vom Programm umzusetzen; du brauchst möglichst viele Beispiele und eine gute Online-Hilfe; in dieser Hinsicht war z.B. das damals DOS orientierte Borland Turbo C++ 3.x einfach Klasse - lang ist's her (sentimentales schwärm;))
Schonmal daran gedacht, dass er nicht gleich als 2. Programm eine riesige IDE mit haufenweise erweiterten Widgets schreiben will? Offensichtlich nicht. Denn für das was er will, reichen die fertigen Widgets der GUI Toolkits absolut aus. Ich glaube du hast noch nie wirklich was anderes als die win api programmiert, und kennst die Sachen dementsprechend auch garnet. So kommt es jedenfalls rüber - deine Argumente sind in keinster Weise nachvollziehbar.
Hallo, Ich hoffe, ich darf mal eine Frage zu QT @ Windows stellen... Und zwar bin ich auch so ein Gelegentlichprogrammierer wie der Threadstarter. Mit QT hab ich unter Linux das eine oder andere Programm problemlos ans Laufen gebracht. Angeregt von Eurer Diskusion habe ich mir nach dem Schema von http://www.haiq.info/de/ QT auf meinem(leider) Vista Rechner installiert. Das Problem, das einfachste "Hello World" läßt sich nicht kompileren. ein qmake erzeugt folgende Fehlermeldung:
1 | Error processing meta file: C:\Qt\4.3.2\lib\qtmain |
2 | Error processing meta file: C:\Qt\4.3.2\lib\qtmaind |
3 | Error processing meta file: C:\Qt\4.3.2\lib\QtGuid |
4 | Error processing meta file: C:\Qt\4.3.2\lib\QtCored |
5 | Error processing meta file: C:\Qt\4.3.2\lib\qtmain |
Meine Recherche im Internet hat leider keine Lösung gebracht, außer, daß es Leute mit XP gibt, die auch das Problem haben. Kann mir jemand vielleicht helfen? In die PATH Variable habeich auf den Pfad zu C:\Qt\4.3.2\bin eingetragen, leider ohne Erfolg :-( Gruß Sebastian
>> Was einfacher ist, ist offensichtlich. > >Das sagt rein gar nichts. Genau so gut kannst du dir mit Hilfe eines >Assistenten dein Programm zusammenklicken und dann behaupten, schau mal, >wie einfach oder du kannst Visual Basic verwenden, irgendeinen >Spaghetticode dahintippen und dich über dein einfaches Fenster freuen. >Dann nimm doch gleich eine Skriptsprache, da haste dein Fenster noch >einfacher. Ich dachte wir hätten uns inzwischen auf C/C++ als Programmiersprache geeinigt? Wieso kommst du jetzt mit VB und irgendwelchen Skriptsprachen an? >Die Hürde kommt spätestens dann, wenn du damit deine eigenen >speziellen Wünsche in ein Programm umsetzen möchtest. Dann wirst du >schnell merken wie angenehm dagegen C war und wie schön es ist ein paar >gut dokumentierte Win32 Funktionen einzubauen. gtkmm, Qt und wxWidgets sind drei sehr mächtige Toolkits, die sehr gut skalieren und ausgezeichnet dokumentiert sind. Eigene maßgeschneiderte Widgets kann man ganz leicht erstellen und auch dank OO auch ganz einfach wiederverwenden. Wenn du erst mal einige Zeit mit einem der drei Toolkits gearbeitet hast, wirst du die Vorteile kennen und leiben lernen. >>> Glaubst du im ernst der Threadstarter möchte erst mal "C++ vernünftig >>> beherrschen" und sich dann (irgend wann mal) der GUI-Programmierung zu >>> widmen? > >> Wenn man kein Script-Kiddie, sondern eine richtiger Programmierer werden >> möchte, ist das der normale Weg. > >Ich glaube du hast nicht mitbekommen, was der Threadstarter eigentlich >wollte?! > >Zitat >"Meien Vorhaben sind zunächstmal vergleichsweise einfach. Ich möchte ein >bisschen mit graphischer Oberfläche Arbeiten und dann meine µCgeräte per >RS232 oder USB steuern können." Am Anfang sind alle etwas übermütig. Ich sehe in C++ Foren immer wieder Leute, die keine Ahnung vom Programmieren haben, aber gleich dicke GUIs und 3D-Spiele erstellen wollen. Früher oder später merkt aber jeder, dass das so nicht geht. Bevor man eine Programmiersprache nicht vernünftig kann, ist es Unsinn schon mit GUI anzufangen. >letztlich kannst aber nur du selber das entscheiden; nur lass dich >nicht von ein paar kurzen Codezeilen blenden, die helfen dir nicht deine >Vorstellung vom Programm umzusetzen; Doch. Wenn man weniger Code braucht um Windows, Buttons, Labels, EditBoxes, usw. zu erstellen, geht die Umsetzung schneller, ist übersichtlicher und Änderungen lassen sich einfacher implementieren.
> Schonmal daran gedacht, dass er nicht gleich als 2. Programm eine > riesige IDE mit haufenweise erweiterten Widgets schreiben will? Das ist doch genau das was ich sage, für das bisschen Oberfläche was er nutzen wird braucht er weder OOP mit Klassen; noch aufgeblähte Toolkits wie QT oder wxWidgets; er braucht kein Java Gedöns mit Just in Time Compiler; er braucht keine Microsoft Foundation Classes deren Syntax er nicht verstehen wird; er braucht kein Haskell (das braucht sowieso niemand); er braucht auch kein Spaghetticode VisualBasic weil er damit auch nie seine Mikrocontroller programmieren wird usw. > Ich glaube du hast noch nie wirklich was anderes als die win api > programmiert, und kennst die Sachen dementsprechend auch garnet. So > kommt es jedenfalls rüber - deine Argumente sind in keinster Weise > nachvollziehbar. Schade, aber ich bin ja auch nur ein Gelegenheitsprogrammierer, der sich noch heute an guten, alten Artikeln in der c't erinnert und orientiert, als Andreas Stiller nachgewiesen hat, dass Hello World unter einer MS IDE (die eigentlich gar nicht schlecht war) zu 98 Prozent aus Microsoft bestand und zu 2 Prozent aus .. na eben 'Hello World'. :) Heute ist das alles vergessen, wir haben ja sooooo viel Megahertz und Megabytes, da darf ruhig interpretiert oder an Libs geladen werden werden, was die Möhre hergibt und ein Klick auf ein Progrämmchen und schon sind 500 MByte weg.
>> Schonmal daran gedacht, dass er nicht gleich als 2. Programm eine >> riesige IDE mit haufenweise erweiterten Widgets schreiben will? > >Das ist doch genau das was ich sage, für das bisschen Oberfläche was er >nutzen wird braucht er weder OOP mit Klassen; noch aufgeblähte Toolkits >wie QT oder wxWidgets; Das macht es aber wesentlich einfacher. Und Einfachheit ist genau das, das der OP will. > Heute ist das > alles vergessen, wir haben ja sooooo viel Megahertz und Megabytes, da > darf ruhig interpretiert oder an Libs geladen werden werden, was die > Möhre hergibt und ein Klick auf ein Progrämmchen und schon sind 500 > MByte weg. Du übertreibst maßlos und merkst es nicht mal.
> Du übertreibst maßlos und merkst es nicht mal.
So? Ich fand die Artikel von A.S. immer sehr sinnig und informativ.
AS ist auch nicht gerade das Nonplusultra. Einige Artikel von dem Herren waren... naja. Die Toolkits sind allesamt einfacher zu programmieren als die win api, und wer GTK als aufgebläht bezeichnet hat damit garantiert noch nie im Leben gearbeitet - das Gegenteil ist der Fall.
> AS ist auch nicht gerade das Nonplusultra. Einige Artikel von dem Herren > waren... naja. Du hast bestimmt bessere Artikel verfasst und veröffentlicht, nicht wahr? > Die Toolkits sind allesamt einfacher zu programmieren als die win api, glaube ich nicht, die API ist gut dokumentiert bzw. es gibt zahlreiche Beispiele dafür > und wer GTK als aufgebläht bezeichnet hat damit garantiert noch nie im > Leben gearbeitet - das Gegenteil ist der Fall. So? GTK = "Gimp Tool Kit", nicht wahr? Jedes Toolkit bläht auf, weil es auf die API aufsetzt, diese kapselt und dann neue Funktionen bzw. Methoden zum Aufruf bereithält. Das erfordert zusätzliche Bibliotheken, zusätzliche Anpassung der Pfade, des Compilers, der IDE. U.U. läuft die fertige Anwendung auf älterer, schwächerer Hardware nicht, weil diese Bibliotheken oder die Laufzeitumgebung dort nicht vorhanden oder lauffähig ist (vielleicht auf einem alten Mainboard mit Windows 98, das zur Steuerung einer speziellen Hardware degradiert wurde). Das Toolkit zwingt dir seine spezielle Syntax auf. Was am Anfang einfach erscheint wird plötzlich undurchsichtig, wenn man Rohdaten bestimmter Fileformate manipulieren möchte (wav, bmp, tif ..) usw. Die MFC glänzt mit einer eigenen Syntax Windows-Nachrichten in vielen kleineren Schleifen abzuarbeiten; man versteht den Fluss, den Ablauf nicht ohne weiteres, dabei soll angeblich alles einfacher als unter Win32 sein. Aber ich bin halt der dumme Gelegenheitscoder und du der Profi der damit sein Geld verdient. Fragt sich nur ob der TS auch zum Profi werden möchte, um mal ab und an ein Programm zu schreiben.
Die C Library ist eigentlich auch unnötig, die setzt auch nur auf der win api auf. Und 'ne Hochsprache setzt auch nur auf Assembler auf, erfordert Bibliotheken und all so'n Zeugs - eigentlich total ineffizient. Also programmierst du von heut an nur noch Assembler... Betriebssystem ist eigentlich auch Käse, geht viel besser ohne. Mal ehrlich, hast du drüber nachgedacht was du da geschrieben hast? Die Toolkits machen alles leichter, und nix komplizierter. Das ist so ziemlich der einzige Grund wieso es die überhaupt gibt. Man muss übrigens nicht selber Artikel schreiben die Artikel andere Leute bewerten zu dürfen (vor allem was den Inhalt angeht). AS ist auch nur ein Mensch.
> Die C Library ist eigentlich auch unnötig, die setzt auch nur auf der > win api auf. Unsinn! Die C Lib ist genormt und bildet den ANSI C Standard ab. Sie ist auf allen Rechnerplattformen verfügbar und ist deshalb ein absolutes MUSS. > Und 'ne Hochsprache setzt auch nur auf Assembler auf, > erfordert Bibliotheken und all so'n Zeugs - eigentlich total > ineffizient. Niemand sagt, dass Hochsprachen ineffizient seien. Diesen Unfug haben doch eher die Glaubenskriege eingangs in diesem Thread angezettelt. Ich habe lediglich mal angedeutet (quasi am Rande), dass man sich schon mal fragen kann, warum eigentlich ein popeliges Hallowelt Progrämmchen derart aufgebläht sein muss oder warum manche Programme sich unglaublich viel Hauptspeicher unter den Nagel reißen (darunter zählt auch (soweit mir bekannt) das von QT Produzierte). Wer Mikrocontroller programmiert, der sollte das auch verstehen können. Man kann auch in Assembler Windows Programme schreiben, ist wahrscheinlich sogar die beste Programmiersprache um zu verstehen, was genau beim Programmablauf passiert. Mit den entsprechenden Makros unterstützt muss das nicht mal in Tipporgien ausarten. Dennoch würde ich einem Anfänger diesen Weg nicht empfehlen. In C tut man sich da um einiges leichter und kommt schneller zum Ziel ohne sich zu weit von der "Systemebene" entfernt zu haben. > Also programmierst du von heut an nur noch Assembler... Betriebssystem > ist eigentlich auch Käse, geht viel besser ohne. Ich dache du bist Profi? Jetzt wirst du reichlich albern. > Mal ehrlich, hast du drüber nachgedacht was du da geschrieben hast? Aber freilich und fortwährend. > Die > Toolkits machen alles leichter, und nix komplizierter. Das ist so > ziemlich der einzige Grund wieso es die überhaupt gibt. Das ist blanker Unsinn! Die Toolkits machen überhaupt nicht alles leichter. Leichter wird es erst dann, wenn die Programme umfangreicher werden. Die Art wie die MFC Windows Nachrichten "zerstückelt verarbeitet" macht nur Sinn, wenn das Programm einen gewissen Umfang hat und dadurch die herkömmliche (eine) Nachrichtenschleife immer länger und unübersichtlicher zu werden droht. Dafür macht (das ist meine subjektive Erfahrung) die Syntax der MFC den Quelltext unleserlicher (gegenüber der reinen Win32 API). Klassen und abgeleitete Klassen in Toolkits, Polymorphie usw. machen auch nur Sinn, wenn ein entsprechend größeres Softwaresystem dabei rauskommen soll, der Lernaufwand ist sonst einfach zu groß. Ich habe immer und immer wieder als Kritikpunkt oder Anregung (je nach dem wie man das benennt) bei QT gelesen, möglichst erst die Objektorientierte Programmierung zu beherrschen und dann QT verwenden und nicht umgekehrt. Wenn so viele Anwender das sagen, dann muss da auch was dran sein und wenn ich mir die komplexeren Beispiele anschaue, dann drängt sich mir dieser Eindruck der Leute ebenfalls auf. OOP lernt sich aber nicht in ein paar Tagen. Das braucht Zeit, viel Zeit. Das ist eine völlig andere "Denke". QT stellt einen Haufen Methoden bereit. Alleine da die Übersicht zu behalten ist weder einfach, noch "leicht". Ich bin auch gar kein Gegner von QT, wxWindows oder gtkmm. Nur wäre ich vorsichtig diese Toolkits dem Anfänger als "leicht" zu verkaufen. Jedes Toolkit erhöht erst mal die Komplexität und erfordert Einarbeitung in das Toolkit selbst. Schon die Einbindung von QT in eine IDE wie Visual Studio Express ist nicht einfach, wie man in entsprechenden Foren nachlesen kann. Im übrigen, wenn Toolkits die Windows-Programmiererei soooo einfach machen würden, dann wären VisualBasic, RealBasic, PureBasic und ähnliche Produkte längst in der Versenkung verschwunden. Die leben nämlich alle davon den Leuten die Angst vor der Kompliziertheit Windows Programme in Sprachen wie C, C++, Delphi o.ä. schreiben zu müssen abzunehmen. Wirklich einfacher wird's wahrscheinlich nur mit einer Skriptsprache, aber dann wird die Freiheit des Programmierens auch meistens spürbar eingeschränkt oder es gibt einfach nicht hinreichend guten Beispielcode für alle möglichen Problemstellungen. > Man muss übrigens nicht selber Artikel schreiben die Artikel andere > Leute bewerten zu dürfen (vor allem was den Inhalt angeht). AS ist auch > nur ein Mensch. Ich hab ihn auch nicht zum Gott erklärt, aber seine Artikel haben Hand und Fuß und seine Programme die er geschrieben hat übrigens auch. Aber darum geht es hier im Thread nicht. (irgendwie tut mir Paul Hamacher langsam leid)
Ich hab langsam keine Lust mehr. Die MFC ist sehr kompliziert, du hast ein Haufen Zeugs um das du dich kümmern musst (wie zB. die von dir angesprochenen Nachrichten - damit musst du dich in GTK zB. nicht großartig beschäftigen). Die Toolkits sind alle recht übersichtlich gehalten, brauchen dafür vll einmal 1MB Ram (einmalig - dann laufen zB. alle GTK Programme ohne Mehrverbrauch). Dafür musst du dich um den ganzen Sch*** von der MFC nicht mehr kümmern (zum mitschreiben: wenig komplexes kommt dazu, viel komplexes fällt weg... na, was macht das unter dem Strich?... Nein, es wird nicht komplizierter, sondern einfacher). Trotzdem pochst du hier stur wie'n Esel auf die MFC. Von Ressourcenverschwendung solltest du lieber garnet erst anfangen, du nimmst windows. Schau dir mal Fluxbox auf'm 486er an, dann können wir über Ressourcenverschwendung reden. XFCE ist übrigens auch ein sehr schneller Windowmanager, zufälligerweise baut der auf GTK auf. Rechner auf denen XFCE läuft würde der windows installer nichtmal mit Handschuhen anfassen. Schreib doch was du willst.
Da ich als Anfänger überhaupt nicht beurteilen kann, was mir persönlich nun leichter fällt, kann ich einfach irgendwo ins Blaue tippen und irgendeine Programmiersprache mit irgendeinem Toolkit wählen dessen Code mir, Programmbeispielen zu Urteile, möglichst einfach vorkommt und viel erreicht. Ob die Einfachheit des Codes nur durch übermäßig großes Hintergrundwissen über das verwendete Toolkit, OOP,... usw. zustande gekommen ist.. keine Ahnung. Was ist wenn ich nun einfach mal C# nehme ;-)
Hallo Paul, Nimm C# Die Diskusion bringt Dich nicht weiter, ich habe selber C# als Freizeitprogrammierer angetestet und muß sagen, es ist völlig OK . Gruß Sebastian P.S. Sollte ein QT Guru hier mal reinschauen mein Problem von oben ^ besteht immer noch ;-)
>Welche Programmiersprache empfehlt ihr mir? (Windowsprogrammierung)
Delphi.
@Sebastian Bei W2K und XP hatte ich eigentlich noch keine Probleme bei der Installation von Qt4 nach der http://www.haiq.info - Methode. Von Vista sind mir auch keine Probleme bekannt, kann ich aber nicht ausschließen, weil ich es nie probiert habe. In der Anlage findest Du einen screenshot meiner Einstellung der Umgebungsvariablen (aber W2K), womit alles hervorragend funktioniert. Zudem das kleine Testprogramm 'HaiQ-Tester.exe', mit dem nach der Installation alle Einstellungen noch einmal überprüft werden. Wenn das läuft, ist Deine Installation OK. Dann solltest probieren, eine simple Lektion, wie im Lehrgang beschrieben, mit der HaiQ-IDE zu compilieren. Wenn es dann noch Probleme geben sollte, sind die Jungs vom http://www.qtcentre.org/forum/ die besten Ansprechpartner. toi.. toi.. toi..
Hi @Suchender: Genau! MfG Spess
delphi mag ich nicht ];-> nein, ich nehm einfach mal C#, ich denke ich werde dabei nicht allzuviel falsch machen. Fragt sich nur noch welches das richtige Buch dafür ist. Ich denke ich frag mal in nem extra Thread nach. lg PoWl
Hallo G. Bremer, danke für Deine Antwort. Die Installation verläuft problemlos, ein Test danach ist auch positiv, nur das kompilieren, oder besser gesagt das Makefile bauen bricht mit dem von mir genannten Fehler ab :-( Nachdem es mit HaiQ nicht funktioniert hat, hab ich es in der Konsole versucht "qmake-qt4 -project" und "qmake-qt4" bricht mit dem Fehler ab. Ich vergleiche Deine Umgebungsvariablen mit meinen, danke dafür Gruß Sebastian
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.