[CodeBreather]

Whats the difference between:

++value;

and

value++;

i know that the ++ before the variable is supposed to increment the variables value "before an operation"(i think thats the right way to word it) and ++ after the variable means "after an operation".

i tend to use value++ instead of writting value += 1. So what exactly is the difference? Maybe i just havent ran into a situation where it mattered. I dont know.

So thanks in advance for your time and help, have a great day.

[ButchDean]

Please run this code:

#include <iostream>
using namespace std;

int main()
{
	int i = 0;
	int j;

	j = ++i;

	cout << j << endl;

	{
		int i = 0;
		int j;

		j = i++;

		cout << j << endl;
	}

	return 0;
}

What do you notice between pre- and post-increment?

[CodeBreather]

ok so in your example it changes the value of i pre and post assightment. but to be more specific would it be true to say that the pre-increment(or decrement too) happens before the variable is used in the expression and the post-increment is after the variable is used in the expression?

[ButchDean]

For the pre-increment the output is 1, and the post-increment the output is 0, telling you that the post-increment to i is not stored to j; the original value of zero is stored prior to incrementing.

[ishkabible]

#include <iostream>
using namespace std;

int main()
{
	{
		int i = 0;
		int j;

		j = ++i;

		cout << j << endl;
	}
	{
		int i = 0;
		int j;

		j = i++;

		cout << j << endl;
	}

	return 0;
}

sorry, shadowing irks me.

This post has been edited by ishkabible: 10 April 2012 - 05:09 PM

[CodeBreather]

@ishkabible
not to steer this in a different direction but "shadowing"?

[ishkabible]

if a variable is declared twice in the same scope the second variables is said to "shadow" the first becuase it is used instead of the first. hence this is know as "shadowing". Its behavior is well defined so butch's program is 100% valid but it's a source of bugs and confusion and there really isn't any reason for it other than to eliminate a few easily avoidable library incompatibilities.

[ButchDean]

It's not declared twice in the same scope! Where did that come from?!

Secondly, the method is also used to keep code inline avoiding a second function call. Don't discredit a perfectly good method.

This post has been edited by ButchDean: 10 April 2012 - 05:29 PM

[CodeBreather]

ok that makes since but i thought that since he had the second set of i and j ints in a seperate {} group i didnt think it mattered even though i wouldnt have written it like that i still see the reason he did it like that i doubt he writes like that in his real code but for the sake of the example it compiled correctly and still taught the lesson that was needed.

So thanks to both of you i appreciate it.

[ButchDean]

Yes, code like this does appear in the real world.

[ishkabible]

Quote

It's not declared twice in the same scope! Where did that come from?!

the second declarations of 'i' and 'j' in your original code, shadow the first. I was a being a bit misleading by saying 'same', I should have said when the same variable is declared once in a parent scope and again in a child scope, the variable declared in the child scope shadows the variable declared in the parent scope. I've always thought of the parent scope as a subset of its child scopes which is why I used that phrasing.

Quote

Secondly, the method is also used to keep code inline avoiding a second function call. Don't discredit a perfectly good method.

I don't understand how that works. could you elaborate?

[ButchDean]

ishkabible, on 11 April 2012 - 04:13 AM, said:

Quote

Secondly, the method is also used to keep code inline avoiding a second function call. Don't discredit a perfectly good method.

I don't understand how that works. could you elaborate?

The code I originally posted gives this assembler sequence:

Spoiler

#include <iostream>
using namespace std;

int main()
{
00411490  push        ebp  
00411491  mov         ebp,esp 
00411493  sub         esp,0F0h 
00411499  push        ebx  
0041149A  push        esi  
0041149B  push        edi  
0041149C  lea         edi,[ebp-0F0h] 
004114A2  mov         ecx,3Ch 
004114A7  mov         eax,0CCCCCCCCh 
004114AC  rep stos    dword ptr es:[edi] 
	int i = 0;
004114AE  mov         dword ptr [i],0 
	int j;

	j = ++i;
004114B5  mov         eax,dword ptr [i] 
004114B8  add         eax,1 
004114BB  mov         dword ptr [i],eax 
004114BE  mov         ecx,dword ptr [i] 
004114C1  mov         dword ptr [j],ecx 

	cout << j << endl;
004114C4  mov         esi,esp 
004114C6  mov         eax,dword ptr [__imp_std::endl (41A324h)] 
004114CB  push        eax  
004114CC  mov         edi,esp 
004114CE  mov         ecx,dword ptr [j] 
004114D1  push        ecx  
004114D2  mov         ecx,dword ptr [__imp_std::cout (41A328h)] 
004114D8  call        dword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (41A32Ch)] 
004114DE  cmp         edi,esp 
004114E0  call        @ILT+400(__RTC_CheckEsp) (411195h) 
004114E5  mov         ecx,eax 
004114E7  call        dword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (41A310h)] 
004114ED  cmp         esi,esp 
004114EF  call        @ILT+400(__RTC_CheckEsp) (411195h) 

	{
		int i = 0;
004114F4  mov         dword ptr [i],0 
		int j;

		j = i++;
004114FB  mov         eax,dword ptr [i] 
004114FE  mov         dword ptr [j],eax 
00411501  mov         ecx,dword ptr [i] 
00411504  add         ecx,1 
00411507  mov         dword ptr [i],ecx 

		cout << j << endl;
0041150A  mov         esi,esp 
0041150C  mov         eax,dword ptr [__imp_std::endl (41A324h)] 
00411511  push        eax  
00411512  mov         edi,esp 
00411514  mov         ecx,dword ptr [j] 
00411517  push        ecx  
00411518  mov         ecx,dword ptr [__imp_std::cout (41A328h)] 
0041151E  call        dword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (41A32Ch)] 
00411524  cmp         edi,esp 
00411526  call        @ILT+400(__RTC_CheckEsp) (411195h) 
0041152B  mov         ecx,eax 
0041152D  call        dword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (41A310h)] 
00411533  cmp         esi,esp 
00411535  call        @ILT+400(__RTC_CheckEsp) (411195h) 
	}

	return 0;
0041153A  xor         eax,eax 
}
0041153C  pop         edi  
0041153D  pop         esi  
0041153E  pop         ebx  
0041153F  add         esp,0F0h 
00411545  cmp         ebp,esp 
00411547  call        @ILT+400(__RTC_CheckEsp) (411195h) 
0041154C  mov         esp,ebp 
0041154E  pop         ebp  
0041154F  ret              

Now, if I revise the code to include a function call...

#include <iostream>
using namespace std;

void TestFunc(int p)
{
	int j;

	j = p;

	cout << j << endl;
}

int main()
{
	int i = 0;

	TestFunc(++i);

	i = 0;

	TestFunc(i++);

	return 0;
}

The following disassembly is generated:

Spoiler

int main()
{
00411560  push        ebp  
00411561  mov         ebp,esp 
00411563  sub         esp,0D0h 
00411569  push        ebx  
0041156A  push        esi  
0041156B  push        edi  
0041156C  lea         edi,[ebp-0D0h] 
00411572  mov         ecx,34h 
00411577  mov         eax,0CCCCCCCCh 
0041157C  rep stos    dword ptr es:[edi] 
	int i = 0;
0041157E  mov         dword ptr [i],0 

	TestFunc(++i);
00411585  mov         eax,dword ptr [i] 
00411588  add         eax,1 
0041158B  mov         dword ptr [i],eax 
0041158E  mov         ecx,dword ptr [i] 
00411591  push        ecx  
00411592  call        TestFunc (411253h) 
00411597  add         esp,4 

	i = 0;
0041159A  mov         dword ptr [i],0 

	TestFunc(i++);
004115A1  mov         eax,dword ptr [i] 
004115A4  mov         dword ptr [ebp-0D0h],eax 
004115AA  mov         ecx,dword ptr [i] 
004115AD  add         ecx,1 
004115B0  mov         dword ptr [i],ecx 
004115B3  mov         edx,dword ptr [ebp-0D0h] 
004115B9  push        edx  
004115BA  call        TestFunc (411253h) 
004115BF  add         esp,4 

	return 0;
004115C2  xor         eax,eax 
}

This is less efficient for several reasons:

1. call TestFunc (411253h) is of course slower than having inline code as before.
2. I'm passing by value, the value is being copied prior to the function call in the sequence:

004115A1  mov         eax,dword ptr [i] 
004115A4  mov         dword ptr [ebp-0D0h],eax 
004115AA  mov         ecx,dword ptr [i] 
004115AD  add         ecx,1 
004115B0  mov         dword ptr [i],ecx 
004115B3  mov         edx,dword ptr [ebp-0D0h] 
004115B9  push        edx  

That is my point.

[ishkabible]

What? how on earth does my example prevent a person from manually inlining their code?

In fact, I tested it; our two programs produce EXACTLY the same output on GCC

g++ -O3 -S test.c -o test.asm
produces the following for *both* programs

	.file	"test.c"
	.text
	.p2align 2,,3
	.def	___tcf_0;	.scl	3;	.type	32;	.endef
___tcf_0:
LFB990:
	.cfi_startproc
	subl	$28, %esp
	.cfi_def_cfa_offset 32
	movl	$__ZStL8__ioinit, (%esp)
	call	__ZNSt8ios_base4InitD1Ev
	addl	$28, %esp
	.cfi_def_cfa_offset 4
	ret
	.cfi_endproc
LFE990:
	.def	___main;	.scl	2;	.type	32;	.endef
	.section	.text.startup,"x"
	.p2align 2,,3
	.globl	_main
	.def	_main;	.scl	2;	.type	32;	.endef
_main:
LFB983:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	andl	$-16, %esp
	subl	$16, %esp
	call	___main
	movl	$1, 4(%esp)
	movl	$__ZSt4cout, (%esp)
	call	__ZNSolsEi
	movl	%eax, (%esp)
	call	__ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
	movl	$0, 4(%esp)
	movl	$__ZSt4cout, (%esp)
	call	__ZNSolsEi
	movl	%eax, (%esp)
	call	__ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
	xorl	%eax, %eax
	leave
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
LFE983:
	.p2align 2,,3
	.def	__GLOBAL__sub_I_main;	.scl	3;	.type	32;	.endef
__GLOBAL__sub_I_main:
LFB991:
	.cfi_startproc
	subl	$28, %esp
	.cfi_def_cfa_offset 32
	movl	$__ZStL8__ioinit, (%esp)
	call	__ZNSt8ios_base4InitC1Ev
	movl	$___tcf_0, (%esp)
	call	_atexit
	addl	$28, %esp
	.cfi_def_cfa_offset 4
	ret
	.cfi_endproc
LFE991:
	.section	.ctors,"w"
	.align 4
	.long	__GLOBAL__sub_I_main
.lcomm __ZStL8__ioinit,1,1
	.def	__ZNSt8ios_base4InitD1Ev;	.scl	2;	.type	32;	.endef
	.def	__ZNSolsEi;	.scl	2;	.type	32;	.endef
	.def	__ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_;	.scl	2;	.type	32;	.endef
	.def	__ZNSt8ios_base4InitC1Ev;	.scl	2;	.type	32;	.endef
	.def	_atexit;	.scl	2;	.type	32;	.endef

the only difference is that my addition to yours get's rid of shadowing.

[ButchDean]

ishkabible, on 12 April 2012 - 02:49 AM, said:

What? how on earth does my example prevent a person from manually inlining their code?

Actually, I didn't say that. Please reread.

ishkabible, on 12 April 2012 - 02:49 AM, said:

In fact, I tested it; our two programs produce EXACTLY the same output on GCC

g++ -O3 -S test.c -o test.asm
produces the following for *both* programs

... snip ...

the only difference is that my addition to yours get's rid of shadowing.

You're making a point against something I didn't say.

My point was that you don't like shadowing, choosing to modify code that works perfectly out personal preference saying that it was bad practice. I pointed out reasons why such methods are justifiable. That's all.