Labs guidelines:
follow homework's canvas submission guideline and/or TA's special instruction.
Homeworks guidelines:
submit a doc or txt file that describes what you did and the result
include C++ source code in your doc and highlight the essential parts
include output files in your doc as appropriate
Learn and practice debugging skill
Debugging is a "skill". Reading enhances knowledge, practice polishes skill. Good engineers design good code. Best engineers are excellent trouble-shooters.
Build on top of your previous code
It is easy to find sample code for all our lab problems. But if you want to be a good programmer, there is no substitute for writing your own code. Writing it one line at a time re-enforces your understanding of each construct, why it is here and why not. Of course, once you understand it, you can just cut-n-paste portions of your code to new labs (or, refactoring...... do you know that word?)
Explore and use the tool
For us programmer, IDE is our valuable tool. Do you know what you have on your tool box? For example, we just mentioned "refactoring". If the new lab need "student" class and my old code has "complex" class that I think I can copy, is there an easier way to change complex class to student class?
Multiple Definition ... lab 1
We're asking for 3-file implementation (main.cpp, complexT.h, and complexT.cpp). A few people encountered multiple definition compiler error when they add any function in the complexT.cpp
As it turns out, the error was caused by main.cpp which has both #include "complexT.h" and #include "complexT.cpp"
Main needs to have #include "complexT.h" so compiler knows what is the complexT. But all the implementation routines have been part of the project as in the separate complexT.cpp file. If main does the #include "complexT.cpp" , then the whole project will have two copies of the implementation code.
Using Sample Code ... lab 1
I saw a few people doing labs by using the sample codes from class web site as a starting point. It is ok to do so as long as you understand what's going on. After all, every program I do starts with something.
If you're going to start with the sample code (or anybody's code), I have a strong recommendation:
comment out code that you do not understand
comment out code that you do not need
comment out code that you do not like
Then, you can grow your program as you experiment and learn. Skill is acquired not by watching things work, but by pondering why things not working.