Welche Programmiersprache empfehlt ihr mir? (Windowsprogrammierung)

[Paul H. (powl)]

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

[madler (Gast)]

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.

[Maik F. (sabuty)]

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.

[Paul H. (powl)]

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

[Gerard C. (gerardchoinka)]

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)

[A. N. (netbandit)]

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.

[Paul H. (powl)]

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

[Εrnst B. (ernst)]

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.

[Simon S. (herrbert)]

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.

[Martin (Gast)]

Keine Ahnung was ihr macht .. aber ich lerne Haskell :)

[Maik F. (sabuty)]

Martin wrote:
> Keine Ahnung was ihr macht .. aber ich lerne Haskell :)

Aber sicher nicht für die GUI-Windows-Programmierung :D

[Andreas W. (Gast)]

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.

[A. N. (netbandit)]

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!

[Stefan B. (stefan)]

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 ;-)

[Εrnst B. (ernst)]

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/

[Stefan B. (stefan)]

Danke!

[Jürgen Schuhmacher (Gast)]

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 ?

[Stefan B. (stefan)]

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)

[Simon K. (simon)]

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.

[Johnny (Gast)]

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.

[Matthias (Gast)]

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.

[Sven P. (Gast)]

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 ;-)

[Simon K. (simon)]

Matthias wrote:
> keine Objektorientierung [...] erforderlich.

Und ich dachte immer Objektorientierung wäre ein Konzept, was dem 
Programmier entgegenkommt ;)

[Markus (Gast)]

> ...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

[Ja mann (Gast)]

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.

[I_ H. (i_h)]

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.

[Johnny (Gast)]

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...

[I_ H. (i_h)]

> 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.

[tom (Gast)]

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.

[Εrnst B. (ernst)]

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...

[Paul H. (powl)]

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

[A. N. (netbandit)]

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.

[Paul H. (powl)]

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 :-)

[madler (Gast)]

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.

[I_ H. (i_h)]

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 .

[Paul H. (powl)]

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.

[Daniel (Gast)]

@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

[spess53 (Gast)]

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

[Icke (Gast)]

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.

[Paul H. (powl)]

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

[I_ H. (i_h)]

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.

[Paul H. (powl)]

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

[Christian R. (supachris)]

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#

[A. N. (netbandit)]

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.

[spess53 (Gast)]

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

[Thomas W. (thomas_v2)]

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).

[I_ H. (i_h)]

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#.

[Paul H. (powl)]

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

[Ralf (Gast)]

> 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

[Paul H. (powl)]

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

[Johnny (Gast)]

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.

[Arc N. (arc)]

> 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

[Rufus Τ. F. (rufus)]

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.

[I_ H. (i_h)]

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.

[Johnny (Gast)]

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. (i_h)]

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.

[G. B. (picoli)]

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

[yalu (Gast)]

@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.

[Arc N. (arc)]

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.

[I_ H. (i_h)]

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:

foo
 |-int: 123
 |-float: 456
 |-vector (3)
 |- |-vector (3)
 |- |- |-int: 0
 |- |- |-int: 1
 |- |- |-int: 2
 |- |-vector (4)
 |- |- |-int: 0
 |- |- |-int: 1
 |- |- |-int: 2
 |- |- |-int: 3
 |- |-vector (5)
 |- |- |-int: 0
 |- |- |-int: 1
 |- |- |-int: 2
 |- |- |-int: 3
 |- |- |-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++.

[Gelegenheitsprogrammierer (Gast)]

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!

[Daniel (Gast)]

@yalu
Ich glaube ich habe meine Werkzeugkiste ausm selben Laden wie Du^^

[I_ H. (i_h)]

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 ;).

[Gelegenheitsprogrammierer (Gast)]

> 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.

[Me (Gast)]

>> 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.

[Gelegenheitsprogrammierer (Gast)]

> 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.

[Me (Gast)]

>> 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.

[I_ H. (i_h)]

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.

[Simon K. (simon)]

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!

[Paul H. (powl)]

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

[I_ H. (i_h)]

> irgendwann zerreiße ich mich noch slebst, die eine hälfte [...]

Je früher du das lernst, desto besser. Das ist ungemein praktisch ;)

[Simon K. (simon)]

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 ;)

[Gelegenheitsprogrammierer (Gast)]

> 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;))

[I_ H. (i_h)]

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.

[Sebastian (Gast)]

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:

Error processing meta file: C:\Qt\4.3.2\lib\qtmain
Error processing meta file: C:\Qt\4.3.2\lib\qtmaind
Error processing meta file: C:\Qt\4.3.2\lib\QtGuid
Error processing meta file: C:\Qt\4.3.2\lib\QtCored
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

[Me (Gast)]

>> 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.

[Gelegenheitsprogrammierer (Gast)]

> 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.

[Happy Coder (Gast)]

>> 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.

[Gelegenheitsprogrammierer (Gast)]

> Du übertreibst maßlos und merkst es nicht mal.

So? Ich fand die Artikel von A.S. immer sehr sinnig und informativ.

[I_ H. (i_h)]

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.

[Gelegenheitsprogrammierer (Gast)]

> 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.

[I_ H. (i_h)]

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.

[Gelegenheitsprogrammierer (Gast)]

> 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)

[I_ H. (i_h)]

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.

[Paul H. (powl)]

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 ;-)

[Sebastian M. (izaseba)]

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 ;-)

[Suchender (Gast)]

>Welche Programmiersprache empfehlt ihr mir? (Windowsprogrammierung)

Delphi.

[G. B. (picoli)]

@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..

[spess53 (Gast)]

Hi

@Suchender: Genau!

MfG Spess

[Paul H. (powl)]

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

[Sebastian M. (izaseba)]

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