# Häufige Fragen und Irrtümer



## sheel (21. September 2011)

*Wann gerne geholfen wird und wann nicht*
*Winforms (Windows Forms), C#, C++/CLI und C++CX gehören nicht zu C und C++!*
*Was ist der Unterschied zwischen C und C++?*
*C und C++ lernen: Wie fängt man an?*
*Unterschied zwischen Debug und Release*
*Ich bin Anfänger und will Spiele programmieren.*
*Welchen Compiler/IDE verwenden?*
*Libraries für GUI und Grafik*

*Wann gerne geholfen wird und wann nicht*
Wenn man gerne schnelle, freundliche und vor allem hilfreiche Antworten möchte gibt es einige Punkte, die man beachten sollte:

Beschreibt euer Problem so genau wie möglich und in verständlichem Deutsch.
Hier gibts zwar gute Programmierer, aber keine Hellseher.
Wenn etwas "nicht funktioniert", sagt bitte, was. Gibt es Fehlermeldungen? Welche?
Was tut das Programm? Was soll es stattdessen tun?
Um Programmcode einzufügen schreibt bitte vor das Codestück [code=cpp] und danach [/code]. Mit diesen Codetags wird der Code vom Forum passend angezeigt, mit Einrückungen, Zeilennummern, Syntaxhighlighting...
Zeigt euren Code! Ohne kann man bei den meisten Fragen nichts machen.
Falls ihr selbst eine Lösung gefunden habt, teilt sie uns mit!
Dadurch wird anderen mit dem selben Problem auch geholfen. 
Bevor ihr etwas fragt, versucht zumindest einmal, die Lösung über Google zu finden.
Denkt euch einen aussagekräftigen Titel für das neue Thema aus.
Gebt an, welchen Compiler und welches Betriebssystem ihr verwendet. Das erleichtert die Hilfe.
Wenn es um GUIs geht, gebt das verwendete Framework an. Qt, wxWidgets, MFC, Winapi...
Nichts davon ist verpflichtend, aber ihr erhöht die Chance, eine Antwort zu bekommen.

Was man _nicht_ tun sollte:

Einfach immer die Frage wiederholen und auf eine fertige Lösung warten. So läufts nicht. _Ihr_ wollt was von _uns_, ohne Gegenleistung, in unserer Freizeit...da könnt ihr zumindest mithelfen.
Alle 10 Minuten fragen, warum noch keiner geholfen hat und andere User per PM um Antworten anbetteln.
Beleidigend werden, weil ihr eine Antwort bekommen habt, die nicht euren Erwartungen entspricht.

*Winforms (Windows Forms), C#, C++/CLI und C++CX gehören nicht zu C und C++!*
Fragen dazu bitte hier im .NET-Forum stellen. Hier geht es _nur_ um C und C++.

C# ist eine komplett eigenständige Sprache und hat mehr mit Java als C gemeinsam. Wenn man sich nicht sicher ist, ob man C# oder C/C++ verwendet: Mit einem "static void Main" im Code ist es ziemlich sicher C#.

