Anzeige:
Seite 2 von 2 ErsteErste 12
Ergebnis 16 bis 19 von 19

Thema: Nativ unter Linux programmieren

  1. #16
    Registrierter Benutzer
    Registriert seit
    23.05.2004
    Beiträge
    592
    C++ ist eine weiterentwicklung von C, also C lebt (mit ein paar wenigen Modifikationen) in C++ weiter.
    C, bzw der C Anteil im C++, hat aber einen wesentlichen Vorteil: Er ist viel genauer, und vor allem binaer spezifiziert.
    Das heisst, das C Strukturen, pointer, typen .... zueinander compilerunabhaengig sind, waehrend bei c++ dem compiler viel mehr freiheit wegens optimierungen gelassen wird.
    Tatsache ist, dass mehr C Compiler einem gemeinsamen ABI (Application Binary Interface) folgen, als C++ Compiler. Es ist jedoch nicht richtig zu sagen, dass das Binärinterface von C Programmen Compilerunabhängig wäre, oder das der C Standard ein ABI spezifiziert. Kategorisch betrachtet gibt es da keinen Unterschied zwischen C und C++.

    Es ist ebenfalls falsch, dass es kein gemeinsames ABI für C++ gäbe. Zumindest für Linux Rechner ist das Itanium C++ ABI die verbreitete Konvention (auch für nicht-Itanium Rechner). Es ist derzeit mindestens vom GCC, vom Intel C++ Compiler, vom Pathscale Compiler und vom Open64 Compiler implementiert. Möglicherweise soll auch der in der Entwicklung befindliche Clang Compiler diesem ABI unter Linux folgen. Das deckt schon einmal eine ganze Menge ab. Nicht kompatibel ist glaube ich der Compiler von Comeau.

    Auf Macosx werden die C++ Compiler sicherlich auch einem gemeinsamen ABI folgen - zumindest GCC und Clang.

    Wichtig ist auch, das die ABI Kompatibilität sowohl bei C als auch bei C++ im Prinzip nur den Kern der jeweiligen Sprache abdeckt. Wenn man z.B. C FILE* Objekte Implementierungsübergreifend verwenden möchte wird man wohl nicht Erfolg haben.

    Wegen all dem stimmt das hier also nicht:
    Im Klartext heisst das, das alles was ueber compilergrenzen gehen soll, C sein muss, waehrend man bei c++ einen compiler definieren muesste.

  2. #17
    Registrierter Benutzer
    Registriert seit
    18.03.2005
    Beiträge
    211
    Es ist ebenfalls falsch, dass es kein gemeinsames ABI für C++ gäbe. Zumindest für Linux Rechner ist das Itanium C++ ABI die verbreitete Konvention
    wenn ich nen Linux auf nen anderen systemcompiler umstelle, tausche ich soweiso die ganzen c/c++ libs aus.
    Seit wann gibts dieses ABI ? Meine letzten versuche mit gentoo vor paar jahren haben auch ergeben, das die mit dem gcc kompilierte c++ standard lib ned mit dem intel harmoniert ....
    Mag sein das eine C++ ABI angestrebt wird, aber verwendung und verbreitung imho hat sie noch ned so erlangt IMHO.
    Unter linux auch eher ned so drastisch, durch den systemcompiler.
    Unter windows eher kritisch, da man da eher nur binaries ausliefert und der compiler ned so vorgeschrieben iss.

    Wenn man z.B. C FILE* Objekte Implementierungsübergreifend verwenden möchte wird man wohl nicht Erfolg haben.
    Greifst du denn auf die FILE Struktur selber zu ?
    Noe, denk du laest das alles die clib machen.
    Wenn du es schaffst, den GCC und den Intel Compiler die selbe clib und die selben c-header zu verwenden, solltest auch FILE Strukturen austauschen koennen.

    Aber alles sehr theoretisch, zumindest fuer mich ... hab unter linux eh lange nix mehr gemacht.
    Hasst Du ein Linux laufen, und optional nen 2ten (c/c++)compiler drauf, mit dem du auch projecte uebersetzt ?

    Ciao ...
    Geändert von RHBaum (14-07-2010 um 11:10 Uhr)

  3. #18
    Registrierter Benutzer
    Registriert seit
    23.05.2004
    Beiträge
    592
    Seit wann gibts dieses ABI ?
    Seit circa 2001: http://www.codesourcery.com/public/cxx-abi/

    Meine letzten versuche mit gentoo vor paar jahren haben auch ergeben, das die mit dem gcc kompilierte c++ standard lib ned mit dem intel harmoniert ....
    Genau, das hatte ich ja schon geschrieben. Die jeweiligen ABIs spezifizieren nur die Kernsprache + etwas Runtime Support (z.B. type_info).

    Immerhin entnehme ich der Intel C++ Online-Dokumentation, dass dieser Compiler die GNU C++-Bibliothek benutzen kann, und unter dieser Voraussetzung Code kompatibel zu GCC produziert. Also eine Situation ganz ähnlich zu der von C.

    Mag sein das eine C++ ABI angestrebt wird, aber verwendung und verbreitung imho hat sie noch ned so erlangt IMHO.
    Wenn man z.B. einen aktuellen GCC verwendet, benutzt man dieses ABI automatisch.

    Aber alles sehr theoretisch, zumindest fuer mich ... hab unter linux eh lange nix mehr gemacht.
    Hasst Du ein Linux laufen, und optional nen 2ten (c/c++)compiler drauf, mit dem du auch projecte uebersetzt ?
    Ich verwende derzeit nur den GCC. Insofern ist das auch für mich nur theoretisch. Ich glaube aber z.B. der Intel-Doku zunächst mal. Klar ist natürlich auch, das man umso mehr Probleme erwarten kann, je mehr Sprachfeatures man verwendet. Vielleicht nehme ich diesen Thread ja mal zur Gelegenheit um tatsächlich mal den Intel Compiler auszuprobieren.

    Oder ich gebe die Frage weiter: Hat irgendein Forenmitglied hier praktische Erfahrung damit unterschiedliche C++ Compiler zu verwenden, und kann aus eigener Anschauung etwas zur Interoperabilität sagen? Natürlich halbwegs aktuelle Erfahrung, also zumindest nach 2001.

    P.S.: Mir fällt noch ein, der C++ von Sun ist ebenfalls *nicht* ABI kompatibel zum GCC unter Linux, meines Wissens nach.

  4. #19
    Registrierter Benutzer
    Registriert seit
    18.03.2005
    Beiträge
    211
    Was auch intressieren wuerde:
    Es gibt paar wenige Flags auch fuern gcc, die die binaere Ausrichtung der Daten bei Klassen und Parameterausrichtung in den Aufrufen etc ... beeinflussen, also ein Klasseninterface selbst bei gleicher version des gcc binaeruncompatibel machen.
    Werden diese Flags spezifiziert oder zumindest verboten ?
    oder gibts fuer diese Dinger Neue Compileranweisungen die diese Flags an bestimmten Interfaces aussetzen oder ne Proxyklasse generieren etc ...

    Ciao ...

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •