ISO IEC 14750:1999 pdf download – Information technology一Open Distributed Processing一Interface Definition Language

ISO IEC 14750:1999 pdf download – Information technology一Open Distributed Processing一Interface Definition Language.
4 ODP IDE syntax and semantics
ODP IDL (the Interface Definition Language) is the language used to desciibe the interface signatures for interfaces that client objects call and object implementations provide. An interface definition written in O1)P 11)1. completely defines the interface signature and fully spec ilies each operation’s parameters.
An ODP 11)1. specification logically consists of one or more files. A tile is conceptually translated in several phases. The first phase is preprocessing, which performs file inclusion and macro substitution. Preprocessing is controlled by directives introduced by lines having # as the first character other than white space. The result of the preprocessing is a sequence of tokens. Such a sequence of tokens, that is. a file after preprocessing, is called a translation unit.
ODP IDL obeys the same lexical rules as C++’). although new keywords are introduced to support distribution concepts. It also provides full support for standard C++ preprocessing features. The ODP IDI. specification is expected to track relevant changes to C++ introduced by the ISO/IEC standardi,ation effort.
The description of Ol)P ll)Ls lexical conventions is presented in 4.1. A description of ODP ll)L preprocessing is presented in 4,2. The scope rules for identifiers in an ODP IDL specification are described in 4.13 on.
The ODP IDL grammar is a subset of ISO/IEC C++ with additional constructs to support the operation invocation mechanism. ODP IDL is a descriptive language: it supports C++ syntax for constant, type. and operation declarations; it does not include any algorithmic structures or variables. The grammar is presented in 4.3.
This clause describes ODP IDL semantics and gives the syntax for ODP IDL grammatical constructs. The description of ODP IDL grammar uses a syntax notation that is similar to Extended Backus-Naur format (EBNF). Table I lists the symbols used in this format and their meaning.
4.1.1
Tokens
There are five kinds of tokens: identifiers, keywords, literals, operators, and other separators. Blanks, horizontal and
vertical tabs, newlines, formfeeds, and comments (collective, ” white space”), as described below, are ignored except as
they serve to separate tokens. Some white space is required to separate otherwise adjacent identifiers, keywords, and
constants.
If the input stream has been parsed into tokens up to a given character, the next token is taken to be the longest string of
characters that could possibly constitute a token.
4.1.2
Comments
The characters /* start a comment, which terminates with the characters */. These comments do not nest. The
characters // start a comment which terminates at the end of the line on which they occur. The comment characters //, /*,
ind */ have no special meaning within a // comment and are treated just like other characters. Similarly, the comment
characters // and /* have no special meaning within a /* comment. Comments may contain alphabetic, digit, graphic,
space, horizontal tab, vertical tab, form feed and newline characters.
4.1.3
Identifers
An identifier is an arbitrarily long sequence of alphabetic, digit, and underscore (“. “) characters. The first character must
be an alphabetic character. All characters are significant.
Identifiers that differ only in case collide and yield a compilation error. An identifier for a definition must be spelled
consistently (with respect to case) throughout a specification.
When comparing two identifiers to see if they collide:
●Upper- and lower-case ltters are treated as the same ltter. Table 2 defines the equivalence mapping of
upper- and lower-case ltters.
The comparison does nor take into account equivalences between digraphs and pairs of letters (e.g. “x”
and “ae” are not considered equivalent) or equivalences between accented and non- accented letters
(e.g. “a” and “a” are not considered equivalent).
AIll characters are significant.
There is only one name space for ODP IDL identifiers. Using the same identifier for a constant and an interface, for
example, produces a compilation error.
4.1.4
Keywords
The identifiers listed in Table 6 reserved for use as keywords, and may not be used otherwise. The keyword object in ODP IDL is used to represent an interface type whereas the keyword interface is used to indicate the start of an interface declaration in an interface signature template. The keyword “object” can be used as a type specifier. The keyword attribute defines a method giving access to a portion of the state of an object. An attribute definition is
logically equivalent to declaring a pair of accessor methods; one to retrieve the value of the attribute and one to set the value of the attribute.