HP aC++/HP C A.06.25 Release Notes

file which defines a dummy function that has a parameter of that type (Widget)
and link it into the executable program.
• Known limitations of exception handling features:
— Interoperability with setjmp/longjmp (undefined by the ISO/ANSI C++
international standard) is unimplemented. Executing longjmp does not cause
any destructors to be run.
— If an unhandled exception is thrown during program initialization phase (that
is, before the main program begins execution) destructors for some constructed
objects may not run.
— HP aC++ does not support the linker option -Bsymbolic. Use the compile
time option -Bprotected_def if you want to throw types out of a shared
library. This limitation also occurs for dynamic_cast and RTTI.
• Known limitations of signal handling features:
— Throwing an exception from a signal handler is not supported, since a signal
can occur anyplace, including optimized regions of code in which the values
of destructible objects are temporarily held in registers. Exception handling
depends on destructible object being up-to-date in memory, but this condition
is only guaranteed at call sites.
— Issuing a longjmp in a signal handler is not recommended for the same reason
that throwing an exception is not supported. The signal handler interrupts
processing of the code resulting in undefined data structures with unpredictable
results.
• Source-level debugging of C++ shared libraries is supported. However, there are
limitations related to debugging C++ shared libraries, generally associated with
classes whose member functions are declared in a shared library, and that have
objects declared outside the shared library where the class is defined. Refer to the
appropriate release notes and manuals for the operating system and debugger
you are using. Refer also to the Software Status Bulletin for additional details.
• Instantiation of shared objects with virtual functions in shared memory is not
supported.
• Using shl_load(3X) or dlopen(3C) with Library-Level Versioning:
Once library-level versioning is used, calls to shl_load() or dlopen() (see
shl_load(3X)) should specify the actual version of the library that is to be loaded.
For example, if libA.so is now a symbolic link to libA.so.1, then calls to
dynamically load this library should specify the latest version available when the
application is compiled, such as:
shl_load("libA.so.1", BIND_DEFERRED, 0);
50 Known Problems and Workarounds