c作业代写 – Information and Resources

c作业代写 – 这是一个C语言的代写任务/p>

Information and Resources

17. Detailed operation sequence: And, to help everyone sort through exactly sequence of operations and what happens at each cycle, these three files (unix format only) show what happens as every fragment gets processed and the whole of the final superstring for each stage: test0-alloutput.txt, test1- alloutput.txt, test2-alloutput.txt. These files are provided solely to help you with your debugging. The required output from your submitted program remains as is shown by the examples below at point #2.
18. Oh dear oh dear!!! [Now as of Sunday lunchtime…] Hmmm, in fact one of the "errors" that has been noted over the last couple of days and had led me to change the output examples on Saturday isn’t actually incorrect, and I’ve again regenerated the output files. In particular, in test2.txt, "hemp" should be processed before "termite", since it comes earlier in the input, and both have an overlap of one. The second part of the Stage 3 tie-breaking rule only applies if the same string has the same maximal overlap at front and back.
19. Oh dear!!! Hannah Perry has spotted a couple of discrepancies between the specification and the example outputs (Andrew Smith also noted something amiss) and the test1 and test2 output files have been regenerated, hopefully correctly this time. If you copied any of the test-out.txt files to your computer (see item #2 at the bottom), please copy them again. [This message as of Saturday morning]
20. Hmmm, strcasestr() not always available: It seems that even doing #12 as shown, not all of your computers (including maybe the labones) are able to properly access the current version of the function strcasestr(). If you have been getting warning messages in your compilation, paste this code in, and use it instead:
21. /* this function isn’t universally available, here is a local version,
22. returns pointer in txt to first place where pat occurs, and returns
23. NULL if pat does not occur in txt, doing case-insensitive tests
24. */
25. char *
26. mystrcasestr(char *txt, char *pat) {
27. int tl=strlen(txt);
28. int pl=strlen(pat);
29. int i;

24. for (i=0; i<=tl-pl; i++) {
25. if (strncasecmp(txt+i, pat, pl)==0) {
26. return txt+i;
27. }
28. }
29. return NULL;
30. }

The "returns a pointer" version of strcasestr() is the version that you will get
on dimefox, so all is ok in that regard.

13. Sample Output Files: Both PC (CRLF pairs) and Unix/mac (LF only) versions of the required output files are now provided under #2, below.
14. String Functions: You will find the string function strcasestr() a very useful tool in this project. To access it, you need both of these lines (and in this order) at the top of your program:
15. #define _GNU_SOURCE
16. #include <string.h>
17. Example Program: As an example of the standard of work that is expected (including the type and degree of commenting), here are: o The 2013 Assignment 1 specification o The skeleton program that was the starting point for the 2013 Assignment 1 o A sample solution to the 2013 Assignment 1.

Note that you are not required to use structs in your Assignment 1 submission,
but may do so if you wish to.

10. Access Denied on dimefox: Note that you won’t have an account yet on dimefox if you have never logged in to a lab machine so far this semester, for example, if you have been using your own computer for all the workshops, or if you simply haven’t attended any workshops. The symptoms of this will be an "access denied" message when you try and connect with scp/puttyscp or ssh/putty when you want to copy/submit your program. You will need to login to a lab machine, get you account initialized, and then wait a few hours for everything to percolate through the various processes involved with transferring those account details on to dimefox. Then you’ll be in a position to ssh/scp and eventually submit.

If you still have problems after you have taken this step, and are sure you are
using the right password (and can log in to other University services using it),
send me an email confirming that you have taken all of these steps

and still can't get access to dimefox. Don't leave this until the last minute. It is a
problem that can't be fixed in a minute!

9. Marking Rubric: The marking rubric is linked here. Lines that do not apply to your program will be removed during the marking process; your mark will then be the sum of the lines that remain, positives and negatives. Marks won’t go below zero in each section, and won’t go below zero overall either.

Note carefully the deductions that will apply in the Academic Honesty Section.
Note also that you are expected to copy the assignment skeleton ass1-skel.c and
include the Authorship Declaration at the top of your program.

8. Attribution for Re-Used Code: It is ok to make use of code (for example, insertionsort, and/or getword(), and etc) from the book or from the lecture slides or from other published/public sources, but you should remember to add an attribution as a comment to each relevant function, saying where you got it from, what modifications you added to make it suit your purpose, and so on — exactly as you would when quoting some other author when writing an essay.

Of course, the expectation is that the assembly and "glueing together" of these
bits to make a final program will all be your own work, and that the "quoted"
bits will be a relatively small fraction of the "new" output you are being asked
to generate. So it is not ok to take a whole solution from somewhere else, even
if it appears on the web; and it is not ok to solicit or commission a solution by
posting the specification to a forum or website and asking for "assistance" or
"guidance" or "suggestions". Just as it wouldn't be ok to submit something you
found online in response to an assignment that involved writing an essay.

And a reminder of what it says in the specification: we will be using similarity-
checking software across all the submissions, and we will be referring cases of
suspected academic misconduct for disciplinary hearings run by the School of
Engineering, and in the past those hearings have resulted (including multiple
times in this subject) in students being awarded penalties including final marks
of zero for the subject, regardless of their other components of assessment.

7. Debugging (more): If a C program encounters a run-time error and exits, there might still be pending output that has not been written. This is a particular problem in the submit environment, because it can look like the program is failing before it generates any output at all. If in doubt, add fflush(stdout) function calls after each of your your debugging printf()’s (or even, add it to the macro), to force all pending output to be written

immediately. You'll then be able to get a much clearer idea of how far the
program is getting before it fails.

And it is certainly a good idea to routinely put an fflush(stdout) call at the end
of each of the program's main stages, to ensure that errors in one stage don't
prevent the output from earlier stages being marked.

6. Debugging: Try putting this at the top of your program:
7. #define DEBUG 1
8. #if DEBUG
9. #define DUMP_DBL(x) printf("line %d: %s = %.5f\n", LINE, #x, x)
10. #else
11. #define DUMP_DBL(x)
12. #endif

and then, later in your code, where you have a double variable (say) score, try

DUMP_DBL(score);

Then change DEBUG to 0 at the top of the program, compile it again, and then run
it again. Get it?

Can then add DUMP_INT and DUMP_STR, and get the extra output turned on
whenever you need it to understand what your program is doing. Then turn it
all off again with one simple edit.

5. Trouble with newline characters: Text files that are created on a PC, or copied to a PC, edited and then saved again on the PC, may end up with PC-format two-character (CR+LF) newline sequence, see the Wiki page for details.

If you have compiled your program on a PC, and it receives a CR+LF sequence,
then getchar() will consume them both, and hand a single-
character '\n' newline to your program. So in that sense, everything works as
expected. Likewise, on a PC when you write a '\n' to stdout, a CR+LF pair will
be placed in to the output file (or passed through the pipe to the next program in
the chain).

The problems arise when you copy your program and a PC-format test file to a
Unix system and then try compiling and executing your program there. Now
the CR characters get in the way and arrive via getchar() into your program as
stand-alone '\r' characters.

The easiest way to defend against these confusions is to write your program so
that it looks at every character that it reads, and if it ever sees a CR come

through, it throws it away. That way, if you do accidentally get CR characters in your test files on the Unix server (or on your Mac) your program won’t be disrupted by them. Here is a function that you should use to do this:

int mygetchar() { int c; while ((c=getchar())==’\r’) { } return c; }

Then just call mygetchar() whenever you would ordinarily call getchar(), on both PC and Mac.

Because most of you work on PCs (including in the labs), the test files that are provided have been created with the PC-style CR+LF newlines, and should work correctly when copied (use right-click->"Save as") to a PC. With mygetchar() they can also be used on a Mac, but won’t interact sensibly using the standard getchar() function.

To be consistent, the final post-submission testing will also be done using PC- style input files but will be executed on a Unix machine, meaning that all submitted programs will need to make use of mygetchar().

You can use the "Preferences->Encodings" menu ("screwdriver/hammer Options->Encodings" in the PC version) in jEdit to select whether to use Unix (LF) or DOS/Windows (CR+LF) encodings in any test files that you create with jEdit. Note that this only applies to newly created files. jEdit will by default respect the formatting in any current files.

Note also that jEdit doesn’t automatically add a newline after the last line of text files, you need to put it there explicitly yourself (just press enter one more time, so that jEdit thinks there is an empty line at the end of the file). Watch out for this problem if you are creating your own test files on Mac or PC. All the test files that are supplied will have a newline at the end of the last line of the file, including the ones used during the post-submission re-testing.

If in any doubt, use od -a in a Unix shell to look at the byte-by-byte contents of a file, and check which format is being used, and whether there is a final newline character (or final CR+LF pair). You can do this on a PC by starting the MinGW shell and then using cd to reach the right directory. There is an od version available within the MinGW shell on the PCs in the labs. On a Mac, Terminal is a Unix shell.

4. Tabs: The default in jEdit is for tabs to be aligned every 8 character positions. Some of you have altered that to four (Preferences->Editing->Tab width), to reflect the layout that the programs in the book have. Then, on submission, the tabs have "appeared" in the output as being 8 again, which can make your program spill past the 80-character RH boundary. When I run the programs for marking, they’ll all get formatted with tabs reflecting 4 character positions, not
   8. But don’t use any fewer than 4 in your jEdit (or other editor) settings.
5. Magic numbers: Here is a summary of the rules about magic numbers: o Where a number is totally self-defining, I’m happy for it to be used any number of times without a hash-define, provided the code is commented each time and/or explicitly sensible variable names are used. For example, in o /* compute percentage / o pcent = 100.0count/totcount;

I wouldn't expect 100 to have been hash-defined, since the comment
explains the role of the 100, and it isn't going to change, ever, even if
other percentages are calculated in the program using 100 too.
This rule also allows 0 and 1, of course, unless they represent something
other than the additive and multiplicative identities, in which case they
should be hash-defined.
This rule also allows while (scanf("%lf%lf", &x, &y)==2), since the 2
is immediately obvious from the adjacent context (two variables to be
read).

o Where a constant is one that is a fact that is in no way ever going to be
varied, then provided it only appears once in the program and is
explained with a comment, then it need not be hash-defined. The
example here is the - 32.0 in the temperature conversion computation,
assuming that it is entirely within a function called Cels2Fahr or etc and
that it isn't used in other places scattered through the program. Anything
of this type that appears even twice should be hash-defined.
o Where a factual constant is used more than once in a program, even if all
occurrences are in a single function, it should be hash-defined.
o Where a constant is one that is clearly an artifact of the problem
description or the program that implements the solution (for example,
numbers like MAXINT, or the number of variables), then they must be
hash-defined, even if only used once in the program.

Make sense?

2. Test data: Test data for Assignment 1, and some sample outputs: o test0.txt and test0-out-dos.txt (PC version) and test0-out-mac.txt (Unix version) o test1.txt and test1-out-dos.txt (PC version) and test1-out-mac.txt (Unix version) o test2.txt and test2-out-dos.txt (PC version) and test2-out-mac.txt (Unix version)

See #5 above to understand why there are two different versions of the output
files. You should copy the right set on to your computer so that you can use the
Unix/MinGW command diff to compare your output with the required output.

Note how when there are more than 10 input fragments only every fifth output
line thereafter gets generated. And note how if there are more than 54
characters in the superstring, only the first 25 and the last 25 get printed.

Your output is expected to exactly match what is shown in these examples.

1. Specification: The specification for the project was provided here on Friday 31 August.