Previous | Contents | Index |
The only translation limits imposed in DEC 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. |
1024 | Arguments in a function call. 1 |
1024 | Parameters in a function definition. 1 |
1012 | Bytes in any one function argument. |
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 Annotated C++ Reference Manual.
2.2.5 Argument-Passing and Return Mechanisms
DEC 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 DEC C++ for DIGITAL UNIX systems. Where appropriate, section numbers
shown in parentheses in the headings (for example, §3.4) refer to
relevant sections in the reference manual portion of The C++ Programming Language, 2nd Edition.
2.3.1 Identifiers (§r.2.3)
In DEC 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 DEC C++ compiler uses the external name encoding scheme described in §7.2.1c of The Annotated C++ Reference Manual, 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 |
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 |
On DIGITAL UNIX systems, DEC C++ also supports the following data types:
Type | Encoding |
---|---|
__int16 | ji4 |
__int32 | ji5 |
__int64 | ji6 |
__s_float | js |
__t_float | jt |
If an external name has more than 1022 characters, the DEC 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 (§r.3.4)
Static objects are initialized in declaration order within a
compilation unit and in link order across compilation units.
2.3.3 Integral Conversions (§r.4.2)
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 (§r.4.3 and §r.4.4)
When converting an integer to a floating-point number that cannot exactly represent the original value, DEC 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 DEC 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, DEC 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, DEC C++ rounds off the result to the nearest representable float value.
DEC C++ performs similar rounding for demotions from long double to double or float.
2.3.5 Explicit Type Conversion (§r.5.2.3)
In DEC 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, 2nd 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 (§r.5.4)
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 (§r.5.6)
The semantics of the division (/) and remainder (%) operator are as follows:
In the following cases of undefined behavior detected at compile time, the DEC 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>, DEC C++ defines this type as
long.
2.3.10 Shift Operators (§r.5.8)
The expression E1>> E2 shifts E1 to the right E2 positions. If E1 has a signed type, DEC 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 (§r.5.10)
When comparing two pointers to members, the DEC C++ compiler guarantees equality if either of the following conditions hold:
When comparing two pointers to members, the DEC 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 (§r.7.1.6)
For variables that are modifiable in ways unknown to the DEC 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 asm Declarations (§r.7.3)
In DEC C++, asm declarations produce a
compile-time error.
2.3.14 Linkage Specifications (§r.7.4)
Specifying linkage other than "C++" or "C" generates a compile-time error.
In object files, DEC 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.15 Class Layout (§r.9.2)
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.15.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.15.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.15.3 Access Specifiers
The layout of a class is unaffected by the presence of access
specifiers.
2.3.15.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
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.17 Temporary Objects (§r.12.2)
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.
Previous | Next | Contents | Index |