cpwcc.gml

开放源码的编译器open watcom 1.6.0版的源代码

.exam end
.pc
The compiler generates code for
.fi gopks.c(pp)
and places it into the "GKS" group.
If the "g" option had not been specified, the code would not have
been placed in any group.
Assume that this file contains the definition of the routine
.id gopengks
as follows:
.millust begin
void far gopengks( int workstation, long int h )
{
    .
    .
    .
}
.millust end
.pc
For a small code model, the routine
.id gopengks
must be defined in this file as
.kwm far
since it is placed in another group.
The "s" option is also specified to prevent a run-time call to the
stack overflow check routine which will be placed in a different
code segment at link time.
The
.id gopengks
routine must be prototyped by C routines in other groups as
.millust begin
void far gopengks( int workstation, long int h );
.millust end
.pc
since it will appear in a different code segment.
.*
.section *refid=wccfast Benchmarking Hints
.*
:INCLUDE file='CPBENCH'
.*
.section *refid=wccdiag Compiler Diagnostics
.*
.np
.ix 'diagnostics' '&product'
.ix 'error file' '&err'
If the compiler prints diagnostic messages to the screen, it will also
place a copy of these messages in a file in your current directory.
The file will have the same file name as the source file and an
extension of "&err".
The compiler issues two types of diagnostic messages, namely
warnings or errors.
A warning message does not prevent the production of an object
file.
However, error messages indicate that a problem is severe enough
that it must be corrected before the compiler will produce an
object file.
The error file is a handy reference when you wish to correct the
errors in the source file.
.np
Just to illustrate the diagnostic features of &product, we will modify
the "hello" program in such a way as to introduce some errors.
.exam begin
#include <stdio.h>

int main()
  {
     int x;
     printf( "Hello world\n" );
     return( y );
  }
.exam end
.np
The equivalent C++ program follows:
.exam begin
#include <iostream.h>
#include <iomanip.h>

int main()
{
    int x;
    cout << "Hello world" << endl;
    return( y );
}
.exam end
.np
In this example, we have added the lines:
.millust begin
int x;
.millust end
.pc
and
.millust begin
return( y );
.millust end
.pc
and changed the keyword
.kwm void
to
.kwm int.
.np
We compile the program with the "warning" option.
.exam begin 1
&prompt.:SF font=1.compiler_name:eSF. hello &sw.w3
.exam end
.np
For the C program, the following output appears on the screen.
.code begin
hello.c(7): Error! E1011: Symbol 'y' has not been declared
hello.c(5): Warning! W202: Symbol 'x' has been defined, but not
                           referenced
hello.c: 8 lines, included 174, 1 warnings, 1 errors
.code end
.np
For the C++ program, the following output appears on the screen.
.code begin
hello.cpp(8): Error! E029: (col 13) symbol 'y' has not been declared
hello.cpp(9): Warning! W014: (col 1) no reference to symbol 'x'
hello.cpp(9): Note! N392: (col 1) 'int x' in 'int main( void )'
              defined in: hello.cpp(6) (col 9)
