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

Re: Couldn't BCB's form designer automatically forward declare?


2005-05-13 04:43:29 AM
cppbuilder28
"Randall Parker" < XXXX@XXXXX.COM >wrote in
message news: XXXX@XXXXX.COM ...
Quote
Andre Kaufmann wrote:
>
>Do you mean include guards ?
>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.

Instead of #ifdef and #endif we need something like:
I think you mean #ifndef. If the symbol is defined, the #ifndef should
prevent reading
any further. If not, something's broken.
MS has #pragma once which does what you want but it's not portable.
For a test, I replaced my normal header guards with this pragma and
it was about the same.
 
 

Re:Re: Couldn't BCB's form designer automatically forward declare?

Alex Bakaev [TeamB] wrote:
Quote
Randall Parker wrote:

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

I would like this solution, but IHMO thereīs no need for multiple
inclusion at all, at least in C++. Why are we forced to add inclusion
guards to every C++ header file !??!
For the very rare cases we wanīt to have a different behavior there
could be a fallback like
extern "C"
{
#include "Multiple.h"
}
Otherwise the C++ compiler could simply include the header file only once.
Quote

If a first line of a header file is the #ifdef guard, then Borland C++
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.

The only curious thing about that is that BCB prompts to compile these
lines (in the statistics), though i donīt think it really "compiles" the
header files multiple times.
But at least BCB has to parse the complete file multiple times. I donīt
know this really, but the significant increase of compilation time makes
me think so.
Andre
 

Re:Re: Couldn't BCB's form designer automatically forward declare?

Alisdair Meredith [TeamB] wrote:
Quote
Andre Kaufmann wrote:


>e) Unit concept should be added to the standard


You mean something like this? <g>

www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf

AlisdairM(TeamB)
Yes, thank you. I already knew of it, but had no closer look at this
proposal, since i have the odd feeling that it would be time to get rid
of some design quirks which C++ has inherited from C. Something like
(C++)++ language and extern "C++" { #include "C++ file"; }
Sorry - just kidding and feeling lucky that i have much more spare time
to drink coffee during compilation than a Delphi programmer *g*.
Andre
 

{smallsort}

Re:Re: Couldn't BCB's form designer automatically forward declare?

Duane Hebert wrote:
Quote

Making it stop declaring the class extern at the end
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.

Definitely. We always delete these as the first thing when we create a
new form
Cheers
Russell
 

Re:Re: Couldn't BCB's form designer automatically forward declare?

In article < XXXX@XXXXX.COM >,
Alisdair Meredith [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
Andre Kaufmann wrote:
>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)

Note that these 2 solutions may reduce the parsing overhead, but do
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.
Indeed, which is why benchmarking should always be approached
cautiously.
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==>www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
 

Re:Re: Couldn't BCB's form designer automatically forward declare?

In article < XXXX@XXXXX.COM >,
Randall Parker < XXXX@XXXXX.COM >wrote:
Quote
Andre Kaufmann wrote:
>Do you mean include guards ?
>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.

Instead of #ifdef and #endif we need something like:

#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.
Many compiler have such extensions. For instance,
in Comeau's PCH processing you can tell it #pragma hdrstop
so it knows what should be in the PCH or not. Or in the
case of the above, we understand the #pragma once directive.
(Note: these pragma are not required by Standard C or Standard C++.)
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==>www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
 

Re:Re: Couldn't BCB's form designer automatically forward declare?

In article <4283bb90$ XXXX@XXXXX.COM >,
Alex Bakaev [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
Randall Parker wrote:
>#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.

If a first line of a header file is the #ifdef guard, then Borland C++
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.
Comeau can also do that.
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==>www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
 

Re:Re: Couldn't BCB's form designer automatically forward declare?

In article < XXXX@XXXXX.COM >,
Duane Hebert < XXXX@XXXXX.COM >wrote:
Quote
"Randall Parker" < XXXX@XXXXX.COM >wrote in
message news: XXXX@XXXXX.COM ...
>Andre Kaufmann wrote:
>>
>>Do you mean include guards ?
>>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.
>
>Instead of #ifdef and #endif we need something like:

I think you mean #ifndef. If the symbol is defined, the #ifndef should
prevent reading
any further. If not, something's broken.
But he means to not even consider rereading it.
Quote
MS has #pragma once which does what you want but it's not portable.
For a test, I replaced my normal header guards with this pragma and
it was about the same.
Comeau supports that too, but right, it's an extension, as all
pragmas really are.
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==>www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
 

Re:Re: Couldn't BCB's form designer automatically forward declare?

In article < XXXX@XXXXX.COM >,
Andre Kaufmann < XXXX@XXXXX.COM >wrote:
Quote
Alex Bakaev [TeamB] wrote:
>Randall Parker wrote:
>>#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.

I would like this solution, but IHMO thereīs no need for multiple
inclusion at all, at least in C++. Why are we forced to add inclusion
guards to every C++ header file !??!
You're not. Anyway, IMO, that's not the question, IMO the question
is why #include at all.
Quote
For the very rare cases we wanīt to have a different behavior there
could be a fallback like

extern "C"
{
#include "Multiple.h"
}

Otherwise the C++ compiler could simply include the header file only once.
Not sure I understand. What would the extern "C" accomplish?
Quote
>
>If a first line of a header file is the #ifdef guard, then Borland C++
>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.
>

The only curious thing about that is that BCB prompts to compile these
lines (in the statistics), though i donīt think it really "compiles" the
header files multiple times.
But at least BCB has to parse the complete file multiple times. I donīt
know this really, but the significant increase of compilation time makes
me think so.
If I understand, the #include is wrapped in say a #ifndef
guard, so there is no need to parse the complete file multiple times.
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==>www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
 

Re:Re: Couldn't BCB's form designer automatically forward declare?

"Greg Comeau" < XXXX@XXXXX.COM >wrote in message news:d67ooo$6um$ XXXX@XXXXX.COM ...
Quote
In article < XXXX@XXXXX.COM >,

>I think you mean #ifndef. If the symbol is defined, the #ifndef should
>prevent reading
>any further. If not, something's broken.

But he means to not even consider rereading it.
That would be a nice feature. What makes it so
hard to implement? How does PCH deal with this?
Does it also have to open each instance of the included
pch.h to find that it has already been parsed?
 

Re:Re: Couldn't BCB's form designer automatically forward declare?

In article < XXXX@XXXXX.COM >,
Duane Hebert < XXXX@XXXXX.COM >wrote:
Quote

"Greg Comeau" < XXXX@XXXXX.COM >wrote in message news:d67ooo$6um$ XXXX@XXXXX.COM ...
>In article < XXXX@XXXXX.COM >,
>
>>I think you mean #ifndef. If the symbol is defined, the #ifndef should
>>prevent reading
>>any further. If not, something's broken.
>
>But he means to not even consider rereading it.

That would be a nice feature. What makes it so
hard to implement?
It's not. If I recall, EDG did it in some 20 lines of code.
Of course, it requires other things to exist, but I can't
imagine them not existing on all C and C++ compilers.
Quote
How does PCH deal with this?
Does it also have to open each instance of the included
pch.h to find that it has already been parsed?
If I understand what you're asking, it's neutral.
--
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==>www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
 

Re:Re: Couldn't BCB's form designer automatically forward declare?

Greg Comeau wrote:
Quote
In article < XXXX@XXXXX.COM >,
Andre Kaufmann < XXXX@XXXXX.COM >wrote:

>Alex Bakaev [TeamB] wrote:
>
>>Randall Parker wrote:
>>
>[...]
>I would like this solution, but IHMO thereīs no need for multiple
>inclusion at all, at least in C++. Why are we forced to add inclusion
>guards to every C++ header file !??!


You're not. Anyway, IMO, that's not the question, IMO the question
is why #include at all.

Would be the best solution, at least for a unit concept in C++. C# also
doesnīt need, better said, doesnīt have an include instruction.
Though the only downside is, that it eventually would be (very) hard for
the compiler to track what files are affected by changes and this would
perhaps lead to a "compile everything behavior".
Quote

>For the very rare cases we wanīt to have a different behavior there
>could be a fallback like
>
>extern "C"
>{
>#include "Multiple.h"
>}
>
>Otherwise the C++ compiler could simply include the header file only once.


Not sure I understand. What would the extern "C" accomplish?

Sorry, bad and wrong example. I was only suggesting a fallback, how to
include a file the "old way", as itīs currently done by every C++
compiler. To be correct it should read 'extern "C++"' ;-)
Perhaps a new keyword would be (IMHO) better:
#force_include "Multiple.h"
I proposed only the extern "C" solution, because the C++ standard
comittee normally doesnīt like to introduce new keywords.
Quote
[...]
>The only curious thing about that is that BCB prompts to compile these
>lines (in the statistics), though i donīt think it really "compiles" the
>header files multiple times.
>But at least BCB has to parse the complete file multiple times. I donīt
>know this really, but the significant increase of compilation time makes
>me think so.


If I understand, the #include is wrapped in say a #ifndef
guard, so there is no need to parse the complete file multiple times.
Normally not, if they assume that itīs the way headerīs are protected
from multiple inclusion and i think they could do so. A {*word*193}
"programmer" could redefine the include guard, so the compiler must keep
track of the macros.
But whom do i tell that ;-), since you are the expert in compiler
technology. Please correct me if my statements are wrong.
Many compilers seem at least to load the header file each time itīs
included.
I donīt know if they are parsed again, but i think so, since most C++
compilers are loading the header files for the second time. And why
should they do so, since they already know that the file is included for
the second time ? Or is it to hard to keep tracking all the guard macros ?
I didnīt check Comeau, but as you wrote in another post, it doesnīt at
least parse the file again.
Perhaps iīve only misinterpreted the behavior and most C++ compiler
donīt parse it again, but the increasing compilation times tell me that
at least they must do something with the file. Searching for the end of
the macro block perhaps ?
Andre
 

