HP aC++ is Hewlett-Packard's implementation of the ANSI/ISO C++ International Standard. The compiler largely conforms to the standard and is evolving towards full conformance. Refer to Standardizing Your Code for listings of standards based features and extensions. Some of the many supported features are listed here:
| Performance | C++ Standards |
|---|---|
| Precompiled Header Files | Standard C++ Library |
| +objdebug Debugging Option | Tools.h++ Library |
| -fast Optimization Option | Templates |
| +DA and +DS Architecture and Scheduling Options | Exception Handling |
| Other Options and Pragmas for Optimizing Your Code | Other Options and Features for Standardizing Your Code |
To use the new library, you must specify the -AA command line option. Note the following:
man 3s copy # finds the Standard Components version man 3f copy # finds the old Standard C++ Library (libstd) version man 3n copy # finds the new Standard C++ Library (libstd_v2) version
Refer to Chapter 2: Installation Information in the HP aC++ Release Notes
NOTE: THIS NEW DEFAULT OPTION MAY CAUSE PROGRAMS TO ABORT WITH SIGNAL 10 AT RUN-TIME.
String literals (quoted character strings) are typed as "const char[]" and programs that attempt to modify string literal data are violating the semantics of this "const" type. Modifying string literal data at the source level translates to writing data into read-only memory at runtime and will result in the process receiving a signal 10 (bus error). Below is an example of such a program:
void f(char *s) { // Warning 829: const char* -> char*
s[0] = 'S'; // abort: write into read-only memory
}
int main() {
f("string literal");
return 0;
}
Programs that attempt to write into a string literal's read-only memory will trigger warnings and errors at compile-time. Fixing the program's compile-time errors and warnings has the benefit of enabling the use of +ESlit, thus taking advantage of improved run-time efficiency and improving the application's portability.
The following code generates the compile-time errors shown below:
int main() {
const char *p = "quoted string";
char* c=p; // Error 440
void main2() {
const char *p = "quoted string";
char* c;
c=p; // Error 203
aCC -c foo.C
Error 440: "foo.C", line 3 # Cannot initialize 'char *' with
'const char *'. char* c=p;
^
Error 203: "foo.C", line 8 # Cannot assign 'char *' with '
const char *'. c=p;
If you see a compile-time warning like the following:
Warning 829: Implicit conversion of string literal to 'char*' is deprecated.
These could be suppressed by a cast or const_cast like the above, then no further messages will occur. Or they could be suppressed by using +W829. A compile-time error is generated unless a cast is done, in which case there is no message, and a SIGBUS signal 10 coulde be generated at runtime.
Note that if you used a cast at compile-time to suppress the error/warning you will have no idea where to change the code to fix the runtime abort. If you want to find the source of your problem, look for const_cast or warning 829, or any indication that you put the cast in the source. When using the debugger, you can print out what you're trying to modify and search for the string to find the source of the problem.
In A.03.15, A.01.23 and prior compiler versions, only floating-point constant values were placed in read-only memory. Other constants and literals were placed in read-write memory.
In prior compiler versions, Warning 829 was issued for assignments and initializations. The compiler now also generates Warning 829 for return statements and function calls where appropriate. This warning may help in finding problems with the new +ESlit default (see next bullet item). The following example generates the messages below:
const foo=5;
char *f(char*p) {
return "goodbye";
}
int main() {
f("hello");
return 0;
}
aCC -c foo.C
Error (future) 600: "foo.C", line 1 # Type specifier is omitted;
"int" is no longer assumed.
const foo=5;
^^^^^
Warning 829: "foo.C", line 4 # Implicit conversion of string literal
to 'char *' is deprecated.
return "goodbye";
^^^^^^^^^
Warning 829: "foo.C", line 8 # Implicit conversion of string literal
to 'char *' is deprecated.
f("hello");
^^^^^^^
Error (future) 600 is now generated (in conformance with the C++ standard) for cases like the following:
Error (future) 600:
Type specifier is omitted; "int" is no longer assumed.
const foo=5; //error 600
static bar() ..... //error 600
The following code corrects the errors:
const int foo=5;
static int bar() .....
Function try blocks are sometimes necessary with class constructor destruction. A function try block is the only means of ensuring that all exceptions thrown during the construction of an object are caught within the constructor.
#assert and
#unassert
preprocessor directives allow
you to set a predicate name or predicate name and token to be tested with a
#if directive.
The -ext option must also be specified at compile and link time.
Behavior when combining the +m[d] or +M[d] option with the -P option is unchanged. Both dependency information and preprocessing output are generated.
For C99 style coding:
For GNU/gcc style coding:
You can use the predefined variables in your code, as in the following examples.
void foo() {
printf("The function name is %s.\n", __func__);
}
Output from the example would be:
The function name is foo.
#includeOutput from the example would be:class a { public: sub (int i) { printf ("__FUNCTION__ = %s\n", __FUNCTION__); printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__); } }; int main (void) { a ax; ax.sub (0); return 0; }
__FUNCTION__ = sub __PRETTY_FUNCTION__ = int a::sub (int)
Also note, the names __FUNCTION__, __PRETTY_FUNCTION__, and __func__ are reserved for use by the compiler. If any other identifier is explicitly declared using any of these names, the behavior is undefined.
If there is an elipsis (...) in the identifier-list in the macro definition, then the trailing arguments, including any separating comma preprocessing tokens, are merged to form a single item: the variable arguments. The number of arguments so combined is such that, following merger, the number of arguments is one more than the number of parameters in the macro definition (excluding the ...).
Any __VA_ARGS__ identifier occuring in the replacement list is treated as if it were a parameter. The variable arguments form the preprocessing tokens used to replace it. Following are examples:
#define debug(...) fprintf(stderr, __VA_ARGS__)
#define showlist(...) puts(#__VA_ARGS__)
#define report(test, ...)((test)?puts(#test):printf(VA_ARGS__))
debug("Flag");
debug("X = %d\n", x);
showlist(The first, second, and third items.);
report(x>y, "X is %d but y is %d", x, y);
Will be expanded to:
fprintf(stderr, "Flag" );
fprintf(stderr, "X = %d\n", x );
puts( "The first, second, and third items." );
((x>y)?puts("x>y"):printf("x is %d but y is %d", x, y))
Similar to the variable arguments function described above, a macro can accept a variable number of arguments. Following is an example:
#define Myprintf(format, args...) \
fprintf (stderr, format, ## args)
Myprintf ("%s:%d: ", input_file_name, line_number)
Will be expanded to:
fprintf (stderr, "%s:%d: " , input_file_name, line_number)Note the use of ## to handle the case when args matches no arguments. In this case, args is empty, and if there is no ##, the macro expansion could be like the following invalid syntax:
fprintf (stderr, "success!\n" , )By using ##, the comma is concatenated with empty valued arguments, and is discarded at macro expansion.
In the case mentioned above, gcc currently discards only the last preceding sequence of non-whitespace characters, while HP aC++ discards the last preprocessor token.
For the latest information on new features, see the HP aC++ Release Notes
If you see the message "Text file data could not be formatted," ensure the
release notes are installed as /opt/aCC/newconfig/RelNotes/ACXX.release.notes.
The previous default behavior remains available by specifying the +inst_auto command-line option when compiling and linking. If you provide archive or shared libraries for distribution, you may want to use +inst_auto to insure consistent behavior between each distribution of your libraries.
Also, if you provide either archive or shared library products, and your customers need to use the prior template instantiation default in their builds, you must build your libraries by using the +inst_auto option.