3

If i have this code :

#include <assert.h>

class Foo {
public:
    bool is_static();
    bool is_stack();
    bool is_dynamic();
};

Foo a;

int main()
{
    Foo b;
    Foo* c = new Foo;

    assert( a.is_static()  && !a.is_stack()  && !a.is_dynamic());
    assert(!b.is_static()  &&  b.is_stack()  && !b.is_dynamic());
    assert(!c->is_static() && !c->is_stack() &&  c->is_dynamic());

    delete c;
}

Is it possible to implement is_stack, is_static, is_dynamic method to do so in order to be assertions fulfilled?

Example of use: counting size of memory which particular objects of type Foo uses on stack, but not counting static or dynamic memory

user3123061
  • 757
  • 5
  • 14

3 Answers3

6

This cannot be done using standard C++ facilities, which take pains to ensure that objects work the same way no matter how they are allocated.

You can do it, however, by asking the OS about your process memory map, and figuring out what address range a given object falls into. (Be sure to use uintptr_t for arithmetic while doing this.)

Potatoswatter
  • 134,909
  • 25
  • 265
  • 421
1

Scroll down to the second answer that gives a wide array of available options depending on the Operating System:

How to determine CPU and memory consumption from inside a process?

I would also recommend reading this article on Tracking Memory Alloactions in C++:

http://www.almostinfinite.com/memtrack.html

Just be aware that it's a ton of work.

Community
  • 1
  • 1
B.K.
  • 9,982
  • 10
  • 73
  • 105
  • You might mean [the first answer](http://stackoverflow.com/a/64166/153285). The thing above that is the question . And it does not address differentiating stack from heap usage. – Potatoswatter Feb 21 '14 at 08:23
1

while the intention is good here, the approach is not the best. Consider a few things:

  • on the stack you allocate temporary variables for your methods. You don't always have to worry about how much stack you use because the lifetime of the temp variables is short

  • related to stack what you usually care about is not corrupting it, which can happen if your program uses pointers and accesses data outside the intended bounds. For this type of problems a isStatic function will not help.

  • for dynamic memory allocation you usually override the new/ delete operators and keep a counter to track the amount of memory used. so again, a isDynamic function might not do the trick.

  • in the case of global variables (you said static but I extended the scope a bit) which are allocated in a separate data section (not stack nor heap) well you don't always care about them because they are statically allocated and the linker will tell you at link time if you don't have enough space. Plus you can check the map file if you really want to know address ranges.

So most of your concerns are solved at compile time and to be honest you rarely care about them. And the rest are (dynamic memory allocation) are treated differently. But if you insist on having those methods you can tell the linker to generate a map file which will give you the address ranges for all data sections and use those for your purposes.

Pandrei
  • 4,843
  • 3
  • 27
  • 44
  • Yes, but counting how much memory some objects uses on stack cannot be generaly solved in compile time, because function calls and usage of stack depends on runtime conditions. – user3123061 Feb 21 '14 at 08:59
  • no it does not :) stack it statically allocated so you can know at compile time the max stack a function will use. What varies at runtime is the how much stack your program will use at a particular point in time. That depends on how many functions are called. – Pandrei Feb 21 '14 at 09:38
  • @Pandrei - what you say might be true for trivial code on some systems, but the compiler cannot know the stack usage of external calls at compile time. On some systems, the stack of a thread may also have to accommodate partial or complete interrupt frames. – Martin James Feb 21 '14 at 10:45
  • @MartinJames that is exactly what I said; the compiler cannot know the stack usage of the program at compile time because it depends on the data path. BUT how much memory a particular object uses, or how much stack a function call will cost can be know at compile time. – Pandrei Feb 21 '14 at 10:52
  • Also, the map file generated by the linker only has stack data for the thread raised by the process loader - it has no idea which, or how many, threads may create instances of foo at runtime. – Martin James Feb 21 '14 at 10:52
  • @Pandrei - not if it's a recursive call. – Martin James Feb 21 '14 at 10:59