home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / cplus / 16003 < prev    next >
Encoding:
Text File  |  1992-11-09  |  2.4 KB  |  50 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!rational.com!thor!rmartin
  3. From: rmartin@thor.Rational.COM (Bob Martin)
  4. Subject: Re: Multiple Header Files Problem
  5. Message-ID: <rmartin.721359424@thor>
  6. Sender: news@rational.com
  7. Organization: Rational
  8. References: <720993360snx@trmphrst.demon.co.uk>
  9. Date: Tue, 10 Nov 1992 01:37:04 GMT
  10. Lines: 38
  11.  
  12. A more interesting variation on this issue is the problem of "circular
  13. inclusion".  Consider a source file: "a.h" which includes "b.h".
  14. However, "b.h" includes "a.h".  This trivial example will fail to
  15. compile.  Unless the compiler is very clever (I haven't seen one yet),
  16. it will sit and spin until it exhauses some resouce (usually memory),
  17. and then it will die a horrible death.  If it prints an error at all,
  18. the error is nearly certain to have nothing to do with the circular
  19. containment.
  20.  
  21. Now this may not seem to be a horrible problem.  But consider that, no
  22. matter how many files are involved in the circularity, the malfunction
  23. of the compiler will be the result.  This if "a.h" includes "b.h"
  24. which includes "c.h" which includes "d.h" which includes "e.h" which
  25. includes "a.h"; then the compiler will still hang up.
  26.  
  27. C++ programs are notorious for long and frenetically branching
  28. inclusions.  If care is not taken to limit the number of #includes
  29. placed in header files, the probability of encountering a circularity
  30. increases with every new class that is created.  When a circularity
  31. does occur, finding it can take a very long time.  Just realizing that
  32. the problem is a circularity is a challenge.  Finding the sources of
  33. the circularity is non-trivial.  And fixing it is not always that easy
  34. either.
  35.  
  36. Thus, it is a good idea, if you are planning a major C++ effort, to
  37. put some thought into designing the physical dependencies of your
  38. source files.  Moreover, use forward declarations instead of #include
  39. wherever possible.  And to that end, avoid inline functions in your
  40. header files, if those inlines force you to use a #include rather than
  41. a forward declartion.  Also, use references and pointers as opposed to
  42. values in data members, member function arguments or return values; if
  43. those values force you to use #includes rather than forward declarations.
  44.  
  45. --
  46. Robert Martin                        Training courses offered in:
  47. R. C. M. Consulting                       Object Oriented Analysis
  48. 2080 Cranbrook Rd.                        Object Oriented Design
  49. Green Oaks, Il 60048 (708) 918-1004       C++
  50.