Clang vs GCC para mi proyecto de desarrollo de Linux

Estoy en la universidad, y para un proyecto estamos usando C. Hemos explorado GCC y Clang, y Clang parece ser mucho más fácil de usar que GCC. Como resultado, me pregunto cuáles son las ventajas o desventajas de usar clang, a diferencia de GCC, para desarrollar en C y C ++ en Linux.

En mi caso, esto se usaría para programas de nivel de estudiante, no para producción.

Si uso Clang, ¿debo depurar con GDB y usar GNU Make, o usar otro depurador y hacer la utilidad?

EDITAR:

Los chicos de gcc realmente mejoraron la experiencia de diagnóstico en gcc (ah competición). Crearon una página wiki para mostrarla aquí . gcc 4.8 ahora también tiene diagnósticos bastante buenos (soporte de color agregado gcc 4.9x). Clang todavía está a la cabeza, pero la brecha se está cerrando.

Original:

Para los estudiantes, recomendaría incondicionalmente Clang.

El rendimiento en términos de código generado entre gcc y Clang ahora no está claro (aunque creo que gcc 4.7 todavía tiene el liderazgo, aún no he visto puntos de referencia concluyentes), pero para que los estudiantes aprendan, en realidad no importa.

Por otro lado, los diagnósticos extremadamente claros de Clang son definitivamente más fáciles de interpretar para los principiantes.

Considere este fragmento simple:

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

Notarás de inmediato que falta el punto y coma después de la definición de la Studentclase, ¿verdad :)?

Bueno, gcc también lo nota , de una manera:

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

Y Clang tampoco protagoniza exactamente aquí, pero aún así:

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

Elegí a propósito un ejemplo que desencadena un mensaje de error poco claro (proveniente de una ambigüedad en la gramática) en lugar de los ejemplos típicos de "Oh, Dios mío, Clang leyó mi mente". Aún así, notamos que Clang evita la avalancha de errores. No hay necesidad de asustar a los estudiantes.

A partir de ahora, GCC tiene un soporte mucho mejor y más completo para las funciones de C ++ 11 que Clang. Además, el generador de código para GCC realiza una mejor optimización que el de Clang (en mi experiencia, no he visto ninguna prueba exhaustiva).

Por otro lado, Clang a menudo compila código más rápido que GCC y produce mejores mensajes de error cuando hay algo mal con su código.

La elección de cuál usar realmente depende de qué cosas son importantes para usted. Valoro el soporte de C ++ 11 y la calidad de generación de código más de lo que valoro la conveniencia de la compilación. Debido a esto, uso GCC. Para usted, las compensaciones pueden ser diferentes.

Utilizo ambos porque a veces dan mensajes de error diferentes y útiles.

El proyecto Python fue capaz de encontrar y corregir una serie de pequeños buglets cuando uno de los desarrolladores principales intentó compilar con clang.

Utilizo Clang y GCC, creo que Clang tiene algunas advertencias útiles, pero para mis propios puntos de referencia de trazado de rayos: es consistentemente un 5-15% más lento que GCC (por supuesto, tome eso con un grano de sal, pero intentó usar indicadores de optimización similares para ambos).

Entonces, por ahora, uso el análisis estático de Clang y sus advertencias con macros complejas: (aunque ahora las advertencias de GCC son bastante buenas, gcc4.8 - 4.9).

Algunas consideraciones

• Clang no tiene soporte para OpenMP, solo importa si aprovechas eso, pero como lo hago, es una limitación para mí. (*****)
• Es posible que la compilación cruzada no sea tan compatible (FreeBSD 10, por ejemplo, todavía usa GCC4.x para ARM), gcc-mingw, por ejemplo, está disponible en Linux ... (YMMV).
• Algunos IDE aún no admiten el análisis de la salida de Clangs ( QtCreator, por ejemplo, *****). EDITAR: QtCreator ahora es compatible con la salida de Clang
• Algunos aspectos de GCC están mejor documentados y dado que GCC ha existido por más tiempo y se usa ampliamente, es posible que le resulte más fácil obtener ayuda con advertencias / mensajes de error.

***** - estas áreas están en desarrollo activo y pronto pueden ser compatibles

Para los programas de nivel de estudiante, Clang tiene el beneficio de que, por defecto, es más estricto. El estándar C. Por ejemplo, la siguiente versión K&R de Hello World es aceptada sin previo aviso por GCC, pero Clang la rechaza con algunos mensajes de error bastante descriptivos:

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

Con GCC, tiene que darlo -Werrorpara que realmente haga un punto sobre que este no es un programa C89 válido. Además, aún necesita usar c99u gcc -std=c99obtener el lenguaje C99.

Creo que el ruido metálico podría ser una alternativa.

GCC y clang tienen algunas diferencias en expresiones como a+++++a, y tengo muchas respuestas diferentes con mis compañeros que usan clang en Mac mientras uso gcc.

El CCG se ha convertido en el estándar, y el sonido metálico podría ser una alternativa. Porque el CCG es muy estable y el sonido metálico aún está en desarrollo.