CCPS 305: Quick guide to C programming for Java folks

Transcription

1 CCPS 305: Quick guide to C programming for Java folks (version of March 30, 2014) For the purposes of the course CCPS 305 Data Structures, this document explains the main ideas of how C and especially its compilation process differ from Java, and so hopefully helps those of you coming from a pure Java background get smoothly started (and more importantly, finished) with the labs of this course. The C program structure and compilation process Unlike in Java where you can simply compile each class separately and the source code of each class is stored in a single file, the compilation process of C is a bit more primitive. Each source code file is compiled in isolation, and instead of immediately producing the final executable, the compiler first turns the source file into an intermediate form called an object file. (Despite the name, this has nothing to do with objects of object oriented programming.) For example, compiling the file foo.c would produce the object file foo.o. After every source file has been separately compiled into the corresponding object file, these object files are finally linked together to produce the final executable. For example, consider the following extremely simple example C source code file test.c, that defines the Hello world function: #include <stdio.h> void test() { printf("hello, world!\n"); } The #include is not a C statement, but a preprocessor directive that includes stdio.h that contains the definitions for console input and output functions, including printf. Since the C programming language is not object oriented, it does not have classes and methods and objects, but only functions. Since each C source file is compiled in isolation, what if some function in it contains a call to another function that is defined in some other source code file? This could be resolved in the linking phase, but unfortunately we ll never get that far, since compiling test.c already fails! For this reason, for every C source file that contains any functions that are meant to be called from other files, we always also write a corresponding header file. This header file contains the prototypes for each function defined in the C file. A prototype is basically a function without a body, telling what parameters it takes and what type of value it returns, which is enough for the compiler to check if a call to it is correct and compile it. This header file is then #included to all other files that want to call some function in it. For example, the header file test.h for our test.c would contain #ifndef TEST_H #define TEST_H void test(); /* no body */ #endif The preprocessor directives #define, #ifndef and #endif ensure that the same header file does not accidentally get included twice in the same compilation process. Yes, C compiler honestly is so stupid and primitive that it doesn't remember what files it has already included into each compilation, so this canonical trick is used. The execution of a C program starts from the main function. We could, of course, also place this function in the same source code file test.c. However, just to make a point, we now put main in the second separate file

2 testmain.c and because the function test is defined in test.c, include the corresponding header file first to tell the compiler that such a function will be defined somewhere and will be properly bound to the call at the linking phase: #include "test.h" int main() { test(); // call a function defined in another file return 0; } Since the C language is nowhere near as standardized as Java (for example, the size of types such as int in bytes can vary in different systems, and in fact, even the number of bits in one byte is not guaranteed to be 8), there are some historical variations in how to define and write the main function. For example, its return type can also be void. However, if you define this function to return an int, you need to return 0 in the end to indicate that the program finished successfully, or some nonzero value to indicate that some kind of error occurred (this should not be needed in this course). For each weekly lab and the two programming projects of the course, I will always provide you the header file and the test file that contains the main method. For example, lab1.h and lab1test.c. You should never modify these files in any way. Instead, you should write from scratch the solution file lab1.c that implements the functions defined and specified in the header file, and submit only that file to me. I will then compile your code with these predefined files into an executable to test it. Do it with a GUI: Quincy The Quincy integrated development environment is free to download and use, and despite its minor idiosyncrasies, it is very suitable for the needs of this course. However, you need to take certain steps to make your project properly compile in it. When you first start Quincy, you need to create a new project. From the dialog that opens with File >New... select Project, and in the dialog that opens, give your project name and the directory where you keep it. Make your project a console application without any extra bells or whistles. Once the project has been created (and it shows as a project window inside Quincy), you can create (or copy) the C source code and header files that you intend to use in this project. Note that each project corresponds to one executable and should therefore have exactly one file with the main function, so you need to have a separate project for each lab in this course. When you submit a lab, just submit the one file labx.c that I asked you to submit, not the entire project folder. After you have written all the files (make sure that they are in the correct working directory that you defined earlier) and want to compile and run your project, first click the project window into focus, and then click on Project >Insert File(s)... to actually insert all the files in your project. (It is not enough just to have them in the same Quincy window.) Project >Build (or F6) compiles the files listed in the project window, and if there were no errors, links them into an executable that you can run with Project >Execute (or F9). Note that the classic C standard allows local variables to be defined only in the beginning of the function. Since this is rather annoying for those of us who live up here in the twenty first century and do not feel like being slaves to the limitations of compiler technology in the seventies, go to Tools >Options and from the Build tab, click on C99 Support for C programs to use the latest C language standard that allows local variables to be defined everywhere within the function. Some of you might want to use some other visual programming tool that you are already familiar with, and that

