Это в основном зависит от вашего компилятора и объема вашей памяти. Если у вас есть несколько килобайт оперативной памяти, динамическое распределение памяти очень помогает. Если реализация malloc из имеющейся у вас стандартной библиотеки не настроена на ваш объем памяти, вы можете написать свой собственный, или есть хорошие примеры, такие как mm_malloc от Ralph Hempel , которые вы можете использовать для написания своего новые и удаляемые операторы сверху.
Я не согласен с теми, которые повторяют мем о том, что исключения и контейнеры stl слишком медленные, или слишком раздутые и т. Д. Конечно, он добавляет немного больше кода, чем просто malloc простого C, но разумное использование исключений может сделать код очень ясно и избегайте слишком много ошибок проверки ошибок в C.
Следует иметь в виду, что распределители STL будут увеличивать свои распределения в степени двух, что означает, что иногда он будет выполнять некоторые перераспределения, пока не достигнет правильного размера, который вы можете предотвратить с помощью Reserve , так что становится дешевле, чем один маллок нужного размера, если вы все равно знаете размер для выделения.
Если у вас есть большой буфер в векторе, например, в какой-то момент он может перераспределиться и закончится использованием в 1,5 раза большего объема памяти, который вы намереваетесь использовать в какой-то момент при перераспределении и перемещении данных. (Например, в какой-то момент у него есть N выделенных байтов, вы добавляете данные через метод добавления или итератора, и он выделяет 2N байтов, копирует первые N и освобождает N. У вас есть 3N байтов, выделенных в какой-то момент).
Так что, в конце концов, у него много преимуществ, и вы платите, если знаете, что делаете. Вы должны немного знать, как работает C ++, чтобы использовать его во встроенных проектах без сюрпризов.
А парню с фиксированными буферами и сбросом вы всегда можете выполнить сброс внутри нового оператора или чего-то еще, если у вас недостаточно памяти, но это будет означать, что вы сделали плохой дизайн, который может исчерпать вашу память.
Исключение, создаваемое в ARM realview 3.1:
--- OSD\#1504 throw fapi_error("OSDHANDLER_BitBlitFill",res);
S:218E72F0 E1A00000 MOV r0,r0
S:218E72F4 E58D0004 STR r0,[sp,#4]
S:218E72F8 E1A02000 MOV r2,r0
S:218E72FC E24F109C ADR r1,{pc}-0x94 ; 0x218e7268
S:218E7300 E28D0010 ADD r0,sp,#0x10
S:218E7304 FA0621E3 BLX _ZNSsC1EPKcRKSaIcE <0x21a6fa98>
S:218E7308 E1A0B000 MOV r11,r0
S:218E730C E1A0200A MOV r2,r10
S:218E7310 E1A01000 MOV r1,r0
S:218E7314 E28D0014 ADD r0,sp,#0x14
S:218E7318 EB05C35F BL fapi_error::fapi_error <0x21a5809c>
S:218E731C E3A00008 MOV r0,#8
S:218E7320 FA056C58 BLX __cxa_allocate_exception <0x21a42488>
S:218E7324 E58D0008 STR r0,[sp,#8]
S:218E7328 E28D1014 ADD r1,sp,#0x14
S:218E732C EB05C340 BL _ZN10fapi_errorC1ERKS_ <0x21a58034>
S:218E7330 E58D0008 STR r0,[sp,#8]
S:218E7334 E28D0014 ADD r0,sp,#0x14
S:218E7338 EB05C36E BL _ZN10fapi_errorD1Ev <0x21a580f8>
S:218E733C E51F2F98 LDR r2,0x218e63ac <OSD\#1126>
S:218E7340 E51F1F98 LDR r1,0x218e63b0 <OSD\#1126>
S:218E7344 E59D0008 LDR r0,[sp,#8]
S:218E7348 FB056D05 BLX __cxa_throw <0x21a42766>
Не кажется таким уж страшным, и внутри {} блоков или функций не добавляются служебные данные, если исключение не выдается.