Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!elroy.jpl.nasa.gov!usc!wuarchive!udel!rochester!kodak!uupsi!sunic!lth.se!newsuser
From: dag@control.lth.se (Dag Bruck)
Newsgroups: comp.lang.c++
Subject: Re: A GNU Makefile (was: ... header files **and** inline management)
Message-ID: <1991Feb18.073640.1335@lth.se>
Date: 18 Feb 91 07:36:40 GMT
References: <1991Feb5.180503.24515@mathcs.sjsu.edu> <3787@lupine.NCD.COM> <1991Feb11.081550.18057@eua.ericsson.se> <3943@lupine.NCD.COM>
Sender: newsuser@lth.se (LTH network news server)
Organization: Department of Automatic Control, Lund, Sweden
Lines: 49

In article <3943@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>In article <1991Feb11.081550.18057@eua.ericsson.se> euamts@eua.ericsson.se (Mats Henricson) writes:
>>The most important thing with a C++ class is its interface to the outside
>>world, i.e. the header file. That is why I design the header file first,
>>and then the .cc-file.
>
>And you never go back and make any changes to the "interface" part once
>you have written it for the first time!?!?!?!
>I'd like to meet you someday.  I've never had the opportunity to meet a
>"perfect" programmer before!
>In other words you want the "implementation" part to be automatically
>derived from the "interface" or "specification" part, eh?

These comments are so stupid that they have to be a deliberate joke.
Just in case they aren't, allow me to point out that:

1.  If the the design is well-understood and verified, for example by
implementing a prototype, we can generate header files and stubs from
the prototype. 

2.  If the design is good, there will be few changes in the
definition, so some automatic help generating the first set of stubs
will be helpful even if subsequent changes must be handcrafted.

3.  Some organizations do software development in a more "serious" way
than either you and I, for example, AT&T and Ericsson.  It should be
plain obvious that they rarely can afford changing the class interface
after it has entered the production environment.

Oh, well.  Excuse me for overreacting.

In any case, I cannot see the big difference of starting with the .H
file and generating the .C file, or going the other way.  The whole
idea of separate .H/.C files is old, and doesn't work too well.  A
better integrated system, like the module concept of Modula-2 (which
I'm experienced with), works much better.  What we need is something
like a database of class definitions, class implementations, typedefs,
etc.  In particular, I miss the possibility to "import" just part of
what is bundled in a .H file.

To answer the obvious question:  No, I don't think this should part of
the C++ language definition, it should be part of the environment.

Dag M. Bruck
--
Department of Automatic Control		E-mail: dag@control.lth.se
Lund Institute of Technology
P. O. Box 118				Phone:	+46 46-104287
S-221 00 Lund, SWEDEN			Fax:    +46 46-138118