Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!aurs01!throop From: throop@aurs01.UUCP (Wayne Throop) Newsgroups: comp.lang.c++ Subject: Re: A GNU Makefile (was: ... header files **and** inline management) Message-ID: <59598@aurs01.UUCP> Date: 21 Feb 91 20:17:20 GMT References: <1991Feb5.180503.24515@mathcs.sjsu.edu> <3787@lupine.NCD.COM> <1991Feb20.083327.2028@eua.ericsson.se> <664@necssd.NEC.COM> Sender: news@aurs01.UUCP Lines: 33 > harrison@necssd.NEC.COM (Mark Harrison) >>,>>>> euamts@eua.ericsson.se (Mats Henricson) writes: >>>> ... but I think [..automatic .h generation..] is a bad idea. [...] >>>> That is why I design the header file first, and then the .cc-file. >> [...] you don't have to change it *that* often > I agree with Mats on this. [...] I have more confidence in someone > who emphasizes generating a code stub from an interface defintion than > in someone who wants to write the code first and then generate the > interface. Just because one edits a .cc file first is not an indication that one is "writing the code first". As I said before (in a different branch of this discussion), I write the .cc file as a file full of stubs (using templates to save typing, of course), and automatically generate the .h files from the .cc files. The advantages this gives me are: 1) it becomes easier to enhance interfaces (on those rare ocasions where it is needed). (Just because something is rare is no reason to make it a headache.) 2) I have one-stop-shopping for editing things, as the interface and (eventually) implementation are presented together, and teased apart by automated tools. Now, note that both of these benefits are somewhat weak. The first has small leverage because of its (intended) rarity. The second problem can be held at bay by a multiple-window editing tool (emacs, X-windows plus editor, whatever). But however marginal the benefits, I still think the benefits are actual, not illusory, and are worthwhile. Wayne Throop ...!mcnc!aurgate!throop