Comments 14
Тупо прибить ограничения к такому языку как С++ ради безопасности - это деградация и тупик развития. Для этого есть другие языки, которые этим козыряют. Для Си нужны профили, типа профиль лютой безопасности, где вообще ничего нельзя опасного написать. Потому что в других модных языках как только нужно сделать опасно, начинается удаление гланд через задний проход. Зачем эта потеря времени для плюсовиков?!
При этом профили и не должны ничего менять в языке, а только ограничивать применение небезопасных подходов. Новый стандарт нужен не для языка, а для стандартизации профилей, типа "собрано с профилем safetyPro+". Обратная совместимость прозрачная. Профиль прикручивается в среде разработки и компилятору и всё.
Для этого есть другие языки, которые этим козыряют.
Ну и пусть козыряют.
Для Си нужны профили, типа профиль лютой безопасности ...
Профили, как в p3038 требуют разработки и принятия нового стандарта С++, тогда как аналогичное по функциональности решение можно сделать уже на C++20.
профили и не должны ничего менять в языке, а только ограничивать применение небезопасных подходов
Профили - это совсем упрощенно. Гораздо лучше была бы возможность определения правил - что экземпляры класса не могут создаваться статически, или должны создаваться только динамически, или не могут создаваться/использоваться в коде, помеченном, как "критический", или не могут использоваться в коде, который может ожидать события, и так далее.
Вот согласен с прошлым коментарием.
дело в том, что часто НАДО писать код, который "небезопасен". Это и работа с железом, и низкоуровневые оптимизации, и работа с другими компонентами системы, которые не предоставляют "безопасного" интерфейса.
И тут плюсы становятся самым удобным языком. Опытеому кодеру известны многие подводные камни, написано огромное количество стат. анализаторов и профайлеров, чудесно (ощутимо лучше чем в других языках) работает отладка. И при этом язык не мешает выполнять грязную работу.
Так данный подход как раз и позволяет это делать. Когда нужно, включает жесткую проверку, а когда требуется её отключить - игнорирует.
И главный плюс подобного похода, полная обратная совместимость с существующим кодом и не требуется принимать новых стандартов языка (или переписывать всё на новом козырном языке). Но об этом я уже писал в самой статье.
у вас предпологается еще включение [] в код и на большом проекте где очень много файлов и строк будет проблематично включать в компиляцию ваш плагин, тоесть это не построение лексического анализа и проверки виртуальных адресов(может и есть построение лексического дерева и проверка каких-то адресов, просто у вас написано не для промышленных масштабов), о чем и говорит ваше предупреждение, плюс ограничение версия clang с каким-то пулом, учитваются ли особенности кланга, или просто наивно происходит проверка как-то?
например std::vector<float>(5,0); clang++(17)/g++(13) по разному чтото делают
Плагин нужен не для компиляции всего проекта, а для проверки корректности использования классов из заголовочной библиотеки. Поэтому его нужно применять только для нового кода. Причем новый код можно компилировать и без плагина, тогда его классы не будут отличаться от обычных shared_ptr и weak_ptr.
Ограничения на версию кланг связаны с наличием фич в самом компиляторе (нельзя приметь пользовательские атрибуты к выражениям). Исправления этих ограничений уже в майнстриме и будет включено в новую версию компилятора, а я просто не хотел брать dev версию clang.
например std::vector(5,0); clang++(17)/g++(13) по разному чтото делают
Особенности версии STL вообще не учитываются при анализе синтаксиса
я не совсем про уровня, но на С++ есть же возможность если надо про уровню написать счетчик байт на вектор допустим, пользоваться unique_ptr, и использовать итераторы, поэтому владения и заимствования интересно конечно, но ведь есть вектор и итератор, есть move и есть memcpy, где скрыта опасность не пойму. а адрес в функцию с перезаписью в адрес это ошибка? допустим void test(int &a){ a=1+2;}, одно из последних вот тоже интересно - есть менеджер ресурсор в нем указатели я сделал создание указателей в менеджере а в игре копирую указатели, это опасно? другой вопрос тоже не менее интересен, не будет ли подход безопасности пересекаться с возможно какими-то доступами потоковыми и прочее?
будет ли код плагина подключенного в бинарнике? просто чтоб такой плагин использовать это же надо добавить этот код в код как я понял
Вообще не понял комментария. Набор знакомых слов, но общий смысл не понял. Можете сформулировать вопросы как-то по другому?
На всякий случай скажу, что в данной статье речь идет не о "доказательной безопасности", а о способе проверки лексики С++ на предмет совпадения шаблонных лексических конструкций как способ демонстрации работоспособности подобного подхода. Но это вовсе не гарантирует безопасную разработку на С++ и корректную работу с указателями, т.к. это только пример.
я всегда открыт к вопросам, прошу задавайте вопросы что не поняли всё обьясню
я себе представляю владение - unique_ptr заимствование iterator, lifetime обусловлен инстансом, получается всё сводится к счету байт если это необходимо например для операций с вектором, отсюда много вопросов, другой вопрос что если в самой конструкции языка есть механизм какойнибудь его будет уже же ведь так не проверить вроде
С другой стороны, вот если unique_ptr, то причём тут счётчик байт, и можно вообще не использовать при работе с вектор, и получается вопросов нет? а если будут, то и проверить можно, тем более что некоторые конструкции языка это запретят, в том числе и заимствование iterator в lifetime. Согласны же?
потомучто в базовых конструкциях может происходить нетривиальное выделение памяти и если в базовой конструкции кидать юникптр то могут быть неожиданности, потом от базовых конструкций могут быть наследования, и уже гдето высоко-высоко, вы такую нить кидаете на Юникптр (далеко ходить не надо 5 классов функционала могут иметь базовые конструкции, и 1 общий где вы ими пользуетесь - например текстурка, юниформы, буффер, шейдер, семплер, трансформация, 2д интерфейс, какойнить ген примитивов, в директиксах еффекты но они вроде могут быть на лету использованы), хотя может тут тоже можно использовать юникптр, просто возможно может будет нужна дозапись/перезапись, шейдеры могут быть причем в таблице с O1 допступом, зачем всё кидать на юникптр, там основные моменты можно кинуть чтобы с верху по 1 команде при выходе или try catch очищать, вектор имеет нюансы всё таки там если надо получше выделять надо считать всётаки, это прочувствовать сегодня можно только на текстовом редакторе (второй тейк по счетчику ) потомучто в стандартном С у нас доступен к примеру односвязный список(если считать односвязный список и не считать вектор то рендер текста в 2д без OpenGL, будет не хороший, программа не будет работать еффективно) а если считать как и с односвязным списком более менее, какой резерв у строки например и у вектора, вот например юзать вектор строк самый первое о чем можно подумать, или строка или вектор чаров, тоесть если подумать с виду что всё тривиально и попасть на вектор строк и не считать можно удивиться
если плыть по течению со счетом на С далее до вокселей тоже ефективно будет, на С++ без счета с чанками тоже еффективно будет потомучто каждый раз будет выделяться точечно фиксировано 1 кусок памяти, где в редакторе текста изза синхро ввода данных, данные поступают не 1 куском
пара примеров
https://www.mbsoftworks.sk/tutorials/opengl4/016-heightmap-pt1-random-terrain/
и моя реализация где я столкнулся с нетривиальностью С++
https://github.com/richKirl/TestDSAWorld/blob/main/Heightmap1/Heightmap1.c
Безопасная работа с памятью на С++ без нарушения обратной совместимости. Библиотека MemSafe и плагин для компилятора