| |
| |
| 3.5, Аноним (5), 20:22, 03/06/2020 [^] [^^] [^^^] [ответить]
| +20 +/– |
Слушай... можешь компилятор С++ написать, но чтоб без сишных дыреней? На питоне норм будет думаю
| | |
| |
| 4.8, Fracta1L (ok), 20:38, 03/06/2020 [^] [^^] [^^^] [ответить]
| –36 +/– |
 С и С++ нужно закопать и хлоркой засыпать, это единственное лечение.
| | |
| |
| 5.10, Ванёк (?), 20:45, 03/06/2020 [^] [^^] [^^^] [ответить]
| +10 +/– |
Что, все дружно переходим на JavaScript? А потом снова на C/C++?
| | |
| 5.11, Корец (?), 20:47, 03/06/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Что предлагаешь взамен? Или как обычно - пустой звук и ничего больше?
| | |
| |
| 6.52, zshfan (ok), 18:08, 04/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Язык Ада например, защищён от выстрелов в ногу архитектурно (я любитель пистона если что)...
| | |
| |
| 7.58, Michael Shigorin (ok), 22:04, 04/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
 Говорят, надо просто ногу брать соответствующего масштаба -- и всё получится (я много писал на модуле-2, если что).
| | |
| 7.60, erthink (ok), 22:19, 04/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
 > Язык Ада например, защищён от выстрелов в ногу архитектурно (я любитель пистона
> если что)...
Ада нередко не то что в ногу, но и вообще не стреляет.
Однако, хуже когда стреляет не в ту сторону, можно в голову попасть.
;)
| | |
| |
| |
| 9.78, erthink (ok), 18:48, 05/06/2020 [^] [^^] [^^^] [ответить] | +1 +/– | Это не чушь, а объективная реальность Грубо говоря, по совокупности _разных_ пр... текст свёрнут, показать | | |
| |
| 10.80, Зз (?), 23:35, 05/06/2020 [^] [^^] [^^^] [ответить] | +1 +/– | Разбудите меня через 150 лет и я скажу вам, что делают на форуме програмистов... текст свёрнут, показать | | |
|
|
|
|
|
| 5.31, Аноним (-), 00:18, 04/06/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> С и С++ нужно закопать и хлоркой засыпать
О, дарю идею - сделай secure delete файла с линуксным (или какое там у тебя) ядром ОС :)
| | |
| |
| 6.59, Michael Shigorin (ok), 22:05, 04/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> С и С++ нужно закопать и хлоркой засыпать
> сделай secure delete файла с линуксным (или какое там у тебя) ядром ОС :)
Думаете, он способен написать соответствующую утилиту на растиго?
| | |
|
|
| 4.13, Ванёк (?), 20:48, 03/06/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
1) С каких пор у Питона меньше дыр? 2) А просадку производительности на порядок при переходе на Питон на всех компьютерах мира кто, как и чем будет компенсировать? 3) И процессорах дыры. Тоже заменим на Питон???
| | |
| |
| 5.30, Аноним (-), 00:16, 04/06/2020 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> 1) С каких пор у Питона меньше дыр?
Там вон эпическая новость про разнос вебсервисов цыски через питонятину. Им так лихо толпу майнеров вгрузили =)
| | |
| 5.56, Аноним84701 (ok), 19:33, 04/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
 >> Слушай... можешь компилятор С++ написать, но чтоб без сишных дыреней? На питоне норм будет думаю
> 1) С каких пор у Питона меньше дыр?
> 2) А просадку производительности на порядок при переходе на Питон на всех компьютерах мира кто, как и чем будет компенсировать?
Просадка результирующего бинарника в производительности "на порядок", именно из-за ЯП компилятора (а не п(р)ограммиста этого компилятора) ...
Н-да, чего только не узнаешь на опеннете 🙄
| | |
| |
| 6.61, Michael Shigorin (ok), 22:29, 04/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Полагаете, тот парень ещё и оптимизатор на питоне изобразить сможет -- да такой, чтоб в этой пятилетке что-то на гора выдал?..
| | |
| |
| 7.67, Аноним84701 (ok), 23:36, 04/06/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Полагаете, тот парень ещё и оптимизатор на питоне изобразить сможет -- да
> такой, чтоб в этой пятилетке что-то на гора выдал?..
Полагаю, что все же не стоит смешивать мух с котлетами, т.е. ЯП компилятора и результат. Тот же PyPy спокойно генерирует машкод для JIT.
Ну а так да, в одиночку, да с полной поддержкой C++17/20 ... первая реализация плюсов, вроде как, являлась транслятором в Си (и Бъерн писал ее не вечерами после работы, а будучи на зарплате Белл Лабс).
Да и потом, помнится, ту же реализацию С++98 ждали несколько лет.
Так что условия изначально "немного" нереалистичны.
| | |
|
|
|
|
| 3.29, Аноним (29), 00:15, 04/06/2020 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> Чтобы отвязаться от поехавшего GNU
И привязаться к совсем поехавшему эплу и всепожирающему гуглу...
| | |
| |
| |
| 5.42, Аноним (42), 12:25, 04/06/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Там целый букет лицензий. Наверное, специально так, чтоб мозги запудрить. Но это не отменяет того, что оно под пятой у Яббла.
| | |
|
|
|
| 2.4, A.Stahl (ok), 20:21, 03/06/2020 [^] [^^] [^^^] [ответить]
| +7 +/– |
 Никто никуда переходить не собирается, но иметь запасной вариант всегда хорошо.
