mikrocontroller.net

Forum: PC-Programmierung visual c++,c# oder ganz was anderes?


Autor: hugo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Kehrer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Kehrer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,
ich sage nicht, das C++ nicht mehr geben soll.
MS bevorzugt C# für Vista.
Bye
Klaus

Autor: Nils (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nils (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Kehrer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nils (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;))

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: hugo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Kehrer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Weinga-Unity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das würde ja bedeuten, dass API Aufrufe bei allen Plattformen gleich
> aufgebaut sind.

Häh?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Weinga-Unity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Weinga-Unity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Weinga-Unity (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fallout-Boy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich blick das immer noch nicht so ganz: Kann man jetzt mit C# (Visual 
Studio) problemlos auf die serielle zugreifen oder nicht?

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, SerialPort (ab NET Framework 2.0)
http://msdn2.microsoft.com/de-de/library/system.io...

Autor: Fallout-Boy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: manow (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.