C und c++ - Dateiendungen und Compilier

Dieses Thema im Forum "Mac OS X Entwickler, Programmierer" wurde erstellt von maceis, 19.03.2004.

  1. maceis

    maceis Thread Starter MacUser Mitglied

    Beiträge:
    16.645
    Zustimmungen:
    596
    MacUser seit:
    24.09.2003
    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
     
  2. Horror

    Horror MacUser Mitglied

    Beiträge:
    1.416
    Zustimmungen:
    9
    MacUser seit:
    03.02.2003
    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
     
  3. maceis

    maceis Thread Starter MacUser Mitglied

    Beiträge:
    16.645
    Zustimmungen:
    596
    MacUser seit:
    24.09.2003
    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.
     
  4. der grimm

    der grimm MacUser Mitglied

    Beiträge:
    467
    Zustimmungen:
    0
    MacUser seit:
    10.03.2004
    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
     
  5. maceis

    maceis Thread Starter MacUser Mitglied

    Beiträge:
    16.645
    Zustimmungen:
    596
    MacUser seit:
    24.09.2003
    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.
     
  6. Rakor

    Rakor MacUser Mitglied

    Beiträge:
    2.785
    Zustimmungen:
    3
    MacUser seit:
    05.11.2003
    &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...
     
    Zuletzt bearbeitet: 22.03.2004
  7. maceis

    maceis Thread Starter MacUser Mitglied

    Beiträge:
    16.645
    Zustimmungen:
    596
    MacUser seit:
    24.09.2003
    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 :mad:
     
  8. Rakor

    Rakor MacUser Mitglied

    Beiträge:
    2.785
    Zustimmungen:
    3
    MacUser seit:
    05.11.2003
    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 ;) )
     
  9. Descartes

    Descartes unregistriert

    Beiträge:
    189
    Zustimmungen:
    0
    MacUser seit:
    14.12.2002
    C => *.c

    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.

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

    Kann:
    g++ -Wall main.c

    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.
     
  10. Descartes

    Descartes unregistriert

    Beiträge:
    189
    Zustimmungen:
    0
    MacUser seit:
    14.12.2002
    &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

    Zum Debugging sollte man die Optimierung mittels -O0 komplett abschalten.
     
Die Seite wird geladen...