Anfänger-Noob-Fragen zu C++ (und MS Visual C++)

[aths]

Einige Fragen hier mögen für jemanden der in C oder C++ programmiert, extrem dämlich klingen. Ich habe in C bzw. C++ bislang nur Textkonsolen-Anwendungen geschrieben und bin dabei überwiegend dem funktionalem Programmier-Paradigma gefolgt. Dinge wie Pragma oder Namespace sagen mir wenig.

Um nicht ständig neue Threads zu eröffnen, werde ich hier neue Fragen ergänzen. Was bereits beantwortet ist, werde ich dann hier durchstreichen.


1) MS Visual C++ 2010 Express legt für das Projekt eine *.cpp und für das Windows-Formuluar eine Form1.h an. Wenn ich auf die Eigenschaft von zum Beispiel einem Label klicke, gelange ich in die Form.h-Datei. Gehört dort der Code hin, der bei dem Event abgearbeitet werden soll, oder gehört der Code in die cpp-Datei?

2) Zum Warmwerden will ich Timer-basiert eine Zahl hochzählen und diese Zahl als Inhalt eines Labels ausgeben. Wie kann ich von einer beliebigen Stelle auf das Label1 von Form1 zugreifen? Edit: Innerhalb der Form1.h funktioniert this->label1->Text. Solange in die Form1.h Code gehört, wäre das Problem gelöst.

3) Ich überlege, Punkt 2 anders zu lösen, nämlich in der Form-Klasse selbst eine Methode hinzuzufügen, um von dort aus den Inhalt des Labels zu ändern und von anderen Funktionen aus lediglich diese Methode aufzurufen, anstatt aus der anderen Funktion direkt auf die Form-Label-Caption-Eigenschaft zu gehen. Ist das ein richtiger Ansatz oder sollte ich lieber versuchen, statt für das Form für das Label eine neue Methode zu schreiben? Ist so ein Stil überhaupt gut oder bläht das nur den Source-Code unnötig auf?

[Gast]

Ich hätte einen Vorschlag für Punkt 0. :)
Du programmierst grade kein C++ mehr, sondern C++ CLI.
Dieses ist eigentlich nur dafür gedacht C++ schön für die MSIL wrappen zu können. Willst du also GUI Programmierung machen, hol C#. Per CLI ist das einfach nur ein Krampf^10.

[aths]

Das Problem ist, dass die Headerfiles die ich für ein anderes Projekt habe, für C sind, nicht für C#. Ich müsste die für C# umschreiben, also sowohl C als auch C# können. Ich hoffe, C-Headerfiles direkt in C++/CLI verwenden zu können.

[Trap]

Berechtiger Hinweis vom Gast. Sobald im Code solche Variablen wie "^args" auftauchen ist man im C++/CLI von MS und nichtmehr im Standard C++.

Das Angebot von MS für GUIs mit C++ ist im Moment etwas blöde, die alten MS-Frameworks sind wirklich alt und mittlerweile überholt (MFC...), das aktuelle (WPF oder Silverlight) ist in .NET "gefangen" und man kommt mit C++ schlecht dran und die neue Variante über WinRT gibt es bis jetzt nur Developer Preview in Windows 8. Direkte Nutzung der Win32-Api macht auch keinen Spaß.

Die einfachsten Möglichkeiten für GUIs in C++ wären im Moment Opensource Frameworks wie http://qt.nokia.com/products/ oder http://www.wxwidgets.org/.

Edit: Ja, für die Verwendung als Wrapper ist C++/CLI gedacht. Du erzeugst eine C# Anwendung für die GUI und eine C++/CLI Bibliothek als Wrapper für die C-Bibliothek. QT oder wxWidgets mit nur reinem C++ ist aber auch eine gute Lösung.

[aths]

