Timeline for What does 'random access' mean?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 8, 2014 at 19:47 | comment | added | abelinux | Of course @Kareem! I was thinking out loud upon your suggestion. I actually wrote it down so that if my reasoning was not correct I'd get the chance of getting.. well.. corrected =P, and therefore learn something new. | |
| Dec 8, 2014 at 19:35 | comment | added | kzidane | @abelinux I think I already suggested that to you. | |
| Dec 8, 2014 at 19:06 | comment | added | abelinux |
Hum... and that's when my previous question comes into play ;) Thinking of it, probably declaring the array in main() and "passing it around" as argument might be better design choice, since the array's scope is "tighter" and clearer: the array belongs in main(). And besides, any function defined in terms of accepting an array and it's size would be completely reusable (which, ideally, is what we'd want most of the time)
|
|
| Dec 8, 2014 at 18:26 | comment | added | kzidane | @abelinux not necessarily! A better approach would probably be passing the array and maybe its size to the function. | |
| Dec 8, 2014 at 14:59 | comment | added | abelinux |
OK, was re-reading some of my "foobar.c" experiments and recalled one more use of mem alloc: to overcome "scope issues"! When you call, e.g. from main() a new function whose purpose is to create an array of (given) size, fill it with random data, and return it to main. If you declare the array as usual, it's created on the stack, and therefore destroyed when leaving this new function's scope. But, if you allocate mem for such array on the heap, it "stays" there and you can return it to main.
|
|
| Dec 8, 2014 at 14:53 | comment | added | kzidane | @abelinux that is true! | |
| Dec 8, 2014 at 14:51 | history | edited | kzidane | CC BY-SA 3.0 |
added 7 characters in body
|
| Dec 8, 2014 at 14:41 | comment | added | abelinux | Uhm... OK, I may have small-talked when referring to "OS". I didn't know specifically who is responsible, all I meant was "it's not me" =P. By "safer" I meant that, since I'm not responsible for alloc and free mem, since someone takes care of that for me, there's less risk (or really no risk at all) of a memory leak. | |
| Dec 8, 2014 at 14:39 | history | edited | kzidane | CC BY-SA 3.0 |
added 7 characters in body
|
| Dec 8, 2014 at 14:32 | comment | added | kzidane | @abelinux you're welcome! And yes, we use dynamic memory allocation when we don't know the amount of memory that we need in advance. And I'm actually not sure what you mean by "safer", but if you at least have an upper-bound to the amount of memory that you need, then you can use arrays which are probably more efficient to use. But here's something, AFAIK, the operating system isn't directly responsible for managing memory in such situation. The compiler is the one that allocates memory and the runtime system takes care of freeing it. | |
| Dec 8, 2014 at 14:05 | comment | added | abelinux |
Thanks @Kareem for (once again) such thoughtful answer. At risk of sliding a bit off-topic: dynamic memory allocation (i.e.: malloc() and free(), rigth?) is "only" necessary when the amount of memory needed is not known in advance, and therefore has to be defined at runtime, right? If you know (or can estimate) in advance how much memory you need, it's always safer and more efficient to let the OS manage it all by itself.. Am I correct? Could this be sort of a "rule of thumb"?
|
|
| Dec 8, 2014 at 13:49 | history | answered | kzidane | CC BY-SA 3.0 |