OOP Grundaufbau
-
Also vorerst soll es einfach nur funktionieren, so wie ich es vorhin beschrieben habe. Und es kam so herüber, als wäre das mit einer Konsolen Oberfläche nicht möglich.
Wenn grafisch würde ich gerne mit einer IDE Arbeiten also käme ja MFC in frage. Mit grafische Oberfläche habe ich bis jetzt nur mit Delphi gearbeitet, als wir das in der Schule hatten. Dort ging das eigentlich ganz gut.
-
SeppJ schrieb:
Der Punkt ist nur, dass man ohne Multitasking keine vernünftig bedienbare grafische Oberfläche bauen kann.
Windows 3.11, das auf DOS aufsetzt, hatte auch kein Multitasking und war "vernünftig bedienbar"
Markus W. schrieb:
Wenn grafisch würde ich gerne mit einer IDE Arbeiten also käme ja MFC in frage.
Mit VS und MFC kannst Du dir ein Grundgerüst für eine grafische Anwendung generieren lassen, z.B. eine Dialogbox. Steuerelemente lassen sich per Drag'n'Drop einfügen und VS erzeugt Handler-Funktionen für Butten-Klicks, Menü-Klicks, usw.
-
Also was wäre denn für meine Anwendung besser geeignet, Konsole oder MFC. Wenn MFC gibt es da ein gutes Tutorial? Das einzig brauchbare, was ich gefunden habe ist dieses, aber das basiert auf einer Veralteten Version von VS.
-
-
Z schrieb:
SeppJ schrieb:
Der Punkt ist nur, dass man ohne Multitasking keine vernünftig bedienbare grafische Oberfläche bauen kann.
Windows 3.11, das auf DOS aufsetzt, hatte auch kein Multitasking und war "vernünftig bedienbar"
Komisch, dann müssen die das Feature wohl wieder entfernt haben. Windows 1.0 konnte noch Multitasking...
-
Also das Tutorial hilft mir leider auch nicht weiter, da alles total anders geworden ist in der 2008 Version.
-
Was wäre denn nun für mein Vorhaben einfacher? In der Konsole bleiben? Wenn ja wie kann ich dann ein Menü programmieren, was unabhängig vom Rest arbeitet, also wo im Hintergrund quasi die Hauptschleife ganz normal weiter arbeitet?
Oder ist es vlt. doch einfacher so ein Programm mit Visual Studio und MFC aufzubauen?
-
SeppJ schrieb:
Z schrieb:
SeppJ schrieb:
Der Punkt ist nur, dass man ohne Multitasking keine vernünftig bedienbare grafische Oberfläche bauen kann.
Windows 3.11, das auf DOS aufsetzt, hatte auch kein Multitasking und war "vernünftig bedienbar"
Komisch, dann müssen die das Feature wohl wieder entfernt haben. Windows 1.0 konnte noch Multitasking...
Das halte ich für ein Gerücht. Beide liefen unter MS-DOS. Multitasking konnten erst die Windows-NT Versionen. Hattest Du eine Endlosschleife in ein Windows-Programm unter 3.11, dann hing der ganze Computer fest.
Markus W. schrieb:
Was wäre denn nun für mein Vorhaben einfacher? In der Konsole bleiben? Wenn ja wie kann ich dann ein Menü programmieren, was unabhängig vom Rest arbeitet, also wo im Hintergrund quasi die Hauptschleife ganz normal weiter arbeitet?
Oder ist es vlt. doch einfacher so ein Programm mit Visual Studio und MFC aufzubauen?Ich finde Menüs sind einfacher unter Windows. Mit VS2008 sollte es auch möglich seine, eine MFC-Dialoganwendung zu erzeugen (Ich habe nur VS2005, damit gehts definitiv).
Du brauchst aber die Vollversion. In der Express Edition sind die MFC nicht enthalten.
-
Als Einstieg in die OOP würde ich nicht gerade mit GUI anfangen. In C++ gibt es viele GUI-Frameworks, und ein grosser Teil davon benutzt fragwürdiges und veraltetes, hässliches C++. Damit würdest du dir wahrscheinlich schlechte Dinge angewöhnen, zumal du noch nicht wirklich ein Gefühl für "schönes Design" hast.
Wenn du wirklich parallel programmieren willst, kannst du Threads benutzen. Aber nur "um den Computer ausgelastet zu haben", auch wenn du die Leistung eigentlich gar nicht benötigst, würde ich das nicht tun. Denn Programmierung mit Threads ist nicht ganz trivial.
Falls du dich doch für diesen Weg entscheidest: Ich kenne zwei plattformunabhängige Bibliotheken, die Funktionalität für Multithreading bereitstellen. Zum einen wäre das Boost, eine Sammlung diverser C++-Bibliotheken, die den Schwerpunkt auf die Sprache selbst legt. Zum anderen hättest du mit SFML ein Multimedia-Framework, das neben Threads auch Funktionalität für 2D-Grafik, Sound und Netzwerk anbietet.
-
Z schrieb:
SeppJ schrieb:
Z schrieb:
SeppJ schrieb:
Der Punkt ist nur, dass man ohne Multitasking keine vernünftig bedienbare grafische Oberfläche bauen kann.
Windows 3.11, das auf DOS aufsetzt, hatte auch kein Multitasking und war "vernünftig bedienbar"
Komisch, dann müssen die das Feature wohl wieder entfernt haben. Windows 1.0 konnte noch Multitasking...
Das halte ich für ein Gerücht. Beide liefen unter MS-DOS. Multitasking konnten erst die Windows-NT Versionen. Hattest Du eine Endlosschleife in ein Windows-Programm unter 3.11, dann hing der ganze Computer fest.
Ich habe nicht gesagt, dass sie es gut konnten. Aber schon die erste Windows Version konnte im Prinzip mehrere Programme ausführen. Und was viel wichtiger ist: Schon damals erlaubte es dem Programmierer, sich sich nicht selber um die grafischen Fensterobjekte kümmern zu müssen, sondern dass die zu den Fensterteilen gehörenden Funktionen bei Benutzung automatisch aufgerufen werden. Dies ermöglicht erst, komplexe GUIs zu schreiben. Man kann sowas natürlich selber schreiben. Habe ich auch schonmal, aber das ist wirklich kein Spaß.
-
SeppJ schrieb:
Ich habe nicht gesagt, dass sie es gut konnten. Aber schon die erste Windows Version konnte im Prinzip mehrere Programme ausführen.
Ja, aber nur wenn die WndProc, die die Messages abhandelt, auch wieder verlassen wurde. Esrt dann hat Windows die WndProc der nächsten Anwendung bedient. Es war "Multitasking", wenn alle Anwendungen mitspielen. Zeigte sich Eine störrisch, dann ging garnichts mehr. :p
-
SeppJ schrieb:
Schon damals erlaubte es dem Programmierer, sich sich nicht selber um die grafischen Fensterobjekte kümmern zu müssen, sondern dass die zu den Fensterteilen gehörenden Funktionen bei Benutzung automatisch aufgerufen werden.
Das geht eigentlich gut ohne Threads, wenn die GUI-Komponenten hierarchisch aufgebaut sind und klare Zuständigkeiten haben. Dann hat der Benutzer eine Hauptschleife, in der eine GUI-Funktion aufgerufen wird, die sich um den Rest kümmert.
Nebenläufigkeit bei GUIs ist vor allem dann wichtig, wenn rechenintensive Vorgänge laufen, während der Benutzer mit der Oberfläche interagieren soll. Oder sonstige Routinen, die am Stück laufen müssen und denen es nicht ausreicht, einmal pro Frame die Kontrolle zu erhalten.
-
Also ich habe gerade mal ein Wenig mit Visual Studio herum gespielt und eigentlich komme ich damit recht gut zurecht. Mit so einem Programm hat man halt sehr schnell eine lauffähige GUI aufgestellt. In der Konsole braucht man ja schon für das Menü eine gewisse Zeit. So erstelle ich einen Button und kann festlegen, was passieren soll, wenn ich drauf klicke.
Also ist mir auf jeden Fall wichtig, dass wenn die Oberfläche läuft permanent noch im Hintergrund mit dem Mikrocontroller kommuniziert werden kann.
Ich habe jetzt mit Visual Studio eine Windows Form Anwendung erstellt. Wie kann ich denn da jetzt in die Hauptschleife meine Kommunikation einbauen, die im Hintergrund erfolgen soll?
-
Ah ich habe gerade entdeckt im Visual Studio gibt es direkt ein Tool "Background Worker" das scheint genau das zu sein, was ich suche.
-
Markus W. schrieb:
Ah ich habe gerade entdeckt im Visual Studio gibt es direkt ein Tool "Background Worker" das scheint genau das zu sein, was ich suche.
Ja, das hört sich verdächtig nach einem separaten Thread an, den Du für Hintergrundprozesse verwenden kannst. Du scheinst eine gute Auffassungsgabe zu haben, weil Du mit Vs schnell zurechtkommst.
Mach weiter so, experimentiere und spiel damit rum. Bei Unklarheiten kosultiere Google mit den passenden Stichwörtern.
-
Zu cmpiler-spezifischen Angelegenheiten haben wir übrigens eigene Unterforen, da wird dir wahrscheinlich besser geholfen (für den Fall, dass MSVC++-spezifische Fragen aufkommen sollten). Es gibt sogar eins für Windows-Forms.
-
SeppJ schrieb:
Der Punkt ist nur, dass man ohne Multitasking keine vernünftig bedienbare grafische Oberfläche bauen kann.
Woher kommt der Quatsch eigentlich immer? Multitasking/threading wird auf Systemen mit nur einem Kern sowieso nur vom OS vorgetäuscht. Die Ideen davon kann man überall in beliebiger Komplexität anwenden. Meistens reicht schon eine simple nicht blockiernde Abfrage der Usereingaben, um eine vernünftig bedienbare grafische Oberfläche zu bauen.
-
ohjeohje schrieb:
Woher kommt der Quatsch eigentlich immer? Multitasking/threading wird auf Systemen mit nur einem Kern sowieso nur vom OS vorgetäuscht. Die Ideen davon kann man überall in beliebiger Komplexität anwenden. Meistens reicht schon eine simple nicht blockiernde Abfrage der Usereingaben, um eine vernünftig bedienbare grafische Oberfläche zu bauen.
Ähm, auch auf nem Multicore-System hast du gute Chancen, dass das OS für eine Multithreaded-Anwendung nur einen Kern verwendet. Lass doch einfach das OS entscheiden, das wird schon wissen was es tut.
So wie es scheint hast du selber noch keine Gui-Anwendung mit rechenintensiver Datenbeschaffung erstellt. Dann wüsstest du dass multithread/multiprocess die einzige bequeme Art sind das Problem zu lösen. Sicher kannst du dir deinen eigenen Scheduler schreiben, der abwechselnd der Gui und dem Rechenteil ausführen lässt. Oder zumindest ein eigenes Design für den Rechenpart, der Die Berechnung stückweise erledigen kann, damit man auch anderen Teilen Rechenzeit geben kann. Aber das wird nie so effizient werden wie das was dir dein OS an die Hand gibt, und außerdem wird es mit dem Wachsen des Programms immer komplizierter und unübersichtlicher. Lass einfach mal noch weitere "Threads" für neue Berechnungen dazu kommen.
Und wenn es doof läuft hast du doch irgendwo wieder eine komplette Blockierung drinnen.
YEAH Baby, Shagadelic!
-
Ich habe ja jetzt zum experimentieren eine Windows Forms Anwendung erstellt. Anscheinend basiert das ganze auf .NET. Ist das für meine Zwecke ausreichend, oder sollte ich mich lieber mit MFC beschäftigen. Ich finde das Windows Forms eigentlich ganz praktisch, da dort schon viel integriert ist, wie zum Beispiel einfacher zugriff auf die Serielle Schnittstelle.
-
l'abra d'or schrieb:
ohjeohje schrieb:
Woher kommt der Quatsch eigentlich immer? Multitasking/threading wird auf Systemen mit nur einem Kern sowieso nur vom OS vorgetäuscht. Die Ideen davon kann man überall in beliebiger Komplexität anwenden. Meistens reicht schon eine simple nicht blockiernde Abfrage der Usereingaben, um eine vernünftig bedienbare grafische Oberfläche zu bauen.
Ähm, auch auf nem Multicore-System hast du gute Chancen, dass das OS für eine Multithreaded-Anwendung nur einen Kern verwendet. Lass doch einfach das OS entscheiden, das wird schon wissen was es tut.
So wie es scheint hast du selber noch keine Gui-Anwendung mit rechenintensiver Datenbeschaffung erstellt. Dann wüsstest du dass multithread/multiprocess die einzige bequeme Art sind das Problem zu lösen. Sicher kannst du dir deinen eigenen Scheduler schreiben, der abwechselnd der Gui und dem Rechenteil ausführen lässt. Oder zumindest ein eigenes Design für den Rechenpart, der Die Berechnung stückweise erledigen kann, damit man auch anderen Teilen Rechenzeit geben kann. Aber das wird nie so effizient werden wie das was dir dein OS an die Hand gibt, und außerdem wird es mit dem Wachsen des Programms immer komplizierter und unübersichtlicher. Lass einfach mal noch weitere "Threads" für neue Berechnungen dazu kommen.
Und wenn es doof läuft hast du doch irgendwo wieder eine komplette Blockierung drinnen.
YEAH Baby, Shagadelic!
