[boost] Re: Forward Declaring Headers

From: Valentin Bonnard (Bonnard.V_at_[hidden])
Date: 2000-03-17 11:00:35

Lois Goldthwaite wrote:

> For classes in the standard library, wouldn't this have to be provided by the
> library implementors? Because they are allowed to add additional defaulted
> parameters to standard functions, or to provide additional functions with fewer
> parameters in lieu of defaulted arguments, a user could never be certain what
> the proper forward declarations would be.  Or did you mean only that boost
> headers should have a companion <*fwd> counterpart?

I understand that Kelvin proposed to try that as a Boost Current
Practice; 
if it is later recognized as Best Current Practice, the standard
committee 
could adopt it too.

The standard doesn't allow the programmer to add names in the std
namespace 
(except specializations), so it would not be legal for him to forward
declare 
any class even...
- ...if the implementor was not allowed to add defaulted template
arguments
- ...for non template classes

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).

The short-term solutions are:
- buy a faster computer for the compilations
- use the xxxfwd method
- investigate how compilers handle precompiled headers

Note that the fwf method is limited: to use the incomplete 
class foo<T>::bar foo must be completed (defined).

CodeWarrior has a primitive form of precompiled headers: 
you precompile a file with lots of declarations (typically, 
the whole MacOS includes), you get a binary file containing 
a dump of the environement at the end of the file.
Then you can begin a compilation with this environement instead 
of the empty one, but you cannot merge two environements.

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)

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.

-- 
Valentin Bonnard