| | |
| 2.6, Аноним (6), 20:25, 03/06/2020 [^] [^^] [^^^] [ответить]
| +12 +/– |
переходить может и не нужно. А вот выявить при пересборке не соответствующие стандарту компиляторо-специфичные костыли - дело очень полезное.
| | |
| |
| 3.9, Аноним (9), 20:42, 03/06/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Аналогично действую. При кроссплатформенной разработке отладка в различных системах позволяет добиться качества кода и поймать некоторые ошибки.
| | |
| |
| |
| 5.75, RomanCh (ok), 14:58, 05/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
 Я всё понимаю конечно, но очень смешно выглядит п.7:
> обязательства не публиковать результаты без предварительного согласования.
Неужели всё так ужасающе плохо, что можно получить результаты за которые будет вот прямо настолько стыдно?
PS Публикация шаблона заявки в MS Word формате, да ещё и с макросами - это прекрасно.
| | |
| |
| 6.76, Michael Shigorin (ok), 16:42, 05/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> обязательства не публиковать результаты без предварительного
>> согласования.
> Неужели всё так ужасающе плохо, что можно получить результаты
> за которые будет вот прямо настолько стыдно?
Порой собирают вообще без оптимизации, насколько до меня долетало... в таких случаях на VLIW всё и впрямь плохо.
Мы вон до сих пор вылавливаем апстримы, сборочные системы которых забивают на CFLAGS/CXXFLAGS, и в лучшем случае суют -O2 там, где хорошо бы -O3 (по крайней мере выпуски на lcc 1.23 у нас собраны именно так и им это явно пошло на пользу).
| | |
| |
| 7.77, RomanCh (ok), 16:57, 05/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Порой собирают вообще без оптимизации, насколько до меня долетало...
Спасибо, понятно. Хотя всё равно странно, ведь оптимизация обычно не даёт прямо космического прироста производительности, даже в разы, не то что на порядки. Т.е. её отсутствие не должно давать в итоге катастрофический результат.
Но в любом случае смешное требование, мне кажется лучше предупреждать что в случае публикации недостоверных сведений наносящих урон компании, могут быть соответствующие встречные действия предприняты. Это выглядит нормальной юридической казуистикой. А нынешний вариант выглядит желанием прикрыть провалы.
| | |
| 7.83, mikhailnov (ok), 14:04, 08/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
 А вот если бы сборочница не пропускала пустой debuginfo, то большая часть апстримов, забивающих на CFLAGS, была бы выявлена и исправлена
