Submission Guidelines

How to upload your programming projects

We will use the Upload Site to upload and to grade projects.

Logging in to Upload Site

If you do not have an Upload Site account (weird, but it could happen), please ask Dr. Rivas to get one immediately. You should be able to log in with your Baylor student account.

Uploading your code

You will submit your code only on the Upload Site. Find the correct assignment, where you would put all the files you want, for example, to submit for project 0. Here are a few things you need to remember and practice:

• Test all of your code locally with plenty of test cases.
• Then upload your tested code to the Upload Site.

Two rubrics for passing each project with a high grade

To pass each project, you must succeed in two high-level areas:

• Functionality. You must pass your professor's judgement. This is usually easy to pass if you create your own test cases, difficult ones, testing extreme situations as well as the normal ones. Your code must function as expected in the design of the project. Submit your code through the Upload Site and wait for the results; your professor will grade your project for functionality automatically.
• Style. The version that you submitted also will be tested to see if it passes the professor's check for style and other correctness issues.

You must write a correct, functioning, programs that are aesthetically beautiful to the eye and that adhere to the style guidelines.

The grade you get will be based on the time you submitted it and its functionality and style. You may upload your code as often as you would like until the deadline.

How often can we submit to the Upload Site?

There is a limit of three tokens per hour that you should use wisely. Do not abuse the site, it is not a testing machine. Avoid doing things at the last minute, because, trust me, the Upload Site can fail too and this will not be an accepted excuse for a late project (or assignment).

How does the professor test your projects

The professor will compile your project using the g++ compiler, and run your project on hidden test cases. You do not have access to these test cases, but you are encouraged to make your own test cases!

For each test case, your project must produce output that is identical (character for character) to the correct output. Further, it must not crash, use too much memory, run too long, etc.

If your code doesn't pass the professor's functionality evaluation, the professor will tell you that your project did not pass, and will give you a reason why. Some common reasons are:

• You have not submitted all the necessary files.
• Your code does not compile.
• Your output does not match professor's output on the same input.
• Your program crashed on an assert during execution (you will be given the assert message -- valuable information!).
• Your program crashed during execution (divide by zero, memory access error, etc.).
• Your program wrote to, or read from, memory it did not own.
• Your program required too much time to execute.

If your project passes the functionality but NOT the style check, then you will be penalized.

Testing and debugging your program

The professor and the upload site are not a testing/debugging/development platform; your professor is there to teach you and GRADE your program. Therefore, you should test your program throroughly on YOUR OWN COMPUTER.

In addition to reading this section on testing your program, you should read this page on how to use the command line shell to run programs, redirect input and output, and compare ("diff") files.

Make your own test cases (and use them!)

The first thing you should do before you begin writing code for any project is to make test cases -- inputs and expected outputs -- for your program (see Project 0 for example). Put each test case in its own file, and save it for later testing. You can make as many as you want. The more that you make, the more chances that you have of catching a program error, if you follow the tips provided below. Think about covering all the tricky cases, but keep your tests simple at the same time.

The way to use your test cases is to run your program and make sure the outputs are all producing the expected behavior.

You should NOT expect that your program is correct if it gives the correct outputs on the sample inputs provided for you on the project web pages. These samples will not cover the breadth of tests that the professor will throw at your program.

Comparing output -- Diff utilities

To check that your output is exactly the same as the output from the sample output, use a diff utility. Two files may appear the same to the naked eye, but may be different due to spaces, newlines, or some other hidden characters. Diff utilities will catch the differences you can't see.

Under OSX or Linux/UNIX, diff should be available from the command line. Under Windows, WinMerge works well. When you run WinMerge for the first time, make sure you do the following: (1) Open the Options control panel (Edit -> Options), then (2) set the options to be "Compare whitespace" and set "Sensitive to EOL" to be true. These options ensure that WinMerge catches every difference.

Metrowerks CodeWarrior also allows you to compare two files (see menu Search, option "Compare Files"). However, CodeWarrior will (by default) ignore differences in newlines, so that is a problem.

Your professor also encourages you to look into the diff modes of the VIM and EMACS editors, if you use one of those.

Comparing output -- other tips

Here are some important tips to make sure you are comparing files correctly:

• Do not use copy and paste. Copy and paste can introduce extra newlines, and perhaps other characters, that aren't part of the original file you are copying from.
• Download files. Instead of copy/paste, download all files directly from the course web pages to your computer. That is, right-click on the link and use "Save target as..." (for Internet Explorer) or "Save link as..." (for Mozilla). This will make sure the file that is on the website is exactly the file that is on your hard drive.
• Use file redirection to provide input to your program. To get input to your program directly from the file, use file input redirection from the command line. In DOS and UNIX (Linux/OSX), you can "redirect" a file to be the input to your program (instead of the keyboard). The DOS syntax (UNIX is basically the same) is

  c:\ds> Prj0.exe < p.in

  This will take the data in p.in and redirect it so that the program will read it in on standard input. The key here is the "<" and the file name.
