Ok, I'll give that a shot. Is there a reasoning why using Path (user variable) rather than a system variable is the better way to go?
Well, system variables have a wider scope that user variables, so if a user variable suffices that is what you should use (what if you have multiple users, each of whom use the same compiler? maybe they don't want to have the compiler look for a bunch of libraries you use because it could cause clashes or whatever, again this is probably not the case but *what if*). That isn't really the reason, though, it's just the compiler expects to find external resources in:
1. built-in directories (you can't change this), this is for system headers e.g. iostream, stdlib.h, ...
2. directories specified in the $PATH (this is implementation dependent) and - for most compilers - in a special compiler variable called $INCLUDE
3. directories specified on the command-line (if using an IDE, this is set via your project options under "header/include directories" or something)
4. the current directory (if using quoted includes)
As I said, it's "better" to pass that info to the compiler by modifying your project settings (lowest scope) but isn't ideal when the project file is shared by everyone since you'll end up clobbering each other's settings and you'll have the same problem. A good version control tool can handle that but in your case it may simply be more effective to use environmental variables and forget about it. This is also the case when installing SDK's since they typically insert themselves in the $PATH so you don't need to do anything special.
Using system-dependent variables e.g. %DEV% in headers is not something you should do, because:
1. its behaviour is not really specified by the compiler, making debugging harder (and, as you see, many integrated IDE tools don't play nice with it)
2. it is most definitely not portable (if/when you ever change compilers, or want to port things to another operating system)
In effect, how the path specified in an #include is interpreted is up to the implementation, so relying on it is kind of like "fixing" a broken door using duct tape instead of metal hinges: it will come crashing down on you eventually. It's much better to turn this into well-defined behaviour by using whatever facilities your compiler (or, failing that, your operating system) offers you when it comes to specifying where library files should be found.
The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.
- Pessimal Algorithms and Simplexity Analysis