Comments 15
Вы про https://safecpp.org/draft.html ?
Нет, это не С++. Но данный проект очень хорошо демонстрирует описанную в статье проблему со старым легаси кодом, когда начинают дорабатывать синтаксис языка, и тем самым нарушают обратную совместимость.
В RFC пишут об обратном: "The proposed Safe C++ should be a pure subset of ISO C++ except few ignorable pragma and attributes. So that other compilers which don’t support the extension can compile the codes accepted by Safe C++."
https://discourse.llvm.org/t/rfc-a-clangir-based-safe-c/83245
Я правда тоже пока не gонял как они собираются делать совместимость в сложных примерах а не приведенных демках. Но вроде как это объявлено целью.
тут смотря что еще понимать под легаси если легаси С то есть моменты (например операторы дальше я пока сам наглядно не сталкивался)
Скрытый текст
vec2 t(vec2 x)
{
return x-1*2+100;//не заработает в С
}тут как бы напрашивается момент где начинается граница ошибок
если стандарты языка С++, то вроде просто надо выбрать стандарт и в него компилировать (но я когда писал компилировал старый код в 23 стандарт и пользовался не всеми преимуществами стандарта - писал на шаблонах + наследование, ну стандартный С++ как мне кажется, с доступными штуками - там вроде всё тривиально, а вот по статье по ссылке где пишут что С++ не безопасен я смотрел ее и никогда не думал так писать - двоякое ощущение), мне лично показалось когда видел ту статью что так можно где угодно ошибки найти
насчет плагинов - ведь кланг в его документации даёт понять что разработчик может добавлять свои плагины, и есть свободно распространяемые плагины который вы привели в пример
Windows.h линкуется собирается с 23 стандартом и вы даже brush сможете вызвать и воспользоваться и другими вызовами, где легаси, где опасность, в чем там проблемы я пока не понял
можно сравнить с ценой вызова на Сшарп и Ява (мне думается надо признать что есть разные языки с разными парадигмами, а так можно бесконечно обижаться на разные подходы)
Предложенный подход в пределе означает реализовать borrow checker для C++ (имеется в виду анализатор схожей мощности). Вряд ли много компаний-пользователей компилятора способны написать такое сложное расширение (это мягко говоря). Если оно будет написано, скорее всего, удобнее будет интегрировать эти наработки в апстрим, чтобы упростить поддержку.
а какой конкретный пример есть на этот счет? может сервер - web не сможет работать с обращениями и будет что сбой? или что произойдёт, что конкретно в race condition плохого у С++?
может легаси не соберётся в чем там проблема можно пример?
у меня есть пример возможно плохой
thread = SDL_CreateThread(TestThread, "TestThread", (void *)NULL);
SDL_WaitThread(thread, &threadReturnValue);я запускал 2-3 окна игроки рендерились
это код дедикейтед сервера
Всё упирается в то что все постоянно пытаются выстроить жесткую систему. А жесткие системы они всегда хрупкие. И чем жестче вы будете контроль тем "веселее" и масштабнее будут разрушения. А если еще учесть что язык позволяет использовать противоречащую здравому смыслу логику для оптимизаций, то язык может и будет безопасным, но всегда будет способен неприятно удивить.
не уверен насчет совместимости, но некоторые предложения от Саттера уже были
https://isocpp.org/files/papers/P3081R0.pdf
Возможна ли безопасная разработка на С++?
Язык позволяет записать любые данные по любому адресу, это база. Запретите это, и это будет уже не C++. А вы "ошибки", "ошибки"...
Не совсем понял, что вы имеете в виду под "необходимость синхронно поддерживать и использовать одни и те же режимы компиляции исходных текстов программ" в той части, где пишете про использование статического анализа?
Google, например, не смотря на стратегию перехода на Memory safe языки (e.g. Rust) в новых проектах продолжает развивать сторонние инструменты, делающие разработку на C++ более безопасной.
У С и С++ исторически сложились сложные отношения с препроцессором. В зависимости от параметров его работы исходный код компилируемой программы может быть трансформирован самым неожиданным образом. И самое плохое, что подобные трансформации кода могут зависеть от встроенных в компилятор препроцессорных определений, версий языка или даже названия самого компилятора.
Поэтому в случае использования любых сторонних инструментов для анализа С++ кода, нужно будет не только в точности передать все опции компиляции, но и имитировать все малейшие нюансы работы препроцессора у используемого компилятора, чтобы сторонний инструмент анализировал в точности тот же самый код программы, который в результате компилируется.
Конечно, в большинстве случаев не должно быть никакого криминала. Особенно если этот самый сторонний инструмент будет анализировать еще и препроцессорные определения на случай различных нюансов либо обрабатывать исходный текст программы уже после обработки препроцессором. Но это лишние заморочки, которые можно легко обойти, просто реализовав дополнительный анализатор в виде плагина компилятора.
Безопасная разработка на С++ без нарушения обратной совместимости с легаси кодом