Declarations and Definitions in One Header

Steven T. Hatton hattons at globalsymmetry.com
Sun Apr 25 01:05:08 BST 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(How) can I use this with KDevelop 3.x-cvs?

http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/C---Interface.html#C++%20Interface
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 #pragma commands; in a future release of GNU C++, an 
alternative mechanism will make these #pragma commands unnecessary. 

The header file contains the full definitions, but is marked with #pragma 
interface in the source code. This allows the compiler to use the header file 
only as an interface specification when ordinary source files incorporate it 
with #include. In the single source file where the full implementation 
belongs, you can use either a naming convention or #pragma implementation to 
indicate this alternate use of the header file.

#pragma interface
#pragma interface "subdir/objects.h"
    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 
functions) 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 #pragma interface is included in a compilation, this auxiliary 
information will not be generated (unless the main input source file itself 
uses #pragma implementation). Instead, the object files will contain 
references to be 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 "objects.h"
    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 #pragma interface. Backup copies of 
inline member functions, debugging information, and the internal tables used 
to implement virtual functions are all generated in implementation files.

    If you use #pragma implementation with no argument, it applies to an 
include file with the same basename1 as your source file. For example, in 
allclass.cc, giving just #pragma implementation by itself is equivalent to 
#pragma implementation "allclass.h".

    In versions of GNU C++ prior to 2.6.0 allclass.h was treated as an 
implementation file whenever you would include it from allclass.cc even if 
you never specified #pragma implementation. This was deemed to be more 
trouble than it was worth, however, and disabled.

    If you use an explicit #pragma implementation, it must appear in your 
source file before you include the affected header files.

    Use the string argument if you want a single implementation file to 
include code from multiple header files. (You must also use #include to 
include the header file; #pragma implementation only specifies how to use the 
file--it doesn't actually include it.)

    There is no way to split up the contents of a single header file into 
multiple implementation files. 

#pragma implementation and #pragma interface also have an effect on function 
inlining.

If you define a class in a header file marked with #pragma interface, the 
effect on a function defined in that class is similar to an explicit extern 
declaration--the compiler emits no code at all to define an independent 
version of the function. Its definition is used only for inlining with its 
callers.

Conversely, when you include the same header file in a main source file that 
declares it as #pragma implementation, the compiler emits code for the 
function itself; this defines a version of the function that can be found via 
pointers (or by callers compiled without inlining). If all calls to the 
function can be inlined, you can avoid emitting the function by compiling 
with -fno-implement-inlines. If any calls were not inlined, you will get 
linker errors.
Footnotes

   1.

      A file's basename was the name stripped of all leading path information 
and of trailing suffixes, such as .h or .C or .cc.


http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/C---Interface.html#C++%20Interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAiwC8wX61+IL0QsMRAtPpAKCfEWhH1qYgFVetuAfpbPAlPso+8gCfYbKw
CFkHOaQH0GkFiAUEZrsoIS0=
=bHJs
-----END PGP SIGNATURE-----

-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«



More information about the KDevelop mailing list