Re: Header Files and Interfaces Yet Again

From: Kai-Uwe Bux (jkherciueh_at_gmx.net)
Date: 06/11/04 

Date: Fri, 11 Jun 2004 09:24:15 -0400

Hi,

These posts are getting a little too long, so I will focus on one point
only.

Steven T. Hatton wrote:
>> The point that I hope to get across is that header files need to provide
>> information to the compiler that is of no concern to the programmer using
>> the library. Private fields of classes are of no concern whatsoever to
>> the user. Nonetheless, a compiler has to know about them at compile time.
>> Therefore, fake headers can not serve as sufficient information to the
>> compiler.
>
> They don't need to. Stroustrups approach is very similar to what you are
> doing. But he actually uses what you call a fake header. There is no rule
> against having multiple declarations appear in the same translation unit.
> I'm not really srue why header files that present things that aren't
> necessary for the client's code should need to be #included in the
> client's
> source file. They should be #included in your source files. What you are
> calling the fake header should be #included in the client's source.
> Stroustrup even #includes the equivilaent in the implementation's header
> to test it for consistency.

and latter:
>> The compiler will need to know a lot more than I want to read in the
>> standard. I do not want the standard to tell me about private members of
>> the container classes.
>
> You really should try to get a copy of Stroustrup's book. It explains how
> both of these can be the case. That is, I get a foo.h user's header file
> and the implementation has a foo_impl.h header file.

That appears to be an interesting concept. But you have me wonder how this
is possible. As you are refering to Java sometimes, let me describe, for
the sake of exposition, what, in my mind, is one of the major conceptual
differences between Java and C++: In Java all obects appear to be handles.
Consider the code:

a = b;
b.some_modifying_method( arg );

My understanding of Java is that the changes inflicted upon b will affect a
as well, after the assignment, a and b are names for the same object.
Whatever you do to it using one name you could as well do using the other.
In C++, this is not true--at least not for the compiler generated
assignment operator.

This difference is important for the ways compiler can go about generating
code. In Java any user defined class could always be represented by a
pointer. Assignment is pointer assignement. Since actual objects are only
created at runtime, it is the linker that must know about the sizes of the
physical objects that the object handles point to. But the compiler can
safely assume that an object handle has the size of one pointer. In C++,
life is more tricky. If the library presents a header:

// file: foo.h

class PhoneDirectory {
// private data fields suppressed.
public:

  void insert ( const std::string & name,
                const std::string & number );

  ...

}

and client code says:

// file: main.cc

#include <PhoneDirectory.h>

int main () {
  PhoneDirectory dir;
  ...

}

Then, how is the compiler supposed to deduce the size of the variable
"dir"?

Best

Kai-Uwe

ps.: Please go gentle on me, I have only a very superficial knowledge of
Java, and what I said may grossly misrepresent Java.

Relevant Pages

  • Re: Cpp Considered Harmful
    ... >> I will observe that many Java IDEs do this rather successfully. ... > Look, if a tool author is willing to fully parse the underlying language, ... > compiler version. ... mentions a header file is in the C compatability appendix. ...
    (comp.lang.cpp)
  • Re: Header Files and Interfaces Yet Again
    ... >> headers to feed to the compiler. ... But he actually uses what you call a fake header. ... I'm not really srue why header files that present things that aren't ... >> something but it appears to me the Standard Library is not designed ...
    (comp.lang.cpp)
  • Re: C++: compiling header files
    ... I'm writing a header file named ... > Anyway, I thought the compiler will just do a syntax check, but it seems it ... The precompilation step is supposed to speed up the ... especially for large header files ...
    (comp.lang.cpp)
  • Re: c++ interpreter
    ... just as the Eclipse developers did for Java. ... arguments, read all the header files, expand all the templates, etc. ... compiler" is on the hard end of the scale. ... the compiler emulation must match the destination compiler ...
    (comp.lang.cpp)
  • Re: Newbie questions (four of them)
    ... > C much more difficult than I did the first semester of Java. ... if you're using an interpreter rather than a compiler - ... Think of the preprocessor as a separate "compiler" which mungs the source ... and make sure that header is included. ...
    (comp.lang.c)