3 is perfectly fine by me. However, make sure that you don't use anything that is not part of the C99 language standard, because I will be compiling and testing your code only in that environment. None of the labs in this course should have any kind of graphics or GUI anyway, nor do any kind of console input or output, except perhaps for your private debugging purposes. The old school cool tool: gcc For those comfortable with Unix/Linux (or the Windows cygwin project), the compiler of choice would be gcc, the grand old man of compilers. gcc is already available for your use in the elara.scs.ryerson.ca server environment (see the SCS User Guide for how to log on to our Unix servers). This compiler (technically, an entire compiler collection not just for C and C++, but a slew of other programming languages) has a ton of bells and whistles for the propeller beanie crowd to tweak, and those interested can go to and check out the documentation pages therein. Fortunately, the basic use of gcc is very easy, since all of these options have reasonable default values. You can log on to elara with any terminal program that supports SSH encryption, but I recommend PuTTy as a good free terminal. If you have the first lab files lab1.c, lab1.h and lab1test.c in some directory in your elara account (note that this is the exact same file system as you have in the SCS Windows machines, so having them there is enough), after logging on to elara and going to that directory, you can issue the command gcc Wall std=c99 lab1.c lab1test.c otest to compile and link your files into the final executable binary file named test. You can of course name this file anything you want, and if you leave out the o command line parameter altogether, the executable will by default be named a.out. To run it, type the command./test Note that the header files are never part of the list of files given to gcc. In the previous example, lab1.h is not given to gcc as any of the command line arguments, since both lab1.c and lab1test.c already include it. The command line option Wall turns on all warnings to the strictest and pickiest level possible. Unlike in Java and its strong type checking where all sorts of hinky things are errors that get caught in compilation, in C it is easy even for experienced programmers to accidentally mix and match different types and make all kinds of silly mistakes that this handy little option then reveals. The option std=c99 makes the compiler use the latest C language standard that allows local variables to be defined anywhere, and the use of // to start a Java style one liner comment. Second, valgrind is a superb memory use correctness checking tool that can instantly reveal a ton of bugs from C programs as soon as they manifest themselves and would otherwise be invisible for a long time until they eventually mysteriously crash the program. It is also available on elara and is extremely easy to use, since valgrind can run any machine code program inside its virtual machine that carefully checks every memory access and pointer operation. To use valgrind from the command line, just write valgrind and then the command normally. Honestly, that s all there is to immediately starting to productively use valgrind! I encourage you in the strongest possible terms to use valgrind to test your labs before you submit them to me, to catch the lurking errors. valgrind./test Some C language gotchas C can sometimes surprise Java programmers with certain inevitable but not immediately obvious consequences of its low level nature. I will update this document with gotchas and problems of the C language as they are

