Функция измерения общего пространства распределяется по куче и стеку в течение всего времени жизни

Ваш пример для измерения использования стека точен и даст вам (почти) правильный ответ. У меня есть предложение для определения использования кучи, но сначала ….

В своей книге «Более эффективный C ++» в пункте 27 Скотт Мейерс (между прочим, мой любимый автор на C ++) описывает, почему в общем смысле и в рамках портативного или полупортативного C ++ невозможно определить, был ли объект размещается в стеке, куче или статически. Но его объяснение относится к выделенным объектам с точки зрения самих объектов, а не к распределению с точки зрения кода, который запрашивает такое распределение. С точки зрения кода, который запрашивает выделение, вы можете точно знать, размещен ли объект, независимо от его типа, в куче или стеке в зависимости от того, как вы запросили его выделение. (Боковая панель: Конечно, это зависит от того, действительно ли ваша система использует стек времени выполнения, что некоторые быстро указывают на то, что стандарт C ++ не гарантирует, однако ни один из этих снобов стандартов никогда не указывает на какой-либо реальный пример другого стандартного стандарта. соответствующий компилятор C ++, который не использует стек времени выполнения. Вернуться к нашему обсуждению …) Например:

int Fred;  // Fred is allocated on the stack
int *Barney = new int; // Barney is allocated on the heap

Фред уничтожит, когда выйдет за рамки; Вы должны явно удалить Барни, когда закончите с ним. Это работает так же для пользовательских типов, включая типы STL:

std::string Fred; // Fred is allocated on the stack (see disclaimer*)
std::string *Barney = new std::string(); // Barney is allocated on the heap

// *Disclaimer:  May not be totally true on some small embedded processors that
//               implement the runtime stack in a special small address space
//               separate from “normal” RAM.

…НО: хотя объект std :: string, известный как Fred, сам по себе расположен в стеке, мы, конечно, знаем, что его данные не могут быть распределены в стеке, потому что его данные имеют переменную длину и должны иметь возможность неограниченного расширения при добавлении символов к этому. Таким образом, только часть управления std :: string (т.е. сам объект std :: string) может быть размещена в стеке.

Вернемся к пункту 27 Скотта Мейера и его применимости к этому обсуждению:

myClass *someFunction() {
int someInputParameter = 42;
myClass Fred(someInputParameter); // Fred is allocated on the stack
myClass *Barney = new myClass(someInputParameter); // Barney is allocated on the heap
return Barney;
}

Согласно пункту 27 Скотта Мейера, ни Фред, ни Барни не могут сами знать, распределены ли они по стеку или куче, или, в этом отношении, статически (то есть «глобально» или «область действия файла» или «статический член некоторого другой класс »). Но внутри someFunction () мы можем знать, потому что мы знаем, как мы запрашивали распределение.

Теперь вернемся к вашей проблеме:

Как я уже сказал, пример, который вы показываете для измерения использования стека, является точным. В main () вы наверняка знаете, что «localVariable» размещается в стеке. И вы наверняка знаете в Quick (), что currPtrLocation находится в стеке. И если ваш стек уменьшается, вы наверняка знаете, что поскольку main () вызывает Quick (), адрес currPtrLocation в Quick () будет ниже адреса localVariable в main (), поэтому ваша арифметика работает , Он не даст совершенно правильный ответ, потому что в Quick () могут быть другие переменные, которые расположены в ячейках стека, но ниже, чем «currPtrLocation», но ваши измерения будут действительно близки; конечно, так близко, как вы должны заботиться. Какой бы ни была величина ошибки, она является фиксированной ошибкой независимо от того, насколько глубоким является ваш стек вызовов, и если вы повторяете какое-либо значительное количество раз, ошибка в процентах от целого будет незначительной. И последнее: если вы хотите, чтобы решение было переносимым даже в те системы, где стек растет, вы можете определить направление разницы между адресами localVariable и currPtrLocation и вычислить разницу (т. Е. Поменять местами аргументы в вычитание) соответственно.

Что касается использования кучи:

В вашей системе могут быть зацепки, которые вы можете использовать для измерения статистики использования кучи, но если вы не хотите вникать в это, вы можете сделать что-то в соответствии с предложением Synxis, но есть некоторые серьезные проблемы с этим ответом. Прежде всего, предложение Synxis пропускает все служебные данные стека, включая адреса возврата, разлитые регистры и т. Д., Которые не являются незначительными. Во-вторых, если вы используете технику измерения стека, как показано в своем вопросе, нет необходимости тщательно поддерживать сумму выделений для объектов, выделенных в стеке. В-третьих, предполагая, что вы только суммируете выделения объектов, выделенных в куче (размер которых вы можете получить с помощью оператора sizeof ()), вы не можете просто продолжать их суммировать. Вам придется вычесть размеры выделений при их удалении, чтобы ваш «totalSize» сохранял общий размер всех В настоящее время выделенные объекты, и вы хотели бы отдельно отслеживать верхнюю отметку totalSize. Таким образом, вы можете узнать самый большой объем памяти, который использовался вашим алгоритмом за один раз. Без этого вы можете запутаться, когда ваш алгоритм сообщает, что он использует что-то вроде 758 гигабайт, даже если у вас есть только 4 ГБ ОЗУ. И, наконец, независимо от того, выделяете ли вы данный объект в стеке или куче, он может делать свои собственные внутренние выделения в куче. (Если при вызове метода для этого объекта он временно выделяется в стеке, если только вы не добавили свой код отслеживания стека в этот метод, общая сумма стека будет не совсем правильной, как я уже описывал, но ошибка будет продолжайте быть более или менее постоянной, в зависимости от того, выполняет ли метод условные выражения, которые могут изменить его поведение при вызове.) В любом случае, относительно этого «данного объекта», который вы размещаете в стеке или куче; если он выделяет собственную внутреннюю память кучи, если вы не добавите отслеживание выделения кучи для внутренних объектов, вы пропустите любой объем памяти кучи, выделенный этим внутренним объектам. Поэтому, возможно, вам лучше изучить хуки статистики, которые ваша система может сделать доступными.

Теперь, предполагая, что вы хотите самостоятельно выполнять выделение кучи треков … Другой вариант, который вы могли бы изучить, — написать базовый класс, из которого ваш алгоритм может получить все объекты, которые он создает. Ваш базовый класс может переопределить оператор new & Оператор удаления так, что сам базовый класс выполняет все отслеживание totalSize (добавляя для «нового» и вычитая для «удаления»), используя переменную статического класса в базовом классе.