| | |
|
|
|
|
|
| 2.7, Аноним (7), 20:31, 03/06/2020 [^] [^^] [^^^] [ответить]
| –16 +/– | |
Вопрос скорее "Зачем оставаться на GCC". Прогресса со второй версии чайная ложка, до сих пор не умеет корректно высокие уровни оптимизации, генерит код, который повреждает память и продолжает работать дальше не генерируя ексцепшена, сборка под определённую архитектуру может "случайно" использовать левые команды процессора…
При всей монструозности шланга он позволяет быть уверенным что код работает так как написано в исходнике и предоставляет на порядок больше возможностей для отладки и статического анализа.
| | |
| |
| 3.17, Аноним (17), 21:30, 03/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>код работает так как написано в исходнике
угу. Тыкал одну из библиотек с поддержкой бенчмарков, так clang, в отличие от gcc, взял и выкорчевал вызовы функций, время выполнения которых пытался замерить. При этом все необходимые переменные, которые после такого стали ненужными, он решил оставить и рассчитать.
| | |
| 3.23, Аноним (23), 22:01, 03/06/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
У шланга высокие уровни оптимизации не особо от низких отличаются. А всё потому, что он способен оптимизировать только лапшой из goto. В gcc оптимизации уровня O3 и не включённые в него включаются в pgo. Остальное баги и регрессии, они исправляются (регулярно). Слишком много изменений происходит в нём, тут ты совершенно неправ.
| | |
|
| |
| |
| 4.69, Ordu (ok), 00:09, 05/06/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > just for YOBA (Youth Oriented, Bydlo-Approved)
Естественно, это не для старпёров. Старпёры пускай водку жрут да в свою Nintendo рубятся, никакой другой fun им недоступен уже.
| | |
|
|
| 2.34, Аномсис (?), 04:57, 04/06/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Можно будет все пакеты распространять в уже оптимизированном биткоде LLVM, а при установке они будут быстро компилироваться с оптимизацией по-максимуму под архитектуру процессора. При этом скорость компиляции будет намного быстрее, чем из изходников C/C++. А в репозитории будет храниться всего одна пакетная база, универсальная, под все архитектуры.
Для сравнения, сейчас репозитории содержат разные ветки, каждая скомпилирована под свою архитектуру.
Если это x86, то компиляция там под i686, т.е. в оптимизации не задействованы функции новых процессоров. Кто хочет задействовать свой процессор по-максимуму, им приходится самим компилировать под свой процессор. А из исходников это очень долго.
| | |
| |
| 3.35, Аноним (23), 06:27, 04/06/2020 [^] [^^] [^^^] [ответить]
| +3 +/– | |
>Если это x86, то компиляция там под i686, т.е. в оптимизации не задействованы функции новых процессоров. Кто хочет задействовать свой процессор по-максимуму, им приходится
А подо что ты там компилировать собрался, под нетбурст? Нынешние процессоры к нему никакого отношения не имеют. Или ты рассчитываешь на simd оптимизации? Это только если в приложении они есть (ручные), на этой почве совершенно не важно для чего 32 битный код компилировать (зачем его вообще компилировать). А по поводу amd64, очень часто оптимизация arch под core2 оказывается быстрее native, так что вот так.
И кстати не взлетит, самый быстрый шланг обычно оказывается медленней gcc+pgo. Намного быстрее наверно не будет, самое тяжолое и муторное это как раз линковка.
| | |
| 3.45, Аноним (42), 12:39, 04/06/2020 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>Можно будет все пакеты распространять в уже оптимизированном биткоде LLVM
Для вас, любителей блобов, и проприерасов уже придумали WASM.
| | |
|
| 2.38, Аноним (38), 09:18, 04/06/2020 [^] [^^] [^^^] [ответить]
| +/– | |
Это ZOG дурацкую работу подкидывает, чтобы отвлечь ресурсы.
Так было с сырым python3 лет 10 назад. (Поддерживать два языка проэкту труднее и более ресурсоемко чем один, код становится жирнее и сложнее)
| | |
| 2.40, DerRoteBaron (ok), 09:36, 04/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
 Хотя бы чтобы почистить код от совсем упоротых GNU-хаков и ошибок, возникающих из-за них. Ну и чтобы не давать GCC застрять на месте. Они как после появления рабочего шланга (или пинков от Линуса) проснулись и начали снова делать приличный тулчейн.
