97cpp.gml

来自「开放源码的编译器open watcom 1.6.0版的源代码」· GML 代码 · 共 424 行 · 第 1/2 页

:P.
Improvements to the loading of
pre-compiled header files increased the
compilation speed.  The reduction of data was aided
by instrumenting the compiler internally to produce
reports on what was happening in the compiler.
This allowed us to modify our input into the compiler
so that repeated compiles were faster than our fastest
competitor.


:LI.
The compilation of class and function templates is still
an ad hoc process.  The internals of the compiler seem
to be robust enough to handle most templates but because
the ISO C++ Draft WP is still not very precise, it is difficult
to decide when to overhaul the compiler handling of templates.
:P.
This year saw the incremental improvement of the template
handling of the compiler.  We hope to add some of the new
features in the ISO C++ Draft WP in the near future.


:LI.
A common theme in the development of the C++ compiler has been
the balance between conformance to the ISO C++ Draft WP and maintaining
compatibility with legacy source code.  The competitive pressure
to adopt subtle changes that allow the Watcom C++ compiler to
compile our competitor's source code is also present.
We have taken the path of issuing warnings in preference to
hard errors for violations that can still generate acceptable
code.  This allows us to diagnose problems in source code
for users that are concerned about minimizing problems but
still support compilation of legacy source code without any
hard errors.
:P.
Another problem with conformance to the ISO C++ Draft WP is that
the standard is still highly volatile and subject to change.
We have taken the stand that we won't implement anything
unless it has survived for roughly a year without change.
Even this conservative manner has resulted in our having
to change the compiler because of a substantial change in
the ISO C++ Draft WP.  We continue to attend the standards
committee meeting in the hope that we can minimize these
kinds of surprises.

:LI. Since the majority of namespace functionality has remained
constant within the ISO C++ Draft WP for approximately a year, that
feature was implemented.  Extensive reverse engineering of other
implementations was performed in order to provide compatibility
code that must be compiled on different systems.  Our proprietory
test suite was upgraded to thoroughly test the new features.
:P.
Some of the technical hurdles that had to be crossed include
enhancing the name mangling syntax to support the new namespace
identifiers.  Fortunately, the name mangling syntax was flexible
enough to accept new additions.
:P.
Namespaces required a generalization
of file scope to be performed within the compiler since previously
there was only one file scope (now named global namespace scope).
There was a lot of code in the compiler that made the assumption
that there was only one file scope.  This code had to be changed
to reflect the new reality of multiple file scopes.
:P.
Namespaces introduced a new feature called unnamed namespaces
that have the property that anything defined or declared within
them will be local to the compilation unit.  This is a very
powerful feature since previously it was impossible to declare
a named class that was guaranteed to be local to the compilation
unit.  The technical challenges here include enhancing the compiler
to automatically localize object file references and definitions
so that the linker will not make them public items.  There are
some cases where items must stay public, so in this case, the
compiler used an innovative hash algorithm to create a (hopefully)
unique name to attach to the public item.  The unique name
had two components, a part which guaranteed uniqueness within
the module and another part that tried to achieve uniqueness
from all other modules.  Of course, it is theoretically possible
for a name to collide with another compilation unit's unnamed
namespace but there are enough safeguards that the programmer
can simply recompile one of the offending modules to correct
the problem.
:P.
Overall, the Watcom C++ implementation of namespaces allows
a programmer to seamlessly use the new feature while maintaining
source compatibility with older C++ code.  In fact, namespaces
are already in use within the Watcom R&D development team.

:LI. Since the majority of the Run-Time Type Identification (RTTI)
functionality has remained
constant within the ISO C++ Draft WP for approximately a year, that
feature was implemented.
This also implementation of new conversions and new casting operations.
Extensive reverse engineering of other
implementations was performed in order to provide compatibility
code that must be compiled on different systems.  Our proprietory
test suite was upgraded to thoroughly test the new features.
:P.
As one of the few compiler vendors to support RTTI in older platforms,
the task of coming up with a suitable object model representation
was an important technical problem that had to be solved.
The RTTI information must be "attached" to classes with virtual functions
so it was clear that the information must be attached to the
virtual function table used to implement virtual functions.
The representation had to satisfy the following constraints:
(1) support all required C++ RTTI semantics
(2) occupy minimal space (important for 16-bit architectures)
(3) support reasonably time efficient operations
(4) support mixing non-RTTI classes
(5) perform correctly during construction and destruction
(6) share information with EH but without requiring EH to be used
(7) support rival vendor enhancements
:P.
The resulting RTTI data structure designed satisfies all of these
constraints.  For 16-bit compilers it is still possible that the
compiler could not represent the required information in one
16-bit segment limited to 64k bytes in length.  The design of
the representation is efficient enough that hierarchies with
thousands of classes can be represented properly (the actual limit
is around 5000 for real-life class hierarchies).  The compiler
will diagnose a problem if the representation will not fit
in a 64k byte segment so it will never violate any architectural
constraints.
:P.
Performing correctly during construction and destruction requires
the use of constructor displacements which have been part of the
C++ compiler object model from the beginning.  The RTTI structure
has information that allows the run-time support to use the
displacement integer to compensate for virtual base layouts
that may be different from the layout when the RTTI descriptor
was generated.  This is currently an innovation since no other
commercial C++ vendor supports this nuance of the C++ language
properly.
:P.
Overall, the RTTI support in the Watcom C++ compiler provides
excellent support for all of the language semantics in a
time and space efficient manner.  The manner in which the
C++ compiler supports RTTI allows a highly flexible set
of possibilities for a programmer to incorporate RTTI
into an existing or new C++ application.


:eUL.

:H5.Run-time libraries

:P.
The Watcom C++ run-time libraries were all developed by Watcom.
Watcom has implemented compiler support routines,
as well as String, Complex and iostreams class libraries.
The industry has only settled on de facto standards for behaviour
in the area of the iostreams class library.
The current ISO C++ Draft standard does not fully define the behaviour
required of the runtime library.
:P.
The tug between existing code and the new ISO C++ Draft Working Paper
continues.  This often requires delicate changes to the various
C++ run-time libraries to maintain an acceptable balance between
these opposing forces.


:H6.The compiler support routines

:P.
The ISO C++ Draft standard was changed to specify that the life-time of 
temporary objects is the duration of a statement. The WATCOM compiler
was implemented with life-times being the duration of a scope.
:P
To support this new definition,
the Watcom C++ compiler exception handling mechanism was restructured.
This required a complete rewrite of most the compiler support routines
because the destruction of objects and exception-handling are an integrated
feature of the language.
:P
The new implementation allows both inline destruction and table-driven (using
run-time routines) destruction of objects.  This increased flexibility permits
a user to generate code optimized for space or time in various ways.
:P.
The use of Operating System specific exception handling mechanisms has
been used in the C++ compiler run-time.  This enables high-speed registration
of exception handling "book keeping" data structures for multi-threaded
applications.  Watcom is exploring the use of more OS-specific exception
handling mechanisms.


:H6.The iostreams class library

:P.
To ensure compatibility with the largest
number of users of the iostreams class library, competitive products,
the draft specification and published works were consulted.
The Watcom iostreams class library was evaluated in terms of conformance
to the de facto industry standard.
:P.
In the process of researching and evaluating the Watcom iostreams
class library conformance an extensive set of test programs were created.
These programs were then bundled into an automated test stream
to ensure continued conformance in the face of future demands on the library.
The construction of the automated test stream environment was complicated
by the multi-platform nature of the Watcom tools.
Each test program is run under all platforms that are supported and must
always produce identical results.  Building the infrastructure required
to support this form of automated test execution and output collection
and verification required further development.
:P.
Additional work was done to ensure that the iostreams class library
performance was in keeping with the Watcom standard for excellence.
This involved creating benchmark programs and then running these
with competitive products.  Deficiencies were found in the Watcom support.
The class library was then modified to address these deficiencies.