Coding Conventions
------------------
I'm not a big fan of coding standards, but I do try to stick to the 
following conventions.

- Functions normally return 0 on success, and negative numbers on failures.
Negative numbers often indicate a specific failure. Returning a positive 
number usually indicates success as well.
   There is one consistent exception to this, most functions that return
a pointer return NULL on failure. NULL is usually 0.

- Prefixes 
   I find using prefixes can be useful in debugging. It is very 
important that prefixes are accurate (labeling an int m_fX is just 
confusing). The most important prefixes are the m_, g_, p, and v prefixes.
The others are, to some extent, optional. I almost never put an f at the 
beginning of the name of a local double, but I almost never leave it out
of a member variable or global variable name.

    m_  -> The variable is a member variable of a class.
    g_  -> The variable is global variable.
    p   -> The variable is a pointer variable.
    v   -> The function is a virtual function.
    C   -> Class names always start with a capital C.

    f   -> The variable is a double or floating point variable.
    n   -> The variable is a form of integer variable. (int, long, short)
    c   -> The variable is a char variable.
    sz  -> The variable is a pointer to char. 
    s   -> The variable is of the C++ type string.

  As I said before, m_, g_, p, and v are the important prefixes. Knowing
that a variable is a class member, global, and or a pointer is very helpful.
The 'v' indicates a virtual function. There are often several different
versions of any virtual function, and it can VERY difficult to figure 
out which one was actually called (similar to tracking down errors involving
a pointer to a function). The 'v' gives you a useful warning that you will 
have to hunt down the correct version of the function.
  

- Passing messages between threads is done using 'que' and 'do' functions.
To reduce the number of botched messages being built, and keep the code as 
simple as possible, all messages are constructed by 'que' functions in 
the class that will respond to the message. When the class handles to the 
message it will call the equivalent 'do' function. 'que' functions are
public while 'do' functions are protected. (See CEventThread in 
thread_classes for more information) 


- I avoid using macros and #define if possible. In my opinion, they
are debugging nightmares. enum, typedef, inline functions, and other 
options are much easier to live with. Not to mention the compiler actually
understands them without an interpreter.

- All header files are wrapped in this kind of statement. 
      #ifndef __FILENAME_H__
      #define __FILENAME_H__
          
       .......  file contents ........

      #endif
        
- All program specific header includes come after the system includes.
This is because a strange #define in local file can have bizarre results,
if it is included before a system file.
   This is fine
        #include <stdio.h>
        #include <queue>
        #include "qmsg.h"
   This is a bad idea
        #include "qmsg.h"
        #include <stdio.h>
        #include <queue>