hallo ich möchte visual c++ 6.0 lernen um windows programme zu schreiben, mit denen ich auf die pc schnittstellen zugreifen kann und vielleicht auch dateien bearbeiten (um messwerte usw zu speicher oder so). welches buch könnt ihr empfehlen? wie steht die meinung zu visual c# oder java? was könnt ihr empfehlen? was wird in der industrie verwendet - bzw kann man das einfach so sagen? ich habe vorkenntnisse in basic,c und in c++ habe ich "geschnuppert". in der schule lernte ich mal pascal - ist aber schon länger her. visual basic habe ich versucht...war sehr einfach...aber vbasic ist glaub ich in der industrie nicht so verbreitet wie visual c++ - oder? naja..bin schon gespannt, was da jetzt für meldungen kommen. achja...ich habe mich natürlich schon im google informiert..jedoch fand nur infos..c# braucht irgendein framework installiert, dass man die programme ausführen kann...c# ist neuer als c++...zukunft hängt von ms ab..visual c++ wird nicht aussterben..usw. aber nichts, was sich auf die anwendung selbst bezieht ..also windows programmierung - schnittstellen - grafiken(diagramme) - dateizugriff - verwendung in der industrie. mfg
Hi Hugo, das kommt erstmal darauf an, welchem Betriebssystem Du arbeitest. (Windows 2000, XP oder Vista) Wenn du früher oder später unter Vista entwickeln willst, dann bleibt Dir nur VB.net oder C# übrig (leider). Die Express-Edition gibt es von MS kostenlos zum Download. Für welche Du Dich entscheidest, ist letzten Endes reine Geschmacksache. Bye Klaus
Was, unter Vista soll es kein C++ mehr geben? Das fände ich schon sehr verwunderlich und hab ich auch noch nie gehört. Meine Empfehlung bei derartigen Anliegen ist wie immer python, weil es sich einfach herrlich leicht damit programmiert und viele Bibliotheken verfügbar sind.
Hi Frank, ich sage nicht, das C++ nicht mehr geben soll. MS bevorzugt C# für Vista. Bye Klaus
Hallo,
> MS bevorzugt C# für Vista.
Das kann ich bestätigen. Das ist eindeutig ein Trend, der ersichtlich
wird, wenn man sich z.B. die Zunahme der C#-Beiträge auf
www.codeproject.com ansieht.
Wenn man Vollzeit-Windows-Programmierer werden möchte, ist zur Zeit C#
die richtige Wahl (sieht man auch an den Stellenanzeigen).
Trotzdem ist MS Visual C++ nach wie vor eine
Standard-Entwicklungsumgebung, in der von Programm-Entwicklung bis hin
zu Schnittstellen- und Plugin-Programmierung so gut wie alles möglich
ist. Die Anzahl der verfügbaren (und auch freien) Libraries ist groß,
die Codequalität von Libraraies und Beispielen im WEB sehr gut.
@hugo
Der Schritt von VB zu Visual C++ ist recht groß. Verschaffe Dir doch
einfach sebst einen Überblick, um zu sehen, ob das für Dich in Frage
kommt: 'Helmut Erlenkötter, Objektorientiertes Programmieren für
Windows, rororo' - ein kompaktes, günstiges und gutes Buch zum Thema
Windows-Programmierung unter MS Visual C++.
Gruß
Nils
Nachtrag @hugo: Ein nicht ganz so günstiges Buch zum Thema C und Windows kann ich sehr empfehlen: Peter Prinz, Ulla Kirch-Prinz, C Einführung und professionelle Anwendung, MITP-Verlag, mit CD (u.a. MS C/C++ Compiler, Book-Edition drauf). Ist zwar nicht C++, aber man kann gleich loslegen... Nochmal Gruß, Nils
2. Nachtrag @hugo: Ein gutes Buch für Vb2005 ist Visual Basic 2005 von Michael Kofler. Die Entwicklungsumgebung ist auf einer CD beigefügt. Bye Klaus
Na, dann fehlt der ja noch der dritte Nachtrag zum Beitrag von Frank: > Meine Empfehlung bei derartigen Anliegen ist wie immer python, weil es > sich einfach herrlich leicht damit programmiert und viele Bibliotheken > verfügbar sind. http://www.physik.uni-muenchen.de/kurs/Computing/python/ ist eine ziemlich gute und umfangreiche Einführung zu Python (auch unter Windows). Allerdings sehe ich im Unterschied zu Frank die Anwendung von Python für Windows-Programme (->Oberflächen) eher kritisch, da man sich für eine GUI entscheiden muss und diese auch auf dem Zielrechner vorhanden sein muß (siehe auch Thread ' GUI Builder für Phyton'). Ansonsten: Klar Python ist toll - Erwartungskonform, gute Performance, strukturiert - für WEB-Anwendungen ideal. Wenn einem die GUI-Problematik und das Vorhandensein der Laufzeitumgebung auf dem Zielrechner egal ist - warum nicht! Das gilt sinngemäß natürlich auch für alle .Net-Anwendungen, da dieses Framework konsequent erst ab Windows XP und Vista als vorhanden vorausgesetzt werden kann. Nochmals @hugo: Die Beschäftigung mit C# ist heute gleichbedeutend mit der zusätzlichen Einarbeitung in .Net und XML (auch im Hinblick auf MS Office-Programmierung). Gruß Nils
Wenn du wirklich nur Windows Programmierung machen willst dann nim C#. Da zurzeit durchaus ein Trend zu z.B. Linux da ist finde ich das die cross Plattform Programmierung immer wichtiger wird. C# und Linux, da gibts zwar Ansätze (mono) aber die sind alles andere als perfekt. Das wird sich sicherlich auch niemals ändern. Microsoft entwickelt neue .NET Funktionen, etc. aber die Quellen liegen nicht offen so muss man durch Revers Engineering das ganze auf Linux portieren... Mein persönlicher Favorit ist daher zurzeit c++ (in Form von GCC) und die Qt Lib für die GUI. Damit lassen sich Programme problemlos portieren. Python habe ich auch installiert, aber eher für kleine Scripts als für GUI Anwendungen. Ist aber sicherlich auch interessant, besonders für Anfänger (man wird zum Einrücken gezwungen ;))
Da MS angekündigt hat, Visual FoxPro nicht mehr weiterzuentwickeln, bin ich seit ein paar Monaten auch damit beschaeftigt, mir für die Zukunft eine neue Programmiersprache auszusuchen. Dabei stosse ich immer wieder auf Python. Und wende mich jedes mal wieder davon ab, weil der von dir geschriebene Kod für alle ersichtlich offen auf dem Tisch liegt. Wenn dieses Manko nicht waere, waere Python in der Tat ein Superding.
also...danke mal für die zahlreihen antworten:) ich habe mich jetzt erstmal für visual c# entschieden. es scheint einfacher als vc++..obwohl vc++ mir lieber gewesen wäre. das liegt aber glaub ich daran, da es vc++ schon länger gibt*g*. mfg und danke :)
windows only welt = c#,c++,python,ruby *unixe = c,c++,python,ruby vereinige diese mengen und entscheide dich c++ und python haben die grössten communities
Hi, vielleicht hilft dieser Artikel etwas, um sich für eine Sprache zu entscheiden: Juval Lowy; October 2005 Generics FAQ: Fundamentals http://msdn2.microsoft.com/en-us/library/aa479859.aspx Man beachte insbesonders die eingefügten Beispiele. Bye Klaus
andy wrote: > vereinige diese mengen und entscheide dich > c++ und python haben die grössten communities Nicht nur das. Für Python, sowie C++ gibts das (von meiner Seite aus sehr empfehlenswerte) Open-Source GUI-Toolkit wxWidgets.
Hallo! Ich programmiere nun auch schon seit etwa 1 1/2 Jahre in C++ sowohl auf Windows als auch Linux. - GUI mit FLTK - USB mit libusb-win32 - Serielle rlserial - Parallele, selber ausprogrammiert. Immer wieder gibt es die Argumente wegen Java usw. sind Plattformunabhängig. Dies stimmt ja auch, solange man sich im entsprechenden Framework befindet, will man sich hinauswagen (z.B. USB usw), siehts schon schlechter aus. In C/C++ Programme plattformunabhängig machen ist durch den Präprozessor keine Kunst und man schafft es, dass der Code sowohl unter Windows als auch Linux kompiliert und auch funktioniert!!! Werde mich beruflich jetzt auch mit C# auseinander setzen müssen, wollte aber meine Erfahrungen mit C/C++ und GUI teilen. mfg Weinga-Unity
C++ ist sowieso nur eine Erweiterung zu C, also sollte es Sinn machen, gleich mit C++ anzufangen, damit man nicht umlernen muss, wenn man mal ein paar komplexere Befehle braucht!
Weinga-Unity wrote: > In C/C++ Programme plattformunabhängig machen ist durch den Präprozessor > keine Kunst und man schafft es, dass der Code sowohl unter Windows als > auch Linux kompiliert und auch funktioniert!!! Das würde ja bedeuten, dass API Aufrufe bei allen Plattformen gleich aufgebaut sind.
> Das würde ja bedeuten, dass API Aufrufe bei allen Plattformen gleich > aufgebaut sind. Häh?
Bartli wrote: >> Das würde ja bedeuten, dass API Aufrufe bei allen Plattformen gleich >> aufgebaut sind. > > Häh? Was heißt hier "Häh?". Wenn deine Behauptung oben stimmen würde, dann bräuchte man garnicht plattformübergreifende GUI Toolkits wie wxWidgets, sondern müsste nur den Preprozessor bemühen....
@Simon: Die API's sind natürlich nicht bei jedem OS gleich. Darum
verwendet man dem Präprozessor, um je nach OS den Code entsprechend
anzupassen:
z.B. Schreiben eines Bytes auf die LPT. Man definiert nun eine eigene
Funktion, die je nach OS (durch die #ifdef) andere API's verwendet. Für
das Hauptprogramm, ist das aber dann egal, weil man ja nur die Funktion
writeLPT verwendet -> man kann sowohl unter LINUX als auch unter Windows
kompilieren.
void writeLPT(int basePort, int x) {
#ifdef unix
outb(x,basePort);
#endif
#ifdef _WIN32
(oup32)(basePort,x); // oup32 liegt in einer DLL
#endif
#ifdef _anderes Betriebssystem
// ...
#endif
}
Ein anderes Beispiel ist z.B. eine Klasse für die serielle
Schnittstelle:
http://www.pvbrowser.org/pvbrowser/sf/manual/rllib/html/classrlSerial.html
man sieht auch hier immer die Unterscheidungen für UNIX und WIN32.
Ich hoffe, dass ich es so etwas besser erklären konnte.
mfg Weinga-Unity
Jau, sowas habe ich mir schon gedacht. Aber ich bin mir nicht sicher, inwiefern dein Codeschnipsel überhaupt ein API-Zugriff ist. Ich vermute nämlich, dass es keiner ist. API-Aufrufe gehen ans Betriebssystem. Und solche API-Aufrufe können zum Beispiel für die Steuerung von einer GUI dienen. Also Fenster erstellen, bestücken usw. Und das ist weiß gott noch nicht das komplexeste an API-Calls. Ich sag nur mal Performance-Counter. So und jetzt zeige mir mal, wie du solche Zugriffe per Preprozessor kapseln kannst, sodass man das Programm einmal mit Windows-API-Calls und einmal mit Unix-API-Calls kompilieren kann. Unter Umständen kann es nämlich sein, dass das Fenster-Handling unter Windows und unter Unix (bzw. einem der Windowmanager) vollkommen anders abläuft. Und HIER besteht die Notwendigkeit von zum Beispiel wxWidgets. (Was aber nicht nur ein Toolkit für GUIs darstellt, sondern auch für andere Sachen. Zum Beispiel Sockets)
Hallo Simon.
Ich versteh deine argumentation nicht ganz. z.B. wxWindows sorgt dafür,
dass der Code für eine GUI auf jeder Plattform gleich aussieht
-> es müssen alle Befehle gleich sein
-> die API's der unterschiedlichen Betriebssysteme müssen so gekapselt
werden, dass am Ende wieder das selbe Interface zur Verfügung steht.
Ich hab mir den Source von wxWidgets mal kurz gezogen. Sie teilen
anscheinend wirklich den Code für jedes OS separat auf, aber ich hab
auch Anzeichen für Präprozessor-Verwedung gefunden. wxWidgets könnte
(meiner Ansicht nach) sicher auch alles in ein File werfen und mir
Präprozessor die OS unterscheiden, das würde aber vielleicht dann extrem
unübersichtlich.
wxPoint wxFrame::GetClientAreaOrigin() const
{
wxPoint pt = wxTopLevelWindow::GetClientAreaOrigin();
#if wxUSE_TOOLBAR && !defined(_WXUNIVERSAL_) && \
(!defined(_WXWINCE_) || (_WIN32_WCE >= 400 && !defined(_POCKETPC_)
&& !defined(_SMARTPHONE_)))
wxToolBar * const toolbar = GetToolBar();
if ( toolbar && toolbar->IsShown() )
........
Falls ich jetzt das falsch verstanden habe was du meinst, musst du
vielleicht noch konkreter werden.
Wegen API in Präprozessor ja/nein: sieh dir nur der rlSerial-Bibliothek
die Funktion openDevice an! Da wird die Windows-API-Funktion CreateFile
verwendet.
Wenn es natürlich unter dem einen OS eine API gibt, dies im anderen
nicht gibt (oder etwas äquivalentes), muss man sich natürlich etwas
überlegen (vielleicht selber ausprogrammieren).
mfg Weinga-Unity
Weinga-Unity wrote: > Wenn es natürlich unter dem einen OS eine API gibt, dies im anderen > nicht gibt (oder etwas äquivalentes), muss man sich natürlich etwas > überlegen (vielleicht selber ausprogrammieren). Da kommen wir endlich zusammen. Alternativ lassen sich auch Toolkits benutzen, die es für unterschiedliche OSes gibt und die Funktionalität kapseln. Und darauf wollte ich hinaus. Also ist dein Vorschlag einfach (salopp gesagt) alles den Präprozessor machen zu lassen nicht immer die Lösung.
Nochmal als Zusammenfassung:
fertiges Toolkit für unterschiedl. OS:
- Verwendung: ohne Kapselung und Präprozessor
- Implementierung des Toolkits selbst: Kapselung mit oder ohne
Präprozessor
TK1 für OS1, TK2 für OS2, ...:
- Verwendung: eigene Lib mit Kapselung durch Präprozessor oder
Kapselung und getrennte Files für die untersch. OS.
- Impelemtierung der TK1...n selbst: unter Verwendung der OS
spezifischen
Funktionen
kein TK gefunden:
- Verwendung: eigene Lib mit Kapeslung durch Präprozessor oder
Kapselung,
und getrennte Files
Fazit: Man schafft es in C/C++ entweder durch fertige
plattformunabhängige Toolkit's oder eigenen Lib's unter Verwendung von
Kapselung (und Präprozessor) plattformunabhängig zu arbeiten, solange
die Plattformen die Funktionen auch zulassen.
mfg Weinga-Unity
> Was heißt hier "Häh?". Wenn deine Behauptung oben stimmen würde, dann > bräuchte man garnicht plattformübergreifende GUI Toolkits wie wxWidgets, > sondern müsste nur den Preprozessor bemühen.... Pff...wo soll ich was genau behauptet haben? Erst Namen der Poster lesen, dann Leute anfräsen.
Bartli wrote: >> Was heißt hier "Häh?". Wenn deine Behauptung oben stimmen würde, dann >> bräuchte man garnicht plattformübergreifende GUI Toolkits wie wxWidgets, >> sondern müsste nur den Preprozessor bemühen.... > > Pff...wo soll ich was genau behauptet haben? Erst Namen der Poster > lesen, dann Leute anfräsen. Jaja, hab ich auf die schnelle nicht gesehen, dass du das gar nicht warst. Aber man sollte auch nicht wahllos Sätze zitieren und "Häh" darunterschreiben, obwohl es überhaupt keinen Sinn macht dies zu tun.
Ich blick das immer noch nicht so ganz: Kann man jetzt mit C# (Visual Studio) problemlos auf die serielle zugreifen oder nicht?
Ja, SerialPort (ab NET Framework 2.0) http://msdn2.microsoft.com/de-de/library/system.io.ports.serialport.aspx
OK, Klassen um auf die serielle zuszugreifen gibt es. Jetzt brauche ich nur noch ein gutes Buch zum Einstieg in C# und vor allem muss dort beschrieben sein, wie man mit der Klasse SerialPort umgeht. Ich war heute in Darmststadt in der Bibliiothek und hatte ungefähr 5 Bücher zum Thema C# in den Händen. Alle gaben einen guten aber allgemeinen Einblick (vor allem das von Charles Petzold)in die objektorientierte Programmierung zu C#. Über technische Problemstellungen wie Zugriff auf RS232 und FFT etc. habe ich dort aber nicht gefunden. Habt ihr vielleicht eine Empfehlung für mich?
weiß ned ob man sie empfehlen kann, aber bei galileocomputing gibt es zwei openbooks zu c sharp http://www.galileocomputing.de/openbook/visual_csharp/ http://www.galileocomputing.de/openbook/csharp/
Thread beobachten
Seitenaufteilung abschaltenBitte 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.