Комментарии 55
Семантика языка C++ перешла под управление чиновников Белого дома :) Ну-ну.
Нет, но на чём писать софт на деньги налогоплатильщиков они решить могут.
В том, что чиновники решают, на чём заказывать софт, нет ничего странного. А вот то, что их мнением руководствуется комитет по стандартизации, довольно необычно.
Странность в том, что бизнес не смог продавить требования к безопасности софта. Пришлось обращаться за помощью к политикам.
В комитет входят представители компаний, работающих в том числе по заказам правительства. Или продающие что-то правительству. Или продающие что-то тем, кто занимается решениями для правительства. Или пишущие софт, который попадает под какие-то требования регуляторов правительства, например для телефонов или автомобилей. Было бы крайне необычно, если бы они решили проигнорировать требования, которые могут сделать язык неприменимым для их бизнеса.
Все это можно сделать и без принятия нового стандарта С++ с помощью пользовательских атрибутов и плагина для компилятора
Чиновники не знают.
«Я нахожу удивительным, что авторы этих государственных документов, похоже, не знают о сильных сторонах современного C++ и усилиях по обеспечению сильных гарантий безопасности. С другой стороны, они понимают, что язык программирования — это лишь одна часть набора инструментов, поэтому важно улучшать инструменты и процессы разработки».
Проблема в том, что Страуструп не то что не знает, а просто не понимает проблему. А проблема не в том, насколько просто писать безбажный код (хинт: сложно, что бы там Страуструп ни говорил). Проблема в том, что писать бажный, падающий, дырявый код просто.
Страуструп — в первую очередь учитель, поэтому задачи и проблемы, которые он видит — это чтобы «ученикам» можно было легко и просто показывать примеры простого, безбажного кода (и поэтому его характерная реакция сводится к «правильно показывайте пишите, неправильно не показывайте пишите»). Добавили там какой-нибудь std::span — всё, его проблема решена, потому что в учебных примерах можно им пользоваться (а плохим не пользоваться). То, что в продакшен-коде есть легаси, которое этим не пользуется, есть люди с разным бекграундом, с разным состоянием выспанности, в конце концов — это всё неважно. Страуструп смотрит на наличие способов не выстрелить себе в ногу, а не на отсутствие способов выстрелить.
Все эти сильные стороны неважны и не исправляют ситуацию, покуда есть слабые.
поэтому важно улучшать инструменты и процессы разработки
Самый лучший вариант в моём опыте — улучшить инструмент разработки через смену ЯП.
Прикольно будет если один из ведущих мэйнтенеров раста окажется человек с ультра левой позицией и склонностью к актавным действиям.
Тогда чиновники переобуются обратно или как всегда, все решения обдуманы на годы вперёд.
П.С. Это просто пример вероятности, да минимальной, но вероятности.
Чиновник не способен мыслить априори.
А точно страус того? Вроде как страустрап. Ну или straustrup.
идею перехода на языки, безопасного работающие с памятью
Статейку бы подредактировать
Да неужто наконец проснулись?))
Неужто начнут удобства в язык завозить каждый год?
Неужто будут оглядываться на успехи конкурентов?
Я конечно верю в сказки, но не до такой степени)
ну судя по набору: java, python, rust - то один новомодный и не особо лучше, так как все равно а) есть unsafe в языке (но зачем, если все можно сделать хорошо - видимо нельзя) а оставшиеся 2 прекрасно из байткода парсятся обратно в код, а вроде как с плюсами это сильно дороже делать
Ну судя по набору мерседес, бнв, ауди, жигули-то не сильно хуже. Те же 4 колеса, да и руль на месте)
С каждым подобным комментом все лучше понимаю, почему комитет так противится, - там мышление примерно такое же. Я вот давече организовал форматирование с плейсхолдерами в стиле php или шарпа (это шире, чем fmt и std format), всрав на это кучу времени и не получив нормальной проверки на этапе компиляции. Будь я чутка помоложе, я бы прям радовался, какой я молодец. Но теперь меня это бесит. Я потратил кучу времени из-за снобизма комитета, который 10-20 лет просто не может завезти простую фичу.
Печально видеть как некогда передовой язык просто тонет в этих дедовских загонах, что и так все хорошо. Нет, не хорошо. Если развитие не ускорится, нормального будущего у языка не будет
За годы совершенствования в С++ навводили столько новых конструкций и парадигм, что теперь приходится заводить новое понятие - профили - чтобы запретить использование введённых ранее вещей.
А язык-то понятнее не становится. Если раньше человеку, не работавшему с С++, но знающему другие языки, можно было глянуть какой-то код и более-менее разобраться, то теперь без помощи друга/LLM не поймёшь. И это не только С++ касается, а всех языков, которые активно "допиливают" годами. А захочет ли молодое поколение лезть в эту "стариковскую" писанину? Может, поэтому и появляются новые языки типа Rust, написанные с нуля.
А в код rust вы пробовали смотреть?
я на rust год уже пишу, очень двоякое впечатление. С одной стороны это лучший язык (pattern matching, borrowing, stdlib, enum'ы, макросы, generics и т.п.), с другой один из худших (инопланетный синтаксис, 50 unsafe в каждом файле в любой серьезной либе/framework'е, сложные примитивы для работы с памятью, время компиляции) в одно и тоже время.
Было бы круто увидеть новый язык похожий на rust, с упрощенным синтаксисом, но с той же основной идеей и крутой std либой. (типа rust2, который никто не собирается писать в ближайшие 20 лет)
Было бы круто увидеть какую-то рабочую группу из выходцев c++, которые сделают новый язык для конкуренции с rust, но без уже хорошо известных граблей rust'а.
Zig. Правда он еще не production-ready, нет готовой многопоточности, инфраструктура меньше чем у rust.
А pattern matching, алгебраические типы данных(ака енумы в rust), дженерики, option и result, функции высшего порядка, все это было и до rust в f#, ocaml и других языках. Кроме borrow checker ничего нового в нем нет. Это и плюс, и минус. Плюс потому что предотвращает класс ошибок. Минус потому что это влияет сильно на время сборки.
И инфраструктура не такая стабильная и богатая, как например на .net или java.
я думаю, основная проблема связанная со временем сборки, это не borrow checker. А минимальная единица кода, которая в rust является crate'ом.
В go например минимальная единица кода это package, в котором обычно пара файликов. А в rust в crate пихают от увесистой либы (~100 файлов) до целого приложения.
Поэтому компилятор почти не может положиться на кеширование уже скомпилированных крейтов, что вынуждает либо страдать, либо искусственно делать микроскопические крейты и как-то менеджить общие зависимости в workspace (aka всё равно страдать).
lifetime — запрещены ссылки на освобождённые или неиспользуемые области памяти, разыменование указателей, явный вызов new/delete.
Интересует как это по факту будет работать, ведь в языке нет информации о времени жизни. Будут вычислять по косвенным данным?
Интересует как это по факту будет работать, ведь в языке нет информации о времени жизни. Будут вычислять по косвенным данным?
У компилятор есть информация о времени жизни переменных https://en.cppreference.com/w/c/language/lifetime
Ну это очень ограниченные времена жизни. Как это должно работать с замыканиями, или в указателями, сохраненными вместе с каллбеком?
Но даже с более простыми случаями могут возникнуть проблемы. Код ниже конечно странно написан, но, например, в любом lock-free алгоритме примерно весь код такой (ради быстродействия):
bool f(int* a, bool b) {
bool b = ...; // что-то делаем с a
if (b) free(a);
}
int* a = malloc(sizeof(int))
bool b = f(a);
if (!b) {
...
free(a);
}
Не представляю, что тут сможет сделать компилятор с профилем lifetime, кроме как запретить такой код полностью.
Так потому что у вас код примера на С, а речь идет о С++ с классами - обертками вокруг голых указателей https://en.cppreference.com/w/cpp/language/raii, а для профилей используются атрибуты.
Вы скинули ссылку на времена жизни в С, по-этому я ответил про С.
Ну хорошо, перепишите мой пример на new/delete и ничего не поменяется. Как кстати и вопрос про замыкания: это невозможно на текущем этапе развития компиляторов.
а для профилей используются атрибуты.
Означает ли это, что время жизни будет задаваться явно через атрибут?
Я искал на cppreference.com, но не обратил внимание, что пример на С. Тогда вот правильная https://en.cppreference.com/w/cpp/language/lifetime и там не должно быть никаких new/delete
Там вся статья состоит из примеров как близко к ноге может пролететь пуля.
Как я и говорил, у компилятора не достаточно данных для оценки времени жизни, ваша ссылка это только подтверждает) Прочитайте например раздел Access outside of lifetime.
Вообще весь документ описывает как нельзя делать и в каких случаях будет UB. Что прозрачно намекает что компилятор не может оценить времена жизни (за исключением когда явно срабатывает RAII), и перекладывает на программиста ответственность за времена жизни.
Теперь вопрос что же придумал Страуструп? Правильно ли я понимаю, что он предлагает явно определять времена жизни через атрибуты?
маллоки в С++ рекомендуется не использовать, простите
Все это было придумано, пока повесточка была актуальна еще, до Трампа (раст повесточный, си слишком свободные и написаны нерукопожатными старыми белыми мужчинами). Сейчас маятник назад качнётся, вот увидите.
Когда espressof допилят rust версию esp-idf то перейду с си на раст, но боже упаси юзать плюсы, я их в прямом смысле боюсь
Можно сразу на Haskell перейти! ;)
Он мне не нравится)
Как минимум синтаксисом и наличием GC
GC сам по себе не зло, трудно даже сказать, что лучше работает - ручное или автоматическое управление памятью. Зависит от ситуации.
На микроконтроллерах gc всё же зло, примеру lvgl (gui библиотека) на МК может потреблять до 100% ресурсов процессора, тут для gc места нету
С другой стороны mjs и micro Python вполне себе работают на МК
На хаскеле можно (и очень приятно) делать DSL'и в том числе для глубокого эмбеддеда: например, ivory.
Тема интересная, я об этом не знал и вообще думал что хаскель почти мертв, но видимо не дорос я ещё до этого, мало свободного времени, и си простой как пробка а раст мне просто нравиться)
Но так как программирование это просто хобби то вполне вероятно что наступит момент когда я из интереса попробую хаскель, люблю экзотику)
Кроме ivory, есть еще copilot. Первый DSL разработан для NASA, второй для DARPA. На первом сделали квадрик с автопилотом, на втором Боинг сделал беспилотный в качестве демо. Для copilot есть даж биндинги для ардуинок. Мы пишем прошивки своих девайсов на ivory.
В Касперском, например, для ядра своей ОС тоже использовали ivory, а потом перешли на свой DSL
a gcc используется в Расте не знаете? на каком этапе если используется? вопрос из разряда просто интересно, что называется безопасным возможность процессора к преобразованию или верхне уровневая семантика?, может быть так что какая-то операция в Расте использует преобразование, через llvm? которая невозможна например на gcc, есть стандарты на это?
del
В 2017 видел стикер-пак с мемами про переписать всё на Rust. С выглядывающим сверху 18-летним парнем и прочее. Прошло 8 лет, мем больше не мем.
В чем проблема? Надо просто выпилять из С++ весь хлам...
Вопрос про умные указатели. Я пытался их использовать, но наткнулся на проблему. Неужели умные указатели настолько глупы, что не подходят для multithreading приложений?
Всё правильно по полочкам разложили!
Но если писать без ошибок, то можно и raw указатели использовать, умные-то придумали лишь чтобы избежать человеческих ошибок при работе с raw указателями. А тут получается есть кейс, где умные указатели не подходят, я был раздосадован, что не смог просто везде использовать только умные указатели, навсегда отказаться от raw указателей... Где же тут искомая безопасная работа с памятью?
Пора закопать стюардессу
А причём тут c++ вообще. Эти проблемы с плейн C раст_ут, его надо править, поскольку ядро линукса быстрее на Rust перепишут, чем на C++
Главная проблема не в том, что на C++ можно или нельзя писать "безопасный код", а в том что язык стал слишком сложным и требует большей квалификации программиста. А так, я всеми руками за C++ и за ассемблер. Но крупным компаниям нужно снижать издержки и им нужны языки на которых может более или менее писать средний индус и чтобы при этом в коде был минимум уязвимостей, при этом скорость выполнения кода уже давно ушла даже не на второй план, а на третий или четвертый. Все тупо заливают железом. Вот в чем проблема. С/С++ даёт кучу возможностей, но за них нужно платить больше чем за условный Python. Тут решает рынок, а он не всегда выбирает то что лучше, он выбирает то что дешевле, или хотя бы лучше по соотношению цена/качество (но последнее не точно).
Страуструп призвал комитет WG21 заняться актуальностью C++ из-за продвижения языков для безопасной работы с памятью