Declarations And Definitions In One Header - Red Hat ENTERPRISE LINUX 3 - USING GCC Using Instructions

214
When used with GNU ld version 2.8 or later on an ELF system such as Linux/GNU or Solaris 2, or on
Microsoft Windows, duplicate copies of these constructs will be discarded at link time. This is known
as COMDAT support.
On targets that don't support COMDAT, but do support weak symbols, GCC will use them. This way
one copy will override all the others, but the unused copies will still take up space in the executable.
For targets which do not support either COMDAT or weak symbols, most entities with vague linkage
will be emitted as local symbols to avoid duplicate definition errors from the linker. This will not
happen for local statics in inlines, however, as having multiple copies will almost certainly break
things.
Section 7.5 Declarations and Definitions in One Header, for another way to control placement of
these constructs.
7.5. Declarations and Definitions in One Header
C++ object definitions can be quite complex. In principle, your source code will need two kinds of
things for each object that you use across more than one source file. First, you need an interface
specification, describing its structure with type declarations and function prototypes. Second, you
need the implementation itself. It can be tedious to maintain a separate interface description in a
header file, in parallel to the actual implementation. It is also dangerous, since separate interface and
implementation definitions may not remain parallel.
With GNU C++, you can use a single header file for both purposes.
Warning: The mechanism to specify this is in transition. For the nonce, you must use one of two
commands; in a future release of GNU C++, an alternative mechanism will make these
unnecessary.
The header file contains the full definitions, but is marked with
code. This allows the compiler to use the header file only as an interface specification when ordinary
source files incorporate it with
belongs, you can use either a naming convention or
alternate use of the header file.
#pragma interface
#pragma interface "
Use this directive in header files that define object classes, to save space in most of the object
files that use those classes. Normally, local copies of certain information (backup copies of inline
member functions, debugging information, and the internal tables that implement virtual func-
tions) must be kept in each object file that includes class definitions. You can use this pragma
to avoid such duplication. When a header file containing
compilation, this auxiliary information will not be generated (unless the main input source file
itself uses
#pragma implementation
resolved at link time.
The second form of this directive is useful for the case where you have multiple headers with
the same name in different directories. If you use this form, you must specify the same string to
#pragma implementation
#pragma implementation
#pragma implementation "
Use this pragma in a main input file, when you want full output from included header files to
be generated (and made globally visible). The included header file, in turn, should use
. In the single source file where the full implementation
#include
/ .h"
subdir objects
). Instead, the object files will contain references to be
.
.h"
objects
Chapter 7. Extensions to the C++ Language
#pragma interface
#pragma implementation
#pragma interface
#pragma
commands
#pragma
in the source
to indicate this
is included in a
#pragma