fk0, легенда (30.10.2019 01:09, просмотров: 620) ответил Evgeny_CD на [ГОСТ Р МЭК 61508-7-2012] -> --> Интересные вещи там написаны...Раздел С.2.6.6 Ограниченное использование указателей
A ссылка -- это же не указатель? А вообще как всегда решаются проблемы прошлого века. Ну будет арифметика на индексах, что-то принципиально поменяется, если в языке нет проверки границ? A даже если бы и были -- не поможет, т.к. программа под windows может упасть, а ракете падать уже некуда. Ошибки должны исключаться в compile time, путём введения более высокого класса абстракций, и самое главное -- возможностью построения своих абстракций, в частности определения типов данных и операций над ними. Поэтому в C++ есть смысл и большой, а в программировании на C без указателей -- никакого. Потом же речь не об отказе от указателей (без которых вообще ничего не сделать будет), а в ограничении арифметики над указателями. Но избавиться от неё вообще -- не получится же. Логика у программы одна, и как её не выкручивай, там уже есть эта арифметика, если нужна. Вопрос только в том, как её облечь в менее взрывоопасную форму.
"Одна точка выхода из функции" превращает сложную функцию в набор if'ов не умещающийся в ширину экрана с 20-ю уровнями вложенности (а разбить функцию не всегда можно из-за ограничений по области видимости). И наделать ошибок в мешанине из if'ов можно запросто. IMHO -- дурная практика. В C++ для того есть деструкторы (гарантированное выполнение действий на выходе из функции). Или можно функцию завернуть в другую, которая и будет как раз выполнять действия на выходе из первой.
"Неиспользование автоматического преобразования типов" -- это ставит крест на любом метапрограммировании на шаблонах. И совершенно не факт, что программы написанные на C в стиле ассемблера руками чем-то лучше. Скорей наоборот, C++-код обычно содержит меньше ошибок, на которых можно закопаться в C или ассемблере.
"Отказ от динамического выделения памяти" -- достаточно бредовая рекомендация, по двум причинам:
1) во-первых средств отладки позволяющих обнаруживать нарушения при работе со статически выделенной памятью куда меньше и они куда менее совершенны, чем средства отладки динамической памяти;
2) во-вторых динамическая память используется именно потому, что не хватает памяти, чтоб статически аллоцировать всё и сразу. Это примерно как перестать ездить на метро и всем выдать по личному лимузину. Место на дорогах кончится. И конечно, программисту запретили malloc -- чем кончится? Тайным знанием, что в одном состоянии программы в A[13] хранится какая-то важная переменная, а в другом весь массив A[] используется под какой-то буфер. Это что ли лучше? С чем боролись...
В качестве полумер можно использовать динамическую память, но выделять её строго на старте приложения. По крайней мере это упростит отладку (на ПК разумеется).
И при использовании динамической памяти нужно представлять жизненный цикл выделенных блоков (что, например, рано или поздно вся выделенная в очередном цикле работы память освобождается), иметь сценарий на случай невозможности выделения (например, откат и повтор ситуации в другом цикле работы). И наконец нужен качественный аллокатор (хотя бы уровня Doug Lea).
[ZX]