Frequently Asked Questions
The Panic Button is a webpage where course announcements are posted. In particular, answers to questions regarding homework are generally answered there. Since these are often in response to student questions received via e-mail after the last class meeting before a submission deadline, it is good practice to check the Panic Page if you are struggling with an assignment and again prior to submitting your code. It's always possible that someone asked a question that affects you even though you might not have thought of it yourself.
The Style Guidelines are a set of rules and conventions that your submitted code is expected to adhere to. They are the result of several years of work examining what kinds of mistakes students frequently make and how those mistakes can be prevented and/or fixed quickly. Compliance with these standards is not optional - points will be deducted for failing to comply with them and significant penalties will be assessed if failure to comply results in the very kind of mistake that adherence would have prevented.
It is a standardized way to name files so that the grader can organize and find homework files more efficiently. A few programs have been developed to partially automate this process and they rely on files being properly named and submitted. Details are in the Style Standards.
By attaching the source code file to an e-mail submitted to the Course Grader. Details are in the Course Policies.
This is outlined in the Style Standards.
These appear to be due to the use of web mail clients. Apparently the e-mail program on the web server doesn't know enough about the platform the file attachment is coming from to properly translate end-of-line sequences. The only solution appears to be to use another e-mail server since attaching the file as a zip file places too much of a burden on the grader.
These are chronicled in a document prepared originally for the Summer Field Session at the Colorado School of Mines. Be aware that, while the style guidelines proposed in this document were the original basis for the guidelines in this course, a number of additions and revisions have occurred. In a few instances, the present Style Guidelines directly contradict the recommendations in the Pitfalls document. In such cases, the Style Guidelines take precedence.
ANSI-compliant code simply means that the code is written so as to conform to the specifications established by ANSI - the American National Standards Institute. ANSI has many committees that develop and publish various standards documents on a wide variety of topics. With regards to the C programming language, the standardization efforts have long since gone international and ANSI works with the International Standards Organization (ISO) to set the language standard.
By conforming to ANSI/ISO standards, your program will probably compile and run as expected on any C compiler that is also ANSI-compliant.
Unless there is a need to use non-ANSI capabilities, your code is expected to be ANSI-compliant. The Grader will have their compiler set for ANSI and non-compliant code won't compile.
The prevailing ANSI/ISO C Language Standard is use today is a version that was adopted in the 1989/1990 timeframe and is therefore referred to as C89. A new standard was adopted in the 1999/2000 timeframe and is referred to as C99. Relatively few compilers are on the market that are fully C99-compliant, if for no other reason than companies using well established C89 compilers are hesitant to incur the expense of upgrading since C99 doesn't bring any fundamentally new capabilities to the language.
The compiler you are using in this course, Borland TurboC/C++ v4.5, is C89 compliant, provided ANSI is selected as the source code option in the Project Options section.
The Borland language extensions give you access to a variety of functions useful for doing such things as detecting when a key has been pressed even if the Enter key wasn't and for moving the cursor around on the screen. They add a significant capability to the kinds of programs you can implement. However, they are not ANSI-compliant and your code is expected to be ANSI-compliant unless the Borland extensions are needed for a given assignment. Such a need will be specifically stated in the assignment and those are the only times you may submit non-ANSI compliant code. Unless restricted by the assignment, you may use any function in the conio.h library, although many of them will not work under Windows NT/2000/XP because of the security features in the operating system.
Because we want to stay focused on algorithms and stay as close to the ASNI standard as we can. Under the present Windows operating systems, we would have to stray far away from this in order to do real time graphics.
Because you are learning a new skill - not just new information. Learning skills takes time. Having said that, many people spend far more time than is necessary because they choose to program like a bull in a china shop. They want to throw a bunch of source code at the compiler, frequently before even reading the entire assignment. Make sure you understand the problem. Develop your algorithm on paper before writing a single line of code. Break the problem down into small chunks and solve each chunk separately. Test your program in stages as it is built up. These will save you enormous time in the long run.
If you are interested, here is a longer rant on this topic.
This is commonly seen with Visual C and with later versions of Borland TurboC. In v4.5, the compiler actually creates a "wrapper" around your code and embeds it in a true Windows program. In these other compilers, your code runs in a DOS console. When you launch such a program from the IDE, it will automatically close when your program exits. To prevent this from happening, end your code with a call that requires keyboard input. The simplest way is to call getc(stdin).
Another common thing that is seen is that your program doesn't appear to run at all. It did, but the generated code took the attitude that if your program doesn't produce any output to the screen, why launch a window? Try forcing some kind of screen output at the beginning of your code and see what happens.
The default limit is 4096 bytes for variables on the program stack. The stack is the memory space where automatic variables reside. The variables you declare within functions are automatic variables. If you try to define large arrays - and at 8-bytes per double they don't have to be very large to exceed 4096 bytes - within functions you can exceed this limit. If the compiler can detect this, it will let you know. But if it can't, then your program may crash at runtime when it overflows the program stack.
The solutions involved using smaller data types, more clever use of you memory, declaring large arrays as global (bad), declaring them as static, or dynamically allocating them.
Each of the programs this semester are quite tractable and can be solved in a reasonable amount of time - IF the problem solving approach that we have tried to emphasize - in the assignment write-ups and website at least - are followed. I can sit down and, from scratch, completely code most of the homework assignments in somewhere between fifteen minutes and slightly over an hour. That certainly does not mean that we expect the students to be able to do that, but being able to write your programs in five hours or so should be quite doable. From working with a number of students as they have struggled with their programs I have seen the same pattern time and time again - namely a refusal to apply the divide-and-conquer approach that we have said is so important. I will sit down with a student and they have their entire program written and coded yet they have syntax errors in the first few lines of code or logic errors that prevent their program from even opening the data file. Now they are confronted with debugging three or four pages of code instead of six to ten lines of code. Worse, their code reflects the disadvantages of trying to solve an entire problem all at once instead of breaking the problem down into specific, well-defined tasks and then tackling each task in turn.
What you will probably find if you look carefully is that you are making the course much harder than it needs to be. This is a common theme that we see every semester and highlights the adage that the burnt hand teaches best. There is only so much advice we can offer and we can't force people to use that advice. I've gone to great lengths to reveal the common pitfalls that many students fall into and how to avoid them and, each semester, a large fraction of the students choose to ignore them and then proceed to run right into them. For instance, after emphasizing how important it is to always verify that a file opens successfully before using it, I will have numerous students come up, after spending hours trying to figure out why their program isn't working, only to discover that their fopen() operation failed and, since they didn't bother to check, things only got worse from there. The attitude (sometimes flatly stated) was that they intended to throw that "extra stuff that we require" on at the end before they turn it in so that they don't lose points. I have a hard time developing a lot of sympathy for the amount of time spent on the homework in situations like that.
On particular case in point came up in Spring of 2003. A student came in asking for some help and one of the things I strongly recommended was that, when checking for equality against a constant, that they put the constant on the left hand side of the equality operator specifically so that if they make the common mistake of using the assignment operator instead of the equality operator that it will become a syntax error, and hence caught by the compiler, in addition to just a logic error. They said, "But that looks odd." I agreed, it does look odd at first, but pointed out that the choice was between "looking odd" and being able to save lots of time otherwise spent tracking down some very subtle logic errors. Two hours later they came back, having made no headway with their program at all, and the problem was that they were setting their file pointer equal to NULL instead of checking to see if it was equal to NULL. They had made the exact mistake I had cautioned them about only minutes before they made it - but they had ignored my advice because "it looks odd". What can I do? Similar tales concerning integer division repeat themselves numerous times each semester - which is why it is a recurring theme on the quizzes and exams.
There are some things that people just have to learn by paying the price of choosing not to listen to the people that have made those same mistakes before them - and I learned many of these same lessons the exact same way. After having been told about the need to clearly identify, in the comments, which pointers need to be allocated memory at run time and making sure that the memory is allocated, I elected not to explicitly identify them - I couldn't be bothered since the program was due the next day - and, as a result, was working with an pointer to an array that hadn't been allocated sufficient memory. It took me twelve non-stop hours to track down. Had I listened and applied the offered advice, it would have taken a few minutes. But does that mean that the program assignment itself was unreasonably long? No. It means that I chose to make it take an unreasonably long time to complete because I chose to ignore the advice that had been freely given. I wasn't happy about it - but it was one of my more useful and effective, not to mention memorable, lessons about the art of computer programming.
If you were to write an if() statement like the following:
if( 1 < 0 ) printf("Impossible Condition.\n");
The if() test will never pass and the printf() statement will never get executed and is therefore referred to as "unreachable code". Since the if() test is comprised entirely of constants, it can be evaluated by the compiler at compile time and the fact that it will always evaluate the same way is recognized by the compiler and a warning flag is raised and reported to the programmer since writing code like this is almost always the result of a logic error.
But what if you had written the code as follows:
if( MYCONSTANT1 < MYCONSTANT2 ) printf("Impossible Condition.\n");
where the two constants are defined using #define statements? As far as the compiler is concerned, nothing has changed. The preprocessor replaces the occurrences of the words with their corresponding values and the expression still reduces to one that can be evaluated by the compiler at compile time and which will always pass or always fail as far as that particular compilation is concerned. So the compiler will still issue the same warning. But in this case, what you have done is created a situation where, depending on the values of these two #define constants, you are (albeit in a clumsy and inefficient manner) controlling whether the code associated with the if() or the code associated with the else (if any) gets compiled. If this is the behavior you want, then you may ignore the warning recognizing that the compiler can't read your mind and that this is an example of you using a trick that, in most cases, is an inadvertent error.
It turns out that there is a cleaner and much more preferred means of selectively compiling portions of code based on the values of #define constants using specific preprocessor directives that are beyond the scope of this course. Using these directives would avoid these types of warnings.
It certainly can. While the performance of a sorting algorithm is highly depended on the nature of the data being sorted - such as whether it starts our pretty random or is more or less sorted to begin with - consider the following:
Results for sorting an array of 8000 values using the three sort algorithms:
Yes, that's right. Even though it is doubly-recursive (calls itself twice, just like fib() does), the quicksort algorithm was 100 times faster than the Selection sort which, itself, was nearly three times faster than the bubble sort. This should show that recursive algorithms do not always suffer a devastating speed penalty compared to iterative algorithms that accomplish the same goal. Of course, we also know that there is at least one iterative method out there that is even faster than this.
Select "Options" on the tool bar and from that menu select "Environment". From the list of topics choose "Debugger". You may then enter the command line arguments that you want the IDE to use. Do not include the name of the program - that is supplied automatically and is not considered a command line argument, it is the