Known Limitations

Some of these limitations will be removed in future releases of HP aC++. Please be aware that some of these limitations are platform-specific.

HP aC++ does not support the xdb debugger. Instead, use the HP DDE debugger or the HP WDB debugger supplied with the product.
Known limitations of 64-bit Applications:
- For a 64-bit application, level 4 optimization (+O4 compile-line option) is not currently supported.
- For a 64-bit application, profile-based optimization (+dfname, +I, +P and +pgmname options) is not currently supported.
- Limitation when Unloading Shared Libraries in a 64-bit Application
  Normally, at program termination (exit) or at a call to shl_unload() or dlclose(), all explicitly loaded libraries are closed automatically and static destructors are executed at that time.
  When a 64-bit application calls shl_unload() or dlclose(), it fails to execute static destructors until program termination. This causes a program abort, since related code and data are no longer present.
HP aC++ does not and will not in the future support installation and/or execution on HP-UX 9.x systems.
In 32-bit mode, HP aC++ does not support large files (i.e., greater than 2 GB) with <iostream.h>.
Known limitations of exception handling features:
- Interoperability with setjmp/longjmp (undefined by the C++ draft proposed 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 be run.
- Symbolic debugging information is not always emitted for objects which are not directly referenced. For instance, if a pointer to an object is used but no fields are ever referenced, then HP aC++ only emits symbolic debug information for the pointer type and not for the type of object that the pointer points to. For instance, use of Widget * only emits debug information for the pointer type
  Widget * and not for Widget. If you wish such information, you can create an extra source file which defines a dummy function that has a parameter of that type (Widget) and link it into the executable program.
Known limitations of signal handling features:
- Throwing an exception in a signal handler is not supported, since a signal can occur anyplace, including optimized regions of code
  in which the values of destructable objects are temporarily held in registers. Exception handling depends on destructable objects 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 in shared memory is not supported.
When you call the <shl_load>(3X) routines in libdld.sl either directly or indirectly (as when your application calls use the +A option, you will see an "unresolved externals" error.
If you want to link archive libraries and libdld.sl, use the -Wl,-a, archive option. The following example directs the linker to use the archive version of standard libraries and (by default) libdld.sl.
aCC prog.o -Wl,-a,archive
Using shl_load(3X) with Library-Level Versioning
Once library-level versioning is used, calls to shl_load() (see shl_load(3X)) should specify the actual version of the library that is to be loaded. For example, if libA.sl is now a symbolic link to libA.1, then calls to dynamically load this library should specify the latest version available when the application is compiled, such as:
shl_load("libA.1", BIND_DEFERRED, 0);
This will insure that, when the application is migrated to a system that has a later version of libA available, the actual version desired is the one that is dynamically loaded.

Memory Allocation Routine alloca()

The compiler supports the built in function, alloca, defined in the /usr/include/alloca.h header file. The implementation of the alloca() routine is system dependent, and its use is not encouraged.

alloca() is a memory allocation routine similar to malloc() (see malloc(3C)). The syntax is:

void *alloca(size_t <size>);

alloca() allocates space from the stack of the caller for a block of at least <size> bytes, but does not initialize the space. The space is automatically freed when the calling routine exits.




	NOTE: Memory returned by alloca() is not related to memory allocated by other memory allocation functions. Behavior of addresses returned by alloca() as parameters to other memory functions is undefined.

To use this function, you can use the <alloca.h> header file or you can specify your own prototype and use the +Olibcalls option.

Known Limitations

Technical documentation

» Table of Contents