• Use file redirection to capture the output of your program. Use output redirection to save your program's output to a file, exactly as it comes out of your program. Here we use ">" and a file name:

  c:\ds> Prj0.exe > p.out

  This will send all the standard output from your program to the file named p.out (and not to the screen).
• Putting it all together, use input and output redirection at the same time:

   Prj0.exe < p.in > p.out

  After this, we can use a diff utility to compare p.out with the output sample you expect (e.g. from the sample output provided). Remember, don't use copy and paste -- use input redirection. Don't compare visually -- use output redirection and a diff utility.

Using the command-line interface

For this class, it's good to get familiar with using the command-line (DOS under Windows, or bash under Mac/Linux/Unix) for testing your program. If you're not familiar with it, the command line may seem cryptic, but it's fairly simple, and it can make you much more efficient than using GUI tools.

The main things to know about using the command line are: how to get to your executable program (usually under the same directory of your project that your compiler automatically created) by using the "cd" and "dir" (or "ls") commands, how to run the program (type in the name, perhaps with a "./" in front for bash), and how to redirect input/output (see section above on comparing output). It's also useful to use the up/down arrow keys to get to recent commands, and to use the TAB key to do auto-completion of a partially-typed command. We may talk about using the command-line in class, but if you want help feel free to come talk to your professor about it.

General tips for testing and debugging

Professor's test cases are hidden, but you can and should develop test cases that will test your program as thoroughly as possible. Think about each project carefully, and what the "boundary conditions" might be. That is, think about large test cases, small ones, complicated ones, simple ones, etc. If the project specifies that some value will be in a range from 1 to 1000 (for example), then test 1 and 1000, as well as values in between (the 1 and 1000 are the boundary conditions). I even recommend developing test cases before you write a single line of code.

Use your debugging skills to find problems in your programs. This means using print statements to check the flow of your program, the values of variables at certain points, and your IDE's debugger (as a last resort). The assert() function can be a good debugging tool.

Use assert()

The C++ function assert() allows you to tell the program "make sure this is true, and if it isn't, crash the program and tell me about it". To access this function in C++, imake sure you #include <cassert>, then simply call assert cond; where -cond- is a conditional statement.

Assert can give you very useful feedback about where your program is going wrong. You pass to assert a condition that should evaluate to true or false. If it is true, then nothing happens. If it's false, then assert crashes your program and prints an informative error about where the program crashed.

Here is an example:

 4: int *fval = new int;
 5: assert(fval != null);

If the memory allocation fails, then fval may not be null, and the program will crash when it gets into the assert. It will print something like this:

  example.cpp:5: failed assertion 'fval != NULL'

If your program stops on an assert() during the professor's grading, the professor will give you the information about that assert, including the assert message, file name and line number. Asserts can be very useful for debugging.

Having problems?

If the professor's feedback is not showing properly, please report this immediately via email. If you are having other kind of problems or errors, check your textbook, class notes, the resources provided, and your professor.

Need some advice?

If you are having problems with your project, you can save your professor a little bit of time by asking for automated advice.

Press the button!

Video tutorial on how to use WinMerge

By Jonathan Myers (Spring 2014)

This video explains how to use winmerge, along with test cases and a solution executable provided by the professor to compare the output of the two executables and ensure that you have properly functioning code. Winmerge actually shows the difference in output.

Before starting, you must first download Winmerge. This is an open source tool developed for Windows that shows differences in files. Unfortunately, there is no Mac version. You must also download the solution executable and various input file test cases off of your professor's website. Once your code is compiled, and your executable along with the professor's executable and input files are all in the same folder, you can open up command prompt to create output files. You use the cd 'FilePath' command to have command prompt enter the desired folder. Once this is accomplished, you can create the output files by using the following format:

Prj2.exe < input.1 > output

A file named "output" will be created with the output from your executable in the same folder. Use the same method for creating a second output containing the output for the second executable:

Sol.exe < input.1 > output2

The names output or output2 do not matter, as long as the two are named something different. They do not need extensions. Once this is done, open winmerge and click the "open" button in the top left. For the "left" file, click browse, go to the folder with all of the executables, and select "output". For the "right" file, click browse, and select "output2". Nothing else needs to be changed, so hit OK. Winmerge will show you the difference in the output of the two files using this method, so you can check to see what you may need to change in your program to match the correct solution.

Max resolution: 720p. This video is compatible with mobile devices.