Using Dev-C++ in the computer labs

This page summarises some of the experience with using Dev C++ in the computer labs in this year and in previous years, and gives some recommendations. However I no longer recommend Dev-C++ for student C++ programming.

1. Networked drives and MS-Windows issues

DevC++ seems to be very good as a basic C++ IDE. The programs it creates are very fast, but are slowed down by (1) the fact that DevC++ creates "development" or "debugging" versions by default and (2) the network drives are sometimes slow. However, there are some occasional problems with the way it is set up at the University, mainly because of the way the network drives work and the "permissions" used. So please pay attention to the following.

On university machines, you should always save your work in the "U:" drive or on a separate flash drive. This is a networked drive that is dedicated to you only, and will be available next time you log on where-ever on campus you are. I strongly recommend a subfolder for all 2NP work and at least one subfolder of this for each 1 or 2-week project you will do.
In room 304 the Dev-C++ installation will not work unless you work from a drive with a colon symbol (e.g. U: or D: or E:). Don't use a network path instead even if it maps to the same location. This appears to be a general issue with MS-Windows.
Be aware that almost everything on the university computers is networked, and the network sometimes runs slowly.
DO NOT name files or folders with spaces or other special characters. The letters, digits, and the special character _ are all safe and OK. Filenames with spaces do not always cause problems but often do. This DOES cause problems sometimes with Dev-C++, sometimes in strange and unpredictable ways.
Avoid using C: or any other hard drive on the university computer you are working on. You may not have the permissions to use these, or if you do, your work may not be there next time.
Always close the execution window where your program runs. If this remains open, sometimes windows "file locking" can prevent successful compilation of the program when you make changes. This appears to be a general issue with MS-Windows.
By default, Dev-C++ will not recompile if you don't make any changes! (It may not be obvious that it hasn't done anything.) One way to force it to re-compile is to make a trivial change to the source file (e.g. to a comment).
The stranger your error, the stranger your error messages might be. Take care not to do anything really silly. For example if you try to compile an empty program or one with no "main" you might get something like "cannot find main.o" or "cannot open main.exe".
If all else fails you might have to close all programs (especially execution windows where your program runs) and try again. If this doesn't work try logging out and logging back on. I have seen unexplainable problems "fixed" by this method.
It should be possible to work entirely from a memory stick. Then instead of saving your work on a subfolder of U: you can save it on your memory stick (D: or E: or whatever).

2. Dev C++ settings

There are a number of system settings available via "tools > environment options" and "tools > compiler options". Not all of these always work for all students. (I think this is a "permissions" thing again.) However, the option "Tools -> Environment options -> Pause console programs after return" always worked for all students I saw try it. This even includes even those students that did this and got an error message. (So if you get an error message, ignore it.)

The System compiler settings in "tools > compiler options" are problematic and do not always work. However, if you create a project file for each project correctly as recommended and always keep all files for a single project in the same folder, then the project file itself has a second copy of these settings. These can be set under the "project" menu with "project > options > compiler options" or something like this. This seems to work for everyone.

IF YOU NEED IT, I recommend you to ALWAYS to use "Tools -> Environment options -> Pause console programs after return" to put a pause in your program if you need it, or running the program from the command prompt. (Ignore the error message.) Do not use system("PAUSE"); or any other input/output unless you really can't avoid it (and if this is the case discuss with me). The reason is that I will be marking your work on a machine where system("PAUSE"); and a number of other things you might want do not work.
Don't #include <windows.h> or anything else that is not mentioned in these web pages. You don't need it and you risk the fact that your program may not run properly on other computers, including the one that is marking your work.
Always create a new project folder for each project, and make sure projects are in separate folders. Set compiler options under the "project" menu.

3. Other Dev C++ quirks/bugs

Apart from strange behaviour due to a slow University network, I am aware of only one of these.

If you use "file > save project as" you must add the extension ".dev" to the file name. I think this is a bug, or an oversight, in Dev C++. Under other circumstances the extension ".dev" is added automatically, but not this one.