Re:Re: Couldn't BCB's form designer automatically forward declare?

Randall Parker wrote:
Quote
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?
What about enums? They can't be forward declared, right? You also have
to consider sets and closures. Can these be forward declared? They are
occasionally needed in a form's header file.
I suppose you could fallback on the notion that vcl.h will always be
included before a form's header file in any given CPP file, and vcl.h
can supply the enum, closure, and set prototypes. However, I have never
liked the approach where header file A must be included before header
file B or else B will generate errors. Besides, if vcl.h is going to
supply the enums, it might was well supply declarations for TForm and
TButton, in which case you don't need the forward declares either.
H^2
 

Re:Re: Couldn't BCB's form designer automatically forward declare?

Quote
Furthermore, I think it would be very helpful to have an option of
declaring all components on a form private.
Unfortunately, __published doesn't just imply scope. If it did, they
could have just used public scope.
Variables that are in __published scope generate extra RTTI information
that is used to initialize the published members from a base class
member when the object is streamed from a DFM resource. What we need is
a scope that generates this RTTI info, but behaves like private scope
during compilation.
There are tricks that can be done. Such as:
groups-beta.google.com/group/borland.public.cppbuilder.language/msg/1ef0b61fc429db78
H^2
 

Re:Re: Couldn't BCB's form designer automatically forward declare?

Harold Howe [TeamB] wrote:
Quote
Randall Parker wrote:

>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?

What about enums? They can't be forward declared, right? You also have
to consider sets and closures. Can these be forward declared? They are
occasionally needed in a form's header file.
But in most forms they are not needed.
Quote
I suppose you could fallback on the notion that vcl.h will always be
included before a form's header file in any given CPP file,
Well, that would be good anyway because that way the vcl.h can be the first thing in
the precompiled header.
Quote
and vcl.h
can supply the enum, closure, and set prototypes. However, I have never
liked the approach where header file A must be included before header
file B or else B will generate errors.
Yes, I do not like that either. But otherwise the header file A has to be included
before prototypes in header file B.
Quote
Besides, if vcl.h is going to
supply the enums, it might was well supply declarations for TForm and
TButton, in which case you don't need the forward declares either.
Which defeats the purpose of trying to make compiles faster.
I'm sufficiently disgusted with having BCB report that a Build of my project
processes 12 million lines that I'm willing to do things that are esthetically
offensive to some.