Wk3-Mtg1: II-8 Loops** (Pt2), II-9 Addresses and Pointers**

Review:

 (There was no homework to review from last session)

II-8 Loops** (Part 2)

We started by reviewing the while and do-while loops, we covered last meeting, as shown at the Wikipedia site.  Their flowcharts are better in that they clearly highlight the difference between the two loops, that of where the test is done "before the code block" or "after the code block"!

We completed this chapter by reviewing the classical for-loop, again using the page at Wikipedia, and noting that it has three parts in parenthesis after the for but before the first open brace. The three parts are: (1) Initialization, (2) Condition, and (3) Increment/Decrement.

Challenge (Counting Down)

The code for this challenge had the loop write but not decrementing and not detecting divided-by-5 at all.  We talked thru the challenge description and updated the code as we talked.  We all three parts of the loop and noticed that we were using a do-while loop.  Tested to see that we got the loop correct and found that our first loop termination was not displaying zero, so we adjusted the test to display zero!  Next we found that we were decrementing by 1 and not by 3 as the text stated so we changed this to using the minus-equals '-=' operator:  i -= 3;  this fixed the final display problem.  Lastly we needed to put out extra info whenever the number just shown was divisible by 5.  We noted that in our last meeting, we talked of the modulus operator (%) and how we should use it.  We remembered our math and noticed the when we divide a numberA by numberB and numberA IS divisible by numberB then we will have a zero remainder!  We use the modulus operator to get the remainder of the integer division and if the remainder is zero (our number is divisible by 5) then we put out the extra line of text.  This corrected the final problem we had with this challenge code.

Challenge (user input)

IN this challenge we are directed to use the readline() function to get user input, convert this input to an integer then use this number given to us by the user as the starting point for our loop.  We started with the same code as our CountingDown example and added the readline() and atoi() use prior to the loop, we then replaced the loop initializer with an initializer which used the number just given to us.  Additionally, we had to make the project link-in the libreadline.dylib file (dynamically linked library [*.dylib] vs. statically linked library [*.lib]) so we could access the readline() function provided by the library.  In main.c where we used readline() and atoi() we also had to include the headers for each :

   #include <readline/readline.h>
   #include <stdlib.h>

This completed our adjustment to the starting code. The changes worked as expected!

As a final review we then replaced the do-while loop with a traditional for loop.  While making these changes we saw that the while loops had all three parts that are shown in the enclosing parenthesis but they are spread all over the code (initializer before the loop, increment/decrement within the loop and the condition at the end of the loop)  By going through the motions of converting the code to a traditional for loop the code became smaller but more importantly we saw that all three important bits of the loop were now in one place and very easy to modify.  This is why we generally prefer for loops to do-while loops!

II-9 Addresses and Pointers**

We reminded ourselves that there are two things we can do with a memory location.  Get its value (contents) or get its address.  The name of our variable is synonymous with its address in memory space. Generally, unless we are dealing with embedded systems, we do not have to care about where our physically reside in memory (what their address really is.)

We talked a lot about the uses of the & (ampersand) and the * (asterisk) operators. We noted that there are three common uses of the two and if we speak them to ourselves as we read the code we can more easily make sense of what they mean.

1. (USE)  &  returns the address of the name to its immediate right.  (e.g., &nNumber - returns the address of the nNumber variable in memory.   When we see the & in code next to a name or function we should read it at "address of" to help reinforce its meaning to us as beginners.
2. (Declaration)  * in a declaration means that the variable-name to its right is to contain a pointer to (or address of) some item in our program.  When we see an * in a declaration statement in our code we read it as "pointer ".  (e.g.,   float *pAmount; - means we are declaring a variable named pAmount which is to contain a pointer to a float variable.)
3. (USE) * in a statement means that we want to interact with the item pointed to by the pointer.  We read this as "value of pointed to item".  Two common use cases are (a) *amountPtr = 7.0; where we are assigning a new value to the float  pointed to by our amountPtr variable, and (b) float fTaxedAmount = *pAmount * 0.065; where we are retrieving the float pointed to by amountPtr and using that value in the equation.

We talked of the size of pointers being fixed (no matter what type of object they point to) and that their size generally reflects the size of the address bus of our current processor architecture (e.g, pointer is 32bits in size on a 32-bit processor while it is 64bits in size on a 64-bit processor.  [There are of course processor architectures where this is not true but that's not germane to what we are learning here! -ed.]

We talked of the special NULL pointer value and it's use.

And Lastly we talked of always placing the * immediately adjacent to the pointer variable name, not the datatype to which it points.  

• int *pMathValue;        <-- GOOD
• int* pAnotherValue;   <-- BAD
• justification reminder:    float *pNumber1,  *pNumber2, fNumber3;
    (unless we place the * next to the variable there is no good place for it in multi-declaration statements, immediately preceding statement)

*Challenge(How much memory?)

This was fairly simple. we went over the code and talked out the debug output.  We found an extra statement in the code, removed it, and then discussed why we didn't need it!

*Challenge(How much range?)

Aha!  This was also simple and in fact example code was found online! We the reviewed the content found on the web and talked about the issues we saw with the answer (e.g., there really is no thing such as a negative zero!)

Homework:  No additional home work was assigned for our next meeting.