hello.cpp: 9 lines, included 1628, 1 warning, 1 error
.code end
.np
.ix 'diagnostics' 'error'
.ix 'diagnostics' 'warning'
Here we see an example of both types of messages.
An error and a warning message have been issued.
As indicated by the error message, we require a declarative
statement for the identifier
.id y.
The warning message indicates that, while it is not a violation of
the rules of &lang. to define a variable without ever using it, we
probably did not intend to do so.
Upon examining the program, we find that:
.autopoint
.point
the variable
.id x
should have been assigned a value, and
.point
the variable
.id y
has probably been incorrectly typed and should have been entered as
.id x.
.endpoint
.if &e'&dohelp eq 0 .do begin
.np
The complete list of &product diagnostic messages is presented
in an appendix of this guide.
.do end
.*
.section *refid=wccinc &product #include File Processing
.*
.np
.ix 'include' 'directive'
.ix 'include' 'header file'
.ix 'include' 'source file'
.ix 'header file' 'including'
.ix 'source file' 'including'
.ix '#include'
When using the
.id #include
preprocessor directive, a header is identified by a sequence of
characters placed between the "<" and ">" delimiters (e.g., <file>)
and a source file is identified by a sequence of characters enclosed
by quotation marks (e.g., "file").
&product makes a distinction between the use of "<>" or quotation
marks to surround the name of the file to be included.
The search techniques for header files and source files are slightly
different.
Consider the following example.
.exam begin 2
#include <stdio.h>  /* a system header file */
#include "stdio.h"  /* your own header or source file */
.exam end
.pc
You should use "<" and ">" when referring to standard or system header
files and quotation marks when referring to your own header and source
files.
.np
The character sequence placed between the delimiters in an
.id #include
directive represents the name of the file to be included.
The file name may include &drive, path, and extension.
.np
It is not necessary to include the &drive and path specifiers in the
file specification when the file resides on a different &drive or in a
different directory.
&product provides a mechanism for looking up include files which may
be located in various directories and disks of the computer system.
&product searches directories for header and source files in the
following order (the search stops once the file has been located):
.ix 'include file' 'searching'
.ix 'header file' 'searching'
.ix 'source file' 'searching'
.autonote
.note
If the file specification enclosed in quotation marks ("file-spec") or
angle brackets (<file-spec>) contains the complete &drive and path
specification, that file is included (provided it exists).
No other searching is performed.
The &drive need not be specified in which case the current &drive is
assumed.
.note
If the file specification is enclosed in quotation marks, the current
directory is searched.
.note
Next, if the file specification is enclosed in quotation marks, the
directory of the file containing the
.id #include
directive is searched.
If the current file is also an
.id #include
file, the directory of the parent file is searched next.
This search continues recursively through all the nested
.id #include
files until the original source file's directory is searched.
.note
.ix 'options' 'i'
Next, if the file specification enclosed in quotation marks
("file-spec") or in angle brackets (<file-spec>), each directory
listed in the "i" path is searched (in the order that they were
specified).
.note
.ix 'options' 'bt'
Next, each directory listed in the
.ev <os>_INCLUDE
environment variable is searched (in the order that they were
specified).
The environment variable name is constructed from the current build
target name.
The default build targets are:
.begpoint
.point DOS
when the host operating system is DOS,
.point OS2
when the host operating system is OS/2,
.point NT
when the host operating system is Windows NT/95, or
.point QNX
when the host operating system is QNX.
.endpoint
.np
For example, the environment variable
.ev OS2_INCLUDE
will be searched if the build target is "OS2".
The build target would be OS/2 if:
.autopoint
.point
the host operating system is OS/2 and the "bt" option was not
specified, or
.point
the "bt=OS2" option was explicitly specified.
.endpoint
.note
Next, each directory listed in the
.ev &incvarup
environment variable is searched (in the order that they were
specified).
.note
.ix '&hdrdirup directory'
Finally, if the file specification is enclosed in quotation marks, an
adjacent "H" directory (i.e.,
.fi ~..&pc.h
.ct ) is searched if it exists.
.endnote
.np
In the above example,
.id <stdio.h>
and
.id "stdio.h"
could refer to two different files if there is a
.fi stdio.h
in the current directory and one in the &product include file
directory
.fi (&pathnamup&hdrdirup)
and the current directory is not listed in an "i" path or the
.ev &incvarup
environment variable.
.np
The compiler will search the directories listed in "i" paths (see
description of the "i" option) and the
.ev &incvarup
environment variable in a manner analogous to that which the operating
system shell will use when searching for programs by using the
.ev PATH
environment variable.
.np
The "&setcmdup" command is used to define an
.ev &incvarup
environment variable that contains a list of directories.
.ix '&setcmdup' '&incvarup environment variable'
A command of the form
.if '&target' eq 'QNX' .do begin
.millust begin
&setcmd &incvarup=path&ps.path...
.millust end
.do end
.el .do begin
.millust begin
&setcmdup &incvarup=[d:]path;[d:]path...
.millust end
.do end
.pc
is issued before running &product the first time.
.if '&target' ne 'QNX' .do begin
The brackets indicate that the drive "d:" is optional and the ellipsis
indicates that any number of paths may be specified.
For Windows NT, use the "System" icon in the Control Panel to define
environment variables.
.do end
.np
We illustrate the use of the
.id #include
directive in the following example.
.exam begin
#include <stdio.h>
#include <time.h>
#include <dos.h>
.exam break
#include "common.c"

int main()
  {
    initialize();
    update_files();
    create_report();
    finalize();
  }
.exam break
#include "part1.c"
#include "part2.c"
.exam end
.pc
If the above text is stored in the source file
.fi report.c
in the current directory then we might issue the following commands to
compile the application.
.exam begin 5
.if '&target' ne 'QNX' .do begin
&prompt.rem -- Two places to look for include files
.do end
&prompt.&setcmd &incvar=&dr3.&pathnam.&hdrdir.&ps.&dr2.&pc.headers
.if '&target' ne 'QNX' .do begin
&prompt.rem -- Now compile application specifying a
&prompt.rem    third location for include files
.do end
&prompt.:SF font=1.compiler_name:eSF. report &sw.fo=..&pc.obj&pc &sw.i=..&pc.source
.exam end
.pc
.ix '&setcmdup' '&incvarup environment variable'
In the above example, the "&setcmdup" command is used to define the
.ev &incvarup
environment variable.
It specifies that the
.fi &pathnam&hdrdir
directory
.if '&target' eq 'QNX' .do begin
(of the current node)
.do end
.el .do begin
(of the "C" disk)
.do end
and the
.fi &pc.headers
directory
.if '&target' eq 'QNX' .do begin
(a directory on node 1)
.do end
.el .do begin
(a directory of the "B" disk)
.do end
are to be searched.
.np
.ix 'options' 'i'
The &product "i" option defines a third place to search for
include files.
The advantage of the
.ev &incvarup
environment variable is that it need not be specified each time the
compiler is run.
.*
.section *refid=wccprep &product Preprocessor
.*
.np
.ix 'preprocessor'
The &product preprocessor forms an integral part of &product..
When any form of the "p" option is specified, only the preprocessor is
invoked.
No code is generated and no object file is produced.
The output of the preprocessor is written to the standard output file,
although it can also be redirected to a file using the "fo" option.
Suppose the following &lang. program is contained in the file
.fi msgid.c.
.keep 20
.exam begin
#define _IBMPC 0
#define _IBMPS2 1

#if _TARGET == _IBMPS2
char *SysId = { "IBM PS/2" };
#else
char *SysId = { "IBM PC" };
#endif

/* Return pointer to System Identification */

char *GetSysId()
  {
    return( SysId );
  }
.exam end
.pc
We can use the &product preprocessor to generate the &lang. code that
would actually be compiled by the compiler by issuing the following
command.
.exam begin 1
&prompt.:SF font=1.compiler_name:eSF. msgid &sw.plc &sw.fo &sw.d_TARGET=_IBMPS2
.exam end
.pc
The file
.fi msgid&pxt
will be created and will contain the following &lang. code.
.millust begin
#line 1 "msgid.c"




char *SysId = { "IBM PS/2" };
#line 9 "msgid.c"

/* Return pointer to System Identification */

char *GetSysId()
  {
    return( SysId );
  }
.millust end
.pc
Note that the file
.fi msgid&pxt
can be used as input to the compiler.
.exam begin 1
&prompt.:SF font=1.compiler_name:eSF. msgid&pxt
.exam end
.pc
Since
.id #line