Compiler Design

GCC Option Refresher The g++ compiler accepts both single-letter options, such as -o, and multi letter options, such as -ansi. Because it accepts both types of options you cannot group multiple single-letter options together, as you may be used to doing in many GNU and Unix/Linux programs. For example, the multiletter option -pg is not the same as the two single-letter options -p -g. The -pg option creates extra code in the final binary that outputs profile information for the GNU code profiler, gprof. On the other hand, the -p -g options generate extra code in the resulting binary that produces profiling information for use by the prof code profiler (-p) and causes gcc to generate debugging information using the operating system’s normal format (-g). Despite its sensitivity to the grouping of multiple single-letter options, you are generally free to mix the order of options and compiler arguments on the gcc command line. That is, invoking g++ as g++ -pg -fno-strength-reduce -g myprog.c -o myprog has the same result as g++ myprog.c -o myprog -g -fno-strength-reduce –pg I wrote that you are generally free to mix the order of options and compiler arguments because, in most cases, the order of options and their arguments does not matter. In some situations, order does matter, if you use several options of the same kind. For example, the -I option specifies the directory or directories to search for include files. So, if you specify -I several times, gcc searches the listed directories in the order specified. Compiling a single source file, myprog.cc, using g++ is easy—just invokes g++, passing the name of the source file as the argument. $ g++ myprog.cc $ ls –l

By default, the result on Linux and Unix systems is an executable file named a.out in the current directory, which you execute by typing ./a.out. On Cygwin systems, you will wind up with a file named a.exe that you can execute by typing either. /a or. /a.exe. To define the name of the output file that g++ produces, use the -o option, as illustrated in the following example:

i

$ g++ myprog.cc -o runme $ ls –l

If you are compiling multiple source files using g++, you can simply specify them all on the gcc command line, as in the following example, which leaves the compiled and linked executable in the file named showdate: $ g++ showdate.cc helper.cc –o showdate If you want to compile these files incrementally and eventually link them into a binary, you can use the –c option to halt compilation after producing an object file, as in the following example: $ $ $ $

g++ -c showdate.cc g++ -c helper.cc g++ showdate.o helper.o –o showdate ls -l

It should be easy to see that a project consisting of more than a few source code files would quickly become exceedingly tedious to compile from the command line, especially after you start adding search directories, optimizations, and other g++ options. The solution to this command-line tedium is the make utility, which is not discussed in this book due to space constraints.

Filename Extensions for C++ Source Files As mentioned in the previous section, all GCC compilers evaluate filename suffixes to identify the type of compilation that they will perform. Table 2-1 lists the filename suffixes that are relevant to g++ and the type of compilation that g++ performs for each.

ii

Table 2-1. GCC Filename Suffixes for C++ A filename with no recognized suffix is considered an object file to be linked. GCC’s failure to recognize a particular filename suffix does not mean you are limited to using the suffixes listed previously to identify source or object files. We can use the -x lang option to identify the language used in one or more input files if you want to use a nonstandard extension. The lang argument tells g++ the input language to use; and for C++, input files can be either c++ (a standard C++ source file) or c++-cpp-output (a C++ source file that has already been preprocessed and therefore need not be preprocessed again).

Command-Line Options for GCC’s C++ Compiler Many command-line options are common to all of the compilers in the GCC suite. Table 2-2 shows the command-line options that are specific to the g++ compiler.

GNU C++ Implementation Details and Extensions When we write C++ code that can be compiled using the GCC C++ compiler, We can take advantage of a number of extensions to both C++ through the compiler itself and the Standard C++ library used by g++, libstdc++.

Attribute Definitions Specific to g++ g++ supports two additional attributes that are explicitly designed for use in C++ applications. These are the init_priority(priority) and java_interface attributes.

The init_priority Attribute The init_priority(priority) attribute enables user control over the order in which objects defined in a namespace scope are initialized . Normally, objects are initialized in the order in which they are defined within a

iii

translation unit. The init_priority attribute takes a single argument, which is an integer value between 101 and 65,535 (inclusive), where lower numbers indicate a higher priority.

The java_interface Attribute The java interface type attribute informs g++ that the class is a Java interface, and can only be used with classes that are declared within an extern “Java” block. Calls to methods declared in this class are called using the GCC Java compiler’s interface table mechanism, instead of the regular C++ virtualunction table mechanism.

C++ Template Instantiation in g++ Templates are most useful features of C++, reducing code size and the amount of duplicate code, encouraging reusability, simplifying debugging and code maintenance, and enforcing type checking at compile time. The GCC g++ compiler extends the standard ISO template definition by adding three capabilities- support for forward declaration of explicit instantiations by using the extern keyword , the ability to instantiate the support data required by the compiler,the ability to only instantiate the static data members of a class without instantiating supportdata. In general, GCC’s g++ compiler supports Borland and Cfront (AT&T) template models.To support the Borland model of template instantiation and use, g++ provides the frepo option to enable template instances for each translation unit that uses them to be generated at compile time by the preprocessor, which stores them in files with the .rpo extension.

Function Name Identifiers in C++ and C GCC compilers predefine two identifiers that store the name of the current function. The FUNCTION__identifier stores the function name as it appears in the source code and __PRETTY_FUNCTION__ stores the name pretty printed in a language-specific fashion. In C programs, the two function names are the same, but in C++ programs they are usually different.

ABI Differences in g++ Versions The C++ application binary interface (ABI) is the binary flip side of the application programming interface (API) defined by the C++ datatypes, classes, and methods in the include files and libraries that are provided by a C++ library implementation. A consistent binary interface is required in order for compiled C++ applications to conform to the binary conventions used in

iv

associated C++ libraries and related object files for things such as physical organization, parameter passing conventions, and naming conventions.

Minimum and Maximum Value Operators GCC’s g++ compiler adds the ? operators, which, respectively, return the minimum and maximum of two integer arguments. For example, the following statement would assign 10 to the min variable: min = 10 ? 15;

Using Java Applications

Exception

Handling

in

C++

The Java and C++ exception handling models differ, and though g++ tries to guess when our C++ code uses Java exceptions, it is always safest to explicitly identify such situations to avoid link failures. To tell g++ that a block of code may use Java exceptions, insert the following pragma in the current translation unit before any code that catches or throws exceptions: #pragma GCC java_exceptions We cannot mix Java and C++ exceptions in the same translation unit.

Visibility Attributes and Pragmas for GCC C++ Libraries GCC versions 4.02 and later provide the new –fvisibility=value option and related internal attributes to enable us to control this behavior in a fashion similar to the mechanism provided by __declspec(dllexport) in Microsoft’s C++ compilers. The new –fhidden option takes two possible values: default, to continue to export all symbols from the current object file, and hidden, which causes g++ not to export the symbols from the current object module. These two visibility cases are reflected by two new per-function/class attributes for use in C++ applications: __attribute__ ((visibility("default"))) and __attribute__ ((visibility("hidden"))). To prevent ELF symbols from being exported from a specific object file, use the –fvisibility=hidden option when compiling that file. This can lead to increased complexity when creating a C++ library using a single Makefile because it requires that our either set manual compilation options for each object file contained in a shared library, or that We add this option to our global compilation flags for the library and therefore do not export any symbols from any of a shared library’s component object files. The best mechanism for making selected symbols visible is through a combination of using the visibility attributes and the –

v

fvisibility=hidden command-line option. For any structs, classes, or methods whose symbols must be externally visible, add the __attribute__ ((visibility ("default"))) attribute to their definition, as in the following example: Class MyClass { int i; __attribute__ ((visibility ("default"))) void MyMethod(); … }; can then add the –fvisibility=hidden option to the generic Makefile compilation flags for all of our object files, which will cause symbols to be hidden for all structs, classes, and methods that are not explicitly marked with the default visibility attribute. A slightly more elegant and memorable solution to symbol visibility is to define a local visibility macro in a global header file shared by all of the object modules in a library, and then put that macro in front of the declaration for any class or method definition whose symbols we do not want to export. In the converse of the previous example, if we want to export symbols by default but restrict those for selected classes and methods, this might look something like the following: #define LOCAL __attribute__ ((visibility ("hidden"))) Class MyClass { int i; LOCAL void MyMethod(); … }; The source module containing this sample code could be compiled without using the –fvisibility=value option and would export all symbols from MyClass with the exception of those in the method MyMethod(). A pragma for the new visibility mechanism is currently supported, but will probably go away in future versions. New code should use visibility __attribute__, but existing class and function declarations can quickly be converted using the visibility pragma, as in the following example: extern void foo(int); #pragma GCC visibility push (hidden) extern void bar(int); #pragma GCC visibility pop In this example, symbols would still be exported from foo() but not from bar(). We must also be especially careful not to use this pragma with userdefined types that can throw exceptions across object file boundaries due to the fact that typeinfo information is part of the symbol information that is hidden.

vi

vii