Figure 2-1 Layout of an Object of D Class
| Previous | Contents | Index |
ident __DECCXX_VER string vvuuteeee T5.2-003 --> 50260003 V6.0-001 --> 60090001 |
The only translation limits imposed in DIGITAL C++ are as follows:
| Limit | Meaning |
|---|---|
| 32,767 | Characters in an internal identifier or macro name. |
| 32,767 | Characters in a logical or physical source line. |
| 32,767 | Bytes in the representation of a string literal. This limit does not apply to string literals formed by concatenation. |
| 32,767 | Significant characters in an external identifier. A warning is issued if such an identifier is truncated. |
The numerical limits, as defined in the header files <limits.h> and <float.h>, are as follows:
Numerical limits not described in this list are defined in the Final
Draft International ANSI C++ Standard (FDIS).
2.2.5 Argument-Passing and Return Mechanisms
DIGITAL C++ passes arrays, functions, and class objects with a constructor or destructor by reference. All other objects are passed by value.
If a class has a constructor or a destructor, it is not passed by value. In this case, the compiler calls a copy constructor to copy the object to a temporary location, and passes the address of that location to the called function.
If the return value of a function is a class that has defined a
constructor or destructor or is greater than 64 bits, storage is
allocated by the caller and the address to this storage is passed in
the first parameter to the called function. The called function uses
the storage provided to construct the return value.
2.3 Implementation Extensions and Features
This section describes the extensions and implementation-specific
features of DIGITAL C++ for DIGITAL UNIX systems.
2.3.1 Identifiers
In DIGITAL C++, the dollar sign ($) is a valid character in an identifier.
For each external function with C++ linkage, the compiler decorates the
function name with a representation of the function's type.
2.3.1.1 External Name Encoding
The DIGITAL C++ compiler uses the external name encoding scheme described in the The Annotated C++ Reference Manual, §7.2.1c, with certain modifications. These modifications are necessary so that the encoding scheme does not depend on case distinction in linker names.
For the basic types, the external name encoding scheme is exactly the same as that described in The Annotated C++ Reference Manual, as follows:
| Type | Encoding |
|---|---|
| void | v |
| char | c |
| short | s |
| int | i |
| long | l |
| float | f |
| double | d |
| long double | r |
| ... | e |
| bool | jb |
| wchar_t | jw |
Class names are encoded as described in The Annotated C++ Reference Manual, except that the DEC C++ compiler uses the lowercase q instead of uppercase Q, and denotes the qualifier count as a decimal number followed by an underscore, as follows:
| Class | Notation | Encoding |
|---|---|---|
| simple | Complex | 7Complex |
| qualified | X::YY | q2_1x2yy |
Type modifiers are encoded as follows:
| Modifier | Encoding |
|---|---|
| const | k |
| signed | g |
| volatile | w |
| unsigned | u |
| __unaligned | b |
Type declarators are encoded as follows:
| Type | Notation | Encoding |
|---|---|---|
| array | [10] | a10_ |
| function | () | x |
| pointer | * | p |
| pointer to member | S::* | m1S |
| reference | & | n |
| unnamed enumeration type | h |
If an external name has more than 1022 characters, the DIGITAL C++
compiler truncates the name to 1022 characters. The compiler keeps the
first 1015 characters intact, reduces (hashes) the remaining characters
to a string of 7 characters, and appends the 7 hashed characters to the
first 1015.
2.3.2 Order of Static Object Initialization
Static objects are initialized in declaration order within a
compilation unit and in link order across compilation units.
2.3.3 Integral Conversions
When demoting an integer to a signed integer, if the value is too large to be represented, the result is truncated and the high-order bits are discarded.
Conversions between signed and unsigned integers of the same size
involve no representation change.
2.3.4 Floating-Point Conversions
When converting an integer to a floating-point number that cannot exactly represent the original value, DIGITAL C++ rounds off the result of the conversion to the nearest value that can be represented exactly.
When the result of converting a floating-point number to an integer or other floating-point number at compile time cannot be represented, the DIGITAL C++ compiler issues a diagnostic message.
When converting an integral number or a double floating-point number to a floating-point number that cannot exactly represent the original value, DIGITAL C++ rounds off the result to the nearest value of type float.
When demoting a double value to float, if the converted value is within range but cannot exactly represent the original value, DIGITAL C++ rounds off the result to the nearest representable float value.
DIGITAL C++ performs similar rounding for demotions from long double to double or float.
2.3.5 Explicit Type Conversion
In DIGITAL C++, the expression T() (where T is a simple type specifier) creates an rvalue of the specified type, whose value is determined by default initialization. According to The C++ Programming Language, 3rd Edition, the behavior is undefined if the type is not a class with a constructor, but the ANSI working draft removes this restriction. With this change you can now write:
int i=int(); // i must be initialized to 0
|
The type of the sizeof operator is size_t. In the header file <stddef.h>, this type is defined as unsigned long, which is the type of the integer
that holds the maximum size of an object.
2.3.7 Explicit Type Conversion
A pointer takes up the same amount of memory storage as objects of type long (or the unsigned equivalent). Therefore, a pointer can convert to any of these types and back again without changing its value. No scaling occurs and the representation of the value is unchanged.
Conversions to and from a shorter integer and a pointer are similar to
conversions to and from a shorter integer and unsigned long. If the shorter integer type was
signed, conversion fills the high-order bits of the pointer with copies
of the sign bit.
2.3.8 Multiplicative Operators
The semantics of the division (/) and remainder (%) operator are as follows:
In the following cases of undefined behavior detected at compile time, the DIGITAL C++ compiler issues a warning:
You can subtract pointers to members of the same array. The result is
the number of elements between the two array members, and is of type
ptrdiff_t. In the header file <stddef.h>, DIGITAL C++ defines this
type as long.
2.3.10 Shift Operators
The expression E1>> E2 shifts E1 to the right E2 positions. If E1 has a signed type, DIGITAL C++ fills the
vacated high-order bits of the shifted value E1 with a copy of E1's sign bit (arithmetic shift).
2.3.11 Equality Operators
When comparing two pointers to members, the DIGITAL C++ compiler guarantees equality if either of the following conditions hold:
When comparing two pointers to members, the DIGITAL C++ compiler guarantees inequality if either of the following conditions hold:
When created by different address expressions, two pointers to members
may compare either as equal or as unequal if they produce the same
member when applied to the same object.
2.3.12 Type Specifiers
For variables that are modifiable in ways unknown to the DIGITAL C++
compiler, use the volatile type
specifier. Declaring an object to be volatile means that every
reference to the object in the source code results in a reference to
memory in the object code.
2.3.13 Linkage Specifications
Specifying linkage other than "C++" or "C" generates a compile-time error.
In object files, DIGITAL C++ decorates with type information the
names of functions with C++ linkage. This permits overloading and
provides rudimentary type checking across compilation units. The
type-encoding algorithm used is similar to that given in §7.2.1c
of The Annotated C++ Reference Manual (see Section 2.3.1.1).
2.3.14 Class Layout
The alignment requirements and sizes of structure components affect the
structure's alignment and size. A structure can begin on any byte
boundary and can occupy any integral number of bytes.
2.3.14.1 Structure Alignment
Structure alignment represents the maximum alignment required by any member within the structure. When the structure or union is a member of an array, padding is added to ensure that the size of a record, in bytes, is a multiple of its alignment.
Components of a structure are laid out in memory in the order in which
they are declared. The first component has the same address as the
entire structure. Padding is inserted between components to satisfy
alignment requirements of individual components.
2.3.14.2 Bit-Fields
The presence of bit-fields causes the alignment of the whole structure or union to be at least the same as that of the bit-field's base type.
For bit-fields (including zero-length bit-fields) not immediately declared following other bit-fields, their base type imposes the alignment requirements (less than that of type int). Within the alignment unit (of the same size as the bit-field's base type), bit-fields are allocated from low order to high order. If a bit-field immediately follows another bit-field, the bits are packed into adjacent space in the same unit, if sufficient space remains; otherwise, padding is inserted at the end of the first bit-field and the second bit-field is put into the next unit.
Bit-fields of base type char must be
smaller than 8 bits. Bit-fields of base type short must be smaller than 16 bits.
2.3.14.3 Access Specifiers
The layout of a class is unaffected by the presence of access
specifiers.
2.3.14.4 Class Subobject Offsets
A class object that has one or more base classes contains instances of its base classes as subobjects. The offsets of nonvirtual base class subobjects are less than the offsets of any data members that are not part of base class subobjects.
The offsets of nonvirtual base classes increase in derivation order. The offset of the first nonvirtual base class subobject of any class is 0. For single inheritance, the address of a class object is always the same as the address of its base class subobject.
If a class has virtual functions, an object of that class contains a pointer to a virtual function table (VFPTR). If a class has virtual base classes, an object of that class contains a pointer to a virtual base class table (VBPTR). For a class with no base classes, the offset of a VFPTR or VBPTR is greater than the offset of any data members. Thus, the offset of the first data member of a class with no base classes is 0, which facilitates interoperability with other languages. If the leftmost base class of a class with base classes has a VFPTR, a VBPTR, or both, and is not virtual, the class and its base class share the table or tables.
The offsets of virtual base class subobjects are greater than the offset of any data member, and increase in the order of derivation of the virtual base classes. In increasing order, a class object contains the following:
Consider the following example:
class B1
{
int x[1];
};
class B2 : virtual B1
{
int y[2];
virtual int fl();
};
class B3 : virtual B2, virtual B1
{
int z[3];
virtual int f2();
};
class D : B3
{
int a[4];
virtual int f1(), f2(), f3();
};
|
Figure 2-1 shows the layout of an object of D class for this example.
Figure 2-1 Layout of an Object of D Class
2.3.15 Multiple Base Classes
Within a class object, base class subobjects are allocated in
derivation order; that is, immediate base classes are allocated in the
order in which they appear in the class declaration.
2.3.16 Temporary Objects
Under the following conditions, the compiler creates temporary objects for class objects with constructors:
Variations in the compiler generation of such temporary objects can
adversely affect their reliability in user programs. The compiler
avoids introducing a temporary object whenever it discovers that the
temporary object is not needed for accurate compilation. Therefore, you
should modify or write your programs so as not to depend on side
effects in the constructors or destructors of temporary objects.
2.3.16.1 Nonconstant Reference Initialization with a Temporary Object
If your program tries to initialize a nonconstant reference with a temporary object, the compiler generates a warning. For example:
struct A {
A(int);
};
void f(A& ar);
void g() {
f(5); // warning!!
}
|
DIGITAL C++ optimizes the implementation of exception handling for normal execution, as follows:
In DIGITAL C++, a procedure with handlers has no intrinsic overhead. For example, procedures with handlers do not have frame pointers or additional register usage.
Some procedures without explicit handlers may have implicit handlers. The compiler creates a handler for each automatic object that has a destructor. The compiler also creates handlers for constructors that initialize subobjects that have destructors. In such a constructor, the compiler creates a handler for each member with a destructor, and a handler for each base class with a destructor.
The -nocleanup option suppresses generation of such implicit handlers, which results in an executable file that is slightly smaller. You should use this option for programs that do not use exception handling or that do not require destruction of automatic objects during exception processing.
Exception specifications in function prototypes that conflict with function definitions are illegal. Chapter 8 describes how DIGITAL C++ handles such conflicts. Beware of such conflicting exception specifications, particularly if you have exception specifications in prototypes that are in header files accessible to other programs.
| Previous | Next | Contents | Index |