Re: Increment and Decrement Operators - C / C++ / MFC Discussion Boards

Re: Increment and Decrement Operators

Richard MacCutchan7-Jan-14 2:48

Richard MacCutchan

7-Jan-14 2:48

Yes. My comments were an over-simplification, but it is still worth avoiding expressions of that sort.

Veni, vidi, abiit domum

Re: Increment and Decrement Operators

Marco Bertschi7-Jan-14 9:41

Marco Bertschi

7-Jan-14 9:41

Richard MacCutchan wrote:
but it is still worth avoiding expressions of that sort.

Every respectable Dev must avoid it.
By the way, my comment was intended to be an addition to yours.

Veni, vidi, caecus | Everything summarizes to Assembly code

Re: Increment and Decrement Operators

Richard MacCutchan7-Jan-14 21:55

Richard MacCutchan

7-Jan-14 21:55

Marco Bertschi wrote:
my comment was intended to be an addition to yours.

Yes, that was how I understood it. Thumbs Up | :thumbsup:

Veni, vidi, abiit domum

Re: Increment and Decrement Operators

David Crow7-Jan-14 16:43

David Crow

7-Jan-14 16:43

sukanta kumar mangal wrote:
As written the last line gives output undefine i think its wrong .it will give correct output as 23.
If u had checked then u already got the result.
here i will explan u how it's work..

At a minimum, you might want to brush up on sequence points.

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous

Re: Increment and Decrement Operators

Ron Beyer7-Jan-14 17:27

Ron Beyer

7-Jan-14 17:27

I'll explain why the behavior is undefined...

This has a lot to do with operator precedence[^], see the ++ as a prefix operator has an equal precedence to the + operator. Its up to the compiler to determine which one to evaluate first, since they are at an equal precedence there is no universal "++(pre) before +".

However, ++ as a postfix operator has a higher precedence than the prefix operator, so for example:

i = 10
result = ++i + i++;

Turns into
result = ++i + 11;

Now, the compiler really doesn't care which one is evaluated first, the + or the ++. Each one is free to implement it as they see fit, so it might be 22 or it might be 23, it depends on which one the programmer handled first.

Re: Increment and Decrement Operators

Suk@nta7-Jan-14 19:27

Suk@nta

7-Jan-14 19:27

no no..in any compiler prefix operator execute first than postfix.
postfix will execute after value returned or assigned to some variable..

Re: Increment and Decrement Operators

Richard MacCutchan7-Jan-14 21:59

Richard MacCutchan

7-Jan-14 21:59

See http://msdn.microsoft.com/en-us/library/126fe14k.aspx[^].

Veni, vidi, abiit domum

Re: Increment and Decrement Operators

Stefan_Lang10-Jan-14 2:49

Stefan_Lang

10-Jan-14 2:49

Am I the only one to spot that at least one of the problems in your last line is not related to increment and decrement at all? The operator+ which is invoked here needs to evaluate both of its operands, but it's undefined whether the first or second operand is evaluated first - the compiler may choose to do either!

So, if the compiler evaluates the first operand first, the following happens:

C++

i = 10;
i = i + 1; // pre-increment of the first argument
first_arg = i;
second_arg = i;
i = i + 1; // post-increment of the second argument
result = first_arg + second_arg; // 11 + 11

Now consider the same on the assumption the compiler evaluates the second operand first:

C++

i = 10;
second_arg = i;
i = i + 1; // post-increment of second argument
i = i + 1; // pre-increment of first argument
first_arg = 1;
result = first_arg + second_arg; // 12 + 10

In this case, the results are the same, but that is just by coincidence - if you had used subtraction in stead of addition you'd be in for a surprise!

You may want to check http://en.cppreference.com/w/cpp/language/eval_order[^] for further information regarding both function argument evaluation and increment/decrement.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Re: Increment and Decrement Operators

Richard MacCutchan10-Jan-14 3:33

Richard MacCutchan

10-Jan-14 3:33

That was exactly my point.

Veni, vidi, abiit domum

Message Closed

7-Jan-14 0:28

Suk@nta

7-Jan-14 0:28

Message Closed

Re: Increment and Decrement Operators

OriginalGriff8-Jan-14 1:59

OriginalGriff

8-Jan-14 1:59

You are making unwarranted assumptions! Laugh | :laugh:

It's more complex that that - Richard is right, you shouldn't mix 'em - see my post below for some compiler nasties...

Never underestimate the power of stupid things in large numbers
--- Serious Sam

Re: Increment and Decrement Operators

Suk@nta9-Jan-14 18:17

Suk@nta

9-Jan-14 18:17

I know increment and decrement operator depend on compiler. actually i had tried it in dev c++.

Re: Increment and Decrement Operators

OriginalGriff9-Jan-14 22:10

OriginalGriff

9-Jan-14 22:10

If you know that something is compiler dependant, then you can't say "it is like this" - because there is a very good chance that the other person is not using the same compiler! Laugh | :laugh:

Never underestimate the power of stupid things in large numbers
--- Serious Sam

Re: Increment and Decrement Operators

Suk@nta10-Jan-14 3:52

Suk@nta

10-Jan-14 3:52

Thanks

Re: Increment and Decrement Operators

Marco Bertschi7-Jan-14 1:31

Marco Bertschi

7-Jan-14 1:31

C++

int i = 0;

C++

i++;

Means that i is incremented after the statements execution

C++

++i;

Means that i is incremented before the statements execution

The same is applicable on i-- and --i

Veni, vidi, caecus | Everything summarizes to Assembly code

Re: Increment and Decrement Operators

tgsb7-Jan-14 20:38

tgsb

7-Jan-14 20:38

O God....wow I am not the only one who is confused? This is the problem I specified when I started this thread, I got surprising answers when i solve these inc and dec problems.So who is correct please tell me and whom explaination I go with to pursue my learning on this topic?

Re: Increment and Decrement Operators

OriginalGriff8-Jan-14 1:56

OriginalGriff

8-Jan-14 1:56

Pre- and post- fix increment and decrement operations are pretty easy in theory, it's only when people get creative that you get problems in practice.
Basically, a prefix (++i or --i) says to increase or decrease the value before you use the variable, so the variable has the new value immediately:

C++

i = 10;
x = ++i + 5;

Can be read as:

C++

i = 10;
i = i + 1;
x = i + 5;

and similarly for the -- version:

C++

i = 10;
x = --i + 5;

Can be read as:

C++

i = 10;
i = i - 1;
x = i + 5;

The postfix version (i++ or i--) does the same thing, but after the variable has been used:

C++

i = 10;
x = i++ + 5;

Can be read as:

C++

i = 10;
x = i + 5;
i = i + 1;

And similarly

C++

i = 10;
x = i-- + 5;

Can be read as:

C++

i = 10;
x = i + 5;
i = i - 1;

The trouble comes when you start mixing operations on the same line (as Richard said):

C++

i = 10;
x = ++i + i++;

The problem is that the language specification does not define exactly when pre- and post- fix operations should occur! Which means that it's implementation specific exactly what you get as a result: The value of i should always be the same: 12 but the value of x can be different depending on the compiler (and to an extent on the target processor - ARM for example has built in pre- and post- fix increment and decrement to it's "machine code" LOAD operations, so it would be quite likely that an efficient compiler would use them directly)

Should it be executed as:

C++

i = 10;
i = i + 1;
x = i + i;
i = i + 1;

Which gives the result 22
or as

C++

i = 10;
i1 = i;
i = i + 1;
x = i1 + i;
i = i + 1;

Which gives 21
Or as

C++

i = 10;
i1 = i;
i = i + 1;
x = i + i1;
i = i + 1;

which also gives 21 by a different route
And bear in mind that the compiler does not have to evaluate the two operands of "+" in left to right order, so it could even give some very strange and unexpected results! Like 23...
So avoid combining them: use them for "simple expressions" such as incrementing an array index each time round a loop, but don't get fancy, or your code may well fail in interesting ways... Laugh | :laugh:

Never underestimate the power of stupid things in large numbers
--- Serious Sam

Re: Increment and Decrement Operators

tgsb8-Jan-14 19:43

tgsb

8-Jan-14 19:43

Thanks sir for highlighting its deep concepts related to the compiler. I hope now I am able to solve these question without getting shocked by their answers. Appreciate all your responses.

Re: Increment and Decrement Operators

OriginalGriff8-Jan-14 19:44

OriginalGriff

8-Jan-14 19:44

You're welcome!

Never underestimate the power of stupid things in large numbers
--- Serious Sam

CTreeCtrl::GetNextSiblingItem never null

dliviu6-Jan-14 1:15

dliviu

6-Jan-14 1:15

Hello!

I just want to pass through all the siblings of a parent CTreeCtrl node.

So I do something like the code from msdn http://msdn.microsoft.com/en-us/library/xfh3f9zt.aspx[^]:

C++

if (m_TreeCtrl.ItemHasChildren(hmyItem))
{
   HTREEITEM hItem = m_TreeCtrl.GetChildItem(hmyItem);

   while (hItem != NULL)
   {
      hItem = m_TreeCtrl.GetNextSiblingItem(hItem);
   }
}

The problem is that, GetNextSiblingItem never returns null. When all the siblings are passed through and the function should return null, it just returns the first sibling. So it enters into an infinite loop. I just cannot understand why it does so.

Re: CTreeCtrl::GetNextSiblingItem never null

_Flaviu7-Jan-14 20:24

_Flaviu

7-Jan-14 20:24

I had used this code several time without any problem ... so, check your code again, eventually load the tree with few simple test items ...

Re: CTreeCtrl::GetNextSiblingItem never null

dliviu8-Jan-14 0:55

dliviu

8-Jan-14 0:55

OK, thanks.

Re: CTreeCtrl::GetNextSiblingItem never null

_Flaviu8-Jan-14 1:27

_Flaviu

8-Jan-14 1:27

I had created an dialog based project, where I put an tree control, named m_Tree, and in OnInitDialog I wrote following code:

C++

HTREEITEM hItem = m_Tree.InsertItem(_T("One"));
m_Tree.InsertItem(_T("Test1"), hItem);
m_Tree.InsertItem(_T("Test2"), hItem);
m_Tree.InsertItem(_T("Test3"), hItem);
m_Tree.InsertItem(_T("Two"));
m_Tree.InsertItem(_T("Three"));
HTREEITEM hRoot = m_Tree.GetRootItem();
if(m_Tree.ItemHasChildren(hRoot))
{
    HTREEITEM hChild = m_Tree.GetChildItem(hRoot);
    while(NULL != hChild)
    {
        TRACE("%s\n", m_Tree.GetItemText(hChild));
        hChild = m_Tree.GetNextSiblingItem(hChild);
    }
}

which are similar with yours, and I get this:

C++

Test1
Test2
Test3

You could try it ...

modified 13-Jan-14 3:48am.

Re: CTreeCtrl::GetNextSiblingItem never null

dliviu8-Jan-14 1:36

dliviu

8-Jan-14 1:36

Thanks for your answer!

I know it works, because I tried another similar tree myself. But I really do not know why it does not work in a particular case. What I am trying to do is to copy a CTreeCtrl from Dialog1 to Dialog2. So I do something like Dialog1::_tree1.GetNextSiblingItem(ci) and then put ci in _tree2 which is in Dialog2, like this _tree2.InsertItem(csChild,NULL, NULL), where csChild = Dialog1::_tree1.GetItemText(ci).

So it may be that this cross dialog thing is the problem.

Short time format

_Flaviu6-Jan-14 0:42

_Flaviu

6-Jan-14 0:42

How can I know which are short time format programatically ? Just like Windows Explorer show on files date modified ... Thank you.

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.