[SOLVED] 代写 2019/10/30 Assignment 3 | io controls: Computer Systems (2000_7081 Combined)

2019/10/30 Assignment 3 | io controls: Computer Systems (2000_7081 Combined)
Assignment 3 | io controls
While developing your programs you will most likely make numerous mistakes and it can sometimes be difficult to identify the source of the problem. In attempting to find the source of a problem you very often want your programs to write out extra messages so you can trace their execution, or you might want them to produce particular error messages to help you. This causes a problem when you come to submit your work because your programs may be producing lots of unwanted output that causes tests to fail.
Output Functions
In order to allow you to add extra output and error messages without interfering with the correct functioning of your programs we have provided a number of functions that you will find described in the includes/iobuffer.h include file.
write_to_output()
You should use the write_to_output() function for any output that your programs are required to produce. During development any calls to this function will result in the argument being immediately written out using cout.
write_to_traces()
If you wish to add your own additional output so that you can trace your programs output, you should use the function write_to_traces(). If you use the function prefix_traces() to set a prefix string, calls to write_to_traces() will appear as a separate line in the output that starts with the prefix. During development any calls to this function will result in the argument (or prefixed argument) being immediately written out using cout.
write_to_logs()
If you wish to add your own additional error messages so that you can get more help understanding what has gone wrong, you should use the function write_to_logs(). If you use the function prefix_logs() to set a prefix string, calls to write_to_logs() will appear as a separate line in the error output that starts with the prefix. During development any calls to this function will result in the argument (or prefixed argument) being immediately written out using cerr.
write_to_errors()
You should use the write_to_errors() function for any errors that your programs are required to produce. During development any calls to this function will result in the argument being immediately written out using cerr.
new/push/pop_error_context()
When writing recursive functions it can be helpful to build a context message that reflects the current call chain. If you call the function push_error_context() at the start of a recursive function, you can build up
https://myuni.adelaide.edu.au/courses/44936/pages/assignment-3-%7C-io-controls 1/2

2019/10/30 Assignment 3 | io controls: Computer Systems (2000_7081 Combined)
a stack of context messages that can be output if an error occurs. Non printing and control characters are escaped in the context messages that are saved.
For each call to push_error_context() you should have a matching call to the function pop_error_context() to record the end of a call to a recursive function. If you lose track of the stack you can simply reset it to be a single entry by calling the function new_error_context().
During development any calls to the function fatal_error() function will result in the stack of error context messages being written out along with any error message using cerr.
Testing and Web Submission Testing
When you want to submit a program for testing it can be really tedious to have go through and remove all the extra output calls you may have added for testing. To avoid the need to do this, the functions described above all operate via a buffering mechanism that can be selectively configured to behave differently between development and submission. During development no buffering is done and all output is immediately written using either cout or cerr.
When the make command is testing our programs it will run a script bin/run-tests to find the test files and run your programs on each one. The first few lines of this scripts set some environment variables that change the behaviour of the output functions. When you submit your work to the Web Submission System, the test script that it uses also make the same changes. Specifically:
all calls to write_to_output() are buffered until a call to print_output() is made,
all calls to write_to_traces() are ignored,
all calls to write_to_logs() are ignored,
all calls to write_to_errors() are buffered until a call to print_errors() is made,
a call to fatal_error() discards all buffered output and errors, any error context messages and the final error message.
Unless specified otherwise, the default error handling process for each component program is to terminate the program with an exit status of 0 and to have not produced any output. Provided that you do not modify the main function in each of the component programs, the configuration changes made by the test scripts should result in the desired behaviour when you pass an error message to the
function fatal_error().
https://myuni.adelaide.edu.au/courses/44936/pages/assignment-3-%7C-io-controls 2/2