Path: utzoo!utgpu!water!watmath!clyde!rutgers!im4u!ut-sally!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Experience with making multiple includes harmless Keywords: cpp Message-ID: <6853@brl-smoke.ARPA> Date: 16 Dec 87 21:23:33 GMT References: <3251@tut.cis.ohio-state.edu> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 22 In article <3251@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: >Two related products that reused our code have ripped out >all of this and converted their c programs to explicitly >list all the header files it needs. > >If I had to do it over again I wouldn't do this. Maybe this isn't >convincing you, but I'm convinced it's a lousy idea. I've tried it both ways, and they both have advantages and drawbacks. The main objections to having the application programmer explicitly include all the prerequisites are: 1) It's sometimes hard to get them in the right order. 2) If a header acquires a new dependency, all the applications may potentially have to be modified. 3) Documenting header interdependencies is a drag. The main extra thing one needs to do to make the header-includes-all- preresuisite-headers approach work slickly is to give each header its own name space. On a large current project we're doing just that, by assigning a unique 2-letter "package prefix" for all visible symbols that each header declares/defines. This approach has been working well so far.