| 1.1, dq0s4y71 (??), 11:10, 06/09/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +15 +/– |
Не понимаю смысла подобных тестов. Время компиляции - ничтожная часть всего времени, затраченного на разработку проекта. А уж пользователям вообще пофигу, сколько времени вы его там компилировали, им важно чтобы программа быстро выполнялась (т.е. качество кода).
| | |
| |
| 2.4, Денис (??), 11:28, 06/09/2012 [^] [^^] [^^^] [ответить]
| +4 +/– |
 В процессе разработки как раз скорость компиляции важна -- если время сборки незначительно, можно прогонять автотесты каждые полчаса, а то и чаще. Очень помогает от тупых ошибок.
| | |
| |
| 3.7, BratSinot (?), 11:58, 06/09/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
Вот только GCC может так долго и толство компилировать из-за оптимизации.
| | |
| |
| 4.52, Аноним (-), 00:34, 07/09/2012 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Вот только GCC может так долго и толство компилировать из-за оптимизации.
Да, при LTO и глобальной оптимизации память он жрет прилично. Но зато выдает на гора более шустрый и компактный код. Учтя что компиляция редко, а работа кода зачастую постоянно - странно экономить на фазе компиляции чтобы постоянно профукивать все полимеры на фазе выполнения.
| | |
|
| 3.9, ананим (?), 12:31, 06/09/2012 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>В процессе разработки как раз скорость компиляции важна
нафиг не важна.
ну не поверю я, что вы все исходники сразу правите, что требует перекомпиляции всех obj-файлов.
зыж
ну или у вас всё в одном, громадном файле.
ну или постоянно делаете make clean. или make mrproper.
| | |
| |
| 4.11, Пыщ я Бетмен (?), 12:45, 06/09/2012 [^] [^^] [^^^] [ответить]
| +3 +/– |
О, как часто тычешься после одной кривой компиляции в ошибки сборки "уже исправленного" проекта, хотя "вроде всё что исправлено должно быть перекомпилировано", что частенько make clean рулит.
Но это ж надо иногда что-то писать и реально собирать самому, чтобы знать про эти грабли
| | |
| |
| 5.13, ананим (?), 13:02, 06/09/2012 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>О, как часто тычешься после одной кривой компиляции в ошибки сборки "уже исправленного" проекта, хотя "вроде всё что исправлено должно быть перекомпилировано", что частенько make clean рулит.
LOL
это функциональность make поддерживает даже БЕЗ написания правил.
ман суффиксные правила (suffixes)
и суффиксы по умолчанию
$ make -p|grep -i suffix
SUFFIXES := .out .a .ln .o .c .cc .C .cpp .p .f .F .m .r .y .l .ym .yl .s .S .mod .sym .def .h .info .dvi .tex .texinfo .texi .txinfo .w .ch .web .sh .elc .el
.SUFFIXES: .out .a .ln .o .c .cc .C .cpp .p .f .F .m .r .y .l .ym .yl .s .S .mod .sym .def .h .info .dvi .tex .texinfo .texi .txinfo .w .ch .web .sh .elc .el
| | |
| |
| 6.14, Алексей (??), 13:18, 06/09/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
И конечно же при изменении .h файла make сможет корректно найти все места, где этот .h используется и их перекомпилировать.
| | |
| |
| |
| |
| 9.46, Ytch (?), 22:03, 06/09/2012 [^] [^^] [^^^] [ответить] | +/– | Ну, как бы, у gcc есть целая группа ключей -M -MM -MD связанная с построен... текст свёрнут, показать | | |
| |
| |
| |
| 12.85, arisu (ok), 11:44, 07/09/2012 [^] [^^] [^^^] [ответить] | +/– |  один из форков jam, сильно переработаный под мою специфику p s точнее, под спе... текст свёрнут, показать | | |
|
|
|
|
|
| 7.32, Аноним (-), 16:14, 06/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
> И конечно же при изменении .h файла make сможет корректно найти все
> места, где этот .h используется и их перекомпилировать.
Сможет, ибо у нормальных людей dependency tracking используется в процессе разработки. Ну и пересобирается только то что зависело от этого .h файла. Как-то так, да.
| | |
| 7.47, Ytch (?), 22:05, 06/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
> И конечно же при изменении .h файла make сможет корректно найти все
> места, где этот .h используется и их перекомпилировать.
Вы не поверите!
(секрет фокуса - см. ключи gcc -M -MM -MD -MMD и т. п.)
| | |
|
|
|
| 4.35, Аноним (-), 16:30, 06/09/2012 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> всех obj-файлов.
спалился ))) У нас они имеют расширение ".o" )))
| | |
| |
| 5.36, ананим (?), 17:03, 06/09/2012 [^] [^^] [^^^] [ответить]
| +3 +/– |
obj-файлы - это не файлы с расширением .obj, чудик! :D
(кстати, винда .obj определит так - http://ru.wikipedia.org/wiki/Obj OBJ — это формат файлов описания геометрии)
а вот определять принадлежность к типу файлов по расширению - ВОТ ЭТО ПАЛЕВО! :D
>$ man gcc
>...
>By default, the object file name for a source file is made by replacing the suffix .c, .i, .s, etc., with .o
.o - всего-лишь расширение по-умолчанию obj-файла.
зыж
и ещё почитай мануалы на утилиту file
ну и узнай что такое /usr/share/misc/magic.mgc
| | |
|
|
| |
| |
| |
| 6.50, Карбофос (ok), 22:24, 06/09/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
 примеры - в студию! или это просто было написано, дабы что-то написать?
p.s. это такой уж проект, что его используют очень многие и, в первую очередь, его тестируют на регрессию
| | |
|
|
|
| 3.49, Карбофос (ok), 22:21, 06/09/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
просто нужно использовать кэш компайлера, тогда проблема скорости компиляции несколько отпадает. да и опция j тоже есть
хотя, не отрицаю того, что скорость сборки важна при сборке проектов с интенсивным изменением кода, когда кэширование слабо поможет.
| | |
| 3.90, Vkni (ok), 13:01, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > В процессе разработки как раз скорость компиляции важна -- если время сборки
> незначительно, можно прогонять автотесты каждые полчаса, а то и чаще. Очень
> помогает от тупых ошибок.
Ставьте -O0, это ускорит компилятор в разы.
| | |
| |
| 4.93, arisu (ok), 13:35, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Ставьте -O0, это ускорит компилятор в разы.
а заодно усыпит некоторые варнинги и изменит поведение программы. happy debugging, bitches!
| | |
| |
| 5.100, AlexAT (ok), 15:00, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
 >> Ставьте -O0, это ускорит компилятор в разы.
> а заодно усыпит некоторые варнинги и изменит поведение программы. happy debugging, bitches!
Только в случае, если код ногами писан.
| | |
| |
| 6.104, arisu (ok), 15:27, 07/09/2012 [^] [^^] [^^^] [ответить] | +/– | угу-угу ты же, вроде, не 171 приветмирщик 187 , а глупости городишь ничего,... большой текст свёрнут, показать | | |
| |
| 7.127, AlexAT (ok), 23:46, 08/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
Про -O3 еще могу поверить. Про -O2 заливайте кому-нибудь другому, либо ссыль на багрепорт.
| | |
|
|
| 5.108, Vkni (ok), 17:10, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> а заодно усыпит некоторые варнинги
точно? какие именно?
> и изменит поведение программы.
это да, бывает.
| | |
| |
| 6.113, arisu (ok), 20:26, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> а заодно усыпит некоторые варнинги
> точно? какие именно?
которые появляются после агрессивной оптимизации. например «использовано до того, как инициализировано». или про алиасинг.
| | |
|
|
|
|
| |
| 3.55, Аноним (-), 00:36, 07/09/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Ну так надо же оправдать переход FreeBSD на Clang.
Странно. Сегодня Зенитар - Кэп. При том вполне годный.
| | |
|
| |
| 3.56, Аноним (-), 00:38, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Один из показателей эффективности компилятора.
Вот только почему-то про другие показатели бсдшники предпочитают не вспоминать. Зато на их несчастье это регулярно вспоминает фороникс, влобешник сравнивая 2 компилера в одинаковой конфигурации, где задом особо не поюлишь. И когда код нагенеренный шлангом сливает раза в три по скорости тому что нагенерил GCC - вот это лихо, да :)
| | |
| |
| 4.65, arisu (ok), 00:53, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
> И когда код нагенеренный шлангом сливает раза в три по скорости тому что нагенерил GCC
> - вот это лихо, да :)
займусь немного взаимоисключающими параграфами: а это тоже в большинстве случаев неважно. числодробилки пишет не так много народу, а в большой прикладухе время сборки может оказаться поважнее того, что выходной код немного медленней.
| | |
| |
| 5.76, Аноним (-), 05:39, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> займусь немного взаимоисключающими параграфами: а это тоже в большинстве случаев неважно.
Да как сказать, зависит от того что считать большинством. Как для начала это большинство оценивалось? По всей планете прошел и статистику собрал кто и что компилит? :)
| | |
| |
| 6.86, arisu (ok), 11:46, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Как для начала это большинство оценивалось?
по примерному порядку человек, использующих числодробилки, и использующих прикладной софт. я не сомневаюсь, что ты и сам можешь это прикинуть, тут большой точности не надо.
| | |
|
|
|
| 3.62, arisu (ok), 00:49, 07/09/2012 [^] [^^] [^^^] [ответить] | +/– | причём достаточно маловажный любители постоянно пересобирать мир могут уже наас... большой текст свёрнут, показать | | |
| |
| 4.83, Клыкастый2 (?), 09:39, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> причём достаточно маловажный.
для оценки самого компилятора? да, не особо интересен. для оценки потенциала, архитектуры - вполне годный. тут надо посмотреть через годик-другой. если так всё и останется - значит толку особого не будет.
> и даже любители бсд постепенно осознают, что бывают версии gcc новее, чем 4.2
ну как бы это нормально. собственно вопрос, что вкорячено в make.conf. и тут варианты только приветствуются. пусть пилят шланг, пусть пилит свой компилер интел, амд - это только плюсы.
| | |
| |
| 5.87, arisu (ok), 12:02, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
ну дык я же не против, чтобы пилили. шланг — проект вполне достойный, и уже даже пригодный к использованию. пусть ещё расширения gcc научится понимать — и вообще хорошо будет.
| | |
|
| 4.91, Vkni (ok), 13:04, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
> пока что в этом плане кланг ничем особо похвастаться не может, увы.
> быть «не хуже» — это не достижение, это минимально необходимое условие.
В общем, да. Но в нынешнее время ещё один компилятор совершенно не повредит.
| | |
|
|
| 2.81, ком.пилятор (?), 09:05, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
есть соурс-бейзед, есть разработчики дистров. Нельзя сказать что скорость сборки вообще никому не важна
| | |
| 2.126, Andrey Mitrofanov (?), 10:25, 08/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Не понимаю смысла подобных тестов. Время компиляции - ничтожная часть всего времени,
Вона яЗен там внизу биёт себя пяткой в груди, что _каждый_ раз при запуске по 10-30% проигрыша есть афигенный чендж на 68% выигрыша один раз при сборке. Это Нужно, это Прогрессивно! Мы все охотно верим, что он приникся и погрузился в мир Будущего - мир континууса интергрейтуса, собирай на каждый чих, не запускай ни разу.
Да, мы не понимаем, но надо же быть благодарными за возможность прикоснуться в Будущему?!</футур>
Тесты это хорошо!! Выкинут наконец из "базы" gcc (обещали же!?), нам таааак полегчает.
+++Ждём FreeBSD 10 без gcc в базе Team, member #000001.
| | |
|
| 1.2, fidaj (ok), 11:12, 06/09/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 Ну вот зачем из письма, залетевшего в рассылку, делать новость на опеннете?
Давайте тогда уж по всем письмам в рассылке (и не только про хорошее) будем писать мегановости... - тем более, что по проблемам проекта есть куда более интересные письма.
Как будто бы в проекте уже вообще ничего не осталось делать - как только меряться скоростью сборки компиляторов...
| | |
| |
| 2.57, Аноним (-), 00:39, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну вот зачем из письма, залетевшего в рассылку, делать новость на опеннете?
Иначе форумные тролли отощают с голодухи :)
| | |
| 2.63, arisu (ok), 00:51, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну вот зачем из письма, залетевшего в рассылку, делать новость на опеннете?
потому что давно не было срачей clang vs gcc.
| | |
|
| |
| 2.27, an. (?), 15:51, 06/09/2012 [^] [^^] [^^^] [ответить] | +1 +/– | По моим измерениям, размер выполняемых файлов процентов на 10 больше у clang 3... большой текст свёрнут, показать | | |
|
| |
| 2.6, BratSinot (?), 11:57, 06/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
Прочитайте новость. Речь идет о C++, С'шные проекты может GCC оторваться.
| | |
| 2.31, Аноним (-), 16:12, 06/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> а tcc вообще всех порвет по скорости компиляции...
...зато проиграет по оптимизации и количеству поддерживаемых архитектур :P
| | |
| |
| 3.37, BratSinot (?), 17:07, 06/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
А че по оптимизации? Он между прочим только инструкции процессора использует.
| | |
| |
| 4.58, Аноним (-), 00:40, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> А че по оптимизации? Он между прочим только инструкции процессора использует.
Кирпичи то у всех одинаковые. Но у одних из них получаются дворцы, а у других - сараи.
Вывод: кроме кирпичей есть еще некоторая разница в том кто и как их разложит :)
| | |
|
|
|
| 1.8, Pickle (?), 12:22, 06/09/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Оке. А теперь приведите сравнение быстродействия проектов собранных с Clang и GCC. При этом на 2-3 различных (полностью) конфигурация. ИМХО, разница будет в другую сторону.
Рабочие сборки вообще (для крупных проектов) запускают без оптимизации (если конечно не её тестируют). "Оптимизацию" кода тоже нет смысла проверять используя "оптимизацию при сборке", т.к. принято оперировать не секундами/минутами/часами, а кол-вом требующихся операций для выполнения той или иной части кода (при этом не стоит забывать и про "скорость" той или иной операции).
| | |
| 1.10, ананим (?), 12:37, 06/09/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
а вот это как в конце сообщения понимать?
>Conclusion:
>-----------
>Both gcc 4.2.1 and 4.7.1 are the fastest compilers for building this specific large C++ library, but both versions of clang are not far behind. Both versions of gcc use quite a bit more memory than either version of clang.
кто врёт-то?
| | |
| |
| 2.21, Михрютка (ok), 14:29, 06/09/2012 [^] [^^] [^^^] [ответить]
| –2 +/– |
 а это некоторые анонимы в целях экономии моска ничего, кроме двух строчек в конце не читают.
