Re: Issue with c++ recursive method

@Rastislav Kiss, it's caused by something called stack overflow. The semantics are a bit tricky to explain, but I'll try my best.
When you start a new program, such as a game, a command prompt, or any other program out there, interpreted or otherwise, it is always allocated two things: heap memory and stack memory. Heap memory is a dynamic store of memory that can be allocated and deallocated at any time. If you create a new variable, heap memory is allocated for it. If you then delete that variable, the memory is returned to the heap for reallocation later; it is not "truly" deleted. Instead, "true" deletion happens when the program exits by either crashing or exiting normally. However, beware that heap memory allocation is random. If you allocate a variable with the address 0xfffffff7, the chance that the next variable you allocate will be at address 0xfffffff8 is incredibly slim, and rarely ever happens.
The next part is stack memory. The stack is where all the really interesting things happen. (The stack is also known as the 'call stack'.) The call stack keeps track of all the active functions (those that have been called but have not yet terminated) from the start of the program to the current point of execution, and handles allocation of all function parameters and local variables. The stack can be visualized using the plate analogy:
Consider a stack of plates in a cafeteria. Because each plate is heavy and they are stacked, you can really only do one of three things:
1) Look at the surface of the top plate
2) Take the top plate off the stack (exposing the one underneath, if it exists)
3) Put a new plate on top of the stack (hiding the one underneath, if it exists)
The stack is almost like an array, but, whereas an array lets you modify elements in any order you want, the stack is very limited. The stack only has three main operations that can be performed: topping (or peeking), pushing and popping. Topping/peeking is used when you want to look at the currently visible element on the stack. Pushing refers to adding an item onto the stack, hiding all the others underneath it. Finally, popping refers to removing the currently visible element from the stack to reveal the next one. If we go back to the plate analogy now, topping/peeking would refer to glancing at the currently visible plate that's on the stack (you know the stack is composed of multiple plates, but you can't see the others yet); pushing refers to adding another plate on top of the currently visible one, hiding it from view and revealing to you the current plate: the one you just added; and popping refers to removing the new plate you just added, perhaps, and revealing the one that was there before you added (or pushed) the plate on the stack. These actions are named for their C function equivalents: examining the stack uses a function either named top () or peek (), while pushing and popping items off of the stack are done via functions named push () and pop (). (There are Intel assembly instruction/register equivalents, too: for peeking, we have the SS/ESP/RSP registers; for popping, we have the POP (Pop a Value from the Stack), POPA/POPAD (Pop All General-Purpose Registers), POPCNT (Return the Count of Number of Bits Set to 1), and POPF/POPFD/POPFQ (Pop Stack into EFLAGS Register); for pushing, we have PUSH (Push Word, Doubleword or Quadword Onto the Stack), PUSHA/PUSHAD (Push All General-Purpose Registers), and PUSHF/PUSHFD/PUSHFQ (Push EFLAGS Register onto the Stack); and for miscellaneous operations we have CALL, RET, ENTER, and LEAVE.
But back to your issue: the reason your suffering stack overflow is that your recursive function is recursively -- or repeatedly -- calling itself. This simply makes the stack larger, as when the function is called, it is pushed onto the stack. So then it calls itself again and again, and pushes more and more of itself on the stack until there is no more stack space available, whereupon the operating system kills it.

_______________________________________________
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
  • ... AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : CAE_Jones via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Ethin via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Rastislav Kiss via Audiogames-reflector

Reply via email to