Re: changing module files

From: Dave Thompson (david.thompson1_at_worldnet.att.net)
Date: 12/25/03 

Date: Thu, 25 Dec 2003 01:45:28 GMT

On Wed, 17 Dec 2003 08:51:49 -0500, "John Lansberry"
<john.lansberry@jhuapl.edu> wrote:
<snip>
> For me, the fact that modules must be compiled is a major obstacle to object
> oriented (OO) programming. That is, objects of different classes
> (definitions of which are encapsulated in modules) cannot USE each other
> (directly or indirectly).
>
> C++ header files avoid that problem, because header files only declare the
> INTERFACE to class member functions. Whether any such member function is
> actually defined somewhere is not determined until compile time.

This is not entirely correct. If you want inline(able) definitions of
methods, they must be defined in the declaration used by callers,
which for a normal source organization is the header file. And the
class declaration includes all data members and methods (and thus
vtable layout) even those to which external access is not allowed.

> Hence, if
> the header file is wrong (provides the wrong list of arguments to a
> function), you won't know about it until link time in C++.

The implementation should always #include the interface specification
used by clients, and any *mismatch* of a method implementation will be
caught at compile time. A *missing* implementation will only be caught
at link -- or for the few automatically synthesized by the compiler,
like default constructor and assignment, not at all. For free routines
mismatch won't be caught until link, because it will just look like an
overload. And (accidental) use of the wrong declaration of a class, or
other data structure, such as by using the wrong include directories,
generally won't be caught at all.

> I'm no fan of
> header files. I think they are ugly and prone to errors. Plus, you need to
> understand and be comfortable with all of the preprocessor macros. IMHO,
> requiring the use of a preprocessor to get something to compile and link
> represents a fundamental flaw in the design of the language.

No macros are needed by C or C++ header files particularly except
(usually) "include guards" to prevent (unnecessarily illegal)
duplicate declarations if the same header is #include'd more than
once, such as for multiple inheritance paths; these are simple and can
be treated almost as noise, like IMPLICIT NONE.

C++ code and even more so C does tend to use macros a lot, and they
don't fit into the language very well, but this is true of source code
and even build commands/files as well as header files.

Certainly source inclusion, while more general, is less precise than a
true module/package/whatever system, whether with separate interfaces
as in Ada or not as in Fortran or Java, but I think 'fundamental flaw'
is going a bit far.

- David.Thompson1 at worldnet.att.net

Relevant Pages

  • Header files
    ... In the fortran code that I have, there is a subroutine in which ... I am using a pgi compiler to compile 2D.F and my code. ... character...and it gives the names of all header files. ...
    (comp.lang.fortran)
  • Re: Problem with reading an int with operator>>
    ... Stephen Howe wrote: ... Now I know there were a few flaws in the header files for Visual Studio ... So that if I did want to use dynamic linking, the VC6 standard library would be defective. ... But as Tom pointed out, there are only two common instantiations of much of the standard library, i.e. those for char and wchar_t, and MS has chosen to compile those into the C++ RTL DLL. ...
    (microsoft.public.vc.stl)
  • Re: Another question on VS2003 to VS2005
    ... EVERY instance of the word "PASCAL" from the Platform SDK, MFC, and other header files. ... One thing you can do is add the /P switch to the compile line for this file (that's ... Check if LONG, GSFAR, GSPASCAL and GSEXPORT are correctly defined as something ... a class definition in a header file that is included before these lines. ...
    (microsoft.public.vc.mfc)
  • Re: Problem with reading an int with operator>>
    ... is not so) is that if you compile stand alone, ... Now I know there were a few flaws in the header files for Visual Studio ... If you compiled with /ML or /MT in force, the constructor I think, lives ... If I examine the imports from MSVCP71.DLL that TEST.EXE has made, ...
    (microsoft.public.vc.stl)
  • Re: Yet another when to use macros question....
    ... Lisp data to go in, and quality machine code to pop out! ... You keep saying that code with functions only is better than macros. ... compile all the way to native code). ... SETQ is a general-purpose assignment operator that ...
    (comp.lang.lisp)