Winforms gehören zu .NET (und damit praktisch zu C#). Auch wenn man denkt, man würde sie in C oder C++ verwenden: Stellt grafik-bezogene Fragen dazu bitte im .NET-Forum. Nicht-Grafik-Probleme können und sollen natürlich weiterhin hier rein. Der Winforms-Teil bezieht sich nur auf die Grafik (Fenster, Buttons, einfach alles was man sieht), nicht auf die anderen C/C++-Funktionen.

C++/CLI und C++CX sind von Microsoft entwickelte Abwandlungen von C++, in einem Fall vom Prinzip her mit C# vermischt, und auch im anderen Fall speziell für WIndowssachen zugeschnitten, In Visual Studio sieht man immer nur "C++", aber nciht alles namens C++ dort ist auch wirklich C++ (seltsame Marketingründe seitens MS). Vor allem wenn man mit Visual Studio C++ lernt besteht die Gefahr, unbewusst diese Spracherweiterungen auch zu verwenden (und zu denken, dass es reines C++ ist).
Die Spracherweiterungen sind nicht automatisch schlecht, aber man muss sich darüber im Klaren sein, dass Programme damit mit anderen C++-Compilern nicht funktionieren, und auch für Betriebssysteme wie Linux nur sehr bedingt einsetzbar sind. Wenn man sich nicht sicher ist, ob man echtes C/C++ hat: "System::", "gcnew" und "^" im Code sind Hinweise auf C++/CLI.

*Was ist der Unterschied zwischen C und C++?*
Vereinfacht gesagt: C++ ist eine Erweiterung von C. In C++ sind einige neue Möglichkeiten für den Programmierer dazugekommen (Klassen, Tempaltes, größere Lib...), die es in C nicht gab. Und ein C-Programm ist praktisch auch ein C++-Programm, das die neuen Sachen eben nicht verwenden (umgekehrt nicht).

Genau genommen stimmt die obige Vereinfachung aber nicht mehr: Seit der Erfindung von C++ hat sich auch C geändert (neue Features erhalten), allerdings nicht immer in die selbe Richtung wie C++. EIn C-Programm kann, je nach dem wie es geschrieben wurde, noch immer auch als C++-Programm verstanden werden, aber eben nicht in allen Fällen. Bestimmte Codeteile in C funktionieren in C++ nixht (Compilerfehler) oder sogar anders (noch schlimmer: Der Compiler sagt ok, aber es macht was Anderes als erwartet).
Zusätzlich gibt es auch viele Dinge in C, die in in C++ auch gültig sind (und das Gleiche machen), die man aber auch anders, mehr auf "C++ - Art", schreiben könnte (wenn man C++ programmieren will): Solche Sachen auf C-Art in ein C++-Programm schreiben wird von vielen Programmierern als schlecht empfunden, vA. weil die C++-Art weniger Möglichkeiten für Programmierfehler bietet oder einfach schönerer "Programmierstil" ist (wobei letzteres natürlich sehr von der persönlichen Meinung abhängt). Auch Lehrer akzeptieren HÜs mit der "falschen" Art eventuell nicht.

Weil die zwei Sprachen trotz allem noch ziemlich ähnlich sind sind viele C++-Compiler auch C-Compiler, können also beide Sprachen verarbeiten. Zum Beispiel in Visual Studio ("Visual C++") kann man auch C programmieren. Für die Sachen, wo es einen Unterschied macht, welche Sprache man will, orientiert sich VS an der Dateinamensendung (programm.c oder programm.cpp).
Andere Compiler wie GCC erlauben das Angeben über die Parameter (zB "-std=...")

*C und C++ lernen: Wie fängt man an?*
Ein Punkt ewiger Diskussionen, und letztendlich lernt jeder auf eine andere Art am Besten.
Meine Meinung dazu ist: Wenn man nur C will natürlich C lernen (klar).
Wenn man beides will mit C anfangen (weil vieles in C++ wiederverwendbar ist, und C für den Einstieg einfacher ist),
Wenn man nur C++ will ... eventuell doch ein paar C-Grundlagen zuerst machen. Ist vermutlich ein angenehmerer Einstieg, C++ ist eine ziemlich umfangreiche Sprache, alles auf einmal kann einen erschlagen.

Als Lernquellen gibt es unzählige Bücher und Internetseiten...eine davon:
C von A bis Z von Galileo.
Dort kann man das Buch, das es auch gedruckt zu kaufen gibt, komplett und kostenlos online lesen. Es ist viel, lasst euch davon aber nicht abhalten. Lesen lohnt sich. Es hilft auch, nach jedem Kapitel einige Übungsprogramme zu schreiben, um das Gelernte zu festigen und eventuelle Unklarheiten oder Missverständnisse aufzudecken.

Aber auch, wenn das die Begeisterung vielleicht dämpft: Wie man am Inhaltsverzeichnis sieht, kann man C nicht in einem Tag oder einer Woche lernen. Das funktioniert mit keiner vernünftigen Programmiersprache, und C ist nicht die leichteste. Wenn ihr es wirklich vernünftig lernen wollt und nicht aufgebt, dauert es Monate bis Jahre.

Wenn ihr das Buch durch habt: Sucht euch selbst eine Aufgabe, wie zB. ein kleines Spiel, ein Chatprogramm, ... Für den Wissensstand gibt es nicht mehr das _eine_ Buch oder Tutorial, aber je nach vorgenommenem Gebiet findet man einiges.
Fangt einfach mal an - Fragen werden sich früh genug ergeben. Nutzt eure Lernquellen und das Internet. Wenn man zu einer bestimmten Funktion eine detaillierte Beschreibung braucht, gibt es online Dokumentationen wie zB. die MSDN. Achtet aber darauf, dass ihr nicht einfach Code irgendwoher kopiert, ohne ihn zu verstehen. Das ist ein Teufelskreis, an dessen Ende man komplett verzweifelt ist.
Für kniffligere Probleme gibts ja dann auch noch immer das Forum hier. Und wenn man sein Projekt geschafft hat hat man nicht nur sein Programm, sondern dabei noch viel dazugelernt. Man wächst mit der Herausforderung.

*Unterschied zwischen Debug und Release*
Die Release-Einstellung ergibt beim Kompilieren einfach das "normale" Programm. Debug ist hauptsächlich für den Programmierer zur Fehlersuche und bietet dafür Möglichkeiten, die es bei Release nicht gibt, ist aber _nicht_ zum Weitergeben geeignet. Nur für den Programmierer.

Genauer: Release-Programme kann man weitergeben, zum Download anbieten, verkaufen usw. usw.,
Debug nicht. Weil:

Debug wird langsamer ausgeführt als Release. Je nach Programm kann das sehr stören.
Debug braucht mehr Festplatten- und Arbeitsspeicher.
Debug braucht zum Starten zusätzliche Dateien am Computer, die meistens mit dem Compiler installiert werden. Andere Leute (Nicht-Programmierer) haben diese Dateien aber oft nicht und können das Debug-Programm daher nicht verwenden.

Wozu ist Debug dann überhaupt gut?
Mit einem Hilfsprogramm, dem sogenannten Debugger (der je nach verwendetem Compiler entweder schon am Computer ist oder nachinstalliert werden muss), kann man den Programmablauf genau untersuchen. Man kann beim gestarteten Programm mitverfolgen, welche Codezeile gerade ausgeführt wird, ständig die Werte der Variablen im Auge behalten, zu Testzwecken auch mal mitten im Programm eine Variable ändern und sich zeigen lassen, wie sich der Ablauf dadurch ändert... zum Fehlerfinden toll. Aber, wie gesagt, nur für den Programmierer interessant.

Auf das Code-schreiben und alles Andere hat das ganze Debug/Release keine Auswirkung. Nur darauf, was beim nächsten Kompilieren rauskommt. Die Programme haben auch, wenn sie normal gestartet werden, keinen sichtbaren Unterschied (außer, vllt., wenn die Langsamkeit/Schnelligkeit auffällt). Nur kann ein Computer ohne Compiler ein Debugprogramm oft nicht starten, und der Fehlersuchmodus geht bei Release nicht.

*Ich bin Anfänger und will Spiele programmieren.*
Sorry, geht nicht. Wirklich nicht. Ganz wirklich.
Lernt zuerst einmal die Grundlagen der Sprache.

Andernfalls wird das nur ein Zusammenfügen von Codeschnipseln, die ihr selbst nicht versteht. Ihr werdet das Spiel auf diese Weise nie fertig bekommen. Und wenn ihr 8 Mal täglich eine Forumfrage stellt, ber der man sich denkt "Was macht der da eigentlich?" werdet ihr von den Stammusern hier bald auch nur noch diese Antwort bekommen: Zuerst Grundlagen lernen.

*Welchen Compiler/IDE verwenden?*
Der Compiler ist das Programm, das denn Programmcode zu einem ausführbaren Programm übersetzt. Eine IDE (Integrated Development Environment) ist ein zum Programmieren spezialisiertes Schreibprogramm, das viele Hilfsfunktionen anbietet und den Compiler über einen Button starten lässt. Auch wenn man es beim Verwenden einer IDE nicht merkt sind das zwei völlig verschiedene Dinge.

Welche man verwendet hängt hauptsächlich vom Betriebssystem ab, sonst eigentlich nur von persönlichen Vorlieben.

Hier eine Liste der Wichtigsten
Compiler

gcc/g++/minGW
Der GNU C-Compiler und sein C++-Äquivalent.
Kostenlos.
Für Windows (minGW) und Linux (und noch mehr).
Ist wirklich "nur" ein Compiler; es gibt aber einige IDEs dafür separat zum Download.
Visual Studio
Ist für mehrere Sprachen, nicht nur C/C++. Man muss aber nicht alles installieren.
Die Express-Varianten sind kostenlos (eingeschränkter Funktionsumfang, reicht aber).
Speziell für Windows. Hat auch eine eigene umfangreiche IDE gleich mit dabei.
ICC
Intel C++ Compiler
Kostenpflichtig, für Windows und Linux.
Für nicht-kommerzielle Linux-Projekte kostenlos (?).
Borland C++
Kostenpflichtig, für Windows.
IDEs

Visual Studio
Zusammen mit dem dazugehörenden Compiler.
Code::Blocks
Kostenlos, für Windows und Linux.
Eclipse
Eine IDE für mehrere Sprachen.
Hauptsächlich bei Java eingesetzt, aber auch C/C++ möglich.
Kostenlos, für Windows, Linux und Mac OS X.
Dev-C++
Lange Zeit veraltet gewesen, wird allerdings seit Juni 2011 wieder weiterentwickelt.
Kostenlos, für Windows.

*Libraries für GUI und Grafik*
GUI=Ein "Fenster" mit Buttons, Textfeldern etc
Da es nicht wie in Java oder .NET-Winforms eine eingebaute, sondern viele wählbare Möglichkeiten gibt, steht man beim Einstieg in den Grafikbereich oft vor der Qual der Wahl.
Hier eine kleine Übersicht über die bekanntesten Bibliotheken und Frameworks.

Qt
Schwerpunkt GUIs
Eine der bekanntesten Möglichkeiten.
Bietet auch die Möglichkeit, die Oberfläche zusammenzuklicken statt zu programmieren.
Für Windows, Linux und Mac OS X (64-bit), C++.
wxWidgets
Schwerpunkt GUIs
Bietet auch die Möglichkeit, die Oberfläche zusammenzuklicken statt zu programmieren.
Für Windows, Linux, Unix und Mac OS X, C++.
Windows Forms
Gehört _nicht_ zu C/C++!
Zur Vollständigkeit: Schwerpunkt GUIs, für Windows.
MFC
Schwerpunkt GUIs
Veraltet.
Bietet auch die Möglichkeit, die Oberfläche zusammenzuklicken statt zu programmieren.
Für Windows, C++.
Winapi
Schwerpunkt GUIs/2D
Im Vergleich zu den Anderen umständlichere Programmierung.
Dafür mehr Möglichkeiten: Alle noch so ungewöhnlichen Sachen machbar,
die über die Normal-Möglichkeiten der anderen Libraries hinausgehen.
Für Windows, C/C++.
SDL/SFML
Schwerpunkt 2D
Für Spiele usw.
Auch Sound etc. integriert.
Für Windows und Linux, C/C++.
OpenGL
Schwerpunkt 3D
Auch für die komplexesten Computerspiele geeignet.
Nichts für Anfänger.
Für Windows, Linux und Mac OS X.
DirectX
Schwerpunkt 3D
Im Gegensatz zu OpenGL auch Sound etc. integriert.
Für Windows.


----------



## SE (21. September 2011)

Top Thema ... aber ich muss dir doch noch ne GANZ BÖSE Frage stellen ... oder besser gesagt zwei :

1) Da ich ja nun jahrelanger Java-Programmierer bin und auch immer mal wieder reinschaue wollte ich mal fragen wie es so mit dem "Lernen einer zweiten Fremdsprache" aussieht : wäre C notwendig um wichtige Grundlagen zu lernen oder könnte ich mit meinem Wissen dierekt in C++ einsteigen ?

2) Was würde sich für JNI besser machen : C/C++ da es das auf allen Plattformen gibt oder C# wegen seiner Nähe zu Java aber dafür die Einschränkung auf M$-Win mit sich bringt ?

Ich finde persönlich dass diese zwei Fragen gerade für Umsteiger von Java wichtig sind und daher auch in die FAQ gehören.
Über ein Feedback *ob PN oder hier* würd ich mich freuen.


----------



## Steiner_B (21. September 2011)

Hallo,

Die FAQs sind wirklich gut geworden, aber kannst du ev. diesen Teil noch ändern?


> .NET bezieht sich nur auf den grafischen Winforms-Teil (Fenster, Buttons, einfach alles was man sieht).


Da .NET nicht nur Winforms ist, sondern eigentlich die ganze Laufzeitumgebung inklusive z.B.: der Garbadge Collection und den meisten Klassen die man in C#/VB/C++CLI verwenden kann. (siehe Wikipedia). Nicht zu vergessen ist natürlich auch WPF/Silverlight


----------



## sheel (21. September 2011)

@SteinerB: Das ist schon klar, aber man darf die Anfänger doch nicht so verwirren 

Ich meine damit nur: Wenn man ein C++/CLI Programm hat, das Winforms verwendet, aber das Problem bei einer davon unabhängigen C-Funktion liegt, muss man nicht ins .NET-Forum posten.
Mir fällt nur keine kompakte, vernünftige, bessere Formulierung dazu ein...

