URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 79825
[ Назад ]

Исходное сообщение
"Версия компилятора Clang с поддержкой SAFECode для выявления..."

Отправлено opennews , 18-Авг-11 21:54 
Анонсирован (http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-August/04250...) выпуск компилятора Clang (http://clang.llvm.org/), разрабатываемого в рамках проекта LLVM, отличающийся добавлением поддержки технологии SAFECode, позволяющей автоматизировать выявление ошибок, связанных с некорректной работой с памятью. Поддержка SAFECode включается через указание специальной опции и никак не влияет на поведение компилятора, когда данная опция не активна, т.е. представленный выпуск может быть использован в роли полной замены классической сборке  clang/clang++. Для загрузки доступны (http://sva.cs.illinois.edu/downloads.html) как исходные тексты, так и готовые сборки для Linux и Mac OS X.


В отличие от инструментов подобных Valgrind,  Clang с поддержкой SAFECode обладает следующими преимуществами:


-  Он быстрее, так как не использует динамической трансляции исполняемого файла и может оптимизировать некоторые runtime-проверки;

-  Он более точен, так как знает расположение ...

URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-August/04250...
Новость: http://www.opennet.me/opennews/art.shtml?num=31533


Содержание

Сообщения в этом обсуждении
"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено XVilka , 18-Авг-11 21:54 
Вот это замечательно! Clang - отличная штука. Теперь все свое стараюсь собирать им и gcc - очень много потенциальных ошибок выявляет.

"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено fyfybgv , 19-Авг-11 02:59 
А ты тоже "указатели инициализируешь", или даже не знаешь зачем это нужно (или не нужно)?


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 05:46 
> (или не нужно)?

Я сильно удивлюсь если он, умея пользоваться идой и колупать дизасмы, вдруг не знает как работать с указателями. Это было бы весьма оригинальное сочетание.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено pavlinux , 19-Авг-11 19:11 
А где было написано про IDA и дизассмы? :)

---

Я тоже немного не врубися... Накой инициализировать указатели?
Ну объявил я его, ну есть такой... а в нужном месте я ему чё-нить присвою.
В первом случае gcc матернётся, что есть не используемая переменная, а так,
забуду и появиться висячий. Хотя, gcc 4.6 тоже орёт, что переменная
инициализирована, но не используется.



"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 24-Авг-11 20:19 
> А где было написано про IDA и дизассмы? :)

Этот человек замечен в ковырянии огороженных мотороло-техасских загрузчиков идой.
И вообще, ну что ты как маленький? Тынц: http://www.opennet.me/~XVilka


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 18-Авг-11 23:18 
старичку gcc потихоньку приходится уходить на покой, еще лет пять и будет нормальный, прогрессивный компилятор, под нормальной лицензией. ура, елки-палки!

"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 18-Авг-11 23:41 
_нормальный_ компилятор на базе clang будет разве что под проприетарной лицензией, либо вообще не выйдет за пределы Apple.
Поэтому альтернативы gcc в ближайшие годы не видать :(

"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено an , 19-Авг-11 01:07 
> Поэтому альтернативы gcc в ближайшие годы не видать :(

Так обычно пытаются утешать себя те, кто с большим трудом в свое время кое-как освоили gcc, и уже не в состоянии переучиваться.

Скажем так, gcc будет жив до тех пор, пока живы люди, для которых альтернативы gcc действительно нет.

Ведь еще живы те, например, для которых нет альтернативы COBOL'у, fortran'у или DOS'овскому FoxPro.

Так что можете спать спокойно дальше.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 03:03 
clang - это внутренняя разработка Apple, и наружу выставляется лишь ее огрызок (в лучший традициях данной компании). Именно поэтому и выбрана такая лицензия (по аналогии с проприетарным андроидом, который якобы "открыт под лицензией Apache").

А открытое сообщество по-прежнему будет довольствоваться этим чудом, которое даже бутстрапиться толком не умеет. А когда им пересоберут Фрю, с нее сбегут не только Яндекс и Рамблер.

Поэтому среди _открытых_ компиляторов альтернативы gcc нет и не будет. Есть лишь проприетарные нишевые решения, вроде icc.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено fyfybgv , 19-Авг-11 03:07 
>  Есть лишь проприетарные нишевые решения, вроде icc.

PathScale



"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 03:16 
Да, зря я за новостями не следил. Пропустил много интересного.

"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено alexxy , 19-Авг-11 13:57 
Это тоже не альтернатива. Он не понимает всего спектра платформ на которых работает gcc. Где там в pathcc arm mips ppc64 ia64? не говоря уже о microblaze tile и тп? нэту так что не альтернатива а нишевое решение которое еще и тупить ацки

"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 16:23 
> говоря уже о microblaze tile и тп?

А как насчет MSP430, AVR, ARM и OpenRISC? Или мы должны выбирать альтернативы аж из целого х86 на все задачи, от мигания светодиодом в брелке до суперкомпьютеров?


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено arcade , 19-Авг-11 10:37 
1. Если clang это закрытая разработка представьте доказательства скрытия кода.
2. Если факт выбора лицензии свидетельствует о желании разработчика скрыть код - сажайте меня за изначилование, орган имеется.
3. Оно уже год как бутстрапится.
4. Фрю им уже пересобрали. Основная причина ухода с фри Рамблера не компилятор.
5. Среди открытых компиляторов уже есть целая куча альтернатив gcc: tcc, pcc.

Хотя бы не передёргивайте.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 16:20 
> 1. Если clang это закрытая разработка представьте доказательства скрытия кода.

Эпплу все это надо сугубо для их xcode. И практически все разработчики шланга в эппле, что как бы намекает.

> 2. Если факт выбора лицензии свидетельствует о желании разработчика скрыть код -
> сажайте меня за изначилование, орган имеется.

Эппл делом доказал на примере iOS, MacOS X и прочих что они не только имеют орган, но и зажимать вполне умеют. Достаточно вспомнить приколы с закрытием, открытием и опять закрытием и опять открытием дарвина :)))

