Re: Stack, Heap, Mfc

>> As I understand it we have to take in to account what is put on the stack
>> and what
>> is put on the heap. Since our classes are instantiated from either a
>> document or view
>> decendant does this not mean that all memory will be on the heap because
>> our
>> document
>> and view classes will be on the heap?
>>
>> If we have a class1 and instantiate it from a CDocument
>> class1 myClass
>> It is not directly put on the heap with 'new' but it will still be a part
>> of
>> CDocument class decendent
>> which is on the heap so the memory for the instance of myClass will also
>> be
>> on the heap.
>>
>> Am I missing something or can I conclude that no memory used for mfc
>> objects
>> is placed on
>> the stack.
>
> That's way too broad a statement. Stack-based (automatic storage duration,
> or simply "auto", technically speaking) MFC objects are used all the time,
> in the form of CString, CDC, and even most modal CDialog objects and what
> they contain (e.g. CStatic, CEdit, CString, etc), etc, etc, etc. I'm not
> quite sure what you're asking, but if you have a class:
>
> struct X
> {
> int y;
> char* z;
> };
>
> The memory for X is laid out like this:
>
> Byte offset 0: y
> Byte offset 4: z
>
> So, the memory for an X is contiguous wherever the X is created, be it the
> stack or the heap. However, z can be set to point to memory on the stack
> or
> the heap.
>
>> Also, if functions are placed on the stack
>
> Functions are code. You mean function arguments, auto variables, and
> compiler housekeeping such as saved registers.
>
>> when they are used and the stack
>> is a limited area of
>> memory. How can you account for recurring functions that will increase
>> the
>> area of the stack used
>> each time the function is called. How can you stop the stack from over
>> flowing.
>
> Every recursive algorithm has a non-recursive end case, and you must
> ensure
> that your algorithm ends up there for the data you supply it before you
> blow the stack. You first try to limit the recursion to an acceptable
> depth. A classic example would be quicksort. You can improve the maximum
> recursion depth from a worst case N to log(N) by going recursive only on
> the smaller of the two subarrays, using tail recursion removal to handle
> the larger. If you cannot limit the recursion, you can either increase the
> stack size (to be avoided) or limit the use of local variables. For
> example, you could replace a large local array with a std::vector, whose
> data lives on the heap.
>
> --
> Doug Harrison
> Microsoft MVP - Visual C++

Thanks Doug.

If I have a class that extends CDocument then all member variables in that
class
object will be on the heap. I can't see any way they would end up on the
stack.
The only way I can see anything of that object being on the stack is if it
is a method
parameter or a local variable. So all function parameters and local
variables will be
placed on the stack. Unless the local variable is specifically created with
'new' or the
function parameter is a reference or pointer then the reference or pointer
will be placed
on the stack.

If I am correct then things are a little clearer.

I am concerned about a stack overflow because I have used several
applications that throw
this exception and I want to avoid it in the application I am planning.

What is tail recursion removal ? Is it splitting the recursion in to a
number of related methods?

I don't plan to use recursion but I do want to understand how to use the
stack and where to draw
the line. I am trying to learn how to quantify the usage of the stack so
that it will be safe from
overflow exceptions.

How do you know when you have to increase the size of the stack?

What about threading?
If you dynamically create 10 threads there will need to be room on the stack
for the local variables
of the methods of the threads. I know the size of the stack is determined by
the compiler but what happens
if you increase the number of threads to 100 or 1000. How do you determine
that there is adequate room
on the stack for the local variables of the thread methods and the local
variables of the methods of the objects
used by the threads.



.

Relevant Pages

  • Re: Memory management strategy
    ... >>trading memory for speed ... The use of registers instead of the stack doesn't need inlining. ... >longer instructions to access smaller data than they were optimized for. ... square) but it didn't need recursion or some kind of stack. ...
    (comp.lang.c)
  • Re: run-time vs compile-time
    ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: run-time vs compile-time
    ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
    (comp.lang.cpp)
  • Re: Error Raising and Memory in VB (general question)
    ... > object is terminated go out of scope, and the memory is also released. ... But why are you saying it uses stack? ... I think we are dealing with heap memory here. ... "COM's IMalloc allocator: ...
    (microsoft.public.vb.general.discussion)
  • Re: Linked List & Dynamic Memory Allocation
    ... Both of you mentioned stack and heap in this ... when I call malloc it uses heap to allocate memory. ... if you have an integer pointer object that lives beyond this scope and you had: ...
    (microsoft.public.vc.mfc)