You must break your program into multiple functions. The simplest organization for this project is to have "main" call several other functions in turn for each step of the processing. You can pass your data to each function as parameters. We highly discourage you from relying on global variables except for symbolic constants.
Any duplicate code should also be moved to smaller auxiliary functions.
You should not be hard-coding numbers in this project. It was okay in Project 3 only because each value was only used once and had little independent meaning.
You can create global symbolic constants in two ways:
// constantconst TYPE NAME = VALUE;// macro#define NAME VALUETechnically, the second method results in slightly faster code, since the preprocessor literally substitutes the name with the text, with a result as if the numbers were hard-coded. But normal constants are also acceptable, and if you want to declare a constant for a single block, you should use them instead of macros.
Here is the basic principle: you have one interface (.h) file for each source (.cpp) file that defines functions called from outside the file. Files that are not accessed by any other, such as the "driver" modules in most projects in this class, do not need an interface file (though there are reasons you might still use one).
This project is just small enough that you can probably get away with one file. In this case, you can put all your declarations at the top of the file, followed by "main", then the rest of the function definitions.
However, it would be a good idea to get used to designing multi-file programs. One good strategy is to put just "main" in your driver, and put your other functions in a "support" module.
You almost certainly need to create a record for the data from one weather station. This results in a slightly weird situation: if you want to use the same record in multiple files, you need to declare it in an interface file and include that file in each source file that uses the record. If you write any functions that operate on a single record, those go in the corresponding source file. Otherwise, you don't need one.
To be be clear:
Functions that operate on a single record should not be combined with those that operate on an array of records. The former go in my_record.cpp, while the latter go in support.cpp.
Note: In this project, if you have no functions that operate on a single record, you can go ahead and include the record declaration in "support.h", since we know the driver will include that header. But I still don't recommend this, since most of the time trying to reduce the number of files just creates problems.
In summary, this is the largest set of files you should consider using for this project:
Finally, just a reminder that you should not have any #include-s in your interface file unless the contents of those interface file intself uses things from the included modules.
The absolute first thing you should do after choosing a basic design and getting things set up is to get the program to read the file and print the table. Don't worry about the calculations until that works. If your input or table output crash or get in an infinite loop, the rest cannot be graded.
You must use real table formatting this time. Remember (a) column headings, (b) appropriate length columns, and (c) keep the whole thing smaller than 80 characters in width. You can abbreviate headings if you need to. There are course pack examples, and my output formatting example shows all the syntax.
You will need extensive error checking that works according to the project spec's. Note that you must (a) print a specific and informative error message for each case and (b) stop execution if applicable.
You can use "exit()" or "return" to halt, depending on your project design. In general you should not use "exit()" in libraries, because it prevents the user from choosing how to handle an error. But because this is an end user program, it's okay.
Remember to always clean up all compiler warnings. If you get any, you are almost certainly doing something unsafe. You can add -Wall (all warnings) to each compilation command in your makefile to see all warnings.