12.2. The System Library: libSystem

 < Day Day Up > 

12.1. Header Files

There are two types of header files in Mac OS X.


Ordinary header files

These header files are inserted into source code by a preprocessor prior to compilation. Ordinary header files have a .h extension.


Precompiled header files

These header files have a .h.gch extension.

Header files serve four functions:

  • They contain C declarations.

  • They contain macro definitions.

  • They provide for conditional compilation.

  • They provide line control when combining multiple source files into a single file that is subsequently compiled.

The mechanism for enabling POSIX.4 compliance is built into the system header files. The preprocessor variables _ANSI_SOURCE, _ _STRICT_ANSI_ _, and _POSIX_SOURCE are supported. Because Mac OS X itself is not POSIX.4 compliant, you cannot achieve strict POSIX.4 compliance. Using these mechanisms, however, is best way to approximate POSIX.4 compliance.


Unix developers will find the ordinary header files familiar, since they follow the BSD convention. The C preprocessor directive #include includes a header file in a C source file. There are essentially three forms of this syntax:


#include < headername.h>

This form is used when the header file is located in the directory /usr/include.


#include < directory/headername.h>

This form is used when the header file is located in the directory /usr/include/ directory, where directory is a subdirectory of /usr/include.


#include " headername.h"

This form is used when the header file is located in a user or nonstandard directory. The form should either be in the same directory as the source file you are compiling or in a directory specified by cc's -Idirectory switch.

You can use #include, followed by a macro, which, when expanded, must be in one of the aforementioned forms.

As noted in the previous chapter, frameworks in Mac OS X are common when you step outside of the BSD portions of the operating system. To include a framework header file in Objective-C code, use the following format:

     #import <frameworkname/headerfilename.h> 

where frameworkname is the name of the framework without the extension and headerfilename is the name of the header file. For example, the included declaration for a Cocoa application would look like:

     #import <Cocoa/Cocoa.h> 

Note that you must use #include rather than #import when including a framework in Carbon code. When preprocessing header files or any preprocessor directives, the following three actions are always taken:

  • Comments are replaced by a single space.

  • Any backslash line continuation escape symbol is removed, and the line following it is joined with the current line. For example:

         #def\     ine \     NMAX 2000

    is processed as:

         #define NMAX 2000

  • Any predefined macro name is replaced with its expression. In Mac OS X, there are both standard ANSI C predefined macros , as well as several predefined macros specific to Mac OS X. For example, _ _APPLE_CC_ _ is replaced by an integer that represents the compiler's version number.

