let's assume we create 3 integers.each takes 1 byte of space
int x=4 (1 byte)
int y=4 (1 byte)
int z=6 (1 byte)
when we launch the program after compiling, does the program take 3 bytes of RAM space?
the more declarations ,the more momory it takes in RAM??
2 nd question: what decides the capacity of a compiled program (exe). I mean HDD space that it would take. 100MB,10MB like....
the more declarations ,the more momory it takes in RAM??
The usual situation is that each process is given a certain amount of stack space that the program can use for things like local variables and function call frames. Assuming those integers are stack objects then they'd be rolled up into the stack size and wouldn't increase the memory footprint of the program at runtime.
But there are other types of objects. Notable is static data, where the size is rolled up into the executable itself and if large, could have an impact on how much memory the running process uses when the executable is loaded.
what decides the capacity of a compiled program (exe).
Code instructions and static data (the so called text and data segments) are the two biggies for the size of an executable. Also note that static linking vs. dynamic linking will affect the size of the file because with the former libraries are stored within the executable.
You might consider looking into the Portable Executable (PE) format for Windows and the Executable and Linkable Format (ELF) format for POSIX to get an idea of how operating systems structure an executable file.
The usual situation is that each process is given a certain amount of stack space that the program can use for things like local variables and function call frames. Assuming those integers are stack objects then they'd be rolled up into the stack size and wouldn't increase the memory footprint of the program at runtime.But there are other types of objects. Notable is static data, where the size is rolled up into the executable itself and if large, could have an impact on how much memory the running process uses when the executable is loaded.
But there are other types of objects. Notable is static data, where the size is rolled up into the executable itself and if large, could have an impact on how much memory the running process uses when the executable is loaded.
what :O .O.o ????
what :O .O.o ????
That's not a meaningful question. I'd like to think that you understood at least some subset of the words I used, so please specify which part of the explanation doesn't make sense and why. I'm happy to elaborate, if I have a clue of what to elaborate on.
Also keep in mind that local variables may not even take up space on the stack. Depending on the architecture, instruction set, compiler, etc., local variables may only exist in registers.
It should also be pointed out, that it's not only variables that take up space - temporary values do too. So if you're thinking about removing variable declarations in favor of larger expressions in order to save memory (or registers), don't - it won't work.
so please specify which part of the explanation doesn't make sense and why
when we launch the program after compiling, does the program take 3 bytes of RAM space?
the more declarations ,the more momory it takes in RAM??
can I get simple yes no answers and a small description to both answers?
Assuming those integers are stack objects then they'd be rolled up into the stack size and wouldn't increase the memory footprint of the program at runtime.
tannks. those are too hard for me. I am new to C++ .very
can I get simple yes no answers and a small description to both answers?
I can certainly give you simple yes and no answers, but they'd be wrong because it's not that simple. Different variable locations result in different storage areas, and thus different RAM usage.
when we launch the program after compiling, does the program take 3 bytes of RAM space?
At least 3 bytes, yes. Exactly 3 bytes, no.
the more declarations ,the more momory it takes in RAM??
No. Let's say you get a big box and toss a few small things into it, if you want to add more things, do you get a bigger box? No, you just toss the new things into the mostly empty big box. That's how the process stack works.
hmmmm......thanks
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.