Clang vs GCC für mein Linux-Entwicklungsprojekt

Ich bin im College und für ein Projekt verwenden wir C. Wir haben GCC und Clang untersucht, und Clang scheint viel benutzerfreundlicher zu sein als GCC. Infolgedessen frage ich mich, welche Vor- oder Nachteile die Verwendung von clang im Gegensatz zu GCC für die Entwicklung in C und C ++ unter Linux hat.

In meinem Fall würde dies für Programme auf Studentenebene verwendet, nicht für die Produktion.

Wenn ich Clang verwende, sollte ich mit GDB debuggen und GNU Make verwenden oder einen anderen Debugger und das Dienstprogramm make verwenden?

BEARBEITEN:

Die gcc-Leute haben die Diagnoseerfahrung in gcc (ah Wettbewerb) wirklich verbessert. Sie haben eine Wiki-Seite erstellt, um sie hier zu präsentieren . gcc 4.8 hat jetzt auch eine recht gute Diagnose (gcc 4.9x hat Farbunterstützung hinzugefügt). Clang liegt immer noch an der Spitze, aber die Lücke schließt sich.

Original:

Für Studenten würde ich Clang bedingungslos empfehlen.

Die Leistung in Bezug auf den generierten Code zwischen gcc und Clang ist jetzt unklar (obwohl ich denke, dass gcc 4.7 immer noch die Führung hat, habe ich noch keine schlüssigen Benchmarks gesehen), aber für die Schüler ist es sowieso nicht wirklich wichtig, zu lernen.

Auf der anderen Seite ist Clangs äußerst klare Diagnose für Anfänger definitiv leichter zu interpretieren.

Betrachten Sie dieses einfache Snippet:

#include <string>
#include <iostream>

struct Student {
std::string surname;
std::string givenname;
}

std::ostream& operator<<(std::ostream& out, Student const& s) {
  return out << "{" << s.surname << ", " << s.givenname << "}";
}

int main() {
  Student me = { "Doe", "John" };
  std::cout << me << "\n";
}

Sie werden sofort feststellen, dass das Semikolon nach der Definition der StudentKlasse fehlt , oder :)?

Nun, gcc bemerkt es auch auf eine Art und Weise:

prog.cpp:9: error: expected initializer before ‘&’ token
prog.cpp: In function ‘int main()’:
prog.cpp:15: error: no match for ‘operator<<’ in ‘std::cout << me’
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:112: note: candidates are: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT, _Traits>& (*)(std::basic_ostream<_CharT, _Traits>&)) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:121: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ios<_CharT, _Traits>& (*)(std::basic_ios<_CharT, _Traits>&)) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:131: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::ios_base& (*)(std::ios_base&)) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:169: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:173: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long unsigned int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:177: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(bool) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/bits/ostream.tcc:97: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(short int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:184: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(short unsigned int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/bits/ostream.tcc:111: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:195: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(unsigned int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:204: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long long int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:208: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long long unsigned int) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:213: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(double) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:217: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(float) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:225: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long double) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/ostream:229: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(const void*) [with _CharT = char, _Traits = std::char_traits<char>]
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/bits/ostream.tcc:125: note:                 std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_streambuf<_CharT, _Traits>*) [with _CharT = char, _Traits = std::char_traits<char>]

Und Clang spielt auch hier nicht gerade die Hauptrolle, aber dennoch:

