Trying to decide which programming language I want to learn

[pbuk]

Sometime after that, i gets incremented to 2.

Indeed. 'sometime after that' is exactly the problem: rather than double-guess the compiler as to when that 'sometime' is, much better to be sure by moving the increment into a separate statement.

 

[Mark44]

Indeed. 'sometime after that' is exactly the problem: rather than double-guess the compiler as to when that 'sometime' is, much better to be sure by moving the increment into a separate statement.

I wrote "sometime after that" because I didn't want to bring up the concept of sequence points. Post-increments and post-decrements occur after sequence points, which are described in this wiki article: https://en.wikipedia.org/wiki/Sequence_point.

In my reply to @yungman's comment about not using increment operators, the example I had in mind was a simple one, with obvious sequence points, like this.

int array[] = {2, 4, 6};
int i = 1;
int val = array[i++];

val will be set to 4, and "sometime after that"; i.e., after the array expression is evaluated, i will be incremented to 2.

 

[sysprog]

I wouldn't be surprised if a c compiler accepted, and processed properly, something to the effect of a[0++], but it also wouldn't surprise me if it didn't : since the 0 is procedure-embedded, that's explicitly "self modifying code", might give a run-time OS hissy-fit. And, it might preclude an optimizer from reserving and using a register, which would be faster.

You could always split the difference :
register int i=0 ; ...a[i++] ;

The compiler would reject the 0++ incrementation directive inside the brackets of the a[0++] expression because 0 is not a variable.

 

[Mark44]

It kind of doing what I want, BUT there's a warning as shown when I ran the program that the vector is out of bound.

That's not a warning -- that's a run-time exception, an error.

It's only defined as 3 element vector, small and I only read in 5 numbers. It cannot be out of bound!

The vector started out with three elements, all of them 0. Each call to push_back() adds a new number after the three 0 elements.

Your logic to exit the 2nd while loop is faulty. The expression dynArr.empty() is true only if there are no elements in the vector. Since you aren't removing them from the vector, the loop condition won't ever be true.

Also if you look at line 32 of the code and look at the top left corner of picture above, I expect to display 12345. But I got 00012345. AND the 12345 is at the right side of the stream. Is it when I use dynArr.push_back, I pushed the 5 numbers AFTER the 3 empty elements? That's the reason I got 000 in front?

Yes.

I made two changes to your code.

vector<int>dynArr;

This change eliminates the first three 0 elements.

unsigned i = 0;
while (i < dynArr.size())
{          
      num = dynArr[i++];
      cout << num << " ";// display all the numbers until the end.          
}

This change eliminates the exception that you saw.

 

[pbuk]

I wrote "sometime after that" because I didn't want to bring up the concept of sequence points. Post-increments and post-decrements occur after sequence points, which are described in this wiki article: https://en.wikipedia.org/wiki/Sequence_point.

Exactly that. I don't think that it is a good idea to tell someone to do something with subtle side effects unless you are going to explain those side effects.

In my reply to @yungman's comment about not using increment operators, the example I had in mind was a simple one, with obvious sequence points, like this.

int array[] = {2, 4, 6};
int i = 1;
int val = array[i++];

val will be set to 4, and "sometime after that"; i.e., after the array expression is evaluated, i will be incremented to 2.

That's the problem with bugs during the code lifecycle, they tend to happen when something that looked simple is modified and an unintended side effect crops up - or even worse the side effect goes unnoticed because it doesn't affect anything until 2 years later when you add another feature.

The way to write that code avoiding all of these potential problems without incurring any performance penalty (even if that mattered) is:

int array[] = {2, 4, 6};
int i = 1;
int val = array[i];
i++;

 

[hmmm27]

The compiler would reject the 0++ incrementation directive inside the brackets of the a[0++] expression because 0 is not a variable.

I'll take your word for it but, as long as the context is only iteration and not re-iteration (ie: it doesn't need to be rezeroed), it saves a superflous explicit declaration.

 

[pbuk]

I'll take your word for it but, as long as the context is only iteration and not re-iteration (ie: it doesn't need to be rezeroed), it saves a superflous explicit declaration.

What's wrong with a[1]?

 

[jtbell]

unsigned i = 0;
while (i < dynArr.size())
{         
      num = dynArr[i++];
      cout << num << " ";// display all the numbers until the end.         
}

This is of course also a common application for a traditional for-loop:

for (int i = 0; i < dynArr.size(); i++)
{
    cout << dynArr[i] << " ";
}

Or in a modern (post 2011) version of C++, a range-based for-loop:

for (int num : dynArr)
{
    cout << num << " ";
}

 

[hmmm27]

What's wrong with a[1]?

Nothing, if your purpose is to explicitly access the second element in an array. In what context were you comparing it to a hypothetical a[0++] statement ?

 

[Mark44]

What's wrong with a[1]?

Nothing, if your purpose is to explicitly access the second element in an array. In what context were you comparing it to a hypothetical a[0++] statement ?

I believe pbuk was referring to this post of yours, #380:

wouldn't be surprised if a c compiler accepted, and processed properly, something to the effect of a[0++]

There's nothing hypothetical about a[0++]. It just flat won't compile.

 

[Mark44]

This thread is getting very long, with just under 400 posts. @yungman, when you have another question, please start a new thread.

 

[yungman]

Thank guys, my big boss just had a hip replacement yesterday and she's home. I am too busy right now to read the replies right now. I'll get to it later tonight or tomorrow.

thanks

 

[Mark44]

I'm closing this thread now. If anyone other than the OP (@yungman) feels the need to reply to a post here, please let me know, and I'll reopen it temporarily.