Clang vs GCC pour mon projet de développement Linux

Je suis à l'université et pour un projet que nous utilisons C. Nous avons exploré GCC et Clang, et Clang semble être beaucoup plus convivial que GCC. En conséquence, je me demande quels sont les avantages ou les inconvénients d'utiliser clang, par opposition à GCC, pour développer en C et C ++ sous Linux?

Dans mon cas, cela serait utilisé pour les programmes de niveau étudiant, pas pour la production.

Si j'utilise Clang, dois-je déboguer avec GDB et utiliser GNU Make, ou utiliser un autre débogueur et faire un utilitaire?

ÉDITER:

Les gars de gcc ont vraiment amélioré l'expérience de diagnostic en gcc (ah compétition). Ils ont créé une page wiki pour le présenter ici . gcc 4.8 a maintenant également de bons diagnostics (gcc 4.9x a ajouté la prise en charge des couleurs). Clang est toujours en tête, mais l'écart se resserre.

Original:

Pour les étudiants, je recommanderais sans réserve Clang.

Les performances en termes de code généré entre gcc et Clang ne sont plus claires (même si je pense que gcc 4.7 a toujours la tête, je n'ai pas encore vu de benchmarks concluants), mais pour les étudiants, l'apprendre n'a pas vraiment d'importance de toute façon.

D'un autre côté, les diagnostics extrêmement clairs de Clang sont certainement plus faciles à interpréter pour les débutants.

Considérez ce simple extrait de code:

#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";
}

Vous remarquerez tout de suite que le point-virgule est manquant après la définition de la Studentclasse, non :)?

Eh bien, gcc le remarque aussi , d'une certaine manière:

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>]

Et Clang ne joue pas exactement ici non plus, mais quand même:

/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.

Je choisis délibérément un exemple qui déclenche un message d'erreur peu clair (provenant d'une ambiguïté dans la grammaire) plutôt que les exemples typiques «Oh mon dieu Clang lis mon esprit». Pourtant, nous remarquons que Clang évite le flot d'erreurs. Pas besoin d'effrayer les étudiants.

À l'heure actuelle, GCC offre une prise en charge bien meilleure et plus complète des fonctionnalités C ++ 11 que Clang. De plus, le générateur de code pour GCC effectue une meilleure optimisation que celui de Clang (d'après mon expérience, je n'ai vu aucun test exhaustif).

D'un autre côté, Clang compile souvent le code plus rapidement que GCC, et produit de meilleurs messages d'erreur lorsqu'il y a quelque chose qui ne va pas avec votre code.

Le choix de celui à utiliser dépend vraiment de ce qui est important pour vous. J'apprécie plus le support C ++ 11 et la qualité de la génération de code que la commodité de la compilation. Pour cette raison, j'utilise GCC. Pour vous, les compromis pourraient être différents.

J'utilise les deux car ils donnent parfois des messages d'erreur différents et utiles.

Le projet Python a pu trouver et corriger un certain nombre de petits bugs lorsque l'un des principaux développeurs a essayé de compiler pour la première fois avec clang.

Je l' utilise aussi bien Clang et GCC, je trouve Clang a quelques avertissements utiles, mais pour mes propres repères ray-tracing - sa constante 5-15% plus lent que GCC (prendre ce avec un grain de sel bien sûr, mais a tenté d'utiliser des drapeaux d'optimisation similaires pour les deux).

Donc pour l'instant j'utilise l'analyse statique de Clang et ses avertissements avec des macros complexes: (bien que maintenant les avertissements de GCC soient à peu près aussi bons - gcc4.8 - 4.9).

Quelques considérations:

• Clang n'a pas de support OpenMP, cela n'a d'importance que si vous en profitez, mais puisque je le fais, c'est une limitation pour moi. (*****)
• La compilation croisée peut ne pas être aussi bien supportée (FreeBSD 10 par exemple utilise toujours GCC4.x pour ARM), gcc-mingw par exemple est disponible sur Linux ... (YMMV).
• Certains IDE ne prennent pas encore en charge l'analyse de la sortie de Clangs ( QtCreator par exemple *****). EDIT: QtCreator prend désormais en charge la sortie de Clang
• Certains aspects de GCC sont mieux documentés et comme GCC existe depuis plus longtemps et est largement utilisé, vous trouverez peut-être plus facile d'obtenir de l'aide avec les avertissements / messages d'erreur.

***** - ces domaines sont en développement actif et pourraient bientôt être soutenus

Pour les programmes de niveau étudiant, Clang a l'avantage d'être, par défaut, plus strict. la norme C. Par exemple, la version K&R suivante de Hello World est acceptée sans avertissement par GCC, mais rejetée par Clang avec quelques messages d'erreur assez descriptifs:

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

Avec GCC, vous devez le donner -Werrorpour qu'il fasse vraiment remarquer que ce n'est pas un programme C89 valide. En outre, vous devez toujours utiliser c99ou gcc -std=c99obtenir le langage C99.

Je pense que clang pourrait être une alternative.

GCC et clang ont des différences sur des expressions telles que a+++++a, et j'ai de nombreuses réponses différentes avec mes pairs qui utilisent clang sur Mac pendant que j'utilise gcc.

GCC est devenu la norme, et clang pourrait être une alternative. Parce que GCC est très stable et que le bruit est encore en développement.