JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Studio 12.2: C++ User's Guide
search filter icon
search icon

Document Information


Part I C++ Compiler

1.  The C++ Compiler

2.  Using the C++ Compiler

3.  Using the C++ Compiler Options

Part II Writing C++ Programs

4.  Language Extensions

4.1 Linker Scoping

4.1.1 Compatibility with Microsoft Windows

4.2 Thread-Local Storage

4.3 Overriding With Less Restrictive Virtual Functions

4.4 Making Forward Declarations of enum Types and Variables

4.5 Using Incomplete enum Types

4.6 Using an enum Name as a Scope Qualifier

4.7 Using Anonymous struct Declarations

4.8 Passing the Address of an Anonymous Class Instance

4.9 Declaring a Static Namespace-Scope Function as a Class Friend

4.10 Using the Predefined __func__ Symbol for Function Name

4.11 Supported Attributes

4.11.1 __packed__

5.  Program Organization

6.  Creating and Using Templates

7.  Compiling Templates

8.  Exception Handling

9.  Improving Program Performance

10.  Building Multithreaded Programs

Part III Libraries

11.  Using Libraries

12.  Using The C++ Standard Library

13.  Using the Classic iostream Library

14.  Using the Complex Arithmetic Library

15.  Building Libraries

Part IV Appendixes

A.  C++ Compiler Options

B.  Pragmas



4.1 Linker Scoping

Use the following declaration specifiers to help constrain declarations and definitions of extern symbols. The scoping restraints you specify for a static archive or an object file will not take effect until the file is linked into a shared library or an executable. Despite this, the compiler can still perform some optimization given the presence of the linker scoping specifiers.

By using these specifiers, you no longer need to use mapfiles for linker scoping. You can also control the default setting for variable scoping by specifying -xldscope on the command line.

For more information, see A.2.136 -xldscope={v}.

Table 4-1 Linker Scoping Declaration Specifiers

Symbol definitions have global linker scoping and is the least restrictive linker scoping. All references to the symbol bind to the definition in the first dynamic load module that defines the symbol. This linker scoping is the current linker scoping for extern symbols.
Symbol definitions have symbolic linker scoping and is more restrictive than global linker scoping. All references to the symbol from within the dynamic load module being linked bind to the symbol defined within the module. Outside of the module, the symbol appears as though it were global. This linker scoping corresponds to the linker option -Bsymbolic. Although you cannot use -Bsymbolic with C++ libraries, you can use the __symbolic specifier without causing problems. See ld(1) for more information on the linker.
Symbol definitions have hidden linker scoping. Hidden linker scoping is more restrictive than symbolic and global linker scoping. All references within a dynamic load module bind to a definition within that module. The symbol will not be visible outside of the module.

A symbol definition may be redeclared with a more restrictive specifier, but may not be redeclared with a less restrictive specifier. A symbol may not be declared with a different specifier once the symbol has been defined.

__global is the least restrictive scoping, __symbolic is more restrictive, and __hidden is the most restrictive scoping.

All virtual functions must be visible to all compilation units that include the class definition because the declaration of virtual functions affects the construction and interpretation of virtual tables.

You can apply the linker scoping specifiers to struct, class, and union declarations and definitions because C++ classes may require generation of implicit information, such as virtual tables and run-time type information. The specifier, in this case, follows the struct, class, or union keyword. Such an application implies the same linker scoping for all its implicit members.

4.1.1 Compatibility with Microsoft Windows

For compatibility with similar scoping features in Microsoft Visual C++ (MSVC++) for dynamic libraries, the following syntax is also supported:

__declspec(dllexport) is equivalent to __symbolic
__declspec(dllimport) is equivalent to __global

When taking advantage of this syntax with Solaris Studio C++, you should add the option -xldscope=hidden to CC command lines. The result will be comparable to the results using MSVC++. With MSVC++, __declspec(dllimport) is supposed to be used only on declarations of external symbols, not on definitions. Example:

__declspec(dllimport) int foo(); // OK 
__declspec(dllimport) int bar() { ... } // not OK  

MSVC++ is lax about allowing dllimport on definitions, and the results using Solaris Studio C++ will be different. In particular, using dllimport on a definition using Solaris Studio C++ results in the symbol having global linkage instead of symbolic linkage. Dynamic libraries on Microsoft Windows do not support global linkage of symbols. If you run into this problem, you can change the source code to use dllexport instead of dllimport on definitions. You will then get the same results with MSVC++ and Solaris Studio C++.