данный конкретный канклюжн относится к сборке boost.
| | |
| |
| 3.25, ананим (?), 15:08, 06/09/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
ага, а некоторые только первые 2-е строчки.
зыж
щечки, щечки подправь.
а то лопнут.
| | |
|
| 2.23, sanDro (ok), 15:00, 06/09/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
 >> кто врёт-то?
Кто кто? Автор новости. Точнее не врёт, а говорит полуправду, что считается хуже чем просто лгать. И что показывает его любовь к clang. Взял из трёх тестов результат одного, который его больше устроил, а остальные в новости вообще не упомянул.
| | |
| |
| 3.59, Аноним (-), 00:42, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> остальные в новости вообще не упомянул.
Ну бсдшники же. Как обычно, свое - не пахнет.
| | |
|
|
| 1.12, Аноним (-), 12:52, 06/09/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
тут уже видимо важна не новость кому-то а итоговый холивар... нафиг мне Clang если в зависимостях gcc если я не разработчик...
| | |
| 1.15, Аноним (-), 13:21, 06/09/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
1. Clang компилит быстрее GCC - факт.
2. GCC оптимизирует программу лучше и на выходе программа работает быстрее чем собранная Clang - факт.
Пользователям положить на 1, для них главное чтобы программа работала шустрее, и как следствие авторам програмы это тоже становится важнее.
Когда Clang дорастет до GCC по второму параметру и при этом сохранит первый(или хотя бы паритет), тогда ОК.
| | |
| |
| 2.28, Алексей (??), 16:06, 06/09/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
Вы не поверите, но компилятор нужен программистам. И скорость компиляции и понятность диагностики ошибок является достаточно важным параметром.
| | |
| |
| 3.60, Аноним (-), 00:43, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Вы не поверите, но компилятор нужен программистам. И скорость компиляции и понятность
> диагностики ошибок является достаточно важным параметром.
...но не настолько чтобы простить в 3 раза более тормознутый код, который еще и более пухлый к тому же зачастую.
| | |
| |
| 4.66, arisu (ok), 00:57, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
> …но не настолько чтобы простить в 3 раза более тормознутый код, который
> еще и более пухлый к тому же зачастую.
вполне настолько. например, некий большой рогалик на c++ (нет, даже не спрашивай; писал это не я) у меня клангом почти в два раза быстрей собирается, нежели gcc. тут речь идёт о разнице в минутах. оно, вроде бы, и не так важно, но в силу специфики написания этого рогалика после изменений может пересобраться чуть ли не половина кода. и пара часов в день — тю-тю, если активно фичи допиливать. а вот разницы в скорости работы собраного кода на глаз не заметно.
| | |
| |
| 5.74, Аноним (-), 05:34, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
> оно, вроде бы, и не так важно, но в силу специфики
> написания этого рогалика после изменений может пересобраться чуть ли не половина
> кода. и пара часов в день — тю-тю, если активно фичи
> допиливать.
Да, так и быть, шланг - хорошая штука для компиляции вот этого твоего конкретного рогалика на си++. Правда это интересует полтора землекопа на всю планету. Я в их число не попадаю :P.
> а вот разницы в скорости работы собраного кода на глаз не заметно.
Да уж, такое и на JS тормозить не будет, а время компиляции вообще станет нулевое. Если продолжить ту же логику чуть дальше.
| | |
| |
| 6.88, arisu (ok), 12:05, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Да, так и быть, шланг - хорошая штука для компиляции вот этого
> твоего конкретного рогалика на си++.
и подобных проектов. которые этим рогаликом не ограничиваются.
> Да уж, такое и на JS тормозить не будет, а время компиляции
> вообще станет нулевое. Если продолжить ту же логику чуть дальше.
а вот про это ты бы лучше не говорил. внутренней структуры игры ты не знаешь, и сколько всего там происходит, тоже. рогалик, кстати, в графике, и даже с какой-никакой анимацией. и между ходами считает всего немало, в том числе и монстриков, которые живут сами по себе на всём уровне, а не только вокруг игрока. поверь, рогалик, где надо заметно долго ждать реакции компа на твой ход, очень быстро начинает раздражать.
| | |
| |
| 7.94, ананим (?), 13:39, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
а нефиг было с таким умным видом вот тут make выкидывать :D
https://www.opennet.ru/openforum/vsluhforumID3/86346.html#48
>а ещё можно, например, выкинуть make.
зыж
брехня это всё.
за 20-30 минут ВСЕ кеды и вмести с Qt компилятся. (как гентушник говорю)
даже при условии, что этот сферический "рогалик" размером с Qt (а я не верю в такие рогалики), даже если компиляция идёт на атомах (очень серьёзная контора видимо!), даже если команда не из тех кому думать, а только прыгать (любое изменение в исходниках приводит к перекомпиляции и пересборке!!! самое время кричать - выкинуть make! :D), даже если этот супер-дупер РОГАЛЪ собирается не частями, а целиком и несколько раз в день (архитект видимо тоже из тех кто прыгает), то и то такие трагические выводы НЕ ПОЛУЧАЮТСЯ.
и это если над проектом "прыгает" куча людей одновременно. :D
| | |
| |
| 8.103, arisu (ok), 15:21, 07/09/2012 [^] [^^] [^^^] [ответить] | +/– | а нефиг балаболить, если ни проекта, ни системы сборки не видел хотя что это я ... текст свёрнут, показать | | |
|
|
| 6.92, Vkni (ok), 13:13, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Да уж, такое и на JS тормозить не будет, а время компиляции
> вообще станет нулевое. Если продолжить ту же логику чуть дальше.
Компиляция - это не только перевод на ассемблер, но и статическая проверка кода. Как там у JS с этим?
| | |
|
|
| 4.67, iZEN (ok), 01:29, 07/09/2012 [^] [^^] [^^^] [ответить]
| –3 +/– |
 > ...но не настолько чтобы простить в 3 раза более тормознутый код, который еще и более пухлый к тому же зачастую.