Auch in dieser Version müsste ich mich zusätzlich noch mit C# befassen, dann könnte ich gleich versuchen, eine DLL zu schreiben die ich Delphi benutze (ich habe Delphi-Programmiererfahrung.) Dann müsste ich mich aber damit befassen, wie man DLLs schreibt und wie man sie nutzt. Ich vermute dass es einfacher ist, die Oberfläche dann gleich in Visual C++ zu schreiben, dann kann ich mir das Bibliothekschreiben ersparen und muss lediglich die Konventionen kennen, wie ich die Windows-Fenster-Elemente bediene.

[Gast]

Das Problem ist, dass die Headerfiles die ich für ein anderes Projekt habe, für C sind, nicht für C#. Ich müsste die für C# umschreiben, also sowohl C als auch C# können. Ich hoffe, C-Headerfiles direkt in C++/CLI verwenden zu können.
Wenn du C Interfaces hast, koenntest du das auch einfach in eine DLL packen und per P/Invoke aus C# drauf zugreifen. Dann hättest du eine Programmiersprache weniger. ;)

1) Welcher Code in den Header und welcher in die Quelldatei gehört, ist eine ewige Grundsatzdiskussion. Wegen der Funktionsweise von C++ Parsern (bzw eher historischen Gründen), macht es bei C++ immer Sinn den Quellcode in die CPP zu verschieben. Modernen Programmiersprachen verzichten nicht umsonst auf die Trennung.
2) Programmiersprachen-unabhängig: Willst du auf auf eine Methode/Property/Membervariable eines Objektes zugreifen, muss diese im Public Interface verfügbar sein und musst du irgendeine Referenz auf dieses Objekt besitzen. Bist du in Form1, ist dieses Referenz "this". Woanders musst du dich selbst drum kümmern.
3) Das was du suchst ist ein Property, das den Text des Labels ändert. Dank des .Net Hintergrunds, sind diese auch in CLI verfügbar.

[aths]

"Einfach" in eine DLL packen – ich habe bislang noch nie was in eine DLL gepackt und weiß nicht wie das geht. P/Invoke sagt mir ebenfalls nichts.

[PatkIllA]

http://en.wikipedia.org/wiki/Platform_Invocation_Services
Je nach benötigten Datenstrukturen kannst du recht einfach die Funktionen aufrufen.

Und wenn du neu einsteigst und sowieso CLI macht würde ich auch gleich auf C# und WPF setzen.

[Trap]

Es geht doch nur darum eine C-Bibliothek zu benutzen, da ist C# und WPF lernen völlig am Ziel vorbei und 1000% Overkill. Ich find beides lohnenswert zu lernen, aber mit dem Problem hier hat es wenig zu tun.

DLLs sind ziemlich einfache Dinge, vielleicht nicht so anfängerfreundlich dokumentiert wie GUI-Tools, aber trotzdem Größenordnungen einfacher: http://msdn.microsoft.com/en-us/library/1ez7dh12.aspx

[PatkIllA]

Eigentlich ist das ganze schon Overkill, weil er eine DLL ja eigentlich in Delphi nutzen will. Ich weiß zwar nicht wie, bin aber verdammt sicher, dass es auch direkt geht. Siehe ein paar Threads weiter unten.

[Nagelbrett]

Falls du dich doch entscheidest, von Delphi weg zu gehen, gibt es eine quasi fertige Lösung für dein DLL Problem in C# hier: http://code.google.com/p/open-hardware-monitor/source/browse/trunk/Hardware/Nvidia/NVAPI.cs
Das stammt aus dem open-hardware-monitor Projekt, einem quelloffenen (Mozilla Public License) Nachbau von CPUIDs HWMonitor und lädt die nvapi.dll direkt.

[aths]

Wenn ich das richtig sehe, enthält diese Datei Codes ähnlich wie die IDs in der nvapi.pas. Das probiere ich morgen mal aus.

edit: Ich habe jetzt, wenn auch in einer falschen Property, den Fan-Speed in Delphi. Das nächste Problem sind Taktraten. Die OpenHardwareMonitor-Software kann ich da nicht nachvollziehen, das muss ich mir noch genauer ansehen.