> 3. Оно уже год как бутстрапится.

So what?

> 4. Фрю им уже пересобрали. Основная причина ухода с фри Рамблера не компилятор.

Сырой, грабельный и никем не поддерживаемый толком компилятор - оптимизма пользователям нацеленным на результат явно не добавит. Поскольку почти все разработчики в эппле а тому нужна макось а на бзди плевать, наивно ожидать что разработчики шланга бросятся решать проблемы оного применительно к бсд. Ну вот и будет у вас как обычно, третий сорт - не брак. Бздунам не привыкать быть третьим сортом на фоне проприетарщиков забирающих первый сорт себе. Проблема только в том что кастомеры не хотят третий сорт. Им первый подавай. Наверное потому и на линуксе с гцц в результате.

> 5. Среди открытых компиляторов уже есть целая куча альтернатив gcc: tcc, pcc.

Они очень альтернативно одаренные альтернативы. А как насчет кодогенерации ну хотя-бы под новомодный ARM? А чтоб еще и с DSP-инструкциями и SIMD, если камень умеет?  

> Хотя бы не передёргивайте.

Ну и к себе это примените, имхо.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 17:48 
>2. Если факт выбора лицензии свидетельствует о желании разработчика скрыть код - сажайте меня за изначилование, орган имеется.

Аналогия некорректна.
Более корректная: возьмем два условных фаллоимитатора. Один можно использовать любых целях, включая изнасилование, другой - в любых целях, кроме изнасилования (механизм ограничения, допустим, предельно прозрачен). Цена и прочие характеристики одинаковы. Если человек приходит в секс-шоп и из этих двух выбирает первый, то его намерения вполне очевидны. Точно так же очевидны намерения гугла и яббла.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 17:51 
>4. Фрю им уже пересобрали. Основная причина ухода с фри Рамблера не компилятор.

А никто и не говорил, что дело в компиляторе (сейчас там gcc по умолчанию, так что clang ни при чем).
Просто после перехода фри на clang там наверняка появится еще туева хуча проблем, начиная от множества хаков при make world и заканчивая кучей внезапных сегфолтов от разных программ.

>5. Среди открытых компиляторов уже есть целая куча альтернатив gcc: tcc, pcc.

А запорожец - реальная альтернатива 911 поршу, да.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено samm , 20-Авг-11 21:44 
Вы говорите о том, в чем ничего не понимаете. Пересобрал все свои проекты clangom без проблем. В некоторых с++ файлах получил вполне справедливые замечания о том, что негоже возвращать false где прототип int. Никаких "жутких проблем" не получил. Ну и опыт гугла мне как-то более показателен чем красноглазые форумные ламеры - http://blog.llvm.org/2011/05/c-at-google-here-be-dragons.html

"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 06:06 
> Так обычно пытаются утешать себя те, кто с большим трудом в свое
> время кое-как освоили gcc, и уже не в состоянии переучиваться.

А чтобы переучиваться - через сколько лет он начнет генерить код под MSP430 допустим? Или там AVR? Или на кой черт переучиваться? GCC поддерживает больше архитектур и генерит более оптимизированный код как правило. А на архитектуру пусть бсдуны наяривают, как обычно.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено z , 19-Авг-11 16:13 
>GCC поддерживает больше архитектур и генерит более оптимизированный код как правило

