New Features in Version A.03.25

+ESplabel Option

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:

+inline_level [i]n Option

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.

-fast Option (Run-time Performance and Porting to HP-UX)

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

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.

See the WDB debugger release notes for details about how to use fix and continue from either the WDB GUI interface or the WDB command line.

HP-PAK and Blink Link no Longer bundled with HP aC++

HP-Pak and Blink Link are no longer bundled with HP aC++ (on HP-UX 11.0).

+Ofailsafe Option new Defaults

There are new default settings for the +Ofailsafe option. Refer to HP aC++ Online Programmer’s Guide for more information.

+DD[data_model] Option

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

+ESlit Option New Default

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 exception behaviors are disabled. See ld(1) for specific flag values. To dynamically change these settings at run time, see 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: 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.

Function Try Blocks as Defined in the C++ Standard

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

#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.

enum x { x1, }; Trailing Comma now Generates Warning 921

Most frequently reported migration issue: enum x { x1, };

The trailing comma is an error, and aC++ now generates Warning 921.

+m[d] and +M[d] Options Have Changed Behavior

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.

+uc Option for Porting to HP-UX

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.

Predefined String Variable Identifiers for Function Names

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

For C99 style coding:

For GNU/gcc style coding:

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.

Macros Having a Variable Number of Arguments

A macro can be defined to accept a variable number of arguments, much as you would define a function. This provides compatibility 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 ellipsis (...) 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 occurring 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 long double Data Type in 64-bit mode Changed to 16-bytes

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.

-D__HPACC_THREAD_SAFE_RB_TREE Macro Ensures Thread Safety

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 details, refer to HP aC++ Online Programmer’s Guide.