DEC C++
Using DEC C++ for DIGITAL UNIX Systems
Previous Contents Index

2.1.6 Explicit Cast to Reference and Conversions (cfront and ms)

Call any constructors or conversion functions as a result of an explicit cast to a reference (contrary to §r.5.4 of the The C++ Programming Language, 2nd Edition).

For example: 


extern "C" void printf(char *, ...); 
 
struct S2; 
 
struct S1 
{ 
    operator S2&() {printf("%s \n", "operator S2& called");} 
}; 
 
struct S2 : public S1 
{ 
    print(){printf("%s \n", "print called");} 
}; 
 
void f(S1 &rs1) 
{ 
    ((S2 &)rs1).print();  // I know this is a pointer to S2. 
} 
 
void main(void) 
{ 
    S2 s2; 
 
    f(s2); 
}

Without the -cfront option, running the program will print: 


print called

But, with the -cfront option, running the program will print: 


operator S2& called 
print called

2.1.7 Access Rights to Enclosing Class (cfront)

Allow members of an inner class to have the same access rights to the enclosing class as members or friends of the enclosing class.

For example: 


class X { 
    protected: 
 class Y { 
 }; 
 class Z { 
     X::Y *y;  // Ok: specifying -cfront makes X::Y accessible 
 }; 
};

2.1.8 Static Incomplete Array Data Members (ms)

Allow static array data members with incomplete class components. For example: 


struct x; 
struct c; 
{ 
   static x a[];  //component x is incomplete, -ms option allows this 
}; 
struct x 
{ 
   int j; 
}

2.1.9 Address of Member Functions without Ampersand (&) Address-of Operator (ms)

When supplying the qualified name of a member function in a pointer-to-member context, permit the ampersand (&) address-of operator to be omitted. For example: 


class C { 
public: 
    int f(); 
}; 
 
int (C::*pmf1)() = C::f;        // with -ms, OK to refer to member function 
                                // without address-of operator 
int (C::*pmf2)() = &C::f;       // without -ms, ampersand must be supplied

2.1.10 Ignored Visual C++ Keywords (ms)

Recognize certain Visual C++ keywords (such as export) but ignore them.

2.1.11 Duplication of Type Qualifiers (ms)

Allow the duplication of type qualifiers. For example: 


const const int i;

2.2 Implementation-Specific Attributes

This section describes pragmas, predefined names, and limits placed on the number of characters and arguments used in DEC C++ programs.

2.2.1 #pragma Preprocessor Directive

The #pragma preprocessor directive is a standard method for implementing features that differ from one compiler to the next. This section describes pragmas specifically implemented in the DEC C++ compiler for DIGITAL UNIX systems.

Although certain #pragma directives are subject to macro expansion, not all of those new to the language in this and later releases are subject to such expansion. Therefore, users should not write programs that rely on macro expansion of the newer pragmas.

2.2.1.1 #pragma define_template Directive

The #pragma define_template preprocessor directive instructs the compiler to define a template with the arguments specified in the pragma. This pragma has the following syntax:

#pragma define_template name < template-argument-list >

For example, the following statement instructs the compiler to define the template mytempl with the arguments arg1 and arg2: 


#pragma define_template mytempl<arg1, arg2>

For more information on how to use templates with the #pragma
define_template directive, see Section 5.3.

2.2.1.2 #pragma environment Directive

The #pragma environment preprocessor directive offers a way to single-handedly set, save, or restore the states of context pragmas. This directive protects include files from contexts set by encompassing programs and protects encompassing programs from contexts that could be set in header files that they include.

On DIGITAL UNIX systems, the #pragma environment directive affects the following pragmas:

This pragma has the following syntax:

#pragma environment command_line
#pragma environment header_defaults
#pragma environment restore
#pragma environment save

command_line

Sets, as specified on the command line, the states of all the context pragmas. You can use this pragma to protect header files from environment pragmas that take effect before the header file is included.

header_defaults

Sets the states of all the context pragmas to their default values for DIGITAL UNIX systems. This is almost equivalent to the situation in which a program with no command line options and no pragmas is compiled; except that this pragma sets the pragma message state to #pragma nostandard, as is appropriate for system header files.

restore

Restores the current state of every pragma that has an associated context.

save

Saves the current state of every pragma that has an associated context.

Someone who creates a general purpose library, distributed as an archive or shared library, typically distributes header files that specify the interface to the library. For calls to the library to work, the header file must normally use the same member alignment, pointer size, extern model, and other compilation options as when the library was built. That header file should contain pragmas to save the user's compilation options, set the correct compilation options for the library, and then restore the user's compilation options when the include file ends. The pragmas let library users choose whatever compilation options are appropriate for their own code without unintentionally affecting the interface to the library.

Not only is the #pragma environment preprocessor directive more convenient than explicitly specifying each individual pragma that controls a compilation option, it is also upwardly compatible. As new pragmas are added to DEC C++, #pragma environment header_defaults will be enhanced to set the state of the new pragmas to their default. Thus, a header file that uses #pragma environment sets a known state for not only the current pragmas in DEC C++, but future pragmas as well. Without requiring further changes to the source code, you can use #pragma environment to protect header files from things like language extensions and enhancements that might introduce additional contexts.

A header file can selectively inherit the state of a pragma from the including file and then use additional pragmas as needed to set the compilation to non-default states. For example: 


#ifdef __PRAGMA_ENVIRONMENT 
#pragma __environment save  (1)
#pragma __environment header_defaults (2)
#pragma member_alignment restore (3)
#pragma member_alignment save (4)
#endif 
. 
.  /* contents of header file */ 
. 
#ifdef __PRAGMA_ENVIRONMENT 
#pragma __environment restore 
#endif

In this example:

  1. Saves the state of all context pragmas
  2. Sets the default compilation environment
  3. Pops the member alignment context from the #pragma member_alignment stack that was pushed by #pragma __environment save (restoring the member alignment context to its pre-existing state)
  4. Pushes the member alignment context back onto the stack so that the #pragma __environment restore can pop the entry off

Thus, the header file is protected from all pragmas, except for the member alignment context that the header file was meant to inherit.

2.2.1.3 #pragma [no]member_alignment Directive

By default, the DEC C++ compiler aligns structure members so that members are stored on the next boundary appropriate to the type of the member; that is, bytes are on the next byte boundary, words are on the next word boundary, and so on.

You can use the #pragma member_alignment preprocessor directive to explicitly specify member alignment. For example, using #pragma member_alignment aligns a long variable on the next longword boundary, and it aligns a short variable on the next word boundary.

Using #pragma nomember_alignment causes the compiler to align structure members on the next byte boundary regardless of the type of the member. The only exception to this is for bit-field members.

If used, the nomember_alignment pragma remains in effect until the compiler encounters the member_alignment pragma.

This pragma has the following syntax:

#pragma member_alignment
#pragma member_alignment save
#pragma member_alignment restore
#pragma nomember_alignment [base_alignment]

restore

Restores the current setting of the member_alignment pragma.

save

Saves the current setting of the member_alignment pragma.

2.2.1.4 #pragma message Directive

The #pragma message preprocessor directive controls the kinds of individual diagnostic messages or groups of messages that the compiler issues.

The #pragma message directive has the following syntax:

#pragma message disable (message-list)
#pragma message enable (message-list)
#pragma message restore
#pragma message save

disable

Supresses the compiler-issued messages specified in the message-list argument. The message-list argument can be any one of the following:

The message identifier is the name following the message text when the -verbose option is set. For example, consider the following message: 


Non-void function "name" does not contain a return statement. (missingreturn).

The message identifier is missingreturn. To prevent the compiler from issuing this message, use the following directive: 


#pragma message disable missingreturn

enable

Enables the compiler to issue the messages specified in the message-list argument.

restore

Restores the saved state of enabling or disabling compiler messages.

save

Saves the current state of enabling or disabling compiler messages.

The save and restore options are useful primarily within header files.

2.2.1.5 #pragma pack Directive

The #pragma pack preprocessor directive specifies the byte boundary for packing members of C structures and C++ classes.

The #pragma pack directive has the following format:

#pragma pack [(n)]

n specifies the new alignment restriction in bytes as follows:
1 Align to byte
2 Align to word
4 Align to longword
8 Align to quadword
16 Align to octaword

A structure member is aligned to either the alignment specified by #pragma pack or the alignment determined by the size of the structure member, whichever is smaller. For example, a short variable in a structure gets byte-aligned if #pragma pack (1) is specified. If #pragma pack (2) , (4) , or (8) is specified, the short variable in the structure gets aligned to word.

If #pragma pack is not used, or if (n) is omitted, packing defaults to 8 on DIGITAL UNIX systems.

2.2.1.6 #pragma pointer_size Directive

The #pragma pointer_size preprocessor directive controls pointer size allocation for the following:

For this pragma to have any effect, you must specify -xtaso, -xtaso_short, -vptr_size, or -vptr_size_short on the cxx command.

This pragma has the following syntax:

#pragma pointer_size {long|64}
#pragma pointer_size {short|32}
#pragma pointer_size restore
#pragma pointer_size save

