Which recursive function will cost less memory? [closed] - c++

Question

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
void func(int depth){
if(depth== 0) return;
int number(12345);
cout << number; //it does something with number
func(--depth);
}
void func2(int depth){
if(depth== 0) return;
{
int number(12345);
cout << number; //it does something with number
}
func2(--depth);
}
void main(){
func(10); //will this function cost more memory?
func2(10);//will this function cost less memory?
}
Hi. I have two functions here. Will func2 cost less memory because its number(12345) is encapsulated by "{}" so that by the time func2 calls the next iteration, number(12345) can go outside the scope and disappear?
I believe func will cost more because its number(12345) is not outside of the scope even when it reaches the next iteration?

Answer 1

Assuming we have AMD/Intel x86_64 architecture and our compiler is GCC.
Lets took assembly output (-O2 -S) and analyze:
func:
.LFB1560:
pushq %rsi
.seh_pushreg %rsi
pushq %rbx
.seh_pushreg %rbx
subq $40, %rsp
.seh_stackalloc 40
.seh_endprologue
movl %ecx, %ebx
testl %ecx, %ecx
je .L3
movq .refptr._ZSt4cout(%rip), %rsi
.p2align 4,,10
.L5:
movl $12345, %edx
movq %rsi, %rcx
call _ZNSolsEi
subl $1, %ebx
jne .L5
.L3:
addq $40, %rsp
popq %rbx
popq %rsi
ret
.seh_endproc
func2:
.LFB2046:
pushq %rsi
.seh_pushreg %rsi
pushq %rbx
.seh_pushreg %rbx
subq $40, %rsp
.seh_stackalloc 40
.seh_endprologue
movl %ecx, %ebx
testl %ecx, %ecx
je .L10
movq .refptr._ZSt4cout(%rip), %rsi
.p2align 4,,10
.L12:
movl $12345, %edx
movq %rsi, %rcx
call _ZNSolsEi
subl $1, %ebx
jne .L12
.L10:
addq $40, %rsp
popq %rbx
popq %rsi
ret
.seh_endproc
So as you can see, both functions completely identical to each other.

Answer 2

Well, GCC 6.2.1 with -O0 produces the same assembly for both of your functions.
What closing braces do, within a single function, is determine when destructors are called. For instance consider the following:
struct Number {
int n;
~Number() { std::cout << "~" << n << ", "; }
};
void func(int depth){
if(depth== 0) return;
Number number{depth};
std::cout << number.n << ", ";
func(--depth);
}
void func2(int depth){
if(depth== 0) return;
{
Number number{depth};
std::cout << number.n << ", ";
}
func2(--depth);
}
int main(int, char**) {
std::cout << "Calling func. \n";
func(10);
std::cout << "\n\n";
std::cout << "Calling func1. \n";
func2(10);
}
This outputs
Calling func.
10, 9, 8, 7, 6, 5, 4, 3, 2, 1, ~1, ~2, ~3, ~4, ~5, ~6, ~7, ~8, ~9, ~10,
Calling func1.
10, ~10, 9, ~9, 8, ~8, 7, ~7, 6, ~6, 5, ~5, 4, ~4, 3, ~3, 2, ~2, 1, ~1,
So if number were some std::vector or maybe std::ifstream, then yes those braces would be quite necessary.

Answer 3

Why speculate?
Since your depth is small (i.e. 10 is small), you should run your MCVE.
Just two small changes will provide info to determine your answer:
a) cout the address of number (in addition to the value).
b) instead of a const number, fetch something that is not constant. (see below)
#include <iostream>
#include <iomanip>
class T595_t
{
public:
T595_t() = default;
~T595_t() = default;
int exec(int , char**)
{
std::cout << "\n func1(10)" << std::flush;
func1(10);
std::cout << "\n func2(10)" << std::flush;
func2(10);
return 0;
}
private: // methods
void func1(int depth)
{
if(depth== 0) return;
uint64_t number(time(nullptr));
std::cout << "\n " << depth
<< " " << number << " " << &number;
func1(--depth);
}
void func2(int depth)
{
if(depth== 0) return;
{
uint64_t number(std::time(nullptr));
std::cout << "\n " << depth
<< " " << number << " " << &number;
}
func2(--depth);
}
}; // class T595_t
int main(int argc, char* argv[])
{
T595_t t595;
return t595.exec(argc, argv);
}
With output (on Ubuntu 17.10, using g++ version 7.2.0.)
func1(10)
10 1523379410 0x7ffd449d7d90
9 1523379410 0x7ffd449d7d60
8 1523379410 0x7ffd449d7d30
7 1523379410 0x7ffd449d7d00
6 1523379410 0x7ffd449d7cd0
5 1523379410 0x7ffd449d7ca0
4 1523379410 0x7ffd449d7c70
3 1523379410 0x7ffd449d7c40
2 1523379410 0x7ffd449d7c10
1 1523379410 0x7ffd449d7be0
func2(10)
10 1523379410 0x7ffd449d7d90
9 1523379410 0x7ffd449d7d60
8 1523379410 0x7ffd449d7d30
7 1523379410 0x7ffd449d7d00
6 1523379410 0x7ffd449d7cd0
5 1523379410 0x7ffd449d7ca0
4 1523379410 0x7ffd449d7c70
3 1523379410 0x7ffd449d7c40
2 1523379410 0x7ffd449d7c10
1 1523379410 0x7ffd449d7be0
When unoptimized, the code gen for each funcX seems to do the same thing. And since the code completes in less than a second, all the values (of number) are the same.