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