C und c++ - Dateiendungen und Compilier

[maceis]

hallo zusammen,

dieser Tage hab ich mir rd. 2 Zentner Bücher über C und c++ ais der Bücherei geholt.
Da heisst es dann, dass man C Code mit der Endung .C versehen muss.

In der man page heisst es aber, dass .C für c++ Code steht und C Code mit der Endung .c vesehen werden soll.

nachdem der ja unter Mac OS die einzelene Compiler Kommandos wild untereinander verlinkt sind, blick ich jetzt gar nimmer durch.

Daher meine Fragen:
1. Welche Dateieindungen muss/kann ich für C-Code verwenden.

2. Welche Dateieindungen muss/kann ich für c++-Code verwenden.

3. Welche Compilerkommandos muss/kann ich für C-Code verwenden.

4. Welche Compilerkommandos muss/kann ich für c++-Code verwenden.

In einem anderen Fred hab ich gelesen, dass man bei c++ anstelle von
#include<iostream.h>
lieber
#include<iostream>
schreiben soll.

Kann das jemand bestätigen und am Besten auch begründen.

Vielen Dank für die Hilfe

 

[Horror]

Also ich persönlich kenne C-Source-Files als .c und C++-Sourcen als .cpp (wobei diese "nicht obligatorisch ist", Zitat aus meinem C++-Buch).

Übersetzen kannst du beide mit dem gcc (GNU C Compiler) oder dem cc, sind beides smybolische Links zum gcc-3.3 (man gcc liefert da in den ersten Zeilen Infos zu). Zu der Sache mit dem Einbinden der Bibliotheken kann ich dir nichts sagen, jedoch "spricht" mein C++-Buch auch von #include <iostream.h>.

Horror

 

[maceis]

hallo Horror,

danke für deine Antwort.
Ich werd mich wohl an die Angaben in den man-Pages halten.

Jedenfalls habe ich bemerkt, dass gar nicht kompiliert wird, wenn die Endung nicht stimmt.

 

[der grimm]

Hi,

#include <iostream.h> ist veraltet und sollte nicht mehr genutzt werden, #include <iostream> ist Standard.

Zumindest müssen bei gcc/g++ C-Quelldateien mit .c enden und C++-Quelldateien mit .cpp. Wenn z.B. eine .c Datei Klassen enthält spuckt der Compiler Fehler aus (so zumindest GCC unter Linux.. habe noch keinen Mac, aber es sollte dort ja nicht anders sein).

Ciao

 

[maceis]

hallo Zeeke,

#include <iostream.h> ist veraltet und sollte nicht mehr genutzt werden, #include <iostream> ist Standard.

Danke für den Tip, aber jetzt machst du mich neugierig.
Wo steht den das ? Bzw. wer sagt das ?

Hat es was "#include <iostream.h>" zu verwenden?
Ich seh´ den Sinn noch nicht so ganz.

 

[Rakor]

Original geschrieben von maceis
hallo Zeeke,

Danke für den Tip, aber jetzt machst du mich neugierig.
Wo steht den das ? Bzw. wer sagt das ?

Hat es was "#include <iostream.h>" zu verwenden?
Ich seh´ den Sinn noch nicht so ganz.

&nbsp;

Zu den Dateiendungen... Die Endung von C-Dateien ist .c die Header haben .h

Die Dateiendung von C++ ist entweder .cpp oder .cc - Die Headerhateien sind entweder .h oder .hh

Bei falschen Dateiendungen sind manche Kompiler recht unangenehm. Der GNU-Compiler akzeptiert nur Dateien mit der entsprechenden Endung.

Allgemein soll das .h in der Includeanweisung von C++ Files verwendet werden. Das hat zum einen etwas mit den neuen Standards des C++ Konsortiums und soll alleine daher schon gemacht werden. Dem Compiler obliegt es somit sich die richtigen Dateien zu suchen. Geanau weiss ich aber auch nicht bescheid was die sich dabei dachten.

Wichtig bei C++ sind die Namespaces. Am sichersten bist du wenn du den standard-Namespace verwendest.

Hinter die Includes machst du einfach ein
using namespace std;

Informier dich mal genauer darüber.


Als Compiler für C kannst du den cc für C++ den g++ nehmen. Is beides der GNU-Compiler.

Wenn du sauberen und ANSI-kompartibelen Code schreiben willst empfehle ich dir als Compilerparameter
-Wall -ansi
zu verwenden.

-Wall : Zeigt dir alle Feher und warnings an
-ansi : prüft ob du ansi-konform bist


Am besten arbeitest du mit Makefiles. Das erleichter dir die arbeit ungemein (besonder wenn du mit vim arbeiten solltest ).

edit: aber in der Manpage erfährst du alles über die Parameter...

 

[maceis]

hallo Rakor,

danke für die ausführliche info.

Ich arbeite in der Tat viel mit dem vim.

Ich glaube inzwischen habe ich vieles begriffen.

Einige Dinge hatten mich verwirrt:

1. Die wilde Verlinkung der Compiler auf dem Panther.
2. Meine Shell, die bei der Autovervollständigung nur .c Dateien erkennt, unabhängig vom Kommando. Hatte das zuerst (nicht nachgedacht) auf den Compiler geschoben.
3. Die Diskrepanz zwischen man-Page und meinen Büchern.

Inzwischen hab ich bemerkt, dass man soagar Objectiv-C mit dem g++ kompilieren kann (sogar fortran und Assembler, aber die kann ich leider nicht

 

[Rakor]

Original geschrieben von maceis
1. Die wilde Verlinkung der Compiler auf dem Panther.
3. Die Diskrepanz zwischen man-Page und meinen Büchern.

Der GNU-CC ist mittlerweile recht mächtig geworden. Auch wenn er nicht gerade den besten code erzeugt (bzgl. geschwindigkeit). Daher hat der GCC ja die optimierungsfunktion -O drinn. Die solltest du beim endgültigen Compilieren auf alle Fälle verwenden! Ich empfehle mal ein -O3. Wenn du währen der Entwicklung debuggst solltest du -O lieber sein lassen, da es im Debugger möglicherweise komische Seiteneffekte durch die Optimierung gibt.

Zu 1.: Das ist normal und liegt nicht am Panther.. ;-)

Zu 3.: Immer wichtig auf die Versionen achten!! Was sind denn das für Dikrepanzen? Und was hast du für Bücher, wenn ich fhragen darf... (Manpage hat [fast] immer recht )

 

[Descartes]

Original geschrieben von maceis
hallo zusammen,

dieser Tage hab ich mir rd. 2 Zentner Bücher über C und c++ ais der Bücherei geholt.
Da heisst es dann, dass man C Code mit der Endung .C versehen muss.

In der man page heisst es aber, dass .C für c++ Code steht und C Code mit der Endung .c vesehen werden soll.

nachdem der ja unter Mac OS die einzelene Compiler Kommandos wild untereinander verlinkt sind, blick ich jetzt gar nimmer durch.

Daher meine Fragen:
1. Welche Dateieindungen muss/kann ich für C-Code verwenden.

C => *.c

Original geschrieben von maceis
2. Welche Dateieindungen muss/kann ich für c++-Code verwenden.

C++ => *.cpp (seltener: *.cc)

Früher war mal im Gespräch für C++ Quellcodes *.C (grosses "C") zu verwenden.
Diese Art der Benennung hat allerdings mehrere Nachteile und sollte -- falls es der Compiler überhaupt erlaubt -- nicht verwendet werden.

Z.B. ist es schwieriger Dateien auf den ersten Blick zu unterscheiden (*.c <--> *.C). Das ganze funktioniert auch nur auf Dateisystemen, die case-sensitiv sind (d.h. die Schreibweise unterscheiden können). Das bei Apple verwendete Dateisystem HFS und HFS+ bietet dieses Feature genausowenige, wie es Microsofts FAT Dateisystem nicht kann.

Original geschrieben von maceis
3. Welche Compilerkommandos muss/kann ich für C-Code verwenden.

Kann:
gcc -Wall -std=c99 main.c

Original geschrieben von maceis
4. Welche Compilerkommandos muss/kann ich für c++-Code verwenden.

Kann:
g++ -Wall main.c

Original geschrieben von maceis
In einem anderen Fred hab ich gelesen, dass man bei c++ anstelle von
#include<iostream.h>
lieber
#include<iostream>
schreiben soll.

Kann das jemand bestätigen und am Besten auch begründen.

Im aktuell gültigen C++-Standard (ISO/IEC 14882-1998) ist definiert, dass die im Standard definierten Funktionsheader nicht unbedingt in Dateiform vorliegen müssen und statt dessen auch auf andere Art und Weise implementiert sein dürfen (z.B. direkt im Compiler und nicht als Datei). Zur Zeit ist mir gerade kein weit verbreiteter C++ Compiler bekannt, der die Headerfiles nicht als Dateien mitliefert. Die Headerfiles heissen auf dem Dateisystem dann ganz genauso, wie du diese beim Includieren benennst. Also z.B. "iostream", "string" usw.

 

[Descartes]

Original geschrieben von Rakor


Der GNU-CC ist mittlerweile recht mächtig geworden. Auch wenn er nicht gerade den besten code erzeugt (bzgl. geschwindigkeit). Daher hat der GCC ja die optimierungsfunktion -O drinn. Die solltest du beim endgültigen Compilieren auf alle Fälle verwenden! Ich empfehle mal ein -O3.

&nbsp;
Die Optimierungseinstellung -O3 sollte beim GCC nicht verwendet werden, da diese bekanntermassen bei nicht-x86 gerne mal fehlerhaft arbeitet. Maximal sollte man sich auf -O2 beschränken.
Sollte man trotzdem irgendwann mal das Gefühl haben, dass man eine höhere Optimierung verwenden muss, dann sollte man auf den Compiler-Schalter -fast zurück greifen, der den Compiler veranlasst explizit für die G5 CPU zu optimieren. Der mit -fast compilierte Code ist allerdings dann nicht mehr auf nicht-G5 CPUs (z.B. G3 oder G5) ausführbar. Damit die -fast Option auch für G3/G4 kompatiblen Code erzeugt, muss man zusätzlich zu -fast auch noch -mcpu=7450 verwenden.

siehe auch:
http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/Optimize-Options.html

Original geschrieben von Rakor
Wenn du währen der Entwicklung debuggst solltest du -O lieber sein lassen, da es im Debugger möglicherweise komische Seiteneffekte durch die Optimierung gibt.
[/B]

Zum Debugging sollte man die Optimierung mittels -O0 komplett abschalten.

 

[Rakor]

Original geschrieben von Descartes
&nbsp;
Die Optimierungseinstellung -O3 sollte beim GCC nicht verwendet werden, da diese bekanntermassen bei nicht-x86 gerne mal fehlerhaft arbeitet. Maximal sollte man sich auf -O2 beschränken.

Oha... Danke, gut zu wissen.... Um ehrlich zu sein habe ich noch nicht wirklich mit gcc auf anderen Plattformen als x86 gearbeitet... Wusste nicht, dass es da Probleme mit dem PPC gibt..

 

[Descartes]

Original geschrieben von maceis
3. Die Diskrepanz zwischen man-Page und meinen Büchern.

&nbsp;
Im Zweifelsfall hat deine Compiler-Dokumentation recht. Ausser du weisst 100%ig, dass deine Buchliteratur die einzige Wahrheit sind, in diesem Fall ist der Compiler oder dessen Dokumentation fehlerhaft.

Allerdings sollte man auch aktuelle und gute Buchliteratur verwenden.
Die häufigsten Fehler in Büchern sind:
"main" Routine als "void main" deklariert? => Buch/Autor taugt nix.
oder auch
"#include <iostream.h>" verwendet, anstatt "#include <iostream>" => Buch ist veraltet und entspricht nicht dem aktuell gültigen C++ Standard

Original geschrieben von maceis
Inzwischen hab ich bemerkt, dass man soagar Objectiv-C mit dem g++ kompilieren kann (sogar fortran und Assembler, aber die kann ich leider nicht

&nbsp;

GCC is the GNU Compiler Collection, which currently contains front ends for C, C++, Objective-C, Fortran, Java, and Ada, as well as libraries for these languages (libstdc++, libgcj,...). Further frontends are available.

Die GNU Compiler Collection (GCC) unterstützt -- sofern die Unterstützung kompiliert wurde -- folgende Programmierprachen:

Programmiersprache => GNU Compilerprogramm

C => gcc
C++ => g++
Objective-C => gcc
Objective-C++ => g++
Fortran => g77
Java => gcj
Ada => gnat

Weitere Frontends (z.B. für COBOL oder Pascal) sind auf der GNU GCC Webseite http://gcc.gnu.org/frontends.html aufgelistet.

Für Assembler Programmierung kannst du den GNU Assembler (gas) (AT&T Syntax) oder den NASM (Intel Syntax) verwenden.

 

[Descartes]

Original geschrieben von Rakor
&nbsp;
Wenn du sauberen und ANSI-kompartibelen Code schreiben willst empfehle ich dir als Compilerparameter
-Wall -ansi
zu verwenden.

-Wall : Zeigt dir alle Feher und warnings an
-ansi : prüft ob du ansi-konform bist

Wer ganz sicher gehen möchte, der verwende zusätzlich noch die Option "-pedantic".

Der Option "-ansi" entspricht "-std=c89".
Mir persönlich ist es lieber, statt der Option "-ansi" den verwendeten C bzw. C++ Standard mit Hilfe der Option "-std=" anzugeben.

Also z.B.
"gcc -std=c99" für C oder "g++ -std=c++98" für C++
Solltest du die GNU Erweiterungen dieser beiden Standards verwenden wollen, dann verwendest du "gcc -std=gnu89" für C inkl. GNU Erweiterungen bzw. "g++ -std=gnu++98" für C++ inkl. GNU Erweiterungen.

Zu den Optionen siehe auch:

Options Controlling C Dialect
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html

Option Summary
http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

 

[maceis]

hallo zusammen

vielen vielen Dank für Eure Hinweise;
für mich als Programmier-Anfänger sind die Gold wert.
Bisher hab ich hauptsächlich Shell-Skripts geschrieben, da war das kompilieren kein Thema, von daher hab ich da überhaupt keine Erfahrung.

Meine ersten c++ Progrämmchen hab ich eigentlich nur so aus Spass mit der Endung .c versehen, wie man kompiliert hatte ich keine Ahnung alse einfach mal den Befehl gcc (oder g++, das weiss ich gar nimmer) eingetippt und - oh Wunder - es hat funktioniert.
Dann mal kurz in die manPage geschaut - nur die Syntax kurz überflogen, -o filename ausprobiert un gut war.

Bei nächsten Versuch hab ich dann nicht mehr *.c genommen, und nichts ging mehr.

Tja und jetzt hab ich Feuer gefangen und mir Bücher besorgt.

Zu 3.: Immer wichtig auf die Versionen achten!! Was sind denn das für Dikrepanzen? Und was hast du für Bücher, wenn ich fhragen darf... (Manpage hat [fast] immer recht

Die Diskrepanz war im Wesentlichen, dass ich gelesen hatte, man soll *.C für c-Code nehmen (weiss nicht mehr wo ich das gefunden hatte, evtl auch online.)

Inzwischen habe ich folgende Bücher (u. a.)
gekauft:
- Hillegass Cocoa Programming for Mac OS X, 2003 -> für 25 Euro gebraucht bei Amazon -> SUPER Buch, aber keine leichte Kost, wenn man wie ich von C kaum Ahnung hat und in c++ auch noch Anfänger ist
- Einsteigerseminar c++, ca. 10Euro

aus der Bücherei:
- den Stroustroup (noch nicht angefangen)
- Willms, goto c++ Programmierung
- Dankert, Praxis der c Programmierung
- John R. Hubbard, Programmieren in c++ (guter Einstieg, sehr ausführlich, aber kein Wort über kompilieren)
- Jetzt lern ich OOP (find ich beim ersten reinlesen nicht so ganz toll geeignet für das was ich vorgabe; geht mehr um Programmierung von Online Rollenspielen, aber nett geschrieben)
und noch ein paar andere
z. B C für Dummies, aber das ist echt für Dummies, bis Seite 60 oder so kommt man über printf und scanf nicht hinaus

 

[Descartes]

Noch ein Tipp:
Verwende nach Möglichkeit die Programmierumgebung von MacOSX: Xcode (liegt unter /Developer/Applications/Xcode.app)
Zwar kannst du deine Programme auch mit einem ASCII Editor deiner Wahl (z.B: Emacs oder dem VIM) schreiben, aber bei Programmen die über ein "Hallo Welt" hinausgehen wirst du dir bald Makefiles wünschen. Und u.a. die Makefile Erstellung nimmt dir diese Programmierumgebung ab.

Desweiteren solltest du wissen, was und in welcher Programmiersprache du programmieren möchtest.
Für Kommandozeilenprogramme kannst du C als auch C++ verwenden. Wobei hier vielleicht C etwas gängiger ist. Zumindest sind die Fälle wo man die C++ spezifischen Vorteile benötigt in der Praxis nicht immer gegeben.
Möchtest du grafische Anwendungen für MacOSX programmieren, solltest du dich mit Objective-C anfreunden. Ob du hierzu erstmal C und danach Objective-C, oder vielleicht doch gleich Objective-C lernst sei dir überlassen.

Für Objective-C gibt es bei weitem nicht so viele Literatur, wie z.B. für C oder C++. Die Referenz dürft bis auf absehbare Zeit wohl noch immer von Apple kommen:

The Objective-C Programming Language
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/index.html

Der Hillegass führt dich an Hand eines einfachen Beispiels (Währungsumrechner) an Objective-C, Oberflächen-Gestaltung (GUI) und die Anwendung der Programmierumgebung heran.