взаимоисключающие понятия


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 16:27 
> взаимоисключающие понятия

Что значит - взаимоисключающие? Есть бенчи от того же фороникса и прочих, и в почти всех из них шланг радостно сливает. Почему-то он чаще сливает в разы чем сколь-нибудь заметно обгоняет гцц, как ни странно. А генерить код для всяких там армов и мипсов он вообще умеет только на бумаге похоже. Про всякие там аврки и вовсе даже речи не идет.

Остается вопрос: да напуркуа б осваивать компилер понимающий полторы архитектуры и с более плохой оптимизацией? И почему это надо засчитать за epic win?


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 16:48 
оптимизация у clang лучше.

А вобще хватит кормить троля - пошел бы ты почитал что ли документацию.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 17:43 
> оптимизация у clang лучше.

Нет, оптимизация лучше у gcc. clang и компилировать-то толком не умеет, куда уж ему оптимизацией заниматься.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено nagual , 23-Авг-11 18:16 
>> взаимоисключающие понятия
> ... Есть бенчи от того же фороникса ...

О да :-)) это это крутые бенчи :-)) круче тока бенчи от intel :-))



"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 30-Авг-11 14:35 
> О да :-)) это это крутые бенчи :-)) круче тока бенчи от intel :-))

Если вы считаете что такие-то бенчи плохие, ну ок: произведите бенчи лучше, которые будут "хорошие". И опубликуйте результаты с внятным описанием параметров тестов, чтобы можно было проверить что вы не врете. И имейте в виду что мы без проблем вычислим потуги подыграть тем или иным кандидатам, так что даже и не пытайтесь.

Субъективно шланг генерит код похуже GCC в среднем по больнице, а на некоторых неудобных ему случаях отхватывает epic fail, сливаясь в 2-3 раза без особых причин, что у фороникса на тестах прекрасно видно. Какой-то плохо-предсказуемый и недопиленный оптимизатор, если называть вещи своими именами.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено ibat , 20-Авг-11 01:13 
FORTRAN не трогать, а если трогать, тогда объяснте и что лутше для научных рассчетов?

"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено qwe , 21-Авг-11 17:01 
Haskell?

"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 04:01 
clang уже есть и он более чем нормальный. Когда в gcc будет статический анализ, нормальное LTO, да просто хотя бы нормальные сообщения об ошибках, можно будет говорить, а пока clang его заруливает.

"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено ананим , 19-Авг-11 04:19 
угу. заруливает. особенно если смело написать:
>Используя Clang уже удалось обеспечить сборку таких значительных проектов, как ядро Linux

а чуть капнёшь по ссылке, и:
>К сожалению не все проблемы еще решены и для того чтобы добиться загрузки системы приходится использовать некоторые компоненты, собранные при помощи GCC. В частности, из-за возникновения внутренних ошибок компилятора и проблем c обработкой массивов переменной длины, пока не удается собрать код SELinux, Posix ACL, IPSec, eCrypt и других подсистем, использующих Crypto API. Разработчики Clang надеются, что код Crypto API не фундаментально завязан на специфичных GNU-расширениях GCC и решить возникшие проблемы удастся незначительными правками. Кроме того, незначительные проблемы наблюдаются при сборке кода, связанного с Xen, IPv6 и Netfilters/Router, не работает код загрузки модулей ядра.

не каждый хеловорд, но заруливает адназначна. особенно если гцц поможет. :D


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено G0Dzilla , 19-Авг-11 05:28 
> угу. заруливает. особенно если смело написать:
>>Используя Clang уже удалось обеспечить сборку таких значительных проектов, как ядро Linux
> а чуть капнёшь по ссылке, и:
>>К сожалению не все проблемы еще решены и для того чтобы добиться загрузки системы приходится использовать некоторые компоненты, собранные при помощи GCC. В частности, из-за возникновения внутренних ошибок компилятора и проблем c обработкой массивов переменной длины, пока не удается собрать код SELinux, Posix ACL, IPSec, eCrypt и других подсистем, использующих Crypto API. Разработчики Clang надеются, что код Crypto API не фундаментально завязан на специфичных GNU-расширениях GCC и решить возникшие проблемы удастся незначительными правками. Кроме того, незначительные проблемы наблюдаются при сборке кода, связанного с Xen, IPv6 и Netfilters/Router, не работает код загрузки модулей ядра.
> не каждый хеловорд, но заруливает адназначна. особенно если гцц поможет. :D

В данном случае речь идет о gcc-змах. А раз clang не gcc, то и обработать его правильно не сможет. Уж это Вы должны суметь понять.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 06:13 
> суметь понять.

