memory #6 - comp.programming

In C I have never really used malloc to alloc memory from the heap. Now when using C's data types you are using the stack if I am correct. In programming requirements are there times when you want memory allocated from either parts of memory? int mem[100]; 100 ints from stack int *pi=malloc(100); 100 ints from heap Bill

"Bill Cunningham" <nospam@nspam.invalid> wrote in message news:48d41d97$0$9727$bbae4d71@news.suddenlink.net... > In C I have never really used malloc to alloc memory from the heap. Now > when using C's data types you are using the stack if I am correct. In > programming requirements are there times when you want memory allocated > from either parts of memory? > > int mem[100]; 100 ints from stack > int *pi=malloc(100); 100 ints from heap > > Bill malloc(100) usually won't hold 100 ints though (50 is common) unless CHAR_BIT is 16 or larger (I wouldn't count on that) but as to the question.. what exactly do you mean? If you mean "does it matter how you allocate your memory" then yes, it Can matter, but sometimes not For example, if the number of ints is known at compile-time and it will be a global variable, it won't matter too much If the length is not known at compile-time then using a VLA may not allways help, for example, returing a pointer to them should be avoided, so if that's necesary you should malloc it instead.

"Bill Cunningham" <nospam@nspam.invalid> wrote in message news:48d41d97$0$9727$bbae4d71@news.suddenlink.net... > In C I have never really used malloc to alloc memory from the heap. Now > when using C's data types you are using the stack if I am correct. In > programming requirements are there times when you want memory allocated > from either parts of memory? > > int mem[100]; 100 ints from stack > int *pi=malloc(100); 100 ints from heap > Obviously? Suppose you want to return an array from a method? If the method allocates the array on the stack then it won't be valid after the method returns. Suppose you need to allocate a very large array? You definitely don't want to do that on the stack! The stack is mainly used for passing information between methods quickly and storing local data and not for large pieces of data. (The cpu has structure for managing the stack efficiently compared to the heap so that it's quick and and it's a *stack* and not meant for random access)

Bill Cunningham wrote: > In C I have never really used malloc to alloc memory from the heap. Now > when using C's data types you are using the stack if I am correct. In > programming requirements are there times when you want memory allocated from > either parts of memory? > > int mem[100]; 100 ints from stack > int *pi=malloc(100); 100 ints from heap Usually heap is bigger than stack. So when you want to use a lot of memory, you use heap. Or when you want the memory usage to be dynamic (e.g. a container where you add and remove items but want to keep the memory usage in minimum at all times), then you again use heap. E.g. if you write image manipulation program and want to load the whole image into memory, you probably want to use heap for that as the size is undefined and can be big, but you don't want to use more memory than what is needed. ( And stack might not be big enough for all the images. )

"Ian Collins" <ian-news@hotmail.com> wrote in message news:6jin58F38973U8@mid.individual.net... > No, 100/sizof(int) ints from where ever dynamic memory is allocated. > Isn't dynamic memory part of the heap for whatever reason? Maybe because there's more of it. The arrays seem to die when their frame is popped but we have to call free() for the heap. Am I right in the first sentence? Bill

"Harold Aptroot" <harold.aptroot@gmail.com> wrote in message news:45c21$48d423ef$53558f0b$21987@cache110.multikabel.net... > If you mean "does it matter how you allocate your memory" then yes, it Can > matter, but sometimes not [snip] Yes that's what I meant. Bill

Bill Cunningham wrote: > "Ian Collins" <ian-news@hotmail.com> wrote in message > news:6jin58F38973U8@mid.individual.net... > >> No, 100/sizof(int) ints from where ever dynamic memory is allocated. >> > Isn't dynamic memory part of the heap for whatever reason? Maybe because > there's more of it. The arrays seem to die when their frame is popped but we > have to call free() for the heap. Am I right in the first sentence? > Now come on Bill, you've been posing to c.l.c long enough to have seen these questions answered a dozen times. Please don't start your cycle of beginner questions all over again here. -- Ian Collins.

Jon Slaughter wrote: > "Bill Cunningham" <nospam@nspam.invalid> wrote in message > >> In C I have never really used malloc to alloc memory from the >> heap. Now when using C's data types you are using the stack if >> I am correct. In programming requirements are there times when >> you want memory allocated from either parts of memory? >> >> int mem[100]; 100 ints from stack >> int *pi=malloc(100); 100 ints from heap >> > Obviously? > > Suppose you want to return an array from a method? If the method > allocates the array on the stack then it won't be valid after > the method returns. Don't confuse him. Bill uses C, which doesn't have C++ methods. In addition "pi = malloc(100);" returns storage for 100 chars, not ints. To get 100 items use the normal malloc call of "pi = malloc(100 * sizeof *pi);", which will follow the type of pi. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section.

Bill Cunningham wrote: > "Ian Collins" <ian-news@hotmail.com> wrote in message > >> No, 100/sizof(int) ints from where ever dynamic memory is >> allocated. > > Isn't dynamic memory part of the heap for whatever reason? Maybe > because there's more of it. The arrays seem to die when their > frame is popped but we have to call free() for the heap. Am I > right in the first sentence? In practice, yes. However there is no strict need for a heap, where it comes from is up to the system designer, and it should never affect your code. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section.

Bill Cunningham said: > http://www.cs.jcu.edu.au/Subjects/cp2003/1997/foils/heapAndStack/heapAndStack.html > > This is good info on the subject anyway. You don't appear capable of distinguishing between good info and bad info. Nothing on that page binds C to anything. Note, too, that the first program on that page violates a constraint and (separately!) invokes undefined behaviour. Whoever wrote it doesn't know very much about C. Furthermore, bear in mind that the explanation is about heaps and stacks, so it's not surprising that it explains about heaps and stacks - but the C language that you claim to have been studying for so many years *does not require* memory to be organised in that way. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ Google users: <http://www.cpax.org.uk/prg/writings/googly.php> "Usenet is a strange place" - dmr 29 July 1999

"Bill Cunningham" <nospam@nspam.invalid> wrote in message > Isn't dynamic memory part of the heap for whatever reason? Maybe > because there's more of it. The arrays seem to die when their frame is > popped but we have to call free() for the heap. Am I right in the first > sentence? > We might as well call the area malloc() allocates from "the heap". A pedant would want to use a more precise term to distinguish between different types of internal organisation. However that doesn't affect the malloc() caller. -- Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm

On Fri, 19 Sep 2008 20:04:41 -0400, Bill Cunningham wrote: > "Ian Collins" <ian-news@hotmail.com> wrote in message > news:6jin58F38973U8@mid.individual.net... > >> No, 100/sizof(int) ints from where ever dynamic memory is allocated. >> > Isn't dynamic memory part of the heap for whatever reason? Maybe > because > there's more of it. The arrays seem to die when their frame is popped > but we have to call free() for the heap. Am I right in the first > sentence? > You don't _need_ the concepts 'stack or 'heap' to understand this. It might only confuse you. 'Normal' variables (global or automatic in C-terms (1)) just have {name,type,size} plus two attributes attached to them: 'visibility' and 'durability'. The 'visibility' aspect (of an identifier) dictates when you can use it, outside this 'scope' you cannot 'see' this name and you cannot use it to get it's 'contents' (the value that is currently stored inside wherever the name refers to. The 'durability' specifies the stretch of time that the variable is supposed to retain it's contents. Malloc() is different. The memory that is returned by it does not have a name or type. It only has a size. Because there is no name, there is no 'visibility' attached to this memory. Also: there is no durability: the memory stays available until you explicitly free() it. EXAMPLE: #include <stdio.h> #include <stdlib.h> int aaa = 101; void func(void); int main(void) { int bbb = 666; int *ppp; /* now you can see and use aaa and bbb and ppp; */ printf("%d %d %p\n", aaa, bbb, (void*) ppp); func(); /* you can still see and use aaa and bbb and ppp; but *not* ccc */ printf("%d %d %p\n", aaa, bbb, (void*) ppp); /* allocate memory for 100 ints; store a pointer to it in ppp; */ ppp = malloc(100 * sizeof *ppp); /* you can still see and use aaa and bbb and ppp; but *not* ccc */ printf("%d %d %p\n", aaa, bbb, (void*) ppp); if (ppp == NULL) exit(0); /* by now you can use the malloc()d memory to do something useful, eg print it */ ppp[0] = 11 ; ppp[10] = 22; ppp[42] = 33 ; ppp[83] = 99; printf("%d %d %d %d\n", ppp[0], ppp[10], ppp[42], ppp[83] ); return 0; } void func(void) { int ccc = 2008; /* now you can see and use aaa and ccc but *not* bbb and ppp; */ printf("%d %d\n", aaa, ccc ); } Now, the next exercise would be to move the ppp variable and the call to malloc() from main() to func(). What will happen ? Just try it, and try to explain. HTH, AvK NOTE: (1) static omitted for clarity.

"Jon Harrop" <jon@ffconsultancy.com> wrote in message news:ob6dne49MpnbpUvVnZ2dnUVZ8v-dnZ2d@bt.com... > Bill Cunningham wrote: >> In C I have never really used malloc to alloc memory from the heap. >> Now >> when using C's data types you are using the stack if I am correct. In >> programming requirements are there times when you want memory allocated >> from either parts of memory? > > Yes. If you allocate variables on the stack then they can only live to the > end of the function in which they were allocated. So if you want to return > a data structure from a function in C you will almost certainly want to > allocate it on the heap instead. Have you ever considered an allocator that is based on a plurality of threads stacks? I have programmed such things for some embedded jobs where there simply was no heap; old versions of Quadros... fun times! :^)

Bill Cunningham wrote: > In C I have never really used malloc to alloc memory from the heap. > Now > when using C's data types you are using the stack if I am correct. In > programming requirements are there times when you want memory allocated > from either parts of memory? Yes. If you allocate variables on the stack then they can only live to the end of the function in which they were allocated. So if you want to return a data structure from a function in C you will almost certainly want to allocate it on the heap instead. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?u

On Sep 19, 5:13=A0pm, "Jon Slaughter" <Jon_Slaugh...@Hotmail.com> wrote: > "Bill Cunningham" <nos...@nspam.invalid> wrote in message > > news:48d41d97$0$9727$bbae4d71@news.suddenlink.net... > > > =A0 =A0In C I have never really used malloc to alloc memory from the he= ap. Now > > when using C's data types you are using the stack if I am correct. In > > programming requirements are there times when you want memory allocated > > from either parts of memory? > > > int mem[100]; 100 ints from stack > > int *pi=3Dmalloc(100); 100 ints from heap > > Obviously? > > Suppose you want to return an array from a method? If the method allocate= s > the array on the stack then it won't be valid after the method returns. > > Suppose you need to allocate a very large array? You definitely don't wan= t > to do that on the stack! > > The stack is mainly used for passing information between methods quickly = and > storing local data and not for large pieces of data. (The cpu has structu= re > for managing the stack efficiently compared to the heap so that it's quic= k > and and it's a *stack* and not meant for random access) Just a suggestion but you C++ guys need to remember: C doesn't have methods, it has functions. C doesn't have containers, it has arrays. And actually at the language level, it doesn't have a stack. (i.e. nothing in the language standard requires passing parameters on a stack. It just happens to be most convenient on most processors.)

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message news:IL-dnRDiz8noCUnVnZ2dnUVZ8uSdnZ2d@bt.com... > You don't appear capable of distinguishing between good info and bad info. > Nothing on that page binds C to anything. Note, too, that the first > program on that page violates a constraint and (separately!) invokes > undefined behaviour. Whoever wrote it doesn't know very much about C. > > Furthermore, bear in mind that the explanation is about heaps and stacks, > so it's not surprising that it explains about heaps and stacks - but the C > language that you claim to have been studying for so many years *does not > require* memory to be organised in that way. IS this an operating system issue? If someone really wanted to gain access to memory won't they somehow have to be able to access the kernel or system calls anyway? Bill

On Sep 22, 3:00=A0pm, "Bill Cunningham" <nos...@nspam.invalid> wrote: > "Richard Heathfield" <r...@see.sig.invalid> wrote in message > > news:IL-dnRDiz8noCUnVnZ2dnUVZ8uSdnZ2d@bt.com... > > > You don't appear capable of distinguishing between good info and bad in= fo. > > Nothing on that page binds C to anything. Note, too, that the first > > program on that page violates a constraint and (separately!) invokes > > undefined behaviour. Whoever wrote it doesn't know very much about C. > > > Furthermore, bear in mind that the explanation is about heaps and stack= s, > > so it's not surprising that it explains about heaps and stacks - but th= e C > > language that you claim to have been studying for so many years *does n= ot > > require* memory to be organised in that way. > > =A0 =A0 IS this an operating system issue? If someone really wanted to ga= in > access to memory won't they somehow have to be able to access the kernel = or > system calls anyway? > > Bill No, it is a programming language issue. It is easier when the memory model of the programming language and of the operating system match, but the model used by the language is to a great extent independent of the OS. Keep in mind that the world supports more than the C branch of programming languages. And there are a world of processors that can have really different architectures. (Ever heard of the Harvard Architecture?) So there are at least three levels of abstraction for memory organization: hardware, OS, and programming language. Those levels are to a great extent independent because without that independence there would be little or no portability. (UNIX would be stuck on PDP-11 machines, FORTRAN would be stuck on IBM mainframes. The INTEL line of processors would have died with the 8086 segment model.) So to answer your question: a C compiler writer needs to worry about the kernel calls, but a C programmer does not. This is precisely because the language's memory model is not tied to the OS' or processor's memory model. The C memory model is essentially flat. Everything exists in one memory space: local variables, static variables, global variables, functions. All those elements can be accessed via pointers which are not specialized to the type of element. How the compiler writer implements malloc() or other structures is hidden to the application programmer. Variable scope is something an application programmer needs to be concerned about, but how that scope is managed is irrelevant to him. HTH, Ed.