Популярное использование распределения динамической памяти

Question

Я читал стандарты кодирования на C, и большинство из них препятствует использованию динамического выделения памяти. Но в популярном использовании динамическое распределение памяти приводит. Есть веская причина для этого. Я задаю причины для его несмотря на недостатки, которые он имеет? Это мои ссылки JPL Стандарты: http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf сила 10: http://spinroot.com/gerard/pdf/P10.pdf

Answer 1

Динамическое распределение памяти обычно запрещается при программировании встроенных систем, особенно в защищенном от вредоносного программного обеспечения. Все отраслевые стандарты для критически важных для безопасности программ запрещают его: MISRA-C, DO178B, IEC 61508, ISO 26262 и т. Д.

Существует много известных проблем с динамическим распределением памяти: медленное и, возможно, индетерминированное время доступа, memory leaks и heap fragmentation.

Ни одна из этих проблем не требуется в любой программе. Но в программировании на ПК/настольном компьютере они считаются необходимым злом, главным образом потому, что основные оперативные системы ограничивают объем памяти статического процесса, заданный каждому процессу, и если вы хотите хранить данные, выходящие за рамки этого, вы должны сохранить его на куча.

Также удобно использовать динамическую память, когда количество данных неизвестно до времени выполнения. Тем не менее, в известном мире с неограниченной памятью нет компьютера, поэтому «я хочу использовать полностью переменную сумму данных, я не знаю, сколько» является своего рода бессмысленным аргументом. Правильный инженер-программист всегда разрабатывает сценарий наихудшего случая.

В частности, во встроенных системах, где объем оперативной памяти ограничен, а последствия ошибок намного хуже, чем всплывающее окно с памятью из памяти, ваша программа должна иметь 100% детерминированное поведение. Вы не можете проектировать такие вещи, как «эта программа будет работать до тех пор, пока она не закончится из ОЗУ, а затем она сработает и сгорит». Вы не можете допустить, чтобы в вашей железнодорожной контрольной системе существовало переменное число «х», вы должны указать верхний предел и разработать систему после этого.

Поэтому независимо от того все проблемы, связанные с динамической памятью упоминалось выше, вы не хотите использовать динамическую память в такого рода системах, просто потому, что это не имеет никакого смысла.

Рекурсия также запрещена этими системами, по тем же причинам.

Answer 2

Динамического распределение памяти в C сидит на смазанные линиях между абстрактной математикой и реальным миром техникой. Математически вы говорите: «Поместите эти данные в некоторую память», и действительно malloc() просто дает вам «некоторую память», в основном притворяясь, что существует неограниченный объем памяти. (И на многих системах реального мира malloc() действительно никогда не выходит из-за переполнения.)

Реальная инженерия должна столкнуться с ограниченностью всех ресурсов, и если вы приблизитесь к проблеме, зная, что у вас есть X имеется доступная память, затем вам необходимо запланировать, куда идет память. Это более громоздко и сложно, но это также может привести к улучшению кода и повышению производительности, если только по той причине, что это заставляет вас внимательно подумать о потоке данных вашей программы.

В отличие от обычных настольных компьютеров, на которых malloc() никогда не сработает, на противоположном конце спектра встроены встроенные машины, у которых нет сложных менеджеров памяти и на которых malloc() по существу «всегда терпит неудачу». Если вы можете программировать без него, то вы можете программировать для таких платформ. С другой стороны, если ваш стиль программирования всегда предполагает неограниченную доступность магической памяти, то вы очень легко найдете программирование на таких платформах.