Gcc est parti aux abimes pour moi le jour ou apple l'a deprecie et mit clang par defaut ya a peu pres 18 mois.
Comme ont dit les autres, et pour rajouter:
- vitesse de compilation (sur des gros projets, ca aide, surtout avec cocoapods qui force un peu a rebuilder les dependences en permanence)
- precision des messages d'erreur
- analyse statique. Xcode/Instruments en sont a un point ou ils peuvent trouver les cycles de retain count et suggerer ou les casser, et il me semble que ARC est tres dependant de l'analyzeur pour savoir ou mettre les retain/release/autorelease
- sur le support objc, gcc est tellement loin derriere que c'est meme plus drole
- De meme, xcode suggere maintenant des solutions aux erreurs de compilations, il me semble que c'est grace a clang.
Du cote du mauvais:
- le code genere est certes plus lent, pas sur que ca se ressente a l'utilisation
- leur generateur de code arm6 etait bugge jusqu'a la moelle, j'ai eu le droit a des binaires malforme (donc qui ne peuvent meme pas se lancer), un mauvais acces a des membres de structs en -O2 (i.e. var.width accedait en fait a var.height. Je deconne pas, bon courage pour debugger ca, et le corriger) et un dernier du meme tonneau, mais ma memoire me fait defaut.
A noter que ces bugs etaient tous pour l'armv6, armv7 n'etait pas affecte et cette plateforme etait mourrante a cette epoque (mais toujours vivotante, ce qui ne rend pas les bugs acceptables).
- lldb a suivi le chemin de flash: prochaine release, promit, ca marchera bien! Au final, ca marchotte mais xcode est toujours pas foutu de lister le contenu d'un tableau dans l'inspector alors qu'il le fait avec gdb, et on s'est tape un an de xcode avec un lldb inutilisable par defaut.
Apres, le monde objective-c est un peu different, gcc n'en a vait rien a faire de ce langage et donc il a toujours ete a la ramasse, loin derriere, mais quand meme, je retourne pas en arriere, meme pour deux barils de gcc.
[^] # Re: Clang vs GCC
Posté par groumly . En réponse à la dépêche LLVM 3.2 et Clang 3.2 publiés. Évalué à 8.
Gcc est parti aux abimes pour moi le jour ou apple l'a deprecie et mit clang par defaut ya a peu pres 18 mois.
Comme ont dit les autres, et pour rajouter:
- vitesse de compilation (sur des gros projets, ca aide, surtout avec cocoapods qui force un peu a rebuilder les dependences en permanence)
- precision des messages d'erreur
- analyse statique. Xcode/Instruments en sont a un point ou ils peuvent trouver les cycles de retain count et suggerer ou les casser, et il me semble que ARC est tres dependant de l'analyzeur pour savoir ou mettre les retain/release/autorelease
- sur le support objc, gcc est tellement loin derriere que c'est meme plus drole
- De meme, xcode suggere maintenant des solutions aux erreurs de compilations, il me semble que c'est grace a clang.
Du cote du mauvais:
- le code genere est certes plus lent, pas sur que ca se ressente a l'utilisation
- leur generateur de code arm6 etait bugge jusqu'a la moelle, j'ai eu le droit a des binaires malforme (donc qui ne peuvent meme pas se lancer), un mauvais acces a des membres de structs en -O2 (i.e. var.width accedait en fait a var.height. Je deconne pas, bon courage pour debugger ca, et le corriger) et un dernier du meme tonneau, mais ma memoire me fait defaut.
A noter que ces bugs etaient tous pour l'armv6, armv7 n'etait pas affecte et cette plateforme etait mourrante a cette epoque (mais toujours vivotante, ce qui ne rend pas les bugs acceptables).
- lldb a suivi le chemin de flash: prochaine release, promit, ca marchera bien! Au final, ca marchotte mais xcode est toujours pas foutu de lister le contenu d'un tableau dans l'inspector alors qu'il le fait avec gdb, et on s'est tape un an de xcode avec un lldb inutilisable par defaut.
Apres, le monde objective-c est un peu different, gcc n'en a vait rien a faire de ce langage et donc il a toujours ete a la ramasse, loin derriere, mais quand meme, je retourne pas en arriere, meme pour deux barils de gcc.