Это слишком много, чтобы выделить 16 КБ в стеке? - PullRequest
10 голосов
/ 07 апреля 2011

Мне нужно создать экземпляр буфера char [16384] перед вызовом функции ac.После того, как функция вернется, я прочитаю некоторые ее части и откажусь от нее.

Можно ли разместить ее в стеке или использовать кучу?

РЕДАКТИРОВАТЬ: Я добавлю немного информации.Код будет работать на нескольких платформах, от ПК до iPhone, где, как мне кажется, пространство стека не будет таким большим, но я понятия не имею об этом.

Ответы [ 6 ]

15 голосов
/ 07 апреля 2011

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

Лично, если бы я увидел это в обзоре кода, я бы поднял красный флаг. Это много памяти, чтобы использовать для стекового буфера. Это может сработать сегодня в очень конкретном месте, где вы его используете, но как насчет завтра, когда вам коллируют с намного большим стеком ниже вас? Или когда клиент выберет сценарий, который вы не рассматривали?

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

5 голосов
/ 07 апреля 2011

Если вы не программируете для встраиваемых систем, кода, который может выполняться из потока, отличного от основного потока, или кода, который вызывается рекурсивно, я бы сказал, что 16k находится в пределах разумного размера, который вы можете выделить в стеке.

Что касается потоков, если вы используете потоки POSIX и хотите, чтобы ваша программа была переносимой, вы можете использовать интерфейс pthread_attr_setstacksize, чтобы указать объем стекового пространства, необходимого вашему потоку, а затем столько, сколько вам нужно.знайте шаблоны вызовов и переоценивайте с хорошим запасом при выборе размера, вы можете быть уверены, что это будет безопасно.

2 голосов
/ 07 апреля 2011

Если вы используете C ++ (поскольку вопрос имеет этот тег), используйте vector<char> buffer(16384) - таким образом вы получите автоматическое освобождение, но большой буфер будет выделен в куче.

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

2 голосов
/ 07 апреля 2011

Полностью зависит от вашей ОС и определений процессов.Лучше выделить его из кучи на malloc и проверить результат (который может дать сбой).Распределение сбоя в стеке может привести к повреждению стека, которое вы не сможете отловить во время выполнения.

1 голос
/ 07 апреля 2011

Я бы сказал, что это зависит от предполагаемого времени жизни буфера.

Если цель состоит в том, чтобы буфер существовал только в области действия функции создания и функций, которые он вызывает, то на основе стекаявляется отличным механизмом, позволяющим избежать утечек памяти.

Если цель состоит в том, чтобы буфер был долгоживущим, из-за чего не хватало объема функции создания, то я бы malloc(3) буфер.

My pthread_attr_setstacksize(3) говорит, что нужно искать в pthread_create(3) информацию о размере стека по умолчанию;к сожалению, все, что у меня есть в моей системе, это справочная страница pthread_create(3posix), предоставляемая POSIX, в которой отсутствуют эти детали;но я помню, что размер стека по умолчанию настолько велик, что большинство людей, которые хотят знать, как установить размер их стека, хотят сжать , чтобы они могли запускать больше потоков в данном объеме памяти.:)

0 голосов
/ 07 апреля 2011

если ваш код не используется несколькими потоками и он не является повторным входом ... тогда я бы просто сделал один malloc при инициализации программы для этого буфера.Вы будете меньше беспокоиться о проблемах архитектуры, связанных с размером стека.Вы определенно не хотите делать malloc / free за звонок.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...