[boost] Re: Forward Declaring Headers

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-03-18 03:24:17

In message <38D256A2.5A2C_at_[hidden]>, Valentin Bonnard
<Bonnard.V_at_[hidden]> writes
[...]
>My personnal feeling is that it (forward declaration) is bugware, 
>the bug being the fact that C++ uses cpp, the long-term fix would be 
>to have context-independant headers (which could thus be precompiled).

However, many dependency management practices (Cheshire Cat, interface
classes, etc) are all based on this not-so-small assumption -- I am not
about to stop all my C++98 development and wait for the future.

>I feel that having to write all these xxxfwd headers is bugware, 
>and I personnaly hate bugware.
>
>bugware: when something is broken, instead of reparring it, 
>  bugware consists of breaking something else to make the two 
>  work together (David Madore)

I disagree (and not just because that's not the definition of bugware
most people work to): if one believes that the preprocessor is bugware
then all kinds of consequences flow from that. However, the preprocessor
is not broken, it just has limitations -- a subtle but important
distinction.

When you design, you design into a context, and in C++ that context
includes (like it or not) the preprocessor. Working in a context means
that you take that context into account and work with practices
appropriate to that context, eg dependency management to reduce physical
coupling in large systems (see Lakos, Sutter, etc).

>More generally, it is the method of finding work-arrounds 
>instead of correcting a problem. It can place a great burden 
>on the person who is designing the work-arround, and on all 
>the ones who are trying to understand it; and none on the 
>faulty one.

As the problem you are trying to correct is the existence of the
preprocessor and the use of header files, I would suggest that is a
little outside Boost's remit -- although it's nice to dream! I am simply
proposing the adoption of a good practice based on working with C++98.
____________________________________________________________

  Kevlin Henney                       Curbralan Ltd
  kevlin_at_[hidden]                [phone]
____________________________________________________________