Q-17, Activity 2.5.2.2. Minor fixes

[PeturOA]

A few related minor issues in Activity 2.5.2.2., section 2.5.2.:

1. The question asks what cout << *ptrN << endl; would print and marks the correct answer as varPtr: 50, but that is not technically correct. It would only print 50. If the intention is to print varPtr: 50 the statement should be cout << "varPtr: " << *ptrN << endl;. As it is, option e is actually the (technically) correct one (although marking it as such would make this a bit of a trick question). Also, varPtr seems to be an older name of the pointer in the example, should probably be updated to ptrN now.

2. The feedback for answer a is inconsistent with the answer itself, after the value was changed from 100 to 9 in commit 8ab95eb.

3. The feedback for answer c is also inconsistent with the answer. Judging the intention by the feedback text, the answer should be updated to be 59, rather than 150.

4. The question itself could be a little clearer about where this extra code should be inserted. Clearly, it needs to be inserted after line 7, for example between lines 7 and 8, rather than "into line 7-8", which could mean the same thing but is a little vague.

[kwizeras]

@PeturOA,
I am working on all the issues (#198) you raised above.
We appreciate your contribution!

[coco3427]

image for refference

[coco3427]

@PeturOA
im working on this issue right now and think i have come to a solution that fixes the inconsistencies. If you dont mind can you view the changes I made and give me feedback.

I think that this resolves the issue, but I may be overlooking something.

[PeturOA]

@coco3427 Thank you. Yes, this is much better. I see you decided to opt for changing the 9 back to 100 (actually it seems to have gone through some more changes in the meantime), so now answers a and c make sense as 100 and 150 respectively, and the feedback now reflects the answers correctly.

Of the items I raised above, consider items 1, 2 and 3 resolved.

As for item 4, it appears also to have been fixed as I suggested. However, now that I look at this, it occurs to me that it could be even clearer. The presentation of the code seems to have changed, because I feel like the line numbers were displayed in the code before, but now they are not. This makes it a little bit tricky for the reader to know exactly which lines the numbers 7 and 8 refer to, as there might be some uncertainty about whether the blank lines are being counted as lines for this purpose. If not, "between lines 7 and 8" would actually place the inserted code inside the loop. Not that it matters, really, because the effect would be exactly the same in this case, but I think this potential confusion distracts a little bit from the point of the question.

To fix this, I would suggest simply displaying the line numbers in the code block above, to make no room for confusion.
If that is not possible with the current setup, then perhaps the question could be rephrased somehow, although it might be tricky to accomplish this clarity without distracting from the question. Perhaps something like
"If the lines [...] were inserted immediately before the loop, what would it cout?"

[PeturOA]

Indeed, here is a picture of what it used to look like before (taken from the current published version in the link I provided initially, and preserved here for posterity):

The line numbers are definitely displayed in this older version.

[PeturOA]

On a related note:
I notice the emphasis of the example has been changed quite a bit in the meantime, to demonstrating the use of nullptr.
But the question is still focusing on how the ptrN and varN are tied together.
I wonder if this disparity needs to be addressed, as it touches on the coherency of the textbook's exposition.

What I mean is that perhaps it's better to avoid mixing explanations of pointers that point to nothing on one hand, and pointers that point to memory locations of other variables and how the value of that memory address is updated and reflected in the pointer, on the other hand.
Those concepts are admittedly very closely related, but they differ a bit in their usage, so I feel like it might be worth separating them in the exposition. To finish explaining one thing before mentioning the other, to maintain clear focus in each section of the book on what is being explained in that section.

But perhaps that's a separate issue.

[pearcej]

@PeturOA I really appreciate your comments and would welcome a pull request to address this.

[PeturOA]

I'll see if I can find the time :)