Newsgroups: comp.lang.c++
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: .h-file extractor from c++ source file available?
Message-ID: <1988Aug10.164919.20178@utzoo.uucp>
Organization: U of Toronto Zoology
References: <2192@hplabsz.HPL.HP.COM> <1988Aug7.005251.7548@utzoo.uucp> <1988Aug8.180524.3167@mntgfx.mentor.com>
Date: Wed, 10 Aug 88 16:49:19 GMT

In article <1988Aug8.180524.3167@mntgfx.mentor.com> rreed@mntgfx.UUCP (Robert Reed) writes:
> >  Some of this may be sensitive to the details of my own programming style, 
> >  but I'd be skeptical of claims that automatic extraction without marking 
> >    worked well.
>
>But that is NOT to say that automatic extraction does not work well.  In the
>last project upon which I worked, we had a tool called autohdr which relied
>on a marking scheme we deeveloped for C... [It]
>generated a temporary header file which was then compared against the current
>header file.  If the files were different, the old file was replaced, and make
>would automatically recompile those targets depending on the header.
>
>The scheme still required the same amount of work for editing, and required
>more overhead for the generation and checking process.  However, the editing
>process was simplified by having a single "module" which contained both
>internal and external declarations.  Revision control is simplified by the
>commonality of unified header/code files.  

Yes, I agree, this works very nicely.  I've been using a simple form of
marking, plus an identical generate-compare-replace setup, experimentally
on a project of mine.  Having everything in the same file is a big win.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu