New versions of VC++ still stuck with function prototypes?

[adebaene]

.... other languages which have no header files don´t need the complete
Windows sources either ;-).

One way or another, they include "under the covers" Windows.h (or a
translation of it in their own dialect, for example the external
function declarations in VB<=6).

And they do it much faster than C++, where the standard procedure is to
include windows.h in the precompiled header.

Bo's remark is still meaningfull nonetheless.

Arnaud
MVP - VC

 

[Carl Daniel [VC++ MVP]]

.... other languages which have no header files don´t need the
complete Windows sources either ;-).
And they do it much faster than C++, where the standard procedure is
to include windows.h in the precompiled header.

Not to defned header files too much (they're a blight, but necessary for
now), keep in mind that most of those other languages expose only a tiny
fraction of what's made available through <windows.h> - far less than 10% in
most cases if I had to guess (and that's exactly what it is).

That notwithstanding, it's certainly the case that a pre-parsed interface
definition file is likely to be much faster to import than a multi-megabyte
string of C/C++ declarations.

Note also that a precompiled header can be thought of as just such a
pre-parsed interface file - it just so happens that the end user needs to
create the file instead of the language system coming with one prebuilt.
Once you've built the PCH file for your app, what difference does it make,
practically speaking?

Of course, if you put inappropriate things (i.e. things that change often)
into your PCH file, you won't really enjoy the benefits.

-cd

 

[Bo Persson]

Arnaud Debaene wrote:
[...]

Concerning templates, the deficiencies of actual compilers
shouldn't be used to judge the validity of the language choices
(though,

concerning this point, I am not sure that export, even correctly
implemented, could improve compilation speed : I believe it's a very
tricky

issue that isn't understood yet, except by a few gurus like Daveed
Vandervoorde who actually have implemented export).

I'm pretty definite about that point: Export can be used to greatly
improve the compilation speed of translation units currently
containing large amounts of included template code.

AFAIK the current compilers supporting export aren´t that much faster,
but sometimes even slower. It´s one of the reasons, benefits compared
to implementation costs, that VC 2005 doesn´t support it. Herb Sutter
has pointed that already out and even the compiler vendors which have
already implemented the export keyword stated that the benefits don´t
outweigh the estimated implementation costs of nearly 2 man years.

Considering that Daveed has put in his share of those 2 man years, I
think his remarks are to be taken very seriously.

I too have thought about how much compile time you could potentially
save, if the large stream and string classes were exported and compiled
just once, instead of at each use. If Daveed says that it is so, there
is still hope!

I was once to excited about this new keyword, but it doesn´t seem to
fulfill my expectations. (Perhaps it needs some time to evolve - don´t
know ?!)

As only one compiler really supports export, it is still hard to find a
library tuned for that.


Bo Persson

 

[Andre Kaufmann]

Not to defned header files too much (they're a blight, but necessary for
now), keep in mind that most of those other languages expose only a tiny
fraction of what's made available through <windows.h> - far less than 10% in
most cases if I had to guess (and that's exactly what it is).

I´ve not yet missed anything of windows.h in other languages. Normally
you need only the import definitions for the windows dll´s. And some
libraries do that declarations of their own, e.g. boost.
But may be we should compare the windows.h header with a .NET language
like C#. All functions of the windows.h header are available through the
..NET framework, though they have not the same name or parameters.

Win32->.NET:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/win32map.asp

Additionally the framework has much more functions and classes than the
windows.h header.
But if you compare the compilation speed of a C# project to a C++
project including the windows.h header, the C# compiler is still much
faster than the C++ compiler. And even the C++ compiler is much faster
in compilation when you use only functions of the .NET framework than
functions of the Win32 API.

That notwithstanding, it's certainly the case that a pre-parsed interface
definition file is likely to be much faster to import than a multi-megabyte
string of C/C++ declarations.

Note also that a precompiled header can be thought of as just such a
pre-parsed interface file - it just so happens that the end user needs to
create the file instead of the language system coming with one prebuilt.
Once you've built the PCH file for your app, what difference does it make,
practically speaking?

I don´t know the internals of e.g. Delphi (Pascal), but AFAIK it
generates some kind of preparsed intermediate code or interface
definition embedded in it´s generated "object" files, so if you
"include" the source file in another location the compiler doesn´t have
to recompile it, since it already has done that. This is only "second
hand" information, so it might be not quite correct.
I use Delphi occasionally for GUI applications, since i mostly do
console / service applications i prefer normally C++ for that task. But
the compilation speed is impressive, though the language isn´t that
complex than C++.


If you include a large number of header files, directly or indirectly in
a cpp file the compiler has to recompile all the header files, although
it already has done that before - except if you are using precompiled
header files and include them in correct order if you are using more
than one.

But it don´t see a reason (except macros), why the C++ compiler
shouldn´t be able to automatically create a precompiled header file for
each header file it has compiled ?! If for such an automatism a
restriction of macros is needed, i´m willing to restrict myself.
I think disc spaces isn´t a problem anymore.

Of course, if you put inappropriate things (i.e. things that change often)
into your PCH file, you won't really enjoy the benefits.

If the compiler would create multiple precompiled header files
automatically even that problem would be solved ;-)

-cd

Andre

 

[Andre Kaufmann]

One way or another, they include "under the covers" Windows.h (or a
translation of it in their own dialect, for example the external
function declarations in VB<=6).

Some C++ libraries do that too, e.g. boost, so that they don´t have to
include the windows.h (and all the headers included by windows.h)

Bo's remark is still meaningfull nonetheless.

Arnaud
MVP - VC

Andre

 

[Andre Kaufmann]

Arnaud Debaene wrote:
[...]


Concerning templates, the deficiencies of actual compilers
shouldn't be used to judge the validity of the language choices

(though,


concerning this point, I am not sure that export, even correctly
implemented, could improve compilation speed : I believe it's a very

tricky


issue that isn't understood yet, except by a few gurus like Daveed
Vandervoorde who actually have implemented export).


I'm pretty definite about that point: Export can be used to greatly
improve the compilation speed of translation units currently
containing large amounts of included template code.

AFAIK the current compilers supporting export aren´t that much faster,
but sometimes even slower. It´s one of the reasons, benefits compared
to implementation costs, that VC 2005 doesn´t support it. Herb Sutter
has pointed that already out and even the compiler vendors which have
already implemented the export keyword stated that the benefits don´t
outweigh the estimated implementation costs of nearly 2 man years.

Considering that Daveed has put in his share of those 2 man years, I
think his remarks are to be taken very seriously.

I too have thought about how much compile time you could potentially
save, if the large stream and string classes were exported and compiled
just once, instead of at each use. If Daveed says that it is so, there
is still hope!

Yes. But as i pointed out in another post in this thread, i think that
would be possible even if you don´t have an export keyword and could be
done for all header files. Since the compiler has already compiled the
header file, why should it reparse and recompiled it again if it´s
included in another cpp file ? Yes - redefinition of macros would
require it to be recompiled, but i would prefer faster compilation and
would live with macros defined locally for the header file or globally
for all header files.

So i don´t see the need for export necessarily, to speed up compilation.

As only one compiler really supports export, it is still hard to find a
library tuned for that.

Hm. I count more than one ;-)

1) Comeau, frontend may be integrated in VC++
2) Intel compiler
3) CBX preview compiler

Since AFAIK they use the EDG frontend, so you far you would be correct -
they are based all on the same (single) implementation.

Bo Persson

Andre

 

[Arnaud Debaene]

Additionally the framework has much more functions and classes than
the windows.h header.
But if you compare the compilation speed of a C# project to a C++
project including the windows.h header, the C# compiler is still much
faster than the C++ compiler. And even the C++ compiler is much faster
in compilation when you use only functions of the .NET framework than
functions of the Win32 API.

There is one stupid thing about Windows.h : the fact that there is only
*one* header for declaring thousands of different APIs, when you need only a
few tens of them (typically). A more granular usage of headers would help
much here, but this is only a specific point on Windows, and do not concern
the principle of headers file, which was the original subject of the
discussion.

Arnaud
MVP - VC