Бред.
| | |
| |
| 5.75, Аноним (-), 05:35, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Бред.
Форониксу с их бенчами расскажи. Почему-то код сгенеренный шлангом проигрывает в вообще всех тестах кроме 1-2 по жизни. В некоторых местах - очень люто, в несколько раз.
| | |
| |
| 6.79, iZEN (ok), 07:08, 07/09/2012 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> Бред.
> Форониксу с их бенчами расскажи. Почему-то код сгенеренный шлангом проигрывает в вообще
> всех тестах кроме 1-2 по жизни. В некоторых местах - очень
> люто, в несколько раз.
Всего-то на 10-30%. Это не "несколько раз".
| | |
| |
| 7.95, ананим (?), 13:56, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
30% - это выкинуть больше чем одно ядро из моего 4-х-ядерника.
думаю хоть с памятью там не такие же проблемы?
| | |
|
|
|
|
|
|
| 1.16, ВовкаОсиист (ok), 13:22, 06/09/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
 Помоему у gcc на данный момент лучьше поддержка С++ чем у шланга, или нет? Как у шланга с С++11?
| | |
| |
| |
| 3.30, Аноним (-), 16:11, 06/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
У него в основном плохо с оптимизацией (в некоторых случаях GCC его разрывает буквально в разы) и с сборкой всего и вся (можно в 2 счета налететь на internal error).
| | |
| |
| 4.33, an. (?), 16:16, 06/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
Попробуйте последний стабильный релиз (3.1) - там они значительно улучшили дело, даже по сравнению с 3.0
| | |
| |
| 5.61, Аноним (-), 00:44, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Попробуйте последний стабильный релиз
Не вижу смысла. Reason: clang не поддерживает половину архитектур с которыми я работаю на регулярной основе.
| | |
| |
| 6.68, iZEN (ok), 01:31, 07/09/2012 [^] [^^] [^^^] [ответить]
| –3 +/– |
>> Попробуйте последний стабильный релиз
> Не вижу смысла. Reason: clang не поддерживает половину архитектур с которыми я
> работаю на регулярной основе.
Да ладно! User294, не ври.
| | |
| |
| 7.71, Led (ok), 03:49, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Clang уже умеет что-то кроме x86 и кое-как (т.е. условно) ARM?
| | |
| 7.73, Аноним (-), 05:22, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Да ладно! User294, не ври.
Ну тогда скажи как мне шлангом бинарь для Atmel AVR получить? Да и для Cortex M3 там когда я смотрел - все было на удивление криво. То-есть, в теории его убедить можно. На практике - через ту еще ж. Не говоря о том что GCC оптимизит намного лучше.
| | |
| |
| 8.80, iZEN (ok), 07:09, 07/09/2012 [^] [^^] [^^^] [ответить] | –2 +/– | Когда всякие там ПЛМ дорастут до уровня микропроцессора, тогда и спрашивай ... текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.69, 4ertus2 (?), 02:06, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
Наткнулся недавно на несоответствие между clang и gcc.
Думал ошибка первого. Оказалось, наоборот: gcc не держит стандарт.
A a(B(c));
в коде должно разрешаться как объявление функции, принимающий параметр B, а не как (как могло бы показаться и проглатывает gcc) создание переменной a с приведением переменной c к типу B (п. 8.2 драфта).
| | |
| |
| 3.89, arisu (ok), 12:08, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– | |
напиши репорт, ребята из gcc такие фишки вполне чинят.
но c++ всё-таки атомная хрень.
| | |
| 3.129, qux (ok), 20:07, 11/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > A a(B(c));
> в коде должно разрешаться как объявление функции, принимающий параметр B, а не
> как (как могло бы показаться и проглатывает gcc) создание переменной a
> с приведением переменной c к типу B (п. 8.2 драфта).
Вы про такое, где если добавить "typedef int B;", то скомпилируется только с предупреждением?
$ echo '
a(B(c));
int main () { return 0; }
' | gcc -x c -
<stdin>:2:3: error: unknown type name ‘B’
По (единственной) ошибке clang сложно понять, считает ли он B(c) объявлением функции:
$ echo '
a(B(c));
int main () { return 0; }
' | clang -x c -
<stdin>:2:3: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
a(B(c));
^
<stdin>:2:5: error: a parameter list without types is only allowed in a function definition
a(B(c));
^
<stdin>:2:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
a(B(c));
^
2 warnings and 1 error generated.
| | |
|
|
| 1.19, анон (?), 14:10, 06/09/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Когда не могут меряться производительностью кода, начинают выкатывать вот такие вот "результаты". И типа они на коне, хоть в чём-то.
| | |
| |
| |
| |
| 4.64, pavlinux (ok), 00:53, 07/09/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > 146% же
100% = 100
100 - 86% = 14
С другой стороны:
14 = 100%
100 = ?
| | |
|
|
|
|