@Spikee: Danke fürs Lob 
Sowas hatte ich mir schon vor Monaten vorgenommen..
nur noch auf die Rechte für den Sticky gewartet 
(Nicht ganz, aber so eine vage Idee war vorhanden).

Zu "C vor C++": Wenn man nicht zu weit in die Feinheiten von C reingreift ist das Lernen von C vor C++ eigentlich kein Mehraufwand. Die gelernten Sachen gibts in C++ ausnahmslos alle noch.
Ich würde eher sagen, besser zuerst pures C, um eine saubere Trennung zu haben.
Alles auf einmal, vom ersten main bis zur OO usw, ist _etwas_ viel für den Anfang.

Zu JNI: Seit wann kann man denn C# einbinden? 
Heißt es nicht Java _Native_ Interface?
Native + C#?
Das wäre für mich was Neues.
Also auch wenn es geht, würde ich ganz klar sagen C.

JNI in die FAQ: Sollte das nicht eher auf die Javaseite?
C vs C++ in die FAQ: Steht schon da 

Gruß


----------



## SE (21. September 2011)

@sheel
Danke für deine Antwort.
Was JNI und C# angeht : keine Ahnung ob das möglich ist ... war nur so die Vermutung da C# ja stark von Java beeinflusst ist ... hätte ja sein können das sich M$ da eine Option offen hält. Das javah laut Doc nur C kann glaube ich nicht ... zumindest C++ sollte drin sein.
Auch werde ich deinem Rat folgen erst pure C zu lernen ... auch wenn ich am Anfang bestimmt Probleme haben werde eben kein OO verwenden zu können *oder is OO auch in C möglich ?*.
Der Hinweis das JNI und C lieber in die Java-FAQ sollte *haben wir sowas eigentlich ? xD* stimmt schon ... aber ich dachte das man es hier vielleicht noch erwähnen KÖNNTE bezüglich des Einsteiges.


