-
The functions are in an area usually called static.
-
The space occupied by the binary code of the functions is there regardless of whether there is an instance or not, because instantiation has nothing to do with the codes. In the background functions are more independent than people imagine.
-
As functions only take up space once and not for each instance created. The function (your code) is global. If you think of the code as a given, there is no reason to exist more than one copy of it. Even if it runs multiple times, in different situations, the code itself only needs to exist once.
If you change the code (if you can do this) it will be changed to all instances, after all there is only one function for all.
It is important to note that the space occupied in memory is relative. It may not occupy anything in RAM. The code is usually loaded by memory file mapping, and the operating system actually loads memory only the pages that are being used. So a function never called has a good chance of never getting into RAM. It will, of course, take up space in virtual addressing. But that's another matter.
Of course, if there are no instances of a class, there is a possibility that the compiler does not include any code in the application's executable.
But even codes that never passed near your code can be included together by being together with codes that your code used effectively. The codes are in inseparable compilation units. If you use a function of a compilation drive, everything goes in this unit. It is common for the unit to have only the specific class or others that have full dependency on it.
It's good to understand that there are no actual instance functions. Everything is normal function. What sets apart from being an instance is the function having a first parameter called this which is a pointer to the instance itself. I will not go into detail here either, it's not the focus.
The exact way all this will proceed can vary in each compiler implementation and may be better suited for each operating system. But none that I know has invented something very innovative.
Consider that there may be an application that allows code injection at run time, which allows for Just-in-Time compilation, or other juggling that modifies this idea a bit (not much), but none of these artifacts are common in C ++.
Remember that these areas of spoken memory are abstract concepts. There is nothing that physically demarcates each part. In the background the static area is not much different from the others. In general, it gets a bit more protected by the operating system against changes, as indicated by the language's runtime .
There are busy spaces that many can not see. There are overhead in the allocation of objects, in addition to their own size, there are data of the types saved, there are virtual tables for dynamic polymorphism, etc. Again everything implementation dependent.
The programmer does not have to manage this memory, it has lifetime throughout the application.
Obviously several of these details can be more scrutinized in other questions.
