DEC C++
Using DEC C++ for DIGITAL UNIX Systems
Previous Contents Index

2.3.17.1 Lifetime of Temporary Objects

Generally DEC C++ implements destruction of temporary objects at the ends of statements. In certain situations, however, temporary objects are destroyed at the end of the expression; they do not persist to the end of the statement. Temporary objects do not persist to the ends of statements in expressions that are:

Consider the following example: 


struct A { 
  void print(int i); 
  A(); 
  ~A() { } 
}; 
 
struct B { 
  A* find(int i); 
  B(int i); 
  B(); 
  ~B() { } 
}; 
 
void f() { 
  B(8).find(6)->print(6); 
  (*(B(5).find(3))).print(3); 
  return; 
}

In the first and second statements inside void f(), DEC C++ destroys the temporary object, created in evaluating the expressions B(8) and B(5), after the call to A::print(int).

2.3.17.2 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!! 
}

2.3.17.3 Static Member Functions Selected by Expressions Creating Temporary Objects

When a static member is accessed through a member access operator, the expression on the left side of the dot (.) or right arrow (->) is not evaluated. In such cases, the compiler creates code that calls the static member function to handle the destruction of a class type temporary; the compiler does not create temporary destructor code. For example: 


struct A { 
        ~A(); 
        static void sf(); 
}; 
 
struct B { 
        A operator ()() const; 
}; 
 
void f () { 
    B bobj; 
    bobj().sf();        // If 'bobj()' is evaluated, a temporary of 
                        // type 'A' is created. 
}

2.3.18 Exception Handling (§r.15)

DEC C++ optimizes the implementation of exception handling for normal execution, as follows:

In DEC 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 7 describes how DEC 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.

2.3.19 File Inclusion (§r.16.4)

The #include directive inserts external text into the macro stream delivered to the DEC C++ compiler. Programmers often use this directive to include global definitions for use with DEC C++ functions and macros in the program stream.

The #include directive has the following search path semantics: