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

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

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.

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

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

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/

Danke!

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.

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

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.

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

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.

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.

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

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

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

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

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:

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

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

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

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.

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.

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.

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

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

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