| 1.3, Аноним (3), 14:26, 28/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
Я так понимаю использование
>режима статического анализа "-fanalyzer"
переводит Rust в статус deprecated.
:)
| | |
| |
| |
| 3.22, Аноним (3), 16:14, 28/04/2021 [^] [^^] [^^^] [ответить]
| –6 +/– |
Это статические анализаторы, которые смотрят ошибки по тексту кода. А "-fanalyzer" компилирует код и по ходу выполнения смотрит ошибки, что, как я понима делает и компилятор Rust. В это смысле достугается паритет. Достугнут он лили нет - вряд ли - не берусь судить.
| | |
| |
| 4.40, Аноним (-), 18:00, 28/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Это статические анализаторы, которые смотрят ошибки по тексту кода. А "-fanalyzer" компилирует код и по ходу выполнения смотрит ошибки, что, как я понима делает и компилятор Rust.
>> Clang Static Analyzer
>> It implements path-sensitive, inter-procedural analysis based on symbolic execution technique.
Как я и подозревал - анализ уровня "слышал звон". И даже по ссылкам не ходил.
> В это смысле достугается паритет.
Там нужно конкретно так смотреть на объем и качество анализа, иначе "ни о чем".
| | |
| |
| 5.42, Аноним (42), 18:40, 28/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
>> It implements path-sensitive, inter-procedural analysis based on symbolic execution technique.
>Как я и подозревал - анализ уровня "слышал звон". И даже по ссылкам не ходил.
Мда, как то эта информация прошла мимо :( Буду знать какой оказывается Clang Static Analyzer
| | |
|
|
|
| 2.19, Аноним (19), 15:57, 28/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Беда в том, что рантайм проверки очень дорогие для приложения. Если придумать некий специальный рантайм для плюсов, проблемы с производительностью у него будут ровно те же, что и у раста. В целом же, раст стоит расценивать исключительно как площадку для экспериментов по улучшению плюсов, а не как замену чему бы то ни было, поэтому выкидывать в ближайшее время ничего не будут.
| | |
| |
| 3.20, Аноним (3), 16:08, 28/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Ну так опция -fanalyzer включается только в dev окружении и выключается в релизе.
| | |
| 3.27, Маняним (?), 16:56, 28/04/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
Какие рантайм проверки? Вы хоть читайте. Это статический, компайл-тайм анализ кода на перечеслинные дефекты. Именно о чем кричат растофилы. Только для такого контроля не надо пердолиться с явным обозначением лайфтайма объектов в языке, изобретать ансейф-код для создания двух и более модифицирующих ссылок, даже в сингл-треде. Анализ кода во-время компиляции основывается на вычислениях во время компиляции и анализе путей исполнения кода. И у компилятора гораздо больше информации о путях исполнения кода чем у внешнего анализатора, которому по сути нужно проделять ту же самую работу чтобы получить её.
| | |
| |
| 4.32, Аноним (19), 17:06, 28/04/2021 [^] [^^] [^^^] [ответить]
| –6 +/– |
Компайл тайм раста по сути бесполезен и является сахаром ради сахара -- сегодняшние анализаторы ничем не хуже. Весь профит в рантайм проверках.
| | |
| |
| 5.37, Аноним (37), 17:46, 28/04/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
Компайл тайм раста, в отличие от обычных анализаторов, дает гарантии
| | |
| |
| 6.43, Аноним (19), 19:06, 28/04/2021 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Компайл тайм раста, в отличие от обычных анализаторов, дает гарантии
Только на той неделе UB в safe исправляли -- так себе гарантии/
| | |
| |
| 7.53, Аноним (53), 21:30, 28/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
C ++ появился в 1983. И базируется он на Си, который появился вообще в 1972. Rust появился в 2010 и сейчас активно развивается. Ничего удивительного что в нем находят огрехи.
Вы лучше ответьте на вопрос, раз С++ так крут, как в нем решена проблема копирования перекрывающихся областей памяти в куче? Я вам сразу скажу - никак. В языке вся работа с памятью на указателях, и у компилятора нет гарантий, что копируемые участки гарантированно не пересекаются. А значит он не может провести часть оптимизаций и предрасчётов во время компиляции, не может векторизовать цикл копирования, и не может распараллелить его. В Rust эта и многие дугие проблемы изначально отсутствуют.
| | |
| |
| 8.71, n00by (ok), 11:00, 29/04/2021 [^] [^^] [^^^] [ответить] | +2 +/– |  Проиллюстрируйте проблему примером кода, что бы было понятно, о чём речь ... текст свёрнут, показать | | |
|
|
| 6.46, Аноним (46), 20:22, 28/04/2021 [^] [^^] [^^^] [ответить]
| –4 +/– |
Единственные гарантии которые может дать rust это боль пониже спины у анонимных экспертов
| | |
|
|
|
|
| 2.33, ranen (?), 17:12, 28/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
 Я уверен, что ни один уважающий себя с-программист не будет использовать этот режим, иначе он испытает такое унижение, что никогда не будет больше программировать!
| | |
| |
| 3.44, Noard (?), 19:46, 28/04/2021 [^] [^^] [^^^] [ответить]
| –3 +/– |
Маловероятно, в этом режиме ничто сложнее студенческих поделок не скомпилируется, си-ппограммисты настолько малоквалифицированны, в настоящее время, что не понимают, что весь объем легаси - это сплошные некорректные трюки (те-же трюки с кучей), а то, что еще может пройти проверку - безбожно тормозящее... и суть появления ржавчины - избавление от трюкачеств в легаси, да, эта проверка этому поможет, но "си-кодеры" не способны осознать, что проще - воспользоваться адекватным инструментом: ржавчиной или плюсами, чем приводить допотопный код на допотопном языке для допотопных контролеров в компилируемое состояние...
| | |
| |
| 4.67, ixrws (??), 09:37, 29/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Очередной ыксперт, сколько же вас развелось то.
Никто бы не стал включать этот режим в gcc, если бы он годился только для просты семплов. Практика показывает, что если код работает корректно на хотя бы 2х различных платформах(а большинство системных С программ работает на хотя бы x86, x86_64, arm и mips), то неведомого трюкачества в коде очень мало и он вполне себе проходит статический анализ. Да, там могут быть косяки, но их крайне мало. А вы, уважаемый ыксперт, просто не знаете насколько много трюков и проблем приходится выпиливать из кода, когда он приколочен к одной ОС и к одной аппаратной платформе. Если же он не приколочен, то и трюков так сильно меньше, потому что та же арифметика указателей без понимания как она работает, хрена с два заработает без багов на разных платформах.
| | |
| 4.79, iZEN (ok), 20:36, 29/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
 > воспользоваться адекватным инструментом: ржавчиной или плюсами, чем приводить допотопный код на допотопном языке для допотопных контролеров в компилируемое состояние...
Так они и ЯП Modula-3, на котором эти проблемы давно решили, не хотят знать. Куда им ржавчину вписывать?
| | |
|
|
| 2.35, Аноним (37), 17:40, 28/04/2021 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Статический анализатор конечно хорошо, но у раста он ещё и с гарантиями
:)
| | |
| 2.110, Аноним (110), 18:30, 12/05/2021 [^] [^^] [^^^] [ответить]
| +/– |
Ценность Rust сильно опустит поддержка GCC опции -D_FORTIFY_SOURCE=3 пока есть только 2.
| | |
|
| 1.5, Аноним (-), 14:30, 28/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
>улучшениями, связанными с будущим стандартом языка Си (C2x), новыми оптимизациями производительности.
Последний стандарт 18 года, полностью поддерживается? На подходе С2x
Чистый Си рулит!
| | |
| |
| |
| |
| |
| 5.45, Аноним (45), 20:01, 28/04/2021 [^] [^^] [^^^] [ответить]
| –4 +/– |
Как насчёт убрать оттуда отвратительную работу со строками из 70-х годов, из-за которых каждая программа на Си кишит дырами и багами?
| | |
| |
| 6.48, Аноним (48), 20:58, 28/04/2021 [^] [^^] [^^^] [ответить]
| –3 +/– |
Да и с макросами что-то делать нужно. Негоже это, когда они чем-то сторонним обрабатываюся. Надо бы, чтобы самим компилятором, чтобы получать адекватные сообщения о проблемах.
| | |
| |
| 7.69, ixrws (??), 09:47, 29/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Макросы это макросы, они в принципе не разрабатывались так, чтобы их нужно было анализировать. Если захочется их анализировать, то возникнет вопрос что это должны быть за макросы, какими возможностями они будут обладать и возможно тогда наворотят такие макросы, что лучше всё же жить с макросами из прошлого века.
Каждое решение имеет свои плюсы и свои минусы. Плюсов у С макросов достаточно, даже самый накаченный макросами код, компилируется очень быстро. Они просты, там просто нет ничего, но при этом выразительны.
| | |
|
| 6.68, ixrws (??), 09:44, 29/04/2021 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Зачем убирать? Что за привычка убирать что-то, из-за чего куча кода поломается. Ну давайте завтра давление в трубах поднимем до 10 атм или опустим до одной. Как там ваши смесители и бачки сливные у унитазов, будут работать? А ведь поднять до 10 и будет стабильнее водоснабжение на высоких этажах. И будете сами себе регуляторы давления ставить, чтобы смеситель не взорвало.
Так вот, куча есть реализаций строк под различные требования. Берите и пользуйтесь. На кой чёрт тащить в стандарт это. Поймите, если вам нужна хорошая реализация строк, с хранением длины и прочего для юникода, то значительному количеству С кода из эмбеда нужны различные компактные реализации строк и они также вправе требовать их в стандарт. Ну и что получится, 20 реализаций и все в стандарт?
| | |
| |
| 7.74, Аноним (-), 15:57, 29/04/2021 [^] [^^] [^^^] [ответить]
| –2 +/– |
переписыай под новые стандарты и не ной, показывая своё рукожопство.
| | |
|
| 6.72, n00by (ok), 11:13, 29/04/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Как насчёт убрать оттуда отвратительную работу со строками из 70-х годов, из-за
> которых каждая программа на Си кишит дырами и багами?
Расскажите в подробностях, кто и как заставляют Вас писать #include <string.h>
Подумаем, что в такой ситуации делать.
| | |
| |
| 7.80, С (?), 22:25, 29/04/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
char abc[3]; strncpy(abc, "abc", 3); Эти функции изначально предназначались не для строк, а для "записей" (record), поэтому не просто копируют строки, но еще и добивают результат нулями до ширины поля. Или не добивают.
| | |
| |
| 8.82, n00by (ok), 06:39, 30/04/2021 [^] [^^] [^^^] [ответить] | +/– | Что не так если не считать отсутствия в языке рекордов Вам не нравится, что... текст свёрнут, показать | | |
| |
| 9.84, С (?), 09:54, 30/04/2021 [^] [^^] [^^^] [ответить] | +/– | Записи не про язык, они больше про файлы В сишке представляются сишными структу... большой текст свёрнут, показать | | |
| |
| 10.85, n00by (ok), 10:57, 30/04/2021 [^] [^^] [^^^] [ответить] | +/– | Тут не экзамен, не надо выдавать почерпнутое из безусловно полезной книжки Вирта... большой текст свёрнут, показать | | |
| |
| 11.87, n00by (ok), 11:58, 30/04/2021 [^] [^^] [^^^] [ответить] | +1 +/– | В общем, вот это и есть проблема Низкоквалифицированные высокомотивированные лю... текст свёрнут, показать | | |
| 11.89, С (?), 14:46, 30/04/2021 [^] [^^] [^^^] [ответить] | +/– | Не читал, осуждаю На заборе тоже сказано Наконец-то Именно об этом мы и го... большой текст свёрнут, показать | | |
| |
| |
| |
| |
| |
| 16.108, n00by (ok), 06:55, 06/05/2021 [^] [^^] [^^^] [ответить] | –1 +/– | Так и не проспался Похоже, я тебя с другим человеком перепутал, получился поклё... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1.9, Аноним (19), 14:54, 28/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
Что-то кроме ворнингов ничего полезного, разве что улучшена поддержка армов. Все прошлые обновления добавляли интересных оптимизаций или хотя бы защит.
| | |
| |
| |
| |
| |
| 5.25, Аноним (19), 16:18, 28/04/2021 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Да.
Исчерпывающий ответ и грамотная аргументированная позиция, аплодирую стоя. Я, в свою очередь, могу пояснить свою позицию: никаких видимых улучшений не добавили. У 10 были осязаемые улучшения PGO и lto (скажем, поддержка zstd), дополнительная заметная логика у ipa. В 9 добавили значительные усовершенствования для PGO и LTO (наверное, самые ощутимые за всё время gcc) В 8 добавили stack-clash-protection и cf-protection. В 7 и 6, ну, подсказки к ошибкам, например. В 5 no-semantic-interposition.
| | |
|
|
|
|
| 1.10, Аноним (10), 14:56, 28/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>для для сборки GCC 11 теперь требуется как минимум GCC 4.8.
Враньё, не собирается.
| | |
| |
| 2.13, Мелкостан (?), 15:04, 28/04/2021 [^] [^^] [^^^] [ответить]
| –10 +/– |
минимум GCC 4.8 <- судьба жадных компании которые знали у кого была лучшая вариация
| | |
| |
| 3.17, Аначик (?), 15:51, 28/04/2021 [^] [^^] [^^^] [ответить]
| +9 +/– | |
>судьба жадных компании которые знали у кого была лучшая вариация
Мой мозг не уловил в этом сообщении логический смысл.
| | |
|
|
| |
| 2.41, Jh (?), 18:22, 28/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
в принципе, сам себя откомпилировал.
10 версия у меня пару пакетов собрать не могла. Посмотрим что с 11
| | |
|
| 1.60, Аноним (60), 01:45, 29/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 Обожаю читать комментарии к таким новостям. Радостно, что столько профессионалов тут. Вот бы собрать всех в одной команде, это же дрим тим.
| | |
| 1.65, xcode (?), 08:51, 29/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 А кто нибудь в курсе, почему в gcc не реализовано расширение "свойства", которое есть в msvc и clang?
вот это?
__declspec( property( get=get_func_name, put=put_func_name ) )
штука весьма полезная и не перекрывается существующими возможностями (в частности перегрузкой операторов и т.п.)
| | |
| |
| 2.102, Омномномним (?), 20:11, 03/05/2021 [^] [^^] [^^^] [ответить]
| +/– |
Не особо понятно, зачем вообще нужны "свойства", если они тривиальные. В C# эта фигня изрядно бесила, обычные мутаторы-инспекторы из С++ очевиднее и нагляднее. Имхо, properties - бесполезный сахар.
| | |
| |
| 3.103, xcode (?), 00:18, 04/05/2021 [^] [^^] [^^^] [ответить]
| +/– |
Тривиальные и не нужны. А вот зачем нужны: есть огромный проект. Нужно его изучить. Если некоторое поле некоторой структуры/класса сделать свойством, и например в геттер и сеттер ставить точки останова, или вывод логов, то можно понять где и как это поле используется. Заодно компилятор отловит все места где есть попытки получить адрес этого поля. Т.е. помимо синтаксического сахара, еще и рефакторинг/отладка/анализ кода.
| | |
|
|
| 1.70, Ананоним (?), 10:46, 29/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Самое главное что нужно знать:
> Компилятор теперь должен поддерживать стандарт C++11 (ранее требовался C++98), т.е. если для сборки GCC 10 достаточно было наличия GCC 3.4, то для сборки GCC 11 теперь требуется как минимум GCC 4.8.
Поясняю - разработчики сами пишут на старом стандарте языка, и всё у них прекрасно получается. Но вам навязывают новые стандарты. Ну что бы жиСь скучной не казалась.
| | |
| |
| 2.76, Аноним (76), 17:09, 29/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
При этом браузер месячной давности уже протухает и не открывает свежайшие сайты.
| | |
| |
| 3.83, вебмакака (?), 07:00, 30/04/2021 [^] [^^] [^^^] [ответить]
| +/– | |
Ну так браузер мы как нада пишем - не только на наираспоследних версиях компилятора, но еще и придумали отдельный нескучный язычок, который вообще каждый день новый.
| | |
|
| 2.88, anonymous (??), 12:48, 30/04/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
Капец, прочитал предложение, перевернул смысл с ног на голову.
Пиши хоть на C++98, тебе как пользователю компилятора никто не запрещает. Сам компилятор теперь для своей сборки требует C++11, а не для кода, который ты быдлокодишь.
| | |
|
| 1.94, Алкоганон (?), 05:50, 02/05/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Добавлена экспериментальная поддержка типов для параллельной обработки данных (SIMD, Data-Parallel Types).
Ну вот совершенно эталонное деръмо.
Все эти SIMD очевино зависят от процессора, платформы и т. д. То есть фактически имеют уровень Ассемблера. Нет конечно ничего плохого в том чтобы компилятор производил оптимизацию с использованием этих инструкций (SIMD и тп) и даже очень приветствовалось бы, но вынос этого на уровень языка и соответственно забот программиста фактически вынуждает писать код уровня Ассемблера. Программиста вынуждает. Вместо компилятора. Опять же нет ничего особенно плохого в Ассемблере и его применении, но... Ассемблер и так доступен тем кому необходим. Здесь же разработчики компилятора по-видимому вынуждают программистов на C писать код фактически на Ассемблере, видимо потому что компилятор у них не способен, но этот фактически ассемблерный код ещё и предлагается оформлять не свойственным Ассемблеру образом. Очевидные проблемы скажем при переходе на другую платформу в итоге очевидно переходят в код на C (без всяких особых преимуществ взамен).
| | |
| 1.95, Алкоганон (?), 06:02, 02/05/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Номера столбцов в диагностических сообщениях теперь отражают не счётчик байт от начала строки
Ещё немного деръмеца в подливку...
| | |
| |
| 2.101, Омномномним (?), 20:00, 03/05/2021 [^] [^^] [^^^] [ответить]
| +/– |
Шо, нравится байтики считать? Ну это пока в диагностический выхлоп Юникод не попадает, в особенности UTF-8, с его кодированием переменной длины.
| | |
|
|
