Re: Linked List & Dynamic Memory Allocation



one-trick-pony wrote:

Interesting point. When I code in C/C++ I choose not to think about
stack and heap. I focus on code than worry about the deep down
details of what is happening. I would like to learn that sometime but
my current goal is to learn the language and manipulating data
structures etc. Both of you mentioned stack and heap in this
example. I am not sure where that fits into the picture. I know, for
instance, when I call malloc it uses heap to allocate memory. But I
don't care where and how it gets memory as long as I get memory
allocated for my program.

Actually, in c++ it is your job to know about the memory, there really is no way out of it. You will have to move to managed if you don't want to know. (I'm not a .net programer so I don't really know what you do need to know.)

To wit, stack memory is managed. You don't have to worry about where it comes from but you do have to know it is only available 'in scope'.
Meaning, when you write:

{ //beginning of scope

int i; The memory now available for 'i'.

} //end of scope and the memory for i doesn't exist and no problems as the compiler won't let you use 'i' from here. But, if you have an integer pointer object that lives beyond this scope and you had:

int* pInt;

{
int i;
pInt= &i;
}
*pInt= 123; //This is broken code.

As for the heap, both malloc and new do the same thing. And you absolutely have to manage this memory yourself. For every new object you must have a corresponding delete object or you will have a memory leak. Or worse, you run out of memory.

Like I mentioned, this is an excercise, I have a very simple program.
There is only main routine-no functions. However, it seems I have to
be careful when I call other functions and manipulate linked list
because then stack becomes involved. I am not sure how will that
effect my program.

Maybe the above addresses your concern here.

The last thing I tried was the first reponse from Jonathan Wood in an
attempt to append items to a linked list.

m_nMode[MAX-1].next = pNewRec;
pNewRec->next = NULL;


It worked by allowing me to attach only 1 item.

That is because the last item you added is not on the stack so you can't use m_nMode[MAX-1] directly to keep adding. Go back to where I talked about walking pointers. At that, I think you have too much on your plate by having three items on the stack and the rest on the heap.

Start with a node pointer:
Node* nodebase= new Node;
node->next= NULL;

nodebase is your starting place. Now keep a second pointer for last inserted. They are the same with one item in the list.

Node* nodepos= nodebase;

Add another node:
nodepos->next= new Node;
nodepos= nodepos->next;
nodepos->next= NULL;

And when you are done with this memory extend the 'walk pointers' code I posted to delete or free the nodes. You can do the above with malloc/free or new/delete. Same code otherwise.

Best, Dan.

.

Relevant Pages

  • 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: ptrs validity
    ... I have a pointer that points to an unknown heap memory block, ... hardware checked segment for each allocation. ...
    (comp.lang.c)
  • Re: Stack, Heap, Mfc
    ... >> is put on the heap. ... >> decendant does this not mean that all memory will be on the heap because ... > stack or the heap. ... You first try to limit the recursion to an acceptable ...
    (microsoft.public.vc.mfc)