----------



## sheel (21. September 2011)

Zu MS und Option offenhalten: Das wäre ein irrsinniger Aufwand, das ganze System alternativ nativen Code unterstützen zu lassen. Sehr unwahrscheinlich. Und davon hätte ich dann auch schon mal was gehört, dass der Compiler wahlweise native Exe macht.

OO in C: Nein, tut mir leid. Nur funktional/imperativ.

JavaFAQ: Ja, haben wir sowas? 
Wenn nicht könnte man ja eine machen...


----------



## deepthroat (30. Oktober 2011)

Hi.





sheel hat gesagt.:


> OO in C: Nein, tut mir leid. Nur funktional/imperativ.


Das sehe ich anders. Nicht zuletzt war C++ ursprünglich nur eine Anzahl von Makros und nannte sich "C with classes".

Auch gibt es einige (wenige?) C Bibliotheken die nach objektorientierten Gesichtspunkten geschrieben sind. MIr fällt da z.B. GTK+ mit der GObject Bibliothek ein. Objekte haben Methoden (den "this" Pointer muss man freilich selbst übergeben) und Konstruktoren und Vererbung ist auch möglich.

Ich würde OOP nicht nur auf Sprachen beschränken, die OOP Schlüsselwörter zur Verfügung stellen. OOP als Konzept macht da nicht halt.