Не очень понятно: какой-то закон запрещает реализовать расширения от гцц? Некоторые из них достаточно удобны, вообще-то. По-моему, для всех будет лучше если вместо воплей "не нужно" вы лучше заткнетесь и просто реализуете фичи. И вам проще и всем остальным. Правильное решение конечно в стандарт втолкать, но ждать еще 10 лет очередной стандарт - как-то слишком уж геморройно (вспомним C++ 0x ставший C++ 11 в результате?!)


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено arcade , 19-Авг-11 11:06 
>> суметь понять.
> Не очень понятно: какой-то закон запрещает реализовать расширения от гцц? Некоторые из
> них достаточно удобны, вообще-то. По-моему, для всех будет лучше если вместо
> воплей "не нужно" вы лучше заткнетесь и просто реализуете фичи. И
> вам проще и всем остальным. Правильное решение конечно в стандарт втолкать,
> но ждать еще 10 лет очередной стандарт - как-то слишком уж
> геморройно (вспомним C++ 0x ставший C++ 11 в результате?!)

А вопрос не в фичах, а "упрощённой модели" реализации. Взять например наследование темплейтов: "http://stackoverflow.com/questions/3829040/scope-problems-in.... В clang-е эта хрень реализована верно и он ошибку видел, а gcc компилил как есть и не заморачивался.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено ананим , 19-Авг-11 12:38 
>А вопрос не в фичах, а "упрощённой модели" реализации.

а вопрос не в фичах и "упрощённой модели" реализации.
вопрос в сборке всего того ПО, которое есть на данный момент.
и если кому то сильно жмут гнушные утилиты, то это его проблемы - я же просто возьму и соберу тем, что собирает без проблем.
зыж
самое время назвать меня красноглазым, угу.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 24-Авг-11 19:12 
да да. есть идиоты которые пишут код под конкретный компилятор и удивляются почему при смене версии gcc все перестало работать.
Есть те кто пишут переносимый код - и тогда собирается даже clang.

Ты видимо относится к первым.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено AlexAT , 24-Авг-11 19:47 
Вам к жабистам. Хотя и у них переносимость не всегда возможна.

"Версия компилятора Clang с поддержкой SAFECode для..."
Отправлено anonymous , 19-Авг-11 12:57 
> Взять например наследование темплейтов

в C, ага.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено G0Dzilla , 19-Авг-11 18:39 
>> суметь понять.
> Не очень понятно: какой-то закон запрещает реализовать расширения от гцц? Некоторые из
> них достаточно удобны, вообще-то. По-моему, для всех будет лучше если вместо
> воплей "не нужно" вы лучше заткнетесь и просто реализуете фичи. И
> вам проще и всем остальным. Правильное решение конечно в стандарт втолкать,
> но ждать еще 10 лет очередной стандарт - как-то слишком уж
> геморройно (вспомним C++ 0x ставший C++ 11 в результате?!)

Закон не запрещает. Но зачем, если есть стандарт, который надо придерживаться. Или Вы хотите сказать, что хаки под IE - тоже хорошо?


"Версия компилятора Clang с поддержкой SAFECode для..."
Отправлено anonymous , 19-Авг-11 19:19 
> Закон не запрещает. Но зачем, если есть стандарт, который надо придерживаться. Или
> Вы хотите сказать, что хаки под IE — тоже хорошо?

если gcc добавляет к стандарту удобные плюшки — я лично буду использовать эти плюшки. стандарты пишут не боги (ох, далеко не боги). и если мне надо ждать ещё 10 лет, чтобы в стандарт внесли очередную удобную плюшку — в анус такой стандарт.

gcc — сам по себе стандарт, de facto. если кому-то нравится быть пуристом — на здоровье, конечно; а я лично мазохизмом не страдаю в такой степени.

к тому же аналогия неверная: gcc *дополняет* стандарт, а IE просто тупо неверно реализует. разница ощутимая.

так что бедняши, которым религия запрещает использовать gcc — ССЗБ.


"Версия компилятора Clang с поддержкой SAFECode для..."
Отправлено Аноним , 24-Авг-11 23:00 
>[оверквотинг удален]
>> Вы хотите сказать, что хаки под IE — тоже хорошо?
> если gcc добавляет к стандарту удобные плюшки — я лично буду использовать
> эти плюшки. стандарты пишут не боги (ох, далеко не боги). и
> если мне надо ждать ещё 10 лет, чтобы в стандарт внесли
> очередную удобную плюшку — в анус такой стандарт.
> gcc — сам по себе стандарт, de facto. если кому-то нравится быть
> пуристом — на здоровье, конечно; а я лично мазохизмом не страдаю
> в такой степени.
> к тому же аналогия неверная: gcc *дополняет* стандарт, а IE просто тупо
> неверно реализует. разница ощутимая.

