ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Use global static variables to preserve data between function invocations. Not the function local static variables.
Quote:
Originally Posted by psionl0
Better still, any variables that need to be conserved between function invocations should be stored by the calling function and a pointer passed to those functions that need it.
Good clarification. The caller should explicitly reference global data to the called function through pointers.
Referencing global variables by name in a function is most often "asking for trouble". But in some cases it is still needed.
Quote:
Originally Posted by wroom
For realtime performance, and also for reliable execution, the concept of avoiding dynamic allocation is essential. Global and static allocation is enforced, and dynamic allocation kept to an absolute minimum.
Having lots of small functions that allocate large arrays/buffers dynamically, for a short time, either on stack or in paged memory, are detrimental to reliable, predictable realtime performance.
Quote:
Originally Posted by psionl0
I have never heard of this rule of thumb before. Is this because of the way Linux allocates memory? There are many cases where the amount of memory required can not be known beforehand and dynamic allocation is the only way around this. In some languages (like Java), every non-elemental variable has to be dynamically allocated.
Interesting point. I think Linux is very efficient in its handling of memory.
But the rule was for "realtime performance". You know, when certain memory pages are locked into RAM, and certain code and data is locked into CPU cache, or the system is designed totally without both paged memory and dynamic cache.
A desktop or server Linux is not a realtime system. An Anti-lock Brake System in a car is running a realtime system. A system with 100% deterministic response time.
Calling malloc or free invites the running of garbage collection mechanisms that are non-deterministic in execution time.
This makes languages like Java, and some central use cases of C++/Cpp totally useless for realtime applications. (Although useable for non-deterministic background processing in the same system as long as it never interferes with the realtime applications).
Calling malloc or free invites the running of garbage collection mechanisms that are non-deterministic in execution time.
It was always my understanding that C/C++ doesn't have garbage collection. That's why you need to free/delete the allocated memory when finished with it. It can lead to heap fragmentation though.
It was always my understanding that C/C++ doesn't have garbage collection. That's why you need to free/delete the allocated memory when finished with it. It can lead to heap fragmentation though.
If a C/C++ program running on Linux uses malloc a couple of times during it's execution, but does not 'free' that memory, the memory will still be free'd to the system when the program exits.
It is true that C/C++ does not do the same periodic garbage collection as Java does/(has to do).
Bot there is still some garbage collection tasks running at certain points.
It is noteworthy that a malloc will return before all the allocated memory is actually mapped in physical memory.
You can in fact overallocate. As long as you don't use all that memory at once, it will not be mapped until it is really needed. But the system will start looking for unused pages that it can use to map the allocated virtual memory. Throwing out pages that was used for file caching. Linux will not keep that much memory as 'unused'. It will use the physical memory the best it can.
Take a look at this example statistics from 'top':
Think about what happens when some program allocates 24 GiB of heap memory on this machine.
There is only 579528 KiB free memory in the system. But it will kick out some of the 29870660 KiB of file cache pages to fulfill the requested allocation. A page at a time.
I think we have wandered off from the OPs question. But it has been an interesting discussion.
It is true that the OS will perform a number of memory management tasks during program execution. However, these tasks are all transparent to the programmer.
As far as the C/C++ programmer is concerned, once memory has been malloc'd, that memory available at all times until it has been free'd or lost (no pointers point to the malloc'd memory any more). Not only that, but the programmer can expect the address to remain unchanged for the life of that memory. The address could be stored in a pointer and no matter how long the program waits, it will still be the correct address when the memory is finally used.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.