Some Notes About Notation

This section provides details about the presentation of information elsewhere on this site.

Coding Style

Coding styles and conventions are important and personal. Whatever convention you eventually settle with the most important thing to do is be consistent. This cannot be stressed enough. The reason for being consistent in the way that you format your code and name variables, classes etc is so that both you and others can read your code. The personal part is in what convention or style you invent or choose for yourself.


All source code presented on this website is unicode compatible unless otherwise specified. In order to make winapi code unicode compatible it is necessary to define both UNICODE and _UNICODE preferably by passing the macros directly to the compiler on a per project rather than on a per file basis. The winapi headers define two macros, _T and TEXT, defined within tchar.h or winnt.h which, together with the winapi TCHAR data type, enable substitution of strings into char or wchar_t strings depending on whether or not UNICODE and _UNICODE have been defined; ie. when UNICODE and _UNICODE are defined the wide character types are produced (wchar_t). In the source code presented in this website I prefer the use of the _T macro. While the results of this are no different from using the TEXT macro, it does require that tchar.h is included.

In order to use standard template library(stl) strings and retain unicode compatibility I typedef a 'ustring' type as follows:

typedef std::basic_string<TCHAR> ustring;

This, essentially, mimics std::string and std::wstring which are basic_strings, too, where the template parameter is char or wchar_t respectively - the same fundamental string types that TCHAR resolves to depending on whether UNICODE (and _UNICODE) are defined or not.


In order for the code presented elsewhere on this website to compile without further modifications, some preprocessor conditionals have sometimes been necessarily used to differentiate between the behaviours of different compilers. Some other preprocessor definitions have also been inserted directly into the code for similar reasons, including definitions required to specify the target operating system. Ideally, any such compiler specific definitions would be better set as compiler switches rather than on a per file basis.

None of the examples on this website explicitly use the WIN32_LEAN_AND_MEAN macro which, if you take a look in <windows.h>, just ensures that some infrequently used headers(two notable exceptions are shellapi.h and mmsystem.h) aren't included during compilation.

The following is a list of preprocessor directives that relate to specific compilers; some may have values which also relate to the version of that compiler:

Preprocesor Definition Compiler
__GNUC__ GNU C/C++ Compiler
__BORLANDC__ Borland C++ or C++ Builder Compiler
__WATCOM__ Watcom compiler
_MSC_VER Microsoft compilers1
__POCC__ Pelles C3
__LCC__ Lcc-win323
  1. _MSC_VER is defined as 1200 for Microsoft Visual C++ 6.0
    _MSC_VER is defined as 1300 for Microsoft Visual C++ .NET 2003
    _MSC_VER is defined as 1400 for Microsoft Visual C++ 2005 (includes VC++ 2005 Express)
  2. Refer to _mingw.h. Version information is defined with three macros, namely __MINGW32_VERSION, __MINGW32_MAJOR_VERSION and __MINGW32_MINOR_VERSION. _mingw.h is included by default (except, at the time of writing, by windres, the resource compiler).
  3. These are exclusively 'C' compilers and will not be discussed further


I use what is euphemistically referred to as UK or GB english throughout this site. Exceptions include, but are not necessarily limited to, the use of the word 'dialog' instead of 'dialogue' when discussing 'dialog boxes'.