CSCI 159 Lab 2 exercises

Lab2 will consist of two parts:

Hopefully most people complete all of the basic exercise and get started on the main exercise within their scheduled lab section on Sept. 15/17th.

Here is the collection of new C++ syntax elements we'll be using for lab2.

Today we'll also experiment with a different editor, pluma


Refresher: logging in and setting up

  1. logging in

  2. opening the browser and today's lab page

  3. opening a terminal window

  4. using make159 to get lab2

  5. getting into lab2 and the edit/compile/test/submit cycle


New: getting feedback/marks from the previous lab(s)

  1. getting the feedback directory the first time

  2. updating the feedback directory (for later labs)

  3. seeing the feedback files


Part 1: the basics of this lab's new C++ features (basic.cpp)

For the first part of today's lab exercise we're adding code to a program to experiment with some of of the more unusual behaviour and limitations of simple data types, while also learning to 'code to standards' as we go. Of course we'll get more practice with the edit/compile/test/submit cycle as we go.

We'll also try to create and call a function of our own: passing data to it, having it perform computation and return a result which our main routine can then use.

Go through the various steps, adding each to your basic.cpp main routine as you go.


Part 2: design and implementation exercise (lab2.cpp)

Now that we've practiced using each of our new C++ features, our objective is to design, write, test, and debug a more interesting program in our lab2.cpp file.

The program we'll be creating is supposed to help EvelKall estimate how many hours per week each of the three members of their help centre staff is genuinely answering phones. To do so, EvelKall's auditors call the help line at random times over the week and see how many times each person answers and how many times calls go unanswered. At the end of the week, the auditor runs our program, entering the results of that week's calls, and our program uses them as the basis for estimating how many hours per week each person is working and how many hours per week there is no one answering calls.

The behaviour we want from our program is as follows:

No error checking is required at this point, you can trust that the user will provide valid data. (When testing your submission for this lab I'll only use valid data.)

Sample output/behaviour

Below is a sample run of the program. Just for the sake of readability the run below shows the user input in bold italics - that of course is something your program couldn't actually do.

Your output doesn't have to look exactly like the output shown below, and the numbers certainly won't, but should provide a similar level of detail and functionality, and demonstrate both left- and right-justified columns.

 
Welcome to EvelKall Monitoring! 
 
We estimate your staff's working hours based on the results of weekly call samples.
 
At the moment it assumes you have 3 staff members, and rounds results to the nearest 0.1 hours.
 
Please enter the name of the first employee (as a single word):  Daphne
Please enter the name of the second employee (as a single word):  Fred
Please enter the name of the third employee (as a single word):  Velma

Please enter the number of times Daphne answered a call: 27
Please enter the number of times Fred answered a call: 6
Please enter the number of times Velma answered a call: 104
Please enter the number of times a call was unanswered: 41

Based on the information you provided, we have the following results:

Estimated weekly hours:
   Daphne:     25.5
   Fred:        5.7
   Velma:      98.2
   Unanswered: 38.7

(Note that results may not equal exactly 168.0 due to output rounding.)

Thanks for using EvelKall Monitoring! 
 

Future modifications

This initial version of our program is pretty limited: not very robust, and not very user friendly. In future labs we'll be improving and expanding upon our design (adding error checking, letting the user identify how many employees there are, tracking behaviour across multiple weeks, etc).

Designing your solution

Take some time to come up with a design - figuring out what functions you want/need to write/call, what you want each of them to do, and how you want to structure your logic in the main routine.

Taking the time to come up with a good design will, in the long run, result in much cleaner and better organized code: code that is easier to write, understand, debug, and maintain.

Good design takes practice though. Don't worry if you have to significantly revise your original design a couple of times as you work through the coding practice: it's normal to recognize the need for some changes as you start getting deeper into the actual code.

If you're having trouble getting started, go to the lecture resources and check out the sections on design and modularity listed under Sept. 22-26. There are also many good resources online to help new programmers learning to design.

In next week's lab time (Sept 22/24) we'll spend about 45 minutes on the first quiz, but the instructor will be available for the rest of the lab to talk about your design ideas/issues.

Standards and submission

Remember to put all your code for this part of the exercise in your lab2.cpp file in your lab2 directory, and submit it prior to the deadline using the "make submit" command.

As with the other lab exercises, you can 'make submit' as often as you like, it basically just copies your latest version to a place where I can access it.

Do remember that your code needs to follow the course code standards, and that it is most effective to code-to-standards as you go.


Prepping for next week's in-lab quiz

You can find discussion of quiz 1 topics, prep ideas, cheat sheet, etc here: csci.viu.ca/~wesselsd/courses/csci159/quizzes/q1/