New and Changed Features

Linker Patch (PHSS_20014) required for +objdebug and shared libraries

+ESplabel option (run-time performance)

+inline_level [i]n option (run-time performance)

-fast option (run-time performance and porting to HP-UX)

Fix and continue debugging (build-time performance)

HP Pac and Blink Link no longer bundled with HP aC++ on HP-UX 11.0

+Ofailsafe option new defaults (run-time performance)

+DD[data_model] option (run-time performance)

+ESlit option new default (run-time performance) NOTE: MAY RESULT IN SIGNAL 10 RUN-TIME ABORTS IN ILL-FORMED PROGRAMS.

Function Try Blocks as defined in the C++ Standard

#assert and #unassert preprocessor directives

enum x { x1, }; trailing comma now generates Warning 921

+m[d] and +M[d] options have changed behavior

+uc option for porting to HP-UX

Predefined string variable identifiers for function names (porting/debug)

Macros having a variable number of arguments (porting)

Alignment of long double data type in 64-bit mode changed to 16-bytes

-D__HPACC_THREAD_SAFE_RB_TREE macro insures thread safety

Preview online documentation to become familiar with the upcoming Standard C++ Library 2.x

Preview man pages in preparation for upcoming Standard C++ Library 2.x

The latest linker patch (PHSS_20014) is needed in order to use the +objdebug option and to build shared libraries. See these release notes, Chapter 2, Current Linker Required, for details.

The +ESplabel option affects how function pointers are dereferenced in generated code. Using this option can improve run-time performance at the expensive of a slight increase in code size for every call. The option can only be used:

The +inline_level [i]n option does implicit inlining of small functions that are not explicitly tagged with the inline keyword. Such inlining happens in addition to explicitly inlined functions. As before, +d and +inline_level 0 turn off all inlining, including implicit inlining.

The -fast option selects a combination of compilation options for optimum execution speed for reasonable build times. Currently chosen options are:

Fix and continue debugging is now supported with HP aC++. Fix and continue speeds up the edit-compile-debug cycle by allowing you to make changes to a program from within the WDB debugger and continue debugging without having to exit the debugger and rebuild. For details about how to use fix and continue from either the WDB GUI interface or the WDB command line, see the WDB debugger release notes at:

opt/langtools/wdb/doc/html/wdb/C/WDBrln.html

HP Pac and Blink Link are no longer bundled with HP aC++ (on HP-UX 11.0).The HP CXperf performance analysis tool is available for download. Refer to:

http://www.hp.com/esy/lang/tools/Performance/index.html

There are new default settings for the +Ofailsafe option. Refer to the Options section of the HP aC++ Online Programmer's Guide.

The +DD[data_model] option specifies the compiler data model as either 32-bit (ILP32) or 64-bit (LP64).

The +FP[flags] option specifies how the run-time environment for floating-point operations should be initialized at program start up. The default is that all behaviors are disabled. See ld(1) for specific flag values. To dynamically change these settings at run time, refer to fesetenv(3M).

By default, string literal data now resides in read-only memory rather than read-write memory. This new default may result in improved run-time performance, because read-only memory is shared. The +ESlit command line option can be used to explicitly specify this behavior. +ESnolit reverts to storing string literal data in read-write memory.

	NOTE: 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 could 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.

HP aC++ continues to more strictly conform to the C++ Standard, enabling porting to additional platforms. Due to closer conformance with the standard, you may see more compile time warnings and errors.

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 prior 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 depricated.
   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() .....

HP aC++ now provides function try blocks, as defined in the C++ Standard.

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.

Most frequently reported migration issue: enum x { x1, };
The trailing comma is an error, and aC++ now generates Warning 921.

Behavior of the +m[d] and +M[d] options has changed. When used with the -E option, only dependency file information is generated, and there is no preprocessing output.

Behavior when combining the +m[d] or +M[d] option with the -P option is unchanged. Both dependency information and preprocessing output are generated.

The +uc option allows you to change the compiler default (signed char) and treat an unqualified (plain) char data type as unsigned char. This may help in porting code from other environments to HP-UX.

As a debugging aid, HP aC++ predefines three string variables for each current function. This functionality provides compatiblity with the C99 standard and with GNU/gcc style coding.

For C99 style coding:

__func__ indicates the function name as it appears in the source.

For GNU/gcc style coding:

 __FUNCTION__  indicates the function name as it appears in the source.

__PRETTY_FUNCTION__  indicates the function name, its argument types, and its return type.

You can use the predefined variables in your code, as in the following examples.

For C99 style coding:

void foo() {
  printf("The function name is %s.\n", __func__);
}
       Output from the example would be:
 
  The function name is foo.

For GNU/gcc style coding:

#include <stdio.h>
 
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;
}
 
       Output from the example would be:
 
__FUNCTION__ = sub
__PRETTY_FUNCTION__ = int  a::sub (int)

Note, these names are not macros. They are predefined string variables. For example, #ifdef __FUNCTION__ has no special meaning inside a function, since the preprocessor does not recognize __FUNCTION__.

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.

A macro can be defined to accept a variable number of arguments, much as you would define a function. This provides compatiblity with the C99 standard and GNU/gcc style coding. If you have coded your macros in GNU/gcc style, you can expect GNU/gcc style behavior. If you have coded your macros to C99 standards, you can expect C99 style behavior.

For C99 style coding:

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));

For GNU/gcc style coding:

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.

Alignment of the long double data type in 64-bit mode (+DA2.0W) is now 16-bytes. This insures compatibility with the HP PA-RISC ABI and HP C. In particular, the layout and alignment of a struct that contains jmp_buf are now identical for HP C and HP aC++ (since jmp_buf is a typedef that is defined with a long double).

For code compiled with the prior 8-byte default, a problem occurs when a long double is a field in a class, struct or union. When the structure in question is shared between C and C++ there is a 50% chance that the fields are not on the same offsets in both languages, and the wrong data will be accessed.

Symptoms of this problem might be:

Note, if you must use the prior 8-byte alignment for long double, use the -Wc,-longdouble,old_alignment option.

The Rogue Wave Standard C++ Library 1.2.1 (libstd) and Tools.h++ 7.0.6 (librwtool) are not thread safe in all cases. The -D__HPACC_THREAD_SAFE_RB_TREE preprocessor macro insures thread safety.

For more detail, refer to the HP aC++ Online Programmer's Guide and choose the Threads and Parallel Processing section.

Preview documentation and man pages are provided for a future release of the Rogue Wave Standard C++ Library 2.x. These documents are online in HTML format. Refer to Chapter 3 of these release notes.

Manual pages are located at /opt/aCC/share/man/man3.Z. To insure that you invoke a man page for the library in which you are interested, specify the appropriate section 3 sub-section. For example, to find the man page for the copy command:

man 3s copy	    # finds the Standard Components version
man 3f copy	    # finds the old Standard C++ Library (libstd)
                 version
man 3n copy	    # finds the future Standard C++ Library preview
                 version