Cześć ;)
Jak wiadomo, do kompilowania C++ mamy szeroką gamę kompilatorów, najpopularniejsze to gcc, clang, od Microsoftu. Którego kompilatora ( i dlaczego) używa się programując zawodowo? Wiem, że odpowiedź może być: to zależy ( w takim razie pytanie brzmi od czego to zależy i którego używa się najczęściej?)
gcc, ze względu na zgodność ze standardami i dostępność na różnych systemach. Chętnie bym też używał clanga, ale pod windowsem na razie ciężko.
gcc, bo
clang za to jest niezły ze względu na jego statyczna analizę kodu, która całkiem nieźle działa, ale jeszcze nie jest tak dojrzały i przetestowany jak gcc.
GCC jest chyba najlepiej rozwiniętym kompilatorem, wspiera wiele systemów, głównie uniskowych ale też i Windowsa ale trochę słabiej, nie jest oficjalnym portem. Wspiera multum architektur, ARM, AVR i inne :P Jest GPL - jest free as freedom, nie tylko open source to różnica na duży plus.
https://gcc.gnu.org/install/specific.html
Clang jest wpierany przez Apple i jest używany w systemach tej firmy. Jest lepszy w założeniach od GCC czyli będzie szybszy i zużywający mniej pamięci podczas kompilacji. Clang nie jest jeszcze w pełni gotowy.
Jest na licencji BSD, open source, tylko to według mnie jego wada bo może zostać oprogramowaniem zastrzeżonym.
http://www.phoronix.com/scan.php?page=article&item=gcc-61-clang39&num=2
Kompilator Microsoftu wspiera tylko Windows, to tak jak intel c++ compiler wspiera lepiej procesory Intel niż AMD. Nie polecam niczego od Microsoftu z systemem włącznie.
Jeżeli chcesz stworzyć aplikację którą będziesz mógł przekompilować na inne systemy czy architektury wybierz GCC
Bardzo sobie cenie ten kompilator.
Będzie trochę offtop, przepraszam, ale what the hell
kacper546 napisał(a):
Clang nie jest jeszcze w pełni gotowy.
Że co?
mlyszczek napisał(a):
clang za to jest niezły ze względu na jego statyczna analizę kodu, która całkiem nieźle działa, ale jeszcze nie jest tak dojrzały i przetestowany jak gcc.
Każdy kolejny kompilator jest i będzie z automatu gorszy bo został wydany po gcc?
Na linuxie nie widzę żadnego powodu by nie używać clang'a. Mniejsze binarki wynikowe (sam porównywałem tylko dwa systemy powyżej 50k wierszy, ale mi to wystarczy), świetne komunikaty błędów, toolset które otrzymujesz "out of the box" bez dodatkowego szperania po sieci, nazewnictwo flag pokrywające się z gcc... Nie ma absolutnie żadnego powodu by nie linuxie nie używać clanga, chyba że skompilowałeś swój system gcc i clangiem i przetestowałeś, że kod wynikowy od gcc dla Twojego systemu jest szybszy.
Chodzi o to, że gcc jest na rynku już blisko 30 latT To jest 30 lat testowania, bugfixingu przez naprawdę wiele osób - w tym duże firmy. etc, a clang jest na rynku raptem 8 lat i nie jest jeszcze tak dobrze przetestowany. Ja nie mówię, że clang jest zły, ale osobiście na dzień dzisiejszy nie zamieniłbym gcc na clanga w moich projektach.
@mlyszczek: OpenSSL jest na rynku przez blisko 20 lat i jest dobrze wytestowany, bugfixowany i... oh wait. :)
Jak potrzebujesz kompilatora, który potrafi wygenerować naprawdę wydajny kod, to chyba tylko ICC od Intela. Do tego masz bajery, których nie ma w clangu/gcc domyślnie (OpenMP, Cilk) + zoptymalizowane biblioteki do numeryki + IPP + niezły profiler (VTune).
@kapojot ICC nie jest jednoznacznie lepszy od darmowych narzędzi, powiedziałbym że istnieje raczej dość wąski przedział zastosowań gdzie można by mniemać, że ICC wygeneruje wydajniejszy kod. Jestem też absolutnie pewien, że dla niektórych systemów binarka od ICC będzie wolniejsza od tej wygenerowanej przez gcc.
A VTune jest zajebisty, serio, najprzyjemniejszy profiler z jakim pracowałem, drogi ale wart każdego grosza. Tylko, że można go sobie kupić osobno i nie trzeba kompilować ICC żeby go używać.
@several: ICC lepiej robi chociażby wektoryzację kodu. Zwykle, żeby dogonić to, co ICC zrobiło ze średnio zoptymalizowanego kodu w C, w gcc musiałem już używać intrinsiców i niemalże ręcznie wszystko optymalizować. Czy wygeneruje szybszy kod do aplikacji "ogólnego przeznaczenia" - nie wiem, nigdy go do tego nie używałem.
Ehmmm @kapojot ale jak ja skompiluję za pomocą ICC kod na jakiegoś cortex'a, albo avr'a:) ICC wspiera chyba tylko swoje procki.
O ile pamiętam, to język miał być przenośny nie kompilator i dla danej platformy powinieneś użyć najlepszego kompilatora.
AVR jest zbyt prymitywny, żeby mówić o jakichś większych optymalizacjach.
Co do ARM - Intel miał swego czasu coś dla XScale, ale poza tym, to wszystkie ARM-y to bezpośrednie zagrożenie dla Intela, więc nawet patrząc od strony biznesowej nie liczyłbym na jakieś rewolucje :). Ale patrząc po tym, jak ARM wyparł Atomy, a teraz atakuje serwery - za chwilę wszystko może się zmienić. Do tego - rozszerzenia wektorowe ARM-a (NEON) wyglądają ciut lepiej niż ich Intelowe odpowiedniki.
Edit:
Popatrzcie na to trochę szerzej - kiedyś (90's) była idea odchodzenia od CISCów i robienia prostych procesorów RISC-owych o możliwie jak najogólnieszym zestawie prostych i szybkich instrukcji. W tamtym świecie kompilatory radziły sobie nawet nieźle. Od jakiegoś czasu (początek 2000) idziemy w drugą stronę - pojawiają się coraz potężniejsze jednostki wektorowe, dedykowane instrukcje do przeróżnych rzeczy, żeby wymienić tylko te od Intela: PCLMULQDQ, AESNI, SHA2, AVX2. Tego kompilatory najnormalniej w świecie nie ogarniają, a już zoptymalizowanie czegoś takiego jak najprostsze mnożenie macierzy przez macierz jest całkowicie poza ich zasięgiem. Cóż, pomału pozostaje nam wracać do czasów, gdzie zdecydowana większość optymalizacji będzie musiała być znowu klepana ręcznie.
Offtop
Chciałem napisać komenta ale..
kapojot napisał(a):
Ale patrząc po tym, jak ARM wyparł Atomy, a teraz atakuje serwery - za chwilę wszystko może się zmienić.
To intel z atomem chciał wejść na terytorium ARMa, nie odwrotnie, dlatego nie można mówić/pisać że ARM wyparł atoma. Na serwerach ARM chce wejść na terytorium intela i z XEONem nie będzie mu tak łatwo jak z atomem. W chwilę to się raczej nic nie zmieni ;)
Chodzi o to, że gcc jest na rynku już blisko 30 latT To jest 30 lat testowania, bugfixingu przez naprawdę wiele osób - w tym duże firmy. etc, a clang jest na rynku raptem 8 lat i nie jest jeszcze tak dobrze przetestowany.
Clang to nie tylko kompilator. To także libclang, biblioteka udostępniająca clangowy parser C++, do wykorzystania np. w mechanizmach podpowiadania składni, wykazach klas i metod itp.
GCC czegoś takiego nie ma, Stallman ponoć twierdził że celowo z powodów ideologicznych.
Z mojego doświadczenia: tam gdzie trzeba używasz kompilatora który bardziej pasuje. Najwięcej projektów robiłem pod Win32/64 i tam szło tylko msvc. Może nie wspiera całkowicie 11/14 etc. ale generuje dość szybki kod release i fantastcznie działa pod Visual Studio, którego najczęściej się używa w pracy pod windą. Gdy trzeba budować pod army/linuhy to clang/gcc. Tyle.
Zupełnie przypadkiem i niepowiązanie wczoraj na ircu ##c++ była dyskusja o błędach gcc.
namespace foo{}
decltype(foo) bar; // wtf?!
A to ICE siedzi w kompilatorze od 4.9 lub wcześniejszej wersji. Dobrze przetestowane spagetti jest tragiczne jeśli chcesz coś do niego dodać.
struct foo
{
void bar();
void baz(void*){}
};
void foo::bar()
{
auto l = [&](auto a){
baz(a);
};
l(nullptr);
}