 |
» |
|
|
|
Some of these limitations with possible workarounds are discussed
in detail elsewhere in this document. Please be aware that some
of these limitations are platform-specific. Non-Derived Class Access to a Protected Constructor
from Another Class | |
The HP C++ A.10.22 compiler incorrectly allows non-derived
classes to access a protected constructor from another class. For
example, the following code should generate a compiler error, but
it does not. class A
{
protected:
A() {}
};
class B
{
public:
B()
{
A a; // This line should generate the error:
// B::B() cannot access A::A(): protected member (1299)
// but it does not.
};
};
|
Known Limitations in Version A.10.22 | |
HP C++ does not support large files
(i.e., greater than 2 GB) with <iostream.h>. For task library users, both libtask
and libV3 are required. When linking, use -ltask -lV3
on the CC command line. This limitation is
removed in later versions of HP C++ Known limitations of profile-based optimization: +P
is incompatible with debug (-g,
-g1), static analysis (-y),
exception handling (+eh), assembly
only mode (-S), and +I. +I is incompatible
with debug (-g, -g1),
static analysis (-y), exception
handling (+eh), assembly only mode
(-S), profiling (-G),
stripping (-s), and +P.
Known limitations of exception handling features: Code compiled in compiler mode with
the +eh option should not use setjmp/longjmp.
To use setjump/longjmp with +eh
in translator mode, replace all setjmp/longjmp calls with Setjmp/Longjmp.
For example: #include <stdio.h>
#include <setjmp.h>
Jmp_buf jb;
struct A {
int x;
A(int i) {x = i;}
~A() {printf("A::~A[%d]\n", x);}
};
void g()
{
A a(1);
Longjmp(jb, 1); // longjmp replaced by Longjmp
}
void f() {
int x;
if (Setjmp(jb) == 0) // setjmp replaced by Setjmp
g();
x = 37;
}
void main() {
try {
f();
printf("about to throw 97\n");
throw 97;
}
catch (int i) {
printf("caught int\n");
}
}
|
The restrictions are: A setjmp
site can be returned to only through a longjmp;
a Setjmp site can be returned to
only through a Longjmp. Results
are otherwise undefined. Behavior is undefined for a longjmp
from a destructor called during object cleanup. C modules that used setjmp/longjmp can be linked
with C++ code that uses Setjmp/Longjmp with +eh
provided that no C++ code compiled with +eh
is invoked between a call to setjmp
and the last longjmp executed to
that setjmp location.
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.
Inhibiting of auto-destructors on the throw and
catch statements in the symbolic debugger is not supported. If you compile template files across nfs
mounts and you see that c++ptcomp or c++ptlink
is idling while waiting to lock the repository, you must verify
that /usr/sbin/rpc.lockd and /usr/sbin/rpc.statd
are running on both systems. The locking scheme used by c++ptlink
and c++ptcomp depends on the rpc(3C)
mechanism. When using the task library, you must not compile
your application sources with the -O
flag. Instead, use the +O1 flag
to get a smaller subset of optimizations. It is necessary to disable
some optimizations for the task library to work properly. Symbolic debugging information is not always emitted
for objects that are not directly referenced. For instance, if a
pointer to an object is used but no fields are ever referenced,
then HP C++ only emits symbolic debug information for the pointer
type and not for the type of object to which the pointer points. 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. Source-level debugging of C++ shared libraries is
supported on HP-UX 9.0 and 10.x. 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. Instantiation of shared objects in shared memory
is not supported. Linking with the -r
option is not supported for applications that use templates. See
"Renaming Object Files" in chapter 5 of HP
C++ Templates Technical Addendum. When you call the shl_load(3) routines
in libdld.sl either directly or indirectly
(as when your application calls setlocale(3) or
iconv(3)), and you use the +A
option, you will get 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. When using templates, if the declaration of a template
class function is not inlined and the definition is inlined and
the function is used before it is defined, HP C++ no longer generates
a compiler error. In this case, HP C++ ignores the inline keyword
in the definition. template <int i> class A {
public:
//declaration of foo function
void foo();
};
main()
{
A<1> a;
//use of foo function before definition
a.foo();
}
//definition of foo function
template <int i> inline void A<i>::foo() { }
|
In HP C++ releases prior to A.10.0, the above example generated
the following compiler messages: CC: "p.c", line 21: warning: a used but not set (116) |
CC: "p.c", line 26: error: A <1 > ::foo() declared with external linkage and called before defined as inline (1144) "p.c", line 26: error detected during the instantiation ofA <1 >"p.c", line 29: is the site of the instantiation |
HP C++ version A.10.22 generates only the following warning: CC: "p.c", line 21: warning: a used but not set (116) |
Although currently no syntax error is generated, an error
may be generated in future releases of HP C++. This may be a consideration
when porting from the current HP C++ to a future version. Note that in the normal case, function foo
would be declared and defined before it is used. The vfork(2) system call is
a "fast" version of fork(2),
in which the parent process is suspended until the child does an
exec. During this time, the child uses the
parent's memory segment, thus avoiding the overhead of
creating its own. See man page for fork(2)
and vfork(2). In an eh program, when the
child defines an automatic destructable object and does an exec
before that object goes out of scope, the global variable __eh_dt_count,
used in managing eh at runtime,
becomes corrupted. This may lead to runtime eh errors during a throw. Use of the option +dup_static_removal
may give you the linker error: Common block requests for
functionname have different lengths.
Update the linker by applying the most recent patches to fix this
problem. If you do not have the latest linker patches, you will get
this error in one of two cases. One, your code violates the C++
requirement that "all inline member functions with the
same name must also have the same body." Two, you use different
compiler options to compile the duplicate inline member functions
of different compilation units. Library providers who ship header files may not want to use
+dup_static_removal because they
do not know if their users compile with the same options as they
do.
|
