OOP Grundaufbau

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.

Nexus

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.

SeppJ

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

Nexus

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.

Nexus

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.

l'abra d'or

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!

Du hast verstanden was ich geschrieben hab.

l'abra d'or

ohjeohje schrieb:

Du hast verstanden was ich geschrieben hab.

Was du geschrieben hast hab ich verstanden. Aber deiner Antwort zu entnehmen hast du etwas anderes gemeint...

SeppJ behauptet: Man braucht A um Z zu machen.
ohjeohje sagt: Man braucht A nicht um Z zu machen.
ohjeohje sagt damit nicht: Man darf A nicht verwenden um Z zu machen.
ohjeohje sagt damit auch nicht: Man muss A selber machen um Z zu machen.

Und zu

l'abra d'or schrieb:

So wie es scheint hast du selber noch keine Gui-Anwendung mit rechenintensiver Datenbeschaffung erstellt.

Meine erste Windowsanwendung, die ich vor über 10 Jahren geschrieben hab, war ein kleines Programm zum Verschlüsseln von Dateien. Schön mit nen Dialog mit Statusanzeige und Cancel-Button, der natürlich auch funktioniert. Alles ganz ohne Threads, nur mit Timer. Da muss man sich nicht mal darum kümmern, ob man den Statusupdate synchronisieren muss, damit die GUI nicht irgendwelchen Müll anzeigt, weil es keinen parallelen Zugriff auf Daten gibt. Und auch aus dieser Aussage folgt jetzt nicht, dass das jetzt jeder so machen muss.

l'abra d'or

ohjeohje schrieb:

Alles ganz ohne Threads, nur mit Timer.

Hmm, wie kommst du an das passende TimerInterval? Wartest du zu lange und gibst dem Rechnenden Thread zu wenig Zeit ist die Verschlüsselung inperformant. Andersrum ist der "Thread" vllt. schon fertig, aber der Timer hat noch nicht ausgelöst und alles wartet auf das TimerEvent.
Und auch wenn du für dich die passenden Einstellungen findest, ist der Rechner des Users vllt. schneller oder langsamer.

Es gibt sicherlich viele Möglichkeiten Threads zu umgehen. Aber keine wird so effizient sein wie Entscheidungen über Rechenzeit an das OS auszulagern.
Ich hoffe da kannst du wenigstens zustimmen.

Thread-Synchronisation ist natürlich ein anderes Thema. Da kann man einiges falsch machen. Und Threads sind sicher nicht immer die beste Lösung.

Dravere

l'abra d'or schrieb:

ohjeohje schrieb:

Alles ganz ohne Threads, nur mit Timer.

Hmm, wie kommst du an das passende TimerInterval? Wartest du zu lange und gibst dem Rechnenden Thread zu wenig Zeit ist die Verschlüsselung inperformant. Andersrum ist der "Thread" vllt. schon fertig, aber der Timer hat noch nicht ausgelöst und alles wartet auf das TimerEvent.

Wahrscheinlich macht er es mit einem einzigen Thread und löst einen Timer aus. In der Message-Loop arbeitet er immer alle GUI-Events ab, auch das Timer-Event. Beim Timer-Event macht er immer einen Teil der Berechnung und gibt dann wieder Zeit dem GUI ab, bis das nächste Timer-Event kommt.

Nicht gerade sehr effizient, aber funktioniert
Und man kann auch effiziente GUI Anwendungen mit nur einem Thread schreiben, sofern man nie grössere Arbeiten erledigen muss, was ich durchaus auch schon öfters erlebt habe.

Multitasking/threading ist definitiv nicht unbedingt nötig.

Grüssli

Gibt es irgendwo Beispiele für ein gutes Konsolen Menü? Und wie könnte ich das denn nun am besten machen, das trotz Menü immer Daten von der Seriellen Schnittstelle geholt und verarbeitet werden?