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
if it is later recognized as Best Current Practice, the standard
could adopt it too.
The standard doesn't allow the programmer to add names in the std
(except specializations), so it would not be legal for him to forward
any class even...
- ...if the implementor was not allowed to add defaulted template
- ...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
-- Valentin Bonnard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk