writing_a_be

这是广泛使用的通信开源项目,对于大容量,高并发的通讯要求完全能够胜任,他广泛可用于网络游戏医学图像网关的高qos要求.更详细的内容可阅读相应的材料

OMG INTERFACE DEFINITION LANGUAGE COMPILER FRONT END PROTOCOLS
==============================================================

INTRODUCTION
------------

Welcome to the publicly available source release of SunSoft's
implementation of the compiler front end (CFE) for OMG Interface Definition
Language!

This document explains how to use the release to create a fully functional
OMG Interface Definition Language to target language compiler for your
selected target system configuration. The section OVERVIEW explains this
document's structure.

CONTEXT
-------

The implementation has three parts:

1. A main program driving the compilation process
2. A parser and attendant utilities for converting the IDL input into
   an internal form
3. One or more back ends which take as input the internal form representing
   the IDL input, and which produce output in a target language and target
   format

The release contains components 1 and 2, and a demonstration implementation
of component 3. To use this release, you

- write a back end which takes the internal representation of the parsed input
  and translates it to the target language and format. You may replace or
  modify the demonstration back end provided.
- link the back end with the provided main program and parser sources
  to produce a complete compiler.

OVERVIEW
--------

This document does not explain IDL nor does it introduce IDL features. 
For this information, refer to the OMG CORBA specification, available by
anonymous FTP from omg.org.

This document does not explain C++, except to demonstrate how it is
used to construct the CFE. The ARM by Stroustrup and Ellis provides a
thorough explanation of C++.

This document consists of two independent parts. The first part
s all CFE supported protocols and the required
application programmer's interface entry points that a conformant 
BE must provide. The second part steps through the process of
constructing a working BE.

The first part describes:

- The compilation process
- The Abstract Syntax Tree (AST) internal representation of parsed IDL
  input
- How access to member data fields is managed
- How the AST is generated from the IDL input (Generator protocol)
- How definition scopes are nested and how name lookup works
- The narrowing mechanism
- How definition scopes are managed and how nodes are added to scopes
- How BEs get control during the AST construction process (Add protocol)
- The inheritance scheme used by the AST and how it affects BEs
- How errors are handled and reported
- How the CFE is initialized
- How the command line arguments are parsed
- What global variables and functions are provided
- What API is required to be supported by a BE in order to link
  with the CFE
- What files must be included in each BE file

The second part describes

- The API to be supplied by each BE
- How to subclass from the AST to add BE specific functionality
- How to subclass from the Generator protocol to create BE specific
  extended AST nodes
- How to write constructors for the derived BE classes
- How to use the Add protocol to store BE specific information
- How to maintain BE specific information which applies to the entire
  AST generated from the IDL input
- How to use data members in your BE
- How to build a complete compiler

PART I. FEATURES OF THE CFE
-=========================-

THE COMPILATION PROCESS
-----------------------

The OMG IDL compiler operates as follows:

- Parses command line arguments. If an option is directed at a
  BE, an appropriate operation provided by the BE is invoked to process
  the option.
- Performs global initialization.
- Forks a copy of the compiler for each file specified as input.
- An ANSI-compatible preprocessor preprocesses the IDL input.
- Parses the file using the CFE parser, and constructs an AST describing the
  IDL input.
- Prints the AST for verification, if requested.
- Invokes the BE to process the AST and produce the output
  characteristic of that BE.

ABSTRACT SYNTAX TREE
--------------------

The AST (Abstract Syntax Tree) is the primary mechanism for communication
between a BE and the CFE. It consists of a tree of instances of classes
defined in the CFE or refinements of those classes as defined in a BE.
The class hierarchy of the AST closely resembles the structure of the IDL
syntax. Most AST classes have direct equivalents in IDL constructs.

The UTL_Scope class defines common functionality for definition scope
management and name lookup. This is explained in a following section.
UTL_Scope is defined in include/utl_scope.hh and implemented in
util/utl_scope.cc.

The AST provides the following classes:

AST_Decl	    Base of the AST class hierarchy. Each class in the AST
		    inherits from AST_Decl. Defined in include/ast_decl.hh
		    and implemented in ast/ast_decl.cc

AST_Type	    Common base class for all classes which represent IDL
		    type constructs. Defined in include/ast_type.hh and
		    implemented in ast/ast_type.cc. Inherits from AST_Decl.

AST_ConcreteType    Common base class for all classes which represent IDL
		    types other than interfaces. Defined in the file
		    include/ast_concrete_type.hh and implemented in
		    ast/ast_concrete_type.cc. Inherits from AST_Type.

AST_PredefinedType  Instances of this class represent all predefined types
		    such as long, char and so forth. Defined in the file
		    include/ast_predefined_type.hh and implemented in
		    ast/ast_predefined_type.cc. Inherits from
		    AST_ConcreteType.

AST_Module	    Represents the IDL module construct. Defined in the
		    file include/ast_module.hh and implemented in
		    ast/ast_module.cc. Inherits from AST_Decl and
		    UTL_Scope.

AST_Root	    Represents the root of the abstract syntax tree being
		    constructed. Is a subclass of AST_Module. Can be
		    subclassed in BEs to store information associated with
		    the entire AST. Defined in the file include/ast_root.hh
		    and implemented in ast/ast_root.cc. Inherits from
		    AST_Module.

AST_Interface	    Represents the IDL interface construct. Defined in
		    include/ast_interface.hh and implemented in the file
		    ast/ast_interface.cc. Inherits from AST_Type and
		    UTL_Scope.

AST_InterfaceFwd    Represents a forward declaration of an IDL interface.
		    Defined in include/ast_interface_fwd.hh and implemented
		    in ast/ast_interface_fwd.cc. Inherits from AST_Decl.

AST_Attribute	    Represents an IDL attribute construct. Defined in
		    include/ast_attribute.hh and implemented in the file
		    ast/ast_attribute.cc. Inherits from AST_Decl.

AST_Exception	    Represents an IDL exception construct. Defined in
		    include/ast_exception.hh and implemented in the file
		    ast/ast_exception.cc. Inherits from AST_Decl.

AST_Structure	    Represents an IDL struct construct. Defined in the file
		    include/ast_structure.hh and implemented in the file
		    ast/ast_structure.cc. Inherits from AST_ConcreteType
		    and UTL_Scope.

AST_Field	    Represents a field in an IDL struct or exception
		    construct. Defined in include/ast_field.hh and
		    implemented in ast/ast_field.cc. Inherits from
		    AST_Decl.

AST_Operation	    Represents an IDL operation construct. Defined in the
		    file include/ast_operation.hh and implemented in
		    ast/ast_operation.cc. Inherits from AST_Decl and
		    UTL_Scope.

AST_Argument	    Represents an argument to an IDL operation construct.
		    Defined in include/ast_argument.hh and implemented in
		    ast/ast_argument.cc. Inherits from AST_Field.

AST_Union	    Represents an IDL union construct. Defined in
		    include/ast_union.hh and implemented in
		    ast/ast_union.cc. Inherits from AST_ConcreteType and
		    from UTL_Scope.

AST_UnionBranch	    Represents an individual branch in an IDL union
		    construct. Defined in include/ast_union_branch.hh and
		    implemented in ast/ast_union_branch.cc. Inherits from
		    AST_Field.

AST_UnionLabel	    Represents the label of an individual branch in an IDL
		    union construct. Defined in include/ast_union_label.hh
		    and implemented in ast/ast_union_label.cc

AST_Constant	    Represents an IDL constant construct. Defined in
		    include/ast_constant.hh and implemented in the file
		    ast/ast_constant.cc. Inherits from AST_Decl.

AST_Enum	    Represents an IDL enum construct. Defined in the file
		    include/ast_enum.hh and implemented in ast/ast_enum.cc.
		    Inherits from AST_ConcreteType and UTL_Scope.

AST_EnumVal	    Represents an enumerator in an IDL enum construct.
		    Defined in include/ast_enum_val.hh and implemented in
		    ast/ast_enum_val.cc. Inherits from AST_Constant.

AST_Sequence	    Represents an IDL sequence construct. Defined in
		    include/ast_sequence.hh and implemented in
		    ast/ast_sequence.cc. Inherits from AST_Decl.

AST_String	    Represents an IDL string construct. Defined in the file
		    include/ast_string.hh and implemented in
		    ast/ast_string.cc. Inherits from AST_Decl.

AST_Array	    Represents an array modifier to the type of an IDL
		    field or typedef declaration. Defined in the file
		    include/ast_array.hh and implemented in
		    ast/ast_array.cc. Inherits from AST_Decl.

AST_Typedef	    Represents an IDL typedef construct. Defined in the file
		    include/ast_typedef.hh and implemented in
		    ast/ast_typedef.cc. Inherits from AST_Decl.

AST_Expression	    Represents an IDL expression. Defined in the file
		    include/ast_expression.hh and implemented in
		    ast/ast_expression.cc.

AST_Root	    A subclass of AST_Module, an instance of this class
		    is used to represent the distinguished root node of
		    the AST. Defined in include/ast_root.hh and implemented
		    in ast/ast_root.cc. Inherits from AST_Module.


USING INSTANCE DATA
-------------------

The AST classes define member data fields in addition to defining
operations on instances. These member data fields are all private, to allow
only the instance in which they are stored direct access. Other objects
(including other instances of the same class) can obtain access to the
member data fields of an instance through accessor functions. These
accessor functions allow retrieval of the data, and in some cases update
functions are also provided to store new values.

There are several reasons why this approach is taken. First, it hides the
actual implementation of the member data fields from outside the class. For
example, a Thermometer class would not expose whether its temperature
reading is stored in Farenheit or Celsius units, and it could allow access
through either unit method.

Second, protecting access to member data in this manner restricts the
ability to update it to the instance itself, save where update functions
are explicitly provided. This makes for more reliable implementations,
since the manipulation of the data is isolated in the class implementation
itself.

Third, wrapping a function call around access to member data allows such
access and update operations to be protected in a multithreaded
environment. While the CFE itself is not multithreaded and the access
operations as currently defined do no special work to protect against
mutliple conflicting access operations, this may be changed in a future
version. Moving the CFE to a multithreaded environment without protecting
access to member data in this manner would be extremely difficult.

The protocol defined in the CFE is that member data fields are all private
and have names which start with the prefix "pd_" (denoting Private Data).
The access functions have names which are the same as the name of the field
sans the prefix. For example, AST_Decl has a field pd_defined_in and an
access function defined_in().

The update functions have names starting with "set_" followed by the name
of the corresponding access function. Thus, AST_Decl defines a function
set_in_main_file(boolean) which sets the pd_in_main_file data member's
value to the boolean provided.

GENERATION OF THE AST
---------------------

The CFE generates the abstract syntax tree after parsing IDL
input. The nodes of the AST are defined by classes introduced in the
previous section, or by subclasses thereof as defined by each BE. In
writing the CFE, we were faced with the following problem: how to generate
the AST containing nodes of the derived classes as defined in each BE
without knowledge of the types and conventions of these BE classes.

One alternative was to define a naming scheme which predetermines the names
of each subclass a BE can define. The AST would then be generated by
calling an appropriate constructor on the BE derived class. This scheme
suffers from some shortcomings:

- It breaks the modularity of the compiler and imports knowledge about
  types defined in a BE into the CFE, where this information does not belong.
- It restricts a compiler to having only one BE loaded at a time because the
  names of these classes can be in use in only one BE at a time.
- It requires a BE to provide derived classes for all AST classes, even for
  those classes where the BE adds no functionality.

The mechanism we chose is different. We define the AST_Generator class
which has an operation for each constructor defined on each AST class. The
operation takes arguments appropriate to the constructor, invokes it and
returns the created AST node, using the type known to the CFE. All such
operations on the generator are declared virtual. The names of all
operations start with "create_" and contain the name of the construct.
Thus, an operation which invokes a constructor of an AST_Module is named
create_module. AST_Generator is defined in include/ast_generator.hh and
implemented in ast/ast_generator.cc.

If a BE derives from any AST class, it must also derive from the
AST_Generator class and redefine the relevant operations to invoke
constructors of the BE provided class instead of the AST provided class.
For example, if BE_Module is a subclass of AST_Module in a BE, the BE would
also define BE_Generator and redefine create_module to call the constructor
of BE_Module instead of that provided by AST_Module.

During initialization, the CFE causes an instance of the BE derived
generator to be created and saved. This is explained in the section on
REQUIRED ENTRY POINTS SUPPLIED BY A BE. During parsing, actions in the Yacc
grammar invoke operations on the saved instance to create new nodes for the
AST as it is being built. These operations invoke constructors for BE
derived classes or for AST provided classes if they were not overridden.

DEFINITION SCOPES
-----------------

IDL is a nested scoped language. The scoping rules are defined by the CORBA
spec and closely follow those of C++.

Scope management is implemented in two classes provided in the utilities
library, UTL_Scope and UTL_Stack. UTL_Scope manages associations between