вот IE просто дополняет стандарт удобными ему вещами, забывая реализовать что не удобно - как и поступает gcc. так за что вы не навидете IE ? Великий Столман завещал его ненавидеть и любить маленьких мальчиков?


"Версия компилятора Clang с поддержкой SAFECode для..."
Отправлено Аноним , 30-Авг-11 14:40 
> вот IE просто дополняет стандарт удобными ему вещами, забывая реализовать что не
> удобно - как и поступает gcc.

gcc довольно неплохо реализует стандарты, что c99, что C++ 11. А то что он реализует что-то сверх того - гм, а что, предлагается еще годков 15 ждать пока примут c(++)2025 какой-нибудь? Если б ишак реализовывал стандарты так как они описаны и более-менее целиком, к нему бы никто никаких претензий не предъявлял бы по части стандартов.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 18:40 
>В данном случае речь идет о gcc-змах.

Речь идет о внутренних ошибках компилятора и проблемах с обработкой массивов переменной длины, уж это вы должны суметь прочитать.


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено nagual , 23-Авг-11 18:21 
> угу. заруливает. особенно если смело написать:
>>Используя Clang уже удалось обеспечить сборку таких значительных проектов, как ядро Linux
> а чуть капнёшь по ссылке, и:
>>К сожалению не все проблемы еще решены и для того чтобы добиться загрузки системы приходится использовать некоторые компоненты, собранные при помощи GCC. В частности, из-за возникновения внутренних ошибок компилятора и проблем c обработкой массивов переменной длины, пока не удается собрать код SELinux, Posix ACL, IPSec, eCrypt и других подсистем, использующих Crypto API. Разработчики Clang надеются, что код Crypto API не фундаментально завязан на специфичных GNU-расширениях GCC и решить возникшие проблемы удастся незначительными правками. Кроме того, незначительные проблемы наблюдаются при сборке кода, связанного с Xen, IPv6 и Netfilters/Router, не работает код загрузки модулей ядра.
> не каждый хеловорд, но заруливает адназначна. особенно если гцц поможет. :D

Вообще то ядро линукса это огромная куча кода драйверов написанного непонятно кем. Многое железо уже умерло  и так так девайсов тех уже нет переписывать это непланируется ...


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 06:09 
> статический анализ, нормальное LTO,

Блин, почему-то в целом оптимизация гцц - лучше. Как именно это достигнуто, мне как программисту вообще до лампочки, LTO там это сделает или что-то еще.

> да просто хотя бы нормальные сообщения об
> ошибках, можно будет говорить, а пока clang его заруливает.

Не хочу ничего сказать, но у меня почему-то нет проблем с пониманием ошибок и варнингов выдаваемых gcc. Наверное я что-то делаю не так. Может, надо потупеть на 20 пунктов?!


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 11:12 
> у меня почему-то нет проблем с пониманием ошибок и варнингов выдаваемых gcc

boost'ом давно пользовался? Что-нибудь серьезное на плюсах вообще писал (на плюсах, а не на C с классами)?


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено ананим , 19-Авг-11 12:40 
qt, кеды и тд.
они вообще ещё не собираются толком шлангом.

"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено ананим , 19-Авг-11 12:46 
зыж
и тут же вдогонку:
>При оценке производительности демонстрационного браузера на основе Qt и QtWebKit, собранного при помощи Clang, на выполнение тестов SunSpider ушло 415.4мс, в то время как QtSDK/64bit в сборке Nokia выполняется за 360.0 мс (замедление на 13%).

и
>Последняя версия Clang успешно собирает Boost и проходит большинство тестов.

а меньшинство видимо вообще не проходит?
и как, опять без пруфов будете кидаться словами?


"Версия компилятора Clang с поддержкой SAFECode для..."
Отправлено anonymous , 19-Авг-11 13:00 
> boost'ом давно пользовался?

я вот, к счастью, никогда.

> Что-нибудь серьезное на плюсах вообще писал (на плюсах, а не на C с классами)?

а что, на плюсах «пишут серьёзное»? в *серьёзных* проектах гайдлайнами цпп обрезан как раз до «сей с классами».


"Версия компилятора Clang с поддержкой SAFECode для выявления..."
Отправлено Аноним , 19-Авг-11 16:41 
> boost'ом давно пользовался?

Не, спасибо, не люблю переростков. Но вообще-то у шланга проблем с сборкой плюсатого софта выше крыши, если уж на то пошло.