Board index » cppbuilder » Couldn't BCB's form designer automatically forward declare?

2005-05-12 06:21:06 AM
cppbuilder37
When BCB's desgner sticks #include statements for their classes in a .h file couldn't
it instead put forward declares in the .h and the real includes in the .cpp?
 

In article <42828551$ XXXX@XXXXX.COM >,
Randall Parker < XXXX@XXXXX.COM >wrote:
<qc.borland.com/wc/qcmain.aspx>
 

"Randall Parker" < XXXX@XXXXX.COM >wrote in
message news:42828551$ XXXX@XXXXX.COM ...
Gambit
 

{smallsort}

Remy Lebeau (TeamB) wrote:
stuff to compile.

"Randall Parker" < XXXX@XXXXX.COM >wrote in
message news: XXXX@XXXXX.COM ...
prevent from exactly that.
Gambit
 

Remy Lebeau (TeamB) wrote:
If so they aren´t of that much help. They prevent the header to be
compiled multiple times in the same cpp unit, but not from being parsed.
To prevent the header from being parsed you have to wrap all include
instructions including the header file with the same include guards.
E.g.:
File: Other.h
#ifndef HEADERH
#include "HEADER.h"
#endif
.....
File: header.h
#ifndef HEADERH
#define HEADERH
....
Each cpp file, which is including this header file, has to compile the
header file again, if there´s no additional include guard around the
include instruction.
So if you have a header file being 1 MB large (Ok heavily oversized ;-)
) which is included in every cpp file, the compiler has to parse and
compile 1 MB for each cpp unit.
Even worse if you include this header file multiple times AFAIK the
compiler will add this file multiple times to the cpp file.
Even if the compiler will preprocess the files and won´t add them to the
"in memory" built cpp file, it at least has to parse the header file
each time it´s included.
Which IMHO is a huge waste of performance and resources.
The only way to prevent this is:
a) Additional guards around each include instruction
b) Precompiled header file (prevents multiple compilation - not parsing)
c) Pimpl idiom, with forward declaration
d) Forward declaration
e) Unit concept should be added to the standard
 

Remy Lebeau (TeamB) wrote:
still be compiled once.
I think this would be a very worthwhile feature.
Cheers
Russell
 

"Russell Hind" < XXXX@XXXXX.COM >wrote in message news: XXXX@XXXXX.COM ...
of the header and inserting a global points in the
beginning of the cpp file would be a good thing
as well. I usually have to change both of these things
whenever using the designer.
 

On Wed, 11 May 2005 15:21:06 -0700, Randall Parker wrote:
header file containing this needs most of the classes header files as
well including other base classes. Even if it could sensibly be
separated into two parts, the effort might be better spent in smarter
handling of re-included header files so that compiler doesn't have to
re-scan the file looking for #if #else #endif tokens.
Graeme
 

Randall Parker wrote:
possible.
Furthermore, I think it would be very helpful to have an option of
declaring all components on a form private. It helps maintaining a
better encapsulation and improve code quality. Right now it's way too
tempting to refer from one form to components on another form, which
kills reusability and introduces unnecessary dependencies, which is a
maintenance hazard in the long run. Visual Studio .NET has this feature,
and by default all components dropped on forms are declared private.
This makes programmers less lazy and enforces them to rethink their
design. Of course for compatibility reasons and for RAD/prototyping you
still want to have the freedom of declaring everything public, but in a
large-scale project it doesn't work out well.
I don't think __published and private are mutually exclusive. It should
be possible for the IDE/designer to see your components on a form via
reflection, while the same declarations be private from the compiler's
point of view.
I'm only talking about components dropped on a form or frame. Published
properties of a component are expected to be public of course.
Tom
 

Andre Kaufmann wrote:
www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf
AlisdairM(TeamB)
 

Remy Lebeau (TeamB) wrote:
Every header you include introduces new names, and increases chances
for accidental (or at least undocumented) dependencies to creep in. It
is not so much the headers, as the additional headers they bring in
turn.
Worse, BCB pollutes the global namespace with a lot of these names, so
it can be hard to defend yourself against some accidental name
overloads, and this is a really subtle bug when it occurs (read, hard
and therefore expensive to track and fix.)
Note that this rampant fowarding of include files is banned in some
coding conventions (our own for instance) and the only place we can do
nothing about it is the generated header files Borland give us.
Even if we fix them manually, the includes are added back so this is
not something we can solve ourselves - it needs Borland action.
That said, I would rather see compiler bug fixes given a higher
priority, but that has been my hobby horse for some time <g>
I agree this is a great issue to have in QC.
AlisdairM(TeamB)
 

Andre Kaufmann wrote:
nothing to address the name pollution. The more names that are in
scope, the more work the compiler must do to resolve name lookup - so
this is a cost that is continually paid even after initial mechanical
parsing.
And still ignores the risk introduced of changing overload resolution
to match functions you did not even know existed...
AlisdairM(TeamB)
 

Andre Kaufmann wrote:
#endfile
or
#pragma stopparsingfile
That way it wouldn't have to scan for the #endif to see if anything is after it.
Though a really smart build system could in theory remember that a given file has
nothing after the #endif and know it doesn't have to look at it again.
 

Randall Parker wrote:
compiler will ignore that file if it has already seen it. It won't parse
it again to search for the #endif, it will simply abort this repeated
#include.
.a