- Forum
- General C++ Programming
- Asking questions about functions
Asking questions about functions
Hello, i decided to begin learn basics of functions in C++ and i have a questions. I have pretty smooth knowing of what lying under functions in C++. But i know that executable of a function stores in CODE segment. Im sorry if these question smooth for you.
1) If there is a function prototype with parameters, are these parameters just abstract variables? It isnt declaration or definition right? But when the function called with passing to her arguments, then at place where function stands definition statement of those parameters actually happens with received value assigment??
2) I've heard about stack frame ( have a bit knowledge about it ), where local variables, parameters and return point stores, right?. What object first goes in a stack, i mean some local variable, parameters or point of return? What is actually point of return?
3) Why if i have for example a function prototype in my programm and i try to call this function from main(), compiler will do his work fine? I didnt include cpp for this function
4) What is obj file? And how is some function actually being compiled?
5) If i have a header file with function prototypes, why it isnt important to include cpp file at compile-time?
6) Am i get it wrong, but executable code of function stores in CODE segment, while her local variables at Stack segment, etc ? What is executable code?
Thanks
1) If there is a function prototype with parameters, are these parameters just abstract variables? It isnt declaration or definition right? But when the function called with passing to her arguments, then at place where function stands definition statement of those parameters actually happens with received value assigment??
2) I've heard about stack frame ( have a bit knowledge about it ), where local variables, parameters and return point stores, right?. What object first goes in a stack, i mean some local variable, parameters or point of return? What is actually point of return?
3) Why if i have for example a function prototype in my programm and i try to call this function from main(), compiler will do his work fine? I didnt include cpp for this function
4) What is obj file? And how is some function actually being compiled?
5) If i have a header file with function prototypes, why it isnt important to include cpp file at compile-time?
6) Am i get it wrong, but executable code of function stores in CODE segment, while her local variables at Stack segment, etc ? What is executable code?
Thanks
Last edited on
| 1) If there is a function prototype with parameters, are these parameters just abstract variables? It isnt declaration or definition right? But when the function called with passing to her arguments, then at place where function stands definition statement of those parameters actually happens with received value assigment?? |
A function prototype is merely a declaration which specifies that the named function is defined somewhere. When that function is called, any arguments are bound to the parameters of the function, and the definition statement runs.
| 2.) I've heard about stack frame ( have a bit knowledge about it ), where local variables, parameters and return point stores, right?. What object first goes in a stack, i mean some local variable, parameters or point of return? What is actually point of return? |
The details are part of the application binary interface (or ABI), which differs between architecture, data model, and operating system. If there is no operating system, the calling convention is up to the compiler and linker instead of the OS.
Specifically, the function call order is called calling convention. For example, my x86-64 computer uses the ILP32 data model, runs Linux, and so follows the System V AMD64 ABI, which is documented here:
https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
See §3.2.
You can also just search online, e.g.:
https://en.wikipedia.org/wiki/X86_calling_conventions
Last edited on
Your questions are very dependent on the underlying architecture that you are compiling for. I will answer them in a very general sense as each has architecture has their own individual quirks.
1) Neither function prototypes or functions exist in assembly/machine code. Functions are a language construct. Function calls are typically mapped to processor jumps (dubbed branches in the case of ARM processors), which literally changes the value of a program counter to a different address. This usually (99% of the time) done in a well defined and standardized fashion called a calling convention, though it does not have to be. This is defined in the platform's ABI.
2) This depends on the ABI.
3) Because the compiler only transforms C++ code to machine code. When the compiler encounters a place where a function is called that isn't defined within the .cpp file, it outputs a dummy instruction in that location and keeps track of where it is in a special type of record called a “relocation”.
4) An object file is a file that contains data (which can be executable code) and relocations for the unresolved functions. It is the result of running a valid source file through the compiler. On link time, the linker grabs all object files, reads their data, resolves the relocations, and outputs an executable with it all.
5) Because the compiler doesn't need to know that much information. It will just add a relocation to the resulting object file.
6) Yes, you are correct. Executable code is just data that is interpreted as instructions for the processor. The distinction is there for primarily security/debugging purposes.
https://en.wikipedia.org/wiki/Application_binary_interface
https://en.wikipedia.org/wiki/Calling_convention
https://en.wikipedia.org/wiki/Compiler
https://en.wikipedia.org/wiki/Linker_(computing)
1) Neither function prototypes or functions exist in assembly/machine code. Functions are a language construct. Function calls are typically mapped to processor jumps (dubbed branches in the case of ARM processors), which literally changes the value of a program counter to a different address. This usually (99% of the time) done in a well defined and standardized fashion called a calling convention, though it does not have to be. This is defined in the platform's ABI.
2) This depends on the ABI.
3) Because the compiler only transforms C++ code to machine code. When the compiler encounters a place where a function is called that isn't defined within the .cpp file, it outputs a dummy instruction in that location and keeps track of where it is in a special type of record called a “relocation”.
4) An object file is a file that contains data (which can be executable code) and relocations for the unresolved functions. It is the result of running a valid source file through the compiler. On link time, the linker grabs all object files, reads their data, resolves the relocations, and outputs an executable with it all.
5) Because the compiler doesn't need to know that much information. It will just add a relocation to the resulting object file.
6) Yes, you are correct. Executable code is just data that is interpreted as instructions for the processor. The distinction is there for primarily security/debugging purposes.
https://en.wikipedia.org/wiki/Application_binary_interface
https://en.wikipedia.org/wiki/Calling_convention
https://en.wikipedia.org/wiki/Compiler
https://en.wikipedia.org/wiki/Linker_(computing)
Last edited on
| mbozzi wrote: |
|---|
| System V AMD64 ABI, which is documented here: https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf |
btw a newer version is available at its home base, https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
So many new things to me came up... I think im going to ask some last questions and then I will go back to book. Thank you guys! :)
So, when i compile my programm its going to be an object file? Am i right that for every function defined the compiler will produce obj file after his work? Could be an object file consists of a executable code in code segment, variables that stores in stack segment and so on? Maybe i am wrong but i've heard about 5 memort segments that can keep programm data, so if i take these 5 segments together they will lead me to the whole program (obj)?
Do you mean that he will find himself cpp file that connected to header file and put header code inside cpp? Im sorry, im new xD
| 4) An object file is a file that contains data (which can be executable code) and relocations for the unresolved functions. It is the result of running a valid source file through the compiler. On link time, the linker grabs all object files, reads their data, resolves the relocations, and outputs an executable with it all. |
So, when i compile my programm its going to be an object file? Am i right that for every function defined the compiler will produce obj file after his work? Could be an object file consists of a executable code in code segment, variables that stores in stack segment and so on? Maybe i am wrong but i've heard about 5 memort segments that can keep programm data, so if i take these 5 segments together they will lead me to the whole program (obj)?
| 5) Because the compiler doesn't need to know that much information. It will just add a relocation to the resulting object file. |
Do you mean that he will find himself cpp file that connected to header file and put header code inside cpp? Im sorry, im new xD
4) yes and no. Compile does give an object file, but it may also link which renders an executable file. A lot of IDEs blur the lines between these 2 terms (compile and link) by doing it all at once etc. Strictly speaking, compile will go to object files, yes. Object files are not generally executable. The linker adds some of the stuff needed to execute. Memory segments may be a dos / intel cpu platform thing, not sure that all systems work that way. Object files are sort of an intermediate step, you can't do much with them unless you know a LOT about the format for your compiler and system.
5) not sure what this is about really. But an object file is generally injectable -- that is, the linker can stick it more or less intact into the executable, with some memory address corrections. The compile process does tie the header and cpp together, but at this point, the code is binary soup, nearly machine language format, it may even BE machine language format but its not wrapped for execution, yet.
5) not sure what this is about really. But an object file is generally injectable -- that is, the linker can stick it more or less intact into the executable, with some memory address corrections. The compile process does tie the header and cpp together, but at this point, the code is binary soup, nearly machine language format, it may even BE machine language format but its not wrapped for execution, yet.
Topic archived. No new replies allowed.