| | |
| 2.50, freehck (ok), 14:08, 04/06/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Напомните, зачем нужно переходить на шланг?
Вопрос не в переходе, а в проверке сборки другим сторонним компилятором. Де факто это конкуренция, что в общем-то хорошо, ибо она позволит:
1) иметь компилятор про запас, если один в силу каких-то обстоятельств загнётся / остановится в развитии,
2) найти больше ошибок, ибо то, что один компилятор проглотит, второй может и не проглотить, и выдать ворнинг или же вообще завалиться
| | |
| |
| 3.63, Michael Shigorin (ok), 22:34, 04/06/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Вопрос не в переходе, а в проверке сборки другим сторонним компилятором.
Скажу больше -- чтобы избежать вендорлока. К сожалению, RMS явно рассматривает компилятор (точнее, gnu extensions) как оружие. В смысле мне рассказывали о письмах проектам с просьбой отвергать патчи, позволяющие собраться clang. Меня такое крайне напрягло.
PS: nested functions нет (и, вероятно, не будет) больше нигде; плюс VLAIS.
| | |
| |
| 4.65, freehck (ok), 23:05, 04/06/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> К сожалению, RMS явно рассматривает компилятор (точнее, gnu extensions) как оружие.
Если по-твоему это "к сожалению", то вероятно ты не вполне понимаешь мотивы Ричарда.
| | |
|
|
| 2.79, Gogi (??), 19:00, 05/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
Зачем склеротикам вообще задавать такие вопросы? Кушайте свои таблеточки, не мешайте продукту развиваться.
| | |
|
| 1.18, Anonymus (?), 21:30, 03/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
>отсутствия некоторых заголовочных файлов
Это да, не суметь скомпилировать простенький "Hello World!" на C99 из-за потери собственных библиотек - это что-то...
>возврат не-void функцией какого-то значения
А вот тут не понял, что не так-то? Или это опечатка?
>использование сравнения указателя с нулём
Да, зачем проверять что-то, действительно.
| | |
| |
| 2.20, Ordu (ok), 21:51, 03/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> возврат не-void функцией какого-то значения
> А вот тут не понял, что не так-то?
Какой смысл в этом? Бессмыслицу в языках программирования нужно выжигать калёным железом. Она хороша только для обфускации кода и больше ни для чего.
>> использование сравнения указателя с нулём
> Да, зачем проверять что-то, действительно.
Проверять нужно, но не нужно при этом приводить указатели к int'у или int'ы к указателю. Если уж очень нужно, сделай это явно. Если явно писать преобразование влом, то для сравнения есть макро NULL.
| | |
| |
| 3.33, userd (ok), 00:47, 04/06/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
 >>> возврат не-void функцией какого-то значения
>> А вот тут не понял, что не так-то?
> Какой смысл в этом? Бессмыслицу в языках программирования нужно выжигать калёным железом. Она хороша только для обфускации кода и больше ни для чего.
В новости как-то нехорошо перевели проблемы.
На странице https://clang.debian.net/ это называется «non-void function should return a value»
типа «error: non-void function 'u_free' should return a value»
Это скорее всего какие-то ошибки в логике.
>>> использование сравнения указателя с нулём
>> Да, зачем проверять что-то, действительно.
> Проверять нужно, но не нужно при этом приводить указатели к int'у или int'ы к указателю. Если уж очень нужно, сделай это явно. Если явно писать преобразование влом, то для сравнения есть макро NULL.
Никто не приводит указатели к int'у или int'ы к указателю :)
Опять-же, в источнике речь идёт не просто о сравнении, а об упорядоченном сравнении.
Типа «error: ordered comparison between pointer and zero ('int *' and 'int')»
в выражении «if (iPos >= 0) {»
Так-то неупорядоченное сравнение типа == и != делайте сколько угодно, NULL тут не причём.
И это тоже скорее всего какие-то ошибки в логике обусловленные изменением типа переменной либо некритичной копи-пастой.
Ждём выступления товарища из команды PVS-Studio с рассказом как его софт позволяет избежать таких вот неприятностей :)
| | |
|
| 2.22, Аноним84701 (ok), 21:53, 03/06/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
>>использование сравнения указателя с нулём
> Да, зачем проверять что-то, действительно.
Да, зачем смотреть в чем дело, действтительно:
domain.c:119:23: error: expression which evaluates to zero treated as a null pointer constant of type 'char *' [-Werror,-Wnon-literal-null-conversion]
hashPtr = '\0';
^~~~
контекст:
/* Is line a comment - ignore everything after '#' character */
if (NULL != (hashPtr = strchr(linePtr, '#'))) {
hashPtr = '\0';
}
Подумаешь, баг в логике (ну или опечатку/забытый *) нашли ...
| | |
| 2.27, Аноним (27), 23:13, 03/06/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> А вот тут не понял, что не так-то? Или это опечатка?
Сижу и не могу воткнуть. Скорее всего опечатка
| | |
|
| |
| 2.28, DontTreadOnMe (?), 23:26, 03/06/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Сначала msvc надо нормальный си научить компилять. Потом добавить ему гнутые расширения. И только потом можно подумать о тестировании.
| | |
|
| |
| |
| |
| 4.66, Wolfy (?), 23:10, 04/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
Учитывая, что все трое — сионисты, очень сомнительное утверждение.
| | |
|
|
| 2.54, Аноним (54), 18:53, 04/06/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Поддерживая одновременно и gcc и clang, мы не лежим ни под GNU ни под Apple.
| | |
| |
| 3.55, erthink (ok), 19:03, 04/06/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Поддерживая одновременно и gcc и clang, мы не лежим ни под GNU
> ни под Apple.
Разработчики с пониженной компиляторной ответственностью?
;)
| | |
|
|
|
