This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: #pragma interface and #pragma implementation


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

On Wednesday 02 June 2004 03:11, Per Bothner wrote:
> Steven T. Hatton wrote:
> > Your comments seem somewhat inconsistent with what the documentation
> > says.

> Wow, I had no idea the documentation made this claim.

The documentation states rather clearly that these #pragmas provide a kind of 
functionality I would like to have.  And its harsh words about splitting the 
implementation from the interface are quite consistent to my thinking. I'm 
still fairly new to C++.  I've had bits of exposure from time to time over 
the past decade, but have only dedicated a few months exclusively to C++.  
There is nothing that has bitten me as hard, nor as many times as issues 
related to headers. 

> I think I can safely say that this documentation is a wee bit misleading
> ...  It seems to have been written by someone who didn't quite
> understand the #pragma.  Either that, or their meaning changed.  Or
> perhaps just my understanding of it changed ...

I've been discussing this on the comp.lang.c++, and have been given new 
insight into this situation.  It seems what these #pragmas do is very close 
to something that /might/ accomplish the goal of using a single file format 
for both header and implementation. I guess what GCC actually does is create 
one object image, and treat it as if it appeared in the different translation 
units.  That might explain the multiple definition errors I was getting while 
using the #pragmas.
 
> #pragma interface just effects the one header file it appears in.
> It causes supression of vtables, debug info, and inline functions
> for declarations (primarily classes) in that header file *unless*
> there is a corresponding #pragma implementation.  In the implementing
> .o file, the vtables etc are made global, so they can be shared by
> other .o files.  The intent is that each foo.h is an interface that
> is implemented by one foo.c file.

That is _not_ what these words mean:

"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. "


> I'd say it's an incorrect understanding - but understandable based on
> the manual.  However, I'm confused by why you'd "previously been
> necessary to put the implementation in the source file to prevent
> multiple definition error".  That suggests to me some further confusion
> on your part as to how C++ works.

I believe I now have sufficient grasp of the issue to understand why the 
inclusion of the same header in multiple source files leads to multiple 
definitions even with include guards.  It's because each source file is 
converted to a unique translation unit.  Now what exactly constitutes a 
header file is a different issue.  I scanned the info pages for how GCC 
determines what a source file is.  I didn't see anything, but I'll continue 
to look, or ask on gnu.gcc.help or gnu.g++.help.

- -- 
Regards,
Steven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAvvFowX61+IL0QsMRAhD8AJ980vDT62J+fJ82/oC5JaJKiaomnACfRD4X
XJSAPo2uepm4XLp4xPkhFsE=
=6N5T
-----END PGP SIGNATURE-----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]