Наткнулся на
интересную презентацию по поводу сабжа. Там на примере carbon.h (Apple всёж
) сравнивается Clang и традиционный gcc, конечно, не в пользу последнего
Здравствуйте, Курилка, Вы писали:
К>Наткнулся на интересную презентацию по поводу сабжа. Там на примере carbon.h (Apple всёж ) сравнивается Clang и традиционный gcc, конечно, не в пользу последнего
Они бы еще нормальный C++ сделали
Насколько я понял, CLang понимает пока только С и Objective C.
Ну а то что GCC — это помойка, уже давно известно. Все-таки более 15 лет развития сказываются. GCCшники одно время хотели выбросить слой работы с деревьями на LLVM, но потом оно у них все завяло (и к лучшему, наверное).
Кстати, LLVM умеет использовать GCC для компиляции своего байт-кода.
Здравствуйте, Курилка, Вы писали:
К>А мне вот интересно — будет ли выгодней использовать Clang вместо GCC для языков, которые используют сишный код в качестве пром. результата компиляции? Или же всё это изврат и правильней прямо транслировать в LLVM?
CLang может быть выгоднее использовать, если он будет лучше оптимизироваться (см. ниже).
Но лучше написать сразу транлсятор в LLVM (это не так уж и сложно) — получим кучу преимуществ: более мощные оптимизации (за счет управления алиасингом и т.п.), возможность интеграции отладчика (в LLVM есть поддержка кастомных отладочных символов), ну и упрощение всей системы.
К>Также вопрос — есть ли разница между результатах C->(GCC)->Native и C->(Clang)->(LLVM)->Native?
Можно сделать, чтобы разницы не было (с помощью цепочки C->(Clang)->(LLVM)->GCC->Native
). В некоторых случаях LLVM выиграет за счет более крутой межпроцессной оптимизации, в некоторых случаях победит GCC за счет большего количества фич. Лично я бы для статической компиляции воспользовался бы цепочкой с GCC.
