Стек против кучи для фиксированного количества объектов, требующих глобальной области видимости

Это не вопрос стека или кучи (что, если быть точным, не означает то, что вы думаете о С ++: это просто структуры данных, такие как вектор, набор или очередь). Это вопрос продолжительности хранения.

Скорее всего, вам понадобятся здесь объекты статической продолжительности, которые могут быть как глобальными, так и членами класса. Автоматические переменные, объявленные внутри функции main, также могут выполнять эту работу, если вы спроектируете способ доступа к ним из другого кода.

Здесь есть некоторая информация о различных сроках хранения C ++ (автоматическая, статическая, динамическая) < / а>. Однако в принятом ответе используется запутанная терминология стека / кучи, но объяснение правильное.

куча предназначена для хранения данных, где время жизни хранилища не может быть определено заранее

Хотя это правильно, это также неполно.

Стек раскручивается, когда вы выходите из его области видимости, поэтому использовать его для переменных с глобальной областью видимости невозможно, как вы сказали. Однако именно здесь вы перестаете быть на правильном пути. Хотя вы знаете время жизни (или, точнее, область действия, поскольку это наиболее важный фактор здесь), вы также знаете, что она выше кадра стека, поэтому, имея только два варианта выбора, вы положил в кучу.

Существует третий вариант - фактическая статическая переменная, объявленная в верхней области видимости, но она будет работать только в том случае, если ваши объекты имеют конструкторы по умолчанию.

TL; DR: использовать глобальное (статическое) хранилище либо для указателя на массив (динамическое выделение), либо только для фактического массива (статическое выделение).

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

Как вы упомянули, стек часто имеет ограничения по размеру. Это оставляет вам два варианта: динамически размещать объекты или сделать их глобальными. Временные затраты на выделение всех ваших объектов один раз при запуске приложения почти наверняка не имеют большого значения. Так что просто выберите тот метод, который вам больше нравится, и сделайте это.

Я думаю, вы сбиваете с толку использование стека (хранилище для локальных переменных и параметров) и данных с незаданной областью (статические переменные класса и данные, выделенные через new или malloc). Одним из подходящих решений, основанных на вашем описании, может быть статический класс, в котором ваш массив указателей объявлен как статический член класса. Это будет размещено в куче подобной структуре (возможно, даже в куче, в зависимости от вашей реализации C ++). «быстрым и грязным» решением было бы объявить массив как статическую переменную (в основном глобальную переменную), однако это не лучший подход с точки зрения ремонтопригодности.

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

Если скорость не является проблемой или вы не можете позволить себе накладные расходы, вам следует вставить объекты в std::vector. Если семантика копирования не определена для объектов, следует использовать std::vector из std::shared_ptrs.