long, or 64

Sets as 64 bits all pointer sizes in declarations that follow this directive, until the compiler encounters another #pragma pointer_size directive.

short, or 32

Sets as 32 bits all pointer sizes in declarations that follow this directive, until the compiler encounters another #pragma pointer_size directive.

restore

Restores the saved pointer size from the pointer size stack.

save

Saves the current pointer size on a pointer size stack.

The save and restore option are particularly useful for specifying mixed pointer support and for protecting header files that interface to older objects. Objects compiled with multiple pointer size pragmas will not be compatible with old objects, and the compiler cannot discern that incompatible objects are being mixed.

Use of short pointers is restricted to DEC C++ and the C compilers resident on DIGITAL UNIX systems. Programs should not attempt to pass short pointers from C++ routines to routines written in any other language except the C programming language. Also, DEC C++ may require explicit conversion of short pointers to long pointers in applications that use short pointers. You should first port those applications in which you are considering using short pointers, and then analyze them to determine if short pointers would be beneficial.

A difference in the size of a pointer in a function declaration is not sufficient to overload a function.

DEC C++ issues an error-level diagnostic if:

2.2.1.7 #pragma required_pointer_size Directive

The #pragma required_pointer_size preprocessor directive controls pointer size allocation in the same way as #pragma pointer_size but without interaction with command-line options. This pragma is always enabled, whether or not you specify any pointer size options on the command line. The same syntax, precautions, and restrictions pertain as with #pragma pointer_size. Neither the pragma name nor its arguments are subject to macro expansion.

2.2.1.8 #pragma required_vptr_size Directive

The #pragma required_vptr_size preprocessor directive controls pointer size allocation in the same way as #pragma required_pointer_size, but it applies to virtual function pointers and virtual bases in a C++ class object. This pragma has the following syntax:

#pragma required_vptr_size {long|64}
#pragma required_vptr_size {short|32}
#pragma required_vptr_size restore
#pragma required_vptr_size save

The parameters have the same meaning as with #pragma required_pointer_size (see Section 2.2.1.6).

The #pragma required_vptr_size directive takes effect at the opening brace of a class declaration. This pragma is always enabled, whether or not you specify any pointer size options on the command line.

2.2.2 Predefined Names (§r.16.10)

Table 2-1 lists the predefined C++ macros used by DEC C++. For information on using predefined macros in header files in the common language environment, see Section 3.1.

Table 2-1 Predefined Macros
Macro Description
__DATE__ A string literal containing the date of the translation in the form Mmm dd yyyy , or Mmm d yyyy if the value of the date is less than 10
__FILE__ A string literal containing the name of the source file being compiled
__TIME__ A string literal containing the time of the translation in the form of hh:mm:ss
__LINE__ A decimal constant containing the current line number in the C++ source file

Table 2-2 lists other names predefined by DEC C++.

(
Table 2-2 Other Predefined Names
Name  
__cplusplus Language identification name.
__DECCXX Language identification name.
__INITIAL_POINTER_SIZE A decimal constant containing the initial pointer size allocation, as specified by the command line. Valid values are: 0 (no pointer size option set), 32 (short or 32-bit pointers allocated), and 64 (long or 64-bit pointers allocated).

On DIGITAL UNIX systems, DEC C++ supports the predefined macro names described in Table 2-3.

Table 2-3 Predefined Macros Specific to DIGITAL UNIX Systems
Name Description
__alpha System identification name
__host_alpha System identification name
__osf__ System identification name
__unix System identification name
__unix__ System identification name

C++ programmers using both DIGITAL UNIX and OpenVMS Alpha operating systems should use the predefined macro __alpha for code that is intended to be portable from one system to the other.

Predefined Implementation Compatibility Macros

When the -cfront command line option is specified, DEC C++ predefines __CFRONT. When the -ms command line option is specified, DEC C++ predefines __MS.

Predefined Version Number Macro

DEC C++ defines the predefined macro __DECCXX_VER. You can use this macro to test that the current compiler version is newer than a particular version. Newer versions of the compiler always have larger values for this macro. If for any reason the version cannot be analyzed by the compiler, then the predefined macro is defined but has the value of 0. Note that releases of DEC C++ prior to Version 5.0 do not define this macro, so you can distinguish earlier compiler versions by checking to determine if the __DECCXX_VER macro is defined.

The following example tests for DEC C++ Version 5.1 or higher: 


#ifdef __DECCXX_VER 
    #if __DECCXX_VER >= 50100000 
        / *Code */ 
    #endif 
#endif

Previous Next Contents Index