Voker57
- @0xd34df00d: *clang *c++ *gccНу и да, типичные размеры в Release-конфигурации (-O2, остальное не так важно), gcc vs clang, в байтах:
Основной бинарь личкрафтов: 1088170 vs 1146148 — ~5.4% разницы, считая относительно среднего.
Вспомогательные библиотеки: 900103 vs 924004 — ~2.6% разницы
Крупный плагин, мало всяких разных шаблонов: 1143677 vs 1216958 — ~6% разницы (на мелком плагине примерно такая же разница).
Средний плагин, сравнительно много всякой шаблонной мути (boost.graph, опирающийся на mpl, как известно): 581440 vs 631057 — аж 12%. Да, шаблоны clang оптимизирует хреновее.
Разница без особых шаблонов — 3-6%.
С шаблонами все печальнее.
А вообще это все бег в мешках, разницу в производительности-то хрен оценишь. - @0xd34df00d: *clang *gcc *c++Итак, некоторые субъективные наблюдения в результате работы с clang.
• Перейти на него легко — достаточно заменить c++/gcc в CMakeCache.txt на clang. Если код изначально не затачивался на разные компиляторные фишки и писался более-менее в соответствии со стандартом, то заточки особо не потребуется.
• Код компилирует строже, чем gcc, однако, местами поведение, скажем так, неочевидно. Например, он типа как инстанциирует шаблон даже там, где не просят (#826889/20).
• Код, им собранный, вполне работоспособен. Личкрафты запустились и успешно работают, например.
• По ощущениям собирает сильно быстрее, чем gcc. Особенно суровый шаблонный код с mpl/графами/етц. По цифрам — сборка clang'ом личкрафтов заняла 6 минут 47 секунд, gcc собирает минут за 8 с небольшим.
• Не оценил я прелести его сообщений об ошибках вообще. На бустовые пока не нарывался, а легонькие и так научился читать, что ли.13 months ago; 14 replies - @0xd34df00d: *clang *неговно *c++ *говноВ дополнение к #826994.
Впрочем, если поместить в моем хедере определение op== в namespace LeechCraft, то все начинает работать как по маслу. Так что, может, это и не clang говно, а gcc. Надо вспоминать алгоритм нахождения кандидатов. Саммоню в тред ярых знатоков C++, и, например, @jtootf. Интересно, кто из компиляторов правее. - @0xd34df00d: *clang *c++ *говноИтак, имеем namespace LeechCraft и глобальный неймспейс. В глобальном в кутишных хедерах определяется куча operator== для разных типов. В моем хедере определяется operator== (const LeechCraft::Entity&, const LeechCraft::Entity&), тоже в глобальном неймспейсе.
Если включить кутишный хедер с определениями кутишных op== до моего, то функция, находящаяся в namespace LeechCraft, при попытке инстанциировать шаблонный объект (QList<T>) из глобального неймспейса с типом T из namespace LeechCraft, не найдет соответствующий operator==, а увидит только кутишные.
Поэтому перед включением любого кутишного приходится делать форвард декларейшн:
namespace LeechCraft
{
struct Entity;
}
bool operator== (const LeechCraft::Entity&, const LeechCraft::Entity&);
clang говно. - @0xd34df00d: *clang *c++ *programming *?Жуйк, я хочу попробовать пройтись clang'ом из trunk по своим исходникам, использующим Qt, Boost и кое-что еще. Расскажи мне, как бы обойтись без перекомпиляции всего clang'ом. Он ведь совместим в плане ABI с gcc, да? Судя по тому, что я уже смог нарыть (народ собирал кутешные примеры только цлангом, с прекомпилед куте) — да, но я хочу быть уверенным.13 months ago; 15 replies
- @0xd34df00d: *clang *говноТаки clang ниасилил собрать те самые исходники из предыдущих постов: pastebin.ca
- @0xd34df00d: *c++ *gcc *clangВсе, достали высеры gcc. Пошел ставить clang (в портажах 2.7), заодно посмотрю, наконец, чо за зверь такой.13 months ago; 29 replies