Gruß


----------



## kickerxy123 (3. Januar 2012)

sheel hat gesagt.:


> DevC++
> Veraltet, nicht mehr zu empfehlen.



Grundsätzlich möchte ich nicht widersprechen, dass die IDE etwas in die jahre gekommen ist. Allerdings möchte ich an dieser Stelle anmerken, dass es wieder aktiv weiterentwickelt wird:
http://orwellengine.blogspot.com/2011/12/dev-c-5100-released.html
(neuste Version vom 27.12.2011). Somit auch standardmäßig c++0x unterstützt und auch Dx Bibliotheken etc mit sich bringt. Damit ist er meiner Meinung nach wieder - besonders auch für Anfänger - geeignet gut und übersichtlich Programme zu entwickeln.
Wenn ihr wollt, könnt ihr dies berücksichtigen. Ansonsten sei es lediglich ein Hinweis für alle "Dev- Fans" (und nein, ich kriege kein Geld für Werbung).

Viele Grüße,
kickerxy123


----------



## ComFreek (3. Januar 2012)

kickerxy123, Danke für den Hinweis! Ich habe den Beitrag oben mal aktualisiert.


----------



## cwriter (12. Januar 2012)

> Hier eine kleine Übersicht über die bekanntesten Bibliotheken und Frameworks.
> Qt
> Schwerpunkt GUIs
> Eine der bekanntesten Möglichkeiten.
> ...


Wo ist hier Mac OS X? Gibt's doch auch. Oder irre ich mich da?
http://developer.qt.nokia.com/wiki/Support_for_Mac_OS_X

Gruss
cwriter

/EDIT: Nur 64bit Mac System!


----------



## ComFreek (12. Januar 2012)

Danke cwriter, ich habe es hinzugefügt!


----------



## sheel (12. Januar 2012)

Hatte Mac gar nicht im Kopf...mal Google befragen,
was es von den anderen Sachen auch für Mac gibt, dann wirds ergänzt.

Und Comfreek war schon wieder schneller


----------



## genodeftest (28. Februar 2012)

Auch Eclipse gibts für Mac. Genauso OpenGL. Fragt sich allerdings, ob jemand zum Programmieren nen Mac verwendet


----------



## ComFreek (28. Februar 2012)

Danke! Ich habe es oben hinzugefügt 
Soweit ich weiß nutzt man für Mac OS X v.a. die Xcode-IDE.


----------



## Parantatatam (29. Februar 2012)

Mh, unter Mac OS X an einen C-Compiler zu gelangen, geht in den meisten Fällen auch nur über Xcode. Aber das, was man unter Mac OS X schreibt, ist aber nach Wünschen von Apple auch Objective-C und hat somit mit C/C++ recht wenig gemein.


----------



## cwriter (1. März 2012)

Hallo Welt

Ich wollte vorschlagen, die C++/CX - Sprache sowie Objective-C auch noch irgendwie zu erwähnen. C++/CX kommt ja mit Windows 8 / VS11 und da wird sicher die Frage auftauchen: "Wozu gehört denn das?".

Generell kommt mit Windows 8 ja einiges neues, das der Erklärung bedarf.

Gruss
cwriter


----------



## sheel (1. März 2012)

ObjC lass ich mal weg.
Viele Fragen dazu gibt es ja nicht im Forum
(kann mich ohne Suchen an überhaupt keine erinnern)
...und außerdem passt es mit C/C++ nicht wirklich in einen Topf.

C++CX (mensch, reicht nicht schon CLI ) wird folgen.
Da gibt es zuerst noch was zu klären.


----------