4 encountered by my students caught unawares with them. Different types of computers also have different machine code and operating systems. An executable compiled in one machine will not run on others, so the same source code needs to be compiled in the other systems separately to produce an executable binary for them. (As opposed to Java, where the exact same bytecode file can be run anywhere where there exists an operational Java Virtual Machine.) You simply can't run the C executable binary that was compiled under Windows in Linux or Mac, or vice versa. Remember to always #include all the standard library header files that you need. For math functions, math.h. For the constant NULL and the memory allocation operations malloc and free, stdlib.h. For string operations, string.h. In C, a header file only contains function prototypes (and typedefs and struct definitions) and it never contains any code. Placing any code there is always wrong and bad. I will instantly and summarily reject any lab or project submission that tries to violate this rule. Similarly, you should never have any header file as part of your project or compilation, since there is nothing to compile there, as a header file only contains prototypes for things defined elsewhere. In C, if a function foo calls function bar that is defined in the same source code file, the definition of function bar must physically come before the definition of function foo. (Yes, the C compiler really is again this stupid. Hey, that s how things were the seventies.) If both functions call each other in mutual recursion, the solution to get around the resulting chicken and egg problem is to write the prototypes in the beginning of the source code file, or if these functions are meant to be called from other files, put these prototypes in the header file. C doesn't have classes, but it has structured types that you can define with the keyword struct. A structured type is basically a class with no methods or a constructor, and all its fields are public. Basically, a struct is a fixed size block of passive data that just sits there, waiting for the code to manipulate it from the outside. Individual structs can be copied with assignment = and passed to and from functions by either value or (preferably) pointer, but they cannot be compared for equality with each other using ==, or given to printf to be output. Unlike in Java, where you can only have references to objects that are separate from your variables, in C your struct variable can either be the struct itself, or it can be a pointer to a struct, so the language must distinguish between these two. If a is a itself the struct, to access its field x, use the dot operator a.x. If p is a pointer to a struct, then to access its field x, use either (*p).x or its syntactic sugar version p >x, which by definition means and works exactly the same as the explicit dereferencing. In C, arrays don't know their own length. Therefore every function that gets an array as a parameter must also get another int parameter (canonically named n) that tells this function the length of the parameter array. When you have an array stored in the memory, just like everything else in C it is just raw bytes representing the elements: there is absolutely nothing in the raw memory that says that an array begins here or an array ends here, so once you forget the start address or the length of the array, there is no general way to get it back. In C, a pointer to an array is really a pointer to its first element, and every time you use an array variable in an expression, it devolves into a pointer to that array. For this reason, if a function takes an array parameter, it actually gets a pointer to the beginning of the array. The operation a[i] that we think of as array indexing is syntactic sugar for the pointer arithmetic expression *(a+i) that firsts offsets the pointer a by i units and then dereferences the result. When you define your own data structures, you write their functions so that there is a function to create and return a new instance of this data structure and another function to release it (a handy rule is to ask if the user of the data structure ever has to explicitly use malloc or free), and after these, the functions for the operations that the data structure supports. Except the function that creates and returns an instance, all of these functions should take a pointer to the data structure to operate on as their first parameter. Even though structs

5 can be passed by value in C, you shouldn't write your functions to operate on a data structure passed by value, since your function would only modify its local copy of the structure, instead of the original structure held by the caller like it is supposed to do. In C, the sizes of different types such as int, long, int* and int** in bytes are not defined by the language standard. You could find them out at runtime with the sizeof operator, but by then it's too late. (Remember, you can't even trust that a byte is equal to eight bits!) For this reason, a program written in one system may seem to work there without any errors, but fails epically right after it is compiled and run in another system where the sizes of, say, the types int and int* are different, and you have accidentally used one where you really meant to use the other. So be careful with types (and keep Wall on with every compilation to catch you napping), and use valgrind to catch your memory errors. printf will output exactly what you tell it to output, nothing more or less. Remember to put the white space and line breaks with \n wherever you need them. The placeholder for an integer is %d, and for a double, %f. (The d stands for decimal, i.e. base 10 as opposed to base 16 hexadecimal, and f stands for float for a floating point number.) We don't need scanf for console input anywhere in this course. C has essentially zero encapsulation, so all function names are global. Therefore, your program cannot be linked if it has two functions with the same name (since C has no function overloading, it doesn't help even if these functions expect different parameters). Especially your program must have exactly one main function in one of its files to properly link and run.