Assignment questions and answers

No new entries will be added to this list after its publication date for assignment two -- new questions-and-answers, even if they apply to CSC 270 assignments in general, will go in the assignment two Q&A file.

Q: I uploaded my file at 11:45 last night [October 24th] and it didn't work at CDF, but it worked fine at home. May I have an extension on account of this?

A: No. It's simply not possible for us to accommodate problems with your own computer equipment. We suggest that you use the CDF computers, which are professionally managed, and which have a good C compiler which correctly implements the C programming language. Use of your own equipment is at your own risk; I can sometimes assist you with it, and I'm not opposed to it, but if problems with your own computer were allowed to cause you to have extensions, everyone would have free extensions. It's just not feasible.

At this date [October 25th] it's a bit late for this information to be of use to you for assignment one. Fortunately I have a time-warp here so I'll post this on the CSC 270 web pages retroactively on October 8th. Please be advised.

Q: How do I compile multiple files together into one program?

A: List multiple files on the command line. For example,

    gcc -Wall -ansi -pedantic testgraph.c graph.c emalloc.c

Q: I want to add a "helper" function in graph.c. Do I add its extern declaration into graph.h?

A: No, for two reasons. First of all, you do not submit graph.h. We will compile your program with the original graph.h. But most of all, graph.h is intended to be a list of functions which are "exported" from graph.c, like "public methods" in Java. If something is analogous to a "private method" (or private instance variable), in C we would not put its extern declaration in the .h file, but rather we would put it right there in the .c file so that it is only accessible to other functions in that .c file itself. In C, the file level is the closest thing we have to a class.

(Actually there is a keyword "static", which means two different things in C (they got stingy about allocating new keywords), but in the case of a function declaration it always means that it is not made available to other files. This keyword is quite underused in C and we won't expect you to use it in this course; sooner or later we'll be moving to C++ and using real classes again. However, the sample solution for assignment one will use "static" properly and you can see how it works at that point.)

Q: Do I have to limit the length of the lines to 80 characters, as I did in CSC 148?

A: Yes. The printer, my computer monitor, etc, are all of finite width. The standard terminal width is 80 characters; all you can expect from me in terms of line width, e.g. in how I format the print-outs, is that I make 80 characters or fewer look acceptably. If lines are longer than that, they will wrap around. Instead, you should wrap them around yourself, taking care to make the result tidy and readable.

Last year, ajr wrote a newsgroup article about this, which the above paragraph is from.

Q: I changed the statement

        x += y;

        if (y == 1)
            x++;
        else
            x += y;

A: You are mistaken about efficiency. The second version will likely run slower than the first, and it will produce a larger compiled program, and it is more likely to contain errors (bugs), and future modification to this program is more likely to introduce bugs because of its unnecessarily complex structure. The most important thing, both in this course and in "real life", is to write your program clearly and correctly.

Many times when people modify their programs in this sort of way for "efficiency" they cause harm and no good. That is, the best you can hope for is that the program works almost as well as before.

There's a saying: "The first rule of optimization is: Don't."

You will have noticed that many large software projects produce programs which are abominably slow. The solution, though, is not to perform "micro-optimizations" of this kind; they may or may not help, but any help will be imperceptible and won't fix the situation. The main way one speeds up unacceptably-slow programs to an acceptable speed is to improve the algorithms. This is much harder when "micro-optimizations" are in place.

Occasionally one does perform these sorts of micro-optimizations, when you're trying to speed up a program in every last possible way. But you do them last, and you only micro-optimize the sections of the code which profiling data has shown to be worth the cost. (Usually this is no code at all; i.e. you don't do it.) The cost is substantial: it creates difficulty reading and working with the program. The benefit of most micro-optimizations is basically zero. Zero benefit for substantial cost is not a good tradeoff.

Q: How do I check whether or not my files have been submitted properly?

A: Type the following command:

submit -l -c csc270h -a a2

This command does not give you the file contents, but it gives you the file size, so you can compare to an "ls -l" of that file and verify whether or not it's the correct one, and you can see whether all your files have been submitted.

You can resubmit a file by simply submitting a file by the same name again. The last one counts.

Q: How do I find out about library functions? E.g. pow() and exp().

A: Every library function has a unix "man page" ("man" is short for "manual"). You can read the exp man page by typing "man exp".

A2: Look it up in the index of your C book, if you have one. Your C book might have a list of commonly-called functions (which would be more useful than a list of absolutely all library functions).

Q: I get some errors when compiling with -ansi and/or -pedantic, but not when compiling only with -Wall. Do I have to fix them?

A: Yes, you have to fix them. Your program should compile with no errors or warnings when compiled with "gcc -Wall -ansi -pedantic testdiffeq.c diffeq.c", using our supplied testeq.c and our supplied diffeq.h.

(Also see the q&a above about warning messages, and the above-cited newsgroup article.)

Q: What does "ISO C89 forbids mixed declarations and code" mean?

A: It means that within a given scope, all declarations must precede all non-declaration statements. For example,

int something(int x)
{
    int y = 3;
    x *= 2;
    int z = x + y;
    ...

int something(int x)
{
    int y = 3;
    int z;
    x *= 2;
    z = x + y;
    ...

Q: That rule is stupid!

A: Yes, it is. As a matter of fact, it's much less stupid than similar rules in most programming languages at the time C was originally invented, but it looks very stupid today. C++ allows the "mixing" of declarations and non-declaration statements. So does the newest C standard, but we're not using that for this course (yet). Please compile with "-ansi" to enforce adherence to the original C standard in this course, for assignments one and two. (Assignments three and four will be in C++, which, among other things, eliminates this silly restriction about declarations having to be at the beginning of a scope.)

Q: What do compiler warnings about "carriage return" mean?

A: They mean that there are spurious control-Ms in your file. Control-M in the ASCII standard is called "carriage return".

These control characters probably arose because you transferred your file incorrectly from ms-dos to unix. The ASCII standard does not specify how lines of a text file are separated. In ms-dos, the line terminator is the two characters control-M and control-J (in that order). In unix, the line terminator is the single character control-J. When you transfer text files between computers, the file transfer program should have an option to change the line terminator character appropriately.

If you transferred your file in the wrong mode, you can fix it up with the "flip" command, as described in the Student Guide to CDF, page 13 ("Removing line feeds").

Q: The examples in the King book say "main()" instead of "int main()". Which one is right? And why do both of them seem to work?

A: There's a rule in C which is mostly historical and is quite silly, which says that the default type for things is int. In particular, the code

    int gloop()
    {
	return 3;
    }

    gloop()
    {
	return 3;
    }

Almost everyone agrees that the latter form is bad. However, some people make an exception for main() for historical reasons. I think that this exception is pointless but harmless. However, leaving off an "int" in any function declaration other than main() is certainly grounds for a complaint by the grader. And since gcc -Wall -ansi -pedantic will indeed give you an error (warning) message for leaving off the "int" in the declaration of main(), you should put the "int" in there too.

The fact that you are/were allowed to leave out the word "int" in declaring a function to have return type int has led to two quite separate uses of this laxness. For one, some C programmers used to omit the type declaration to indicate that no value was returned, especially in the very early days before the "void" type was added to the language. However, other C programmers got used to leaving off the "int" just because you could.

This means that other than in the case of main(), you really don't know what is meant by a missing type declaration these days. If you mean that the function returns int, say "int"; if you mean that the function doesn't return anything, say "void". This is why the modern version of gcc gives a warning if "return type defaults to 'int'".