Hallo, ich bin gerade dabei C++ zu lernen. Ich nutze Visual Studio 2008 Professionell. Jetzt wollte ich für ein Projekt ein Interface für einen Atmega schreiben, also der PC soll die vom Uc gelieferten Daten auswerten, und welche zurückschicken. Das ganze wollte ich über RS232 machen. Das klappt auch schon soweit. Nur mein Problem ist. Ich brauche ja eine Benutzeroberfläche um die muss man sich ja beim uc zum Glück nicht kümmern. Ich habe jetzt die Wahl entweder ich mache das ganze in der Konsole. Aber da sehe ich das Problem, das ich ja zur Bedienung Eingaberoutinen brauche. Und so ein Cin hält ja das komplette Programm an. Das ist aber nicht gut, da das Programm ja noch mit dem UC kommunizieren soll im Hintergrund. Oder ich mache das ganze mit einer Grafischen Oberfläche MFC oder ähnlichem. Wäre das einem absolutem Anfänger zu empfehlen? Ist es damit leichter im Hintergrund Sachen abzuarbeiten? Da die Grafische Oberfläche ja auf Multitasking basiert? Viele Grüße
> Und so ein Cin hält ja das komplette Programm an. > Das ist aber nicht gut, da das Programm ja noch mit > dem UC kommunizieren soll im Hintergrund. Das kann es aber auch ohne graphische Oberfläche - das Stichwort hier ist Multithreading. Die Kommunikation kannst Du in einem eigenen Thread ablaufen lassen, und die Eingabe/Ausgabe erfolgt getrennt davon im Hauptthread. Du musst nur geeignete Mechanismen zur Synchronisation der Threads verwenden, die sind erforderlich, wenn beispielsweise der Hauptthread dem Kommunikationsthread mitteilen will, daß Daten vorhanden sind, die zu versenden sind. Aber dafür existieren geeignete Synchronisationsobjekte wie z.B. die Critical Section. Eine graphische Oberfläche nimmt Dir dieses übrigens nicht ab, auch hier empfiehlt es sich, die Kommunikation in einen im Hintergrund laufenden "Worker-Thread" zu verlagern.
Kannst du mir dazu Literatur empfehlen? Im Moment lese ich gerade C++ von A bis Z. Da sollte das Multitasking später auch noch kommen. Ich suche nur noch ein Buch, wo verstärkt auf Visual Studio eingegangen wird. Und auch vlt. da in Verbindung mit Multitasking. Und gibt es generell Einwände, das ganze gleich Grafisch zu machen? Viel Soll das Programm von der Oberfläche nicht können. Außer ein paar Werte auf dem Atmega auszulesen, und auf Knopfdruck ein paar Befehle via RS232 zu senden. Es wäre halt gut, wenn ich es hin bekommen könnte, das z.B. auf der Grafischen Oberfläche eine Variable aktuell angezeigt wird, also sobald die vom UC kommt, dass dann die Anzeige geändert wird. Bei der Konsole sehe ich das Problem, dass für den Eigentlichen Grundaufbau also Menüs etc. sehr viel Zeit in Anspruch genommen wird, während ich in Visual Studio mit einem Klick einen Button habe.
Hallo, verwende doch c# oder Java für das PC-Programm. Das ist viel einfacher als C++.
Hase schrieb: > Hallo, > > verwende doch c# oder Java für das PC-Programm. Das ist viel einfacher > als C++. Die Idee ist gut, das Argument schlecht. Meine Sachen für Windows mache ich nur noch in C#, eine wunderbare Sprache. Von vornherein auf Objektorientierung ausgelegt und nicht irgedwie reingebaselt wie bei C++ und vorallem da mächtige .net Framework im Hintergrund. Zitat Larry Wall (Erfinder von Perl): "Eine gute Programmiersprache macht einfaches einfach und kompliziertes möglich". Das trifft IMHO genau aif C# zu, Bei C++ ist zwar alles möglich, aber leider eben auch (zu) viel zu kompliziert.
Also ich würde schon gerne bei C++ bleiben, da mir die Sprache eigentlich zu sagt. Ich habe auch schon 500 Seiten dazu gelesen. Das wäre Dann umsonst, und ich müsste nochmal komplett mit C# von vorne anfangen.
schau Dir mal Qt an. Das hat elegante Unterstützung für Threads und IIRC auch serielle Kommunikation.
So also Qt habe ich mal installiert. Die IDE ist ja ganz schön überladen. Nur finde ich dort keine Serielle Schnittstelle.
Boost hat Unterstützung dafür: http://www.boost.org/doc/libs/1_40_0/doc/html/boost_asio/overview/serial_ports.html
Also Boost erscheint mir sehr aufwendig, was ich damit bis jetzt gesehen habe.
Wenn du eh schon in VS 2008 arbeitest, nimm doch statt nativem C++, Managed C++. Dort hast du das ganze .net Framework im Rücken. Sachen wie Multithreding, serielle Schnittstelle, GUI sind damit sehr einfach und trotzdem mächtig.
Hallo, wenn es um die Programmierung von Benutzeroberflächen unter Windows geht, dann ist c# oder Java viel einfacher als c++. Siehe dazu auch: Jochen Kalmbach: C++/CLI und WinForms macht keinen Sinn Die Vorteile beider Sprachen: - Das Framework für die GUI ist integriert. - Viel weniger Ärger mit Zeigern. - Der Compiler ist pingeliger. Das ist für Anfänger sehr wichtig. Viel Spass.
Markus W. schrieb: > So also Qt habe ich mal installiert. Die IDE ist ja ganz schön > überladen. Die muß man ja nicht benutzen. > Nur finde ich dort keine Serielle Schnittstelle. Qt selbst enthält dafür keinen Support. Da müßtest du noch z.B. QExtSerialPort installieren. Andreas Kanzler schrieb: > Wenn du eh schon in VS 2008 arbeitest, nimm doch statt nativem C++, > Managed C++. Das halte ich für so sinnvoll wie einen Kropf. Das ist im Kern eigentlich ein C# mit einer in Richtung C++ verbogenen Syntax. Mit echtem C++ hat das nicht mehr viel zu tun, auch wenn's auf den ersten Blick wie C++ aussehen mag. > Dort hast du das ganze .net Framework im Rücken. Sachen wie > Multithreding, serielle Schnittstelle, GUI sind damit sehr einfach und > trotzdem mächtig. Und sehr plattformgebunden.
Wenn du gern mit nativem C++ arbeitst dann lies das Buch durch. Umsonst ist das auf keinen Fall! Multithreading ist in C++ zwar nicht ganz so einfach wie in C#, dafür ist der Lerneffekt größer ;) Selbst wenn du später die GUI mit C# oder Java schreibst hast du einen viel schnelleren Einstieg, denn das meiste ist ähnlich. managed c++ ist eine Krücke! Wenn du unbedingt mit C++ unter Windows eine Gui bauen willst nimmt man entweder C++/CLI oder eben Qt
Hi, hat jemand Erfahrungen mit der benutzung von Boost in einem Qt-Programm? Ist das ohne weiteres moeglich - also funktioniert z.b. das Signal/Slot - Konzept weiterhin, etc?
brott schrieb: > Hi, hat jemand Erfahrungen mit der benutzung von Boost in einem > Qt-Programm? Ist das ohne weiteres moeglich - also funktioniert z.b. das > Signal/Slot - Konzept weiterhin, etc? Ich hab das zwar bisher nicht versucht, aber ich sehe keinen Grund, warum es nicht funktionieren sollte. Wo siehst du da ein Problem?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.