Tor Didriksen wrote:
> On Mon, 29 Jun 2009 12:55:45 +0200, Kristian Nielsen
> <knielsen@stripped> wrote:
>> Mats Kindahl <mats@stripped> writes:
>>> Just to clarify, when we mention forward declarations here, we are
>>> talking about
>>> forward declarations of *classes* only, not variables, so the "extern
>>> int foo"
>>> is not an example of a forward declaration we are considering. For
>>> functions and
>>> variables, it is a requirement to use an include file.
>> Mats, could you describe what the benefits are of using forward
>> of structs/classes in place of #including the definition?
>> Clearly, self-references in structs (whether direct or recursive) require
>> forward declarations, but otherwise?
>> It seems to me to be a simpler if code referencing struct/class FOO would
>> always do so by including file_defining_FOO.h? What am I missing? I don't
>> remember seeing this style much in C/C++ code...
> Please see
> for an explanation.
> If a class 'Bar' is implemented in terms of another class 'Foo', or uses
> it's interface in some way,
> it will typically store a pointer to it (in its private section).
> By forward declaring the class
> class Foo;
> rather than
> #include "foo.h"
> you can often drastically cut down on the number of header files included.
> The savings in compile time can be quite substantial.
> I remember doing this on a project sometime in the 90's cutting down
> compile/build time from a day (yes 24 hours) to about one hour.
In addition to reducing the compile time (which I personally don't think should
be a goal for a coding style), there is also a risk of introducing a circular
include if including definitions that are not used in *header files* in a
sequence of steps that in themselves do not introduce a circular include (e.g.,
by different developers).
It also avoids exposing internals unless necessary , which is a good habit in
Source code files cannot introduce circular dependencies, since they are
"terminal" (nobody includes a source file, right? ;) ), so by using a forward
declaration in the header file and include the definition (if needed) in the
source file, we minimize the risk of introducing circular include dependencies.
Just my few cents,
> -- didrik
>> (More generally, I think your proposal would benefit from explaining more
>> concretely what problems you are trying to solve. Clearly there are
>> some real
>> issues that are being addressed, like the possibility to use parts of the
>> server code in unit tests that has been hinted at. It seems to me that
>> proposal mixes some changes needed to solve concrete problems with other
>> changes that are more a matter of style and preferences).
>> - Kristian.
Senior Software Engineer
Database Technology Group