Programmers who come from a C programming background will be familiar with the C language pre-processor.

This is a stage in the compilation process that performs some processing on the source code prior to it being compiled.

Typically, this allows for the substitution of constant values, the expansion of macros (small fragments of code that are used very often) and the conditional inclusion or exclusion of code usually based on the platform being used.

Standard JavaScript does not support this functionality but several embedded interpreter products do, as does the ScriptEase interpreter. Now, it is available in JScript although you should limit its use to those situations where you know the script will be executed on a compliant system.

To avoid problems with non-compliant systems, you should place the pre-processor directives inside comment blocks. This at least will hide them from the platforms that don't support this capability. However, you need to be aware of how your script will behave if the pre-processor directives are ignored. This can become quite complex and may outweigh any advantages of using the pre-processor. You must make provision for this if your scripts need to run on Netscape Navigator for example, because it will cause an interpretation error when it sees the @ symbol at the beginning of each directive.

The leading comment should be placed immediately in front of the @ symbol. The trailing comment delimiter should have an additional @ sign to indicate it matches the prefixing comment symbol. So the activation directive:

@cc_on

Should be coded like this:

/*@cc_on@*/

In a predictable environment, there are no concerns about portability and you need not use the comment encapsulation technique to hide the directives.

Placing the pre-processor directives inside quotes makes them ineffective.

Undefined values return the NaN value. There are no error reports when a directive that does not exist is used. However, placing a trailing @ symbol without it being part of the comment hiding mechanism will generate a parsing error.

Warnings:

• Note that each implementation of a pre-processor is implementation-specific. There are as yet no standards for this and there are several alternative and mutually non-compliant alternatives. Some copy the C language pre-processor directives and commence with a hash symbol (#) while others use a completely different syntax altogether (for example JScript with its @ symbol).

• Although this capability was introduced in JScript 3.0, which was available in version 4 of MSIE, attempting to use the pre-processor directives may well crash a Macintosh version 4.5 MSIE browser. Some directives may work in certain restricted situations.

• MSIE version 5 for Macintosh exhibits some shortcomings in its implementation of the platform detection mechanisms.