That disables a whole pile of the potential optimisations, of course. You could define jackApples as a "static variable" (as opposed to making it eg. a field in a class or struct):

namespace {
  auto jackApples = 3;
}

auto setJackApples(int newJackApples) -> void {
  jackApples = newJackApples;
}

The most obvious consequence of this is that jackApples now has an address in memory, which you could find out with &jackApples. Executable programs are arranged into a sequence of blocks when they're compiled, which have some historical names based on what they used to be for:

• the header section, which identifies what kind of program it is, and where the other blocks start
• the text section, which contains all of the executable code, and which might be made read-only by the OS.
• the data section, which contains variables that have a known value at startup
• the bss section, which contains variables that we know will exist but don't have a value. Might be zero'd out by the OS, might contain unknown leftover values.
• after those sections, the heap starts. This is where we allocate anything that we don't know the size of at startup. Your program will ask the operating system to "move the end of the heap" if it needs some space to eg. load a picture from disk that your program will then use.
• at the very end of memory, and counting down, the OS will allocate "the stack". This is where all of your variables that are local to each function are kept - it's the "working area"

Because it's statically allocated, jackApples will be in the data section; if you opened up the executable with a hex editor, you'd see a 3 there.

getTheNumberOfApples() will be optimised by the compiler to return the contents of the memory address plus 4. That still counts as a very simple and short function, and it's quite likely that the compiler would inline it and remove the initial function. The actual process of calling a function is to:

• push the address of where we are in the program onto the stack
• push any variables used by the function onto the stack (which would be none, in this case)
• if on x86 / x64, do a whole pile of stack alignment operations :-(
• set the address of "where we are in the program" to the address of the function
• push some extra space on the stack for all the variables used by the function
• run all the code in the function
• put the result of the function into one of the CPU registers
• pop all of our "working space" back off the stack again
• pop the address of "where we came from" off of the stack, and make that the place that we'll continue running the program for

That takes a while, and worse - modern CPUs will try to "pipeline" all the instructions that they know are coming so that it all runs faster. Jumping to a function might break that pipeline, causing a "stall", which slows things down enormously. Much better to inline short functions - the fact that the value is "number in memory address plus four" might be optimised away a little wherever it's used, too.