ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Пятница
29 марта
955817 Топик полностью
Связанные сообщения
Functional Safety
Каждый раз когда говорится о "выбросах", "помехах" и "оптронах" начинаю понимать, что говорящие не понимают как оно работает. П...2019-12-15
Спасибо, вообще в документе многие пункты достаточно разумны, я особо подчерку для некоторых здешних читателей:2019-10-30
[ГОСТ Р МЭК 61508-7-2012] -> --> Интересные вещи там написаны...Раздел С.2.6.6 Ограниченное использование указат...2019-10-29
Отказ от динамической памяти -- сомнительное занятие, подходящее лишь для маленьких программок: в системе физической памяти обыч...2014-01-03
Я вот вижу интересную ссылку, но процитирую здесь полностью, т.к. информацию приходится достатвать уже из archive.org и кешей гу...2013-11-25
fk0, легенда (30.10.2019 01:09, просмотров: 576) ответил 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]