The following rules must be kept in mind:

  • The preprocessor does not recognize comments or macros placed between the < and > symbols in an #include directive.

  • Comments placed within string constants are regarded as part of the string constant and are not recognized as C comments.

  • If ANSI trigraph preprocessing is enabled with cc -trigraph, you must not use a backslash continuation escape symbol within a trigraph sequence, or the trigraph will not be interpreted correctly. ANSI trigraphs are three-character sequences that represent characters that may not be available on older terminals. For example, ??< translates to {. ANSI trigraphs are a rare occurrence these days.

12.1.1. Precompiled Header Files

Mac OS X's Xcode Tools support and provide extensive documentation on building and using precompiled header files. This section highlights a few of the issues that may be of interest to Unix developers new to Mac OS X when it comes to working with precompiled headers.

Precompiled header files are binary files that have been generated from ordinary C header files and preprocessed and parsed using cc. When such a precompiled header is created, both macros and declarations present in the corresponding ordinary header file are sorted, resulting in a faster compile time, a reduced symbol table size, and consequently, faster lookup. Precompiled header files are given a .h.gch extension and are produced from ordinary header files that end with a .h extension. There is no risk that a precompiled header file will get out of sync with the .h file, because the compiler checks the timestamp of the actual header file.

When using precompiled header files , you should not refer to the .h.gch version of the name, but rather to the .h version in the #include directive. If a precompiled version of the header file is available, it is used automatically; otherwise, the real header file (.h) is used. So, to include foo.h.gch, specify foo.h. The fact that cc is using a precompiled header is totally hidden from you.

You can create precompiled header files either using the cc -precomp or cc -x c-header -c compile driver flags. For example, the following command illustrates this process in its simplest, context-independent form:

     cc -precomp header.h 

The following command has the same effect:

     cc -x c-header -c header.h 

In either case, the resulting precompiled header is named header.h.gch. If there is context dependence (for example, some conditional compilation), the -Dsymbol flag is used. In this case, the command to build a precompiled header file (with the FOO symbol defined) is:

     cc -precomp -DFOO header.h -o header.h.gch 

The -x switch supplies the language (see "Supported Languages" in Chapter 11):

     gcc -x c c-header header.h 

Then, you can compile main.c as usual:

     gcc -o main main.c 

Example 12-1 shows header.h, and Example 12-2 shows main.c.

Example 12-1. The header .h file
 /* header.h: a trivial header file. */ #define x 100

Example 12-2. The main .c application
 /* main.c: a simple program that includes header.h. */ #include "header.h" #include <stdio.h> int main( ) {   printf("%d\n", x);   return 0; } 

There are a few issues to keep in mind when you use a precompiled header file.

  • You can include only one precompiled header file in any given compilation.

  • Although you can place preprocessor directives before it, no C tokens can be placed before the #include of the precompiled header. For example, if you switch positions of the two #include directives in Example 12-2, the precompiled header, header.h.gch, is ignored by the compiler.

  • The language of the precompiled header must match the language of the source in which it is included.

  • The precompiled header and the current compilation, in which the precompiled header is being included, must be the same. So, for example, you can't include a procompiled header that was produced by GCC 3.3 in a code being compiled with GCC 4.0.

For more details on building and using precompiled header files, read the documentation stored in /Developer/ADC Reference Library/documentation/DeveloperTools/gcc-4.0.0/ gcc/Preccompiled-Headers.html.

Persistent Front End (PFE) precompilation , needed for C++ and Objective-C++ in pre-Tiger versions of Mac OS X, and cpp-precomp are not supported in Tiger.


12.1.2. malloc.h

make may fail to compile some types of Unix software if it cannot find malloc.h. Software designed for older Unix systems may expect to find this header file in /usr/include; however, malloc.h is not present in this directory. The set of malloc( ) function prototypes is actually found in stdlib.h. For portability, your programs should include stdlib.h instead of malloc.h. (This is the norm; systems that require malloc.h are the rare exception these days.) GNU autoconf will detect systems that require malloc.h and define the HAVE_MALLOC_H macro. If you do not use GNU autoconf, you will need to detect this case on your own and set the macro accordingly. You can handle such cases with this code:

     #include <stdlib.h>     #ifdef HAVE_MALLOC_H     #include <malloc.h>     #endif 

For a list of libraries that come with Mac OS X, see the "Interesting and Important Libraries" section, later in this chapter.

12.1.3. poll.h

In pre-Tiger versions of Mac OS X, one issue in porting software from a System V platform to a BSD platform such as Mac OS X was the lack of the poll( ) system call function, which provides a mechanism for I/O multiplexing. Panther provided this function through emulation, which made use of its BSD analog select( ). In Tiger, poll( ) is provided as a native function. The associated header file, /usr/include/poll.h, is included with Panther as well as Tiger.

12.1.4. wchar.h and iconv.h

Another issue in porting Unix software to pre-Panther versions of Mac OS X was the relatively weak support for wide (i.e., more than 8-bits) character datatypes (e.g., Unicode). Panther and Tiger provide better support for wide character data types by including the GNU libiconv, which provides the iconv( ) function to convert between various text encodings. Additionally, the wchar_t type is supported in both Panther and Tiger. The header files iconv.h and wchar.h are also included. Alternatively, you can use the APIs available in the CoreFoundation's String services , which are described in CFString.h.

12.1.5. dlfcn.h

This header file, associated with dl-functions like dlopen( ), is included in Tiger. The functions such as dlopen( ) are actually included in libSystem.

12.1.6. alloc.h

Although this header file is not included with Mac OS X, its functionality is provided by stdlib.h. If your code makes a specific request to include alloc.h, you have several choices. One option is to remove the #include <alloc.h> statement in your source code. This may be cumbersome, however, if your include statement appears in many files. Another alternative is to create your own version of alloc.h. A sample alloc.h is suggested in The Apple Developer Connection's Technical Note TN2071 (http://developer.apple.com/technotes/tn2002/tn2071.html).

12.1.7. lcyrpt.h

Although lcrypt.h is not included in Mac OS X, its functionality is provided in unistd.h .

12.1.8. values.h

The values.h file, another header file found on many Unix systems, is not included in Mac OS X. Its functionality, however, is provided by limits.h .

     < Day Day Up > 


    Mac OS X Tiger for Unix Geeks
    Mac OS X Tiger for Unix Geeks
    ISBN: 0596009127
    EAN: 2147483647
    Year: 2006
    Pages: 176

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net