/tmp/webcompile/_25327_1.cc:9:6: error: redefinition of 'ostream' as different kind of symbol
std::ostream& operator<<(std::ostream& out, Student const& s) {
     ^
In file included from /tmp/webcompile/_25327_1.cc:1:
In file included from /usr/include/c++/4.3/string:49:
In file included from /usr/include/c++/4.3/bits/localefwd.h:47:
/usr/include/c++/4.3/iosfwd:134:33: note: previous definition is here
  typedef basic_ostream<char>           ostream;        ///< @isiosfwd
                                        ^
/tmp/webcompile/_25327_1.cc:9:13: error: expected ';' after top level declarator
std::ostream& operator<<(std::ostream& out, Student const& s) {
            ^
            ;
2 errors generated.

Ich wähle absichtlich ein Beispiel, das eine unklare Fehlermeldung auslöst (aufgrund einer Mehrdeutigkeit in der Grammatik), anstatt der typischen Beispiele "Oh mein Gott Clang, lies meine Gedanken". Trotzdem stellen wir fest, dass Clang die Flut von Fehlern vermeidet. Keine Notwendigkeit, Schüler abzuschrecken.

Ab sofort bietet GCC eine viel bessere und umfassendere Unterstützung für C ++ 11-Funktionen als Clang. Außerdem führt der Codegenerator für GCC eine bessere Optimierung durch als der in Clang (meiner Erfahrung nach habe ich keine erschöpfenden Tests gesehen).

Andererseits kompiliert Clang Code häufig schneller als GCC und erzeugt bessere Fehlermeldungen, wenn etwas mit Ihrem Code nicht stimmt.

Die Wahl, welche Sie verwenden möchten, hängt wirklich davon ab, welche Dinge für Sie wichtig sind. Ich schätze die Unterstützung von C ++ 11 und die Qualität der Codegenerierung mehr als die Bequemlichkeit der Kompilierung. Aus diesem Grund benutze ich GCC. Für Sie könnten die Kompromisse unterschiedlich sein.

Ich benutze beide, weil sie manchmal unterschiedliche, nützliche Fehlermeldungen geben.

Das Python-Projekt konnte eine Reihe kleiner Fehler finden und beheben, als einer der Kernentwickler zum ersten Mal versuchte, mit clang zu kompilieren.

Ich verwende sowohl Clang als auch GCC. Ich finde, Clang hat einige nützliche Warnungen, aber für meine eigenen Raytracing-Benchmarks - es ist durchweg 5-15% langsamer als GCC (nimm das natürlich mit Salzkorn, habe aber versucht, ähnliche Optimierungsflags zu verwenden für beide).

Daher verwende ich vorerst die statische Analyse von Clang und ihre Warnungen mit komplexen Makros: (obwohl die Warnungen von GCC jetzt ziemlich gut sind - gcc4.8 - 4.9).

Einige Überlegungen:

• Clang hat keine OpenMP-Unterstützung, ist nur wichtig, wenn Sie dies nutzen, aber da ich dies tue, ist dies eine Einschränkung für mich. (*****)
• Cross Compilation wird möglicherweise nicht so gut unterstützt (FreeBSD 10 verwendet beispielsweise immer noch GCC4.x für ARM), gcc-mingw ist beispielsweise unter Linux verfügbar ... (YMMV).
• Einige IDEs unterstützen das Parsen der Clangs-Ausgabe noch nicht ( QtCreator zum Beispiel *****). BEARBEITEN: QtCreator unterstützt jetzt die Ausgabe von Clang
• Einige Aspekte von GCC sind besser dokumentiert. Da es GCC schon länger gibt und weit verbreitet ist, ist es möglicherweise einfacher, Hilfe bei Warnungen / Fehlermeldungen zu erhalten.

***** - Diese Bereiche befinden sich in aktiver Entwicklung und werden möglicherweise bald unterstützt

Für Programme auf Studentenebene hat Clang den Vorteil, dass es standardmäßig strenger ist. der C-Standard. Beispielsweise wird die folgende K & R-Version von Hello World von GCC ohne Vorwarnung akzeptiert, von Clang jedoch mit einigen ziemlich beschreibenden Fehlermeldungen abgelehnt:

main()
{
    puts("Hello, world!");
}

Bei GCC müssen Sie es geben -Werror, damit es wirklich darauf hinweist , dass es sich nicht um ein gültiges C89-Programm handelt. Außerdem müssen Sie noch die Sprache C99 verwenden c99oder gcc -std=c99herunterladen.

Ich denke, Clang könnte eine Alternative sein.

GCC und Clang haben einige Unterschiede in Bezug auf Ausdrücke wie a+++++a, und ich habe viele verschiedene Antworten mit meinem Kollegen, der Clang auf dem Mac verwendet, während ich gcc verwende.

GCC ist zum Standard geworden, und Clang könnte eine Alternative sein. Weil GCC sehr stabil ist und Clang sich noch in der Entwicklung befindet.