Мы используем C ++ во встроенной системной среде и в основном не хотим никакого динамического распределения памяти (см., Например, Ресурсы для управления памятью во встроенном приложении по тем же причинам, по которым мы этого не делаем). Тем не менее, мы не хотим обойтись без некоторых хороших функций на основе C ++, таких как контейнеры STL и std :: string. Для первого мы зарезервируем определенный размер при инициализации и не позволим контейнеру вырасти за пределы своей емкости. Что касается последних (std :: string), я немного скептически относился к тому, как их использовать «безопасно», поскольку они иногда выделяют память в куче.
Тем не менее, я обнаружил обстоятельства, при которых использование std :: string (и, как правило, других объектов, выделяющих кучу) вполне допустимо: я бы выделил сам объект в стеке (в определенной области, ограниченной {}, поскольку я говорит с C ++) и позволяет им выделять кучу при условии, что они фактически освобождают всю свою зарезервированную память, когда они выходят за пределы области видимости.
Я понимаю, что этот метод определенно не гарантирует свободу фрагментации памяти, но я чувствую, что если рассматриваемая область действия недолговечна, это на самом деле приводит к непрерывной свободной памяти после ее окончания.
У меня также были сомнения, что может возникнуть проблема, когда несколько задач используют одну и ту же кучу, но все же свободная память должна быть непрерывной в конце при условии, что все доступные области недолговечны (например, не блокируются). В качестве альтернативы для меня было бы приемлемо, что только одной задаче разрешено выделять память в куче, а другим - нет, если это действительно имеет значение.
Допустимо ли предложенное мной использование объектов, выделяющих кучу? Есть ли у кого-нибудь другая стратегия (частично) для включения динамического распределения памяти без риска фрагментации памяти?
