By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,364 Members | 1,272 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,364 IT Pros & Developers. It's quick & easy.

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

P: n/a
_R
Given that VS2005 has made an effort to clean up the syntax of VC++
(in C++/CLI), is there any future plans to do away with function
protos, ala C#/VB? What are they needed for these days?

Nov 17 '05 #1
Share this Question
Share on Google+
26 Replies


P: n/a
_R wrote:
Given that VS2005 has made an effort to clean up the syntax of VC++
(in C++/CLI), is there any future plans to do away with function
protos, ala C#/VB? You mean remove the header files? I hope they will never do it!
What are they needed for these days?

- Clean separation of interface and implementation (not clear enough IMHO,
but still better than in C# or VB).
- Limitation of what need to be recompiled when you modify an implementation
detail : C# compilation model doesn't scale well because each time you
modify the slightest detail in an assembly, you need to recompile all
dependent code. With C++, you need only to relink dependencies. Although C#
or VB.NET compilers are faster than C++ compiler (because the syntax is much
simplier), it means that it can be difficult to build a huge project with C#
or VB.

Arnaud
MVP - VC
Nov 17 '05 #2

P: n/a
Arnaud Debaene wrote:
_R wrote:
Given that VS2005 has made an effort to clean up the syntax of VC++
(in C++/CLI), is there any future plans to do away with function
protos, ala C#/VB?
You mean remove the header files? I hope they will never do it!


I hope they will (try to) support that in a future standard, since that
could drastically improve compilation speed.
What are they needed for these days?
- Clean separation of interface and implementation (not clear enough IMHO,
but still better than in C# or VB).


For that purpose, you donīt need any header file. C++ doesnīt offer any
better separation than the other languages. If you make heavy use of
templates you effectively cannot separate the interface from the
implementation, or have to use code separation "tricks" like the pimpl
idiom.
Some languages are separating their code files into 2 halves. One
interface section and one implementation section. I donīt see any
reason, why that cannot be done in C++ and AFAIK IBM has offered a
proprietary C++ solution. I think that would offer a much better
handling and for template interfaces there wouldnīt be a need for an
export keyword.

- Limitation of what need to be recompiled when you modify an implementation
detail : C# compilation model doesn't scale well because each time you
modify the slightest detail in an assembly, you need to recompile all
dependent code. With C++, you need only to relink dependencies. Although C#
or VB.NET compilers are faster than C++ compiler (because the syntax is much
simplier), it means that it can be difficult to build a huge project with C#
or VB.

If you have a large C++ project, youīll have to use sooner or later
precompiled header files to speed up compilation. And when you touch a
single header file, the C++ compiler has to recompiled the whole
project. Not much better than in other languages.
The syntax of the C++ compiler is complex, but itīs not the only reason
why a C++ compiler needs so much more time, than a C# or VB compiler.
Besides better optimization, the main reason is the separation into
header and implementation files.
Yes - normally there should be only the interface in the header file,
but effectively you will have also implementation code (templates, stl,
windows.h) to include in the header files. And if the project grows, you
have to permanently think of code separation, so that the compilation
speed wonīt be too slow.

Donīt get me wrong, i love C++ in many aspects, but sometimes i still
prefer other languages because of compilation speed.
If my C# project with 200 units compiles faster completely than a single
C++ unit of my project with also 200 units and header files what is the
advantage of a clear separation in 2 files ?

The C++ compiler could automatically detect (ok not an easy task for a
C++ compiler) if the implementation or the interface has changed and
mark the object file if the implementation or the interface has changed.
Each other C++ file including the changed unit (header + implementation)
file could then simply check if the interface has changed or not. If not
there wouldnīt be a need to recompile the unit.
This could only work, if the usage of macros is restricted and side
effects are disallowed.
And this would perhaps allow to improve compilation speed of templates
too, perhaps this would be a better solution than the export keyword.

I donīt know if the C++ language could be changed that way and if it
would increase compilation speed that much as i would expect.
We will know it if another language offers templates, the way C++ offers
them, too ;-)

And there must be have been a reason, why (AFAIK) IBM tried to implement
something similiar in their C++ compiler .

Arnaud
MVP - VC


Andre
Nov 17 '05 #3

P: n/a
Andre Kaufmann wrote:
Arnaud Debaene wrote:
_R wrote:
Given that VS2005 has made an effort to clean up the syntax of VC++
(in C++/CLI), is there any future plans to do away with function
protos, ala C#/VB?
You mean remove the header files? I hope they will never do it!


I hope they will (try to) support that in a future standard, since
that could drastically improve compilation speed.


Of course it wouldn't. The thing that can (and does) drastically improve
compilation time is a clean separation of interface from implementation.
This separation can be accomplished through properly designed header files,
but it's really an extra-lingual hack. As you point out below, IBM's Visual
Age C++ product made an attempt at providing a cleaner module definition for
C++, but so far no such definition has gained momentum in the C++ community.
Donīt get me wrong, i love C++ in many aspects, but sometimes i still
prefer other languages because of compilation speed.
If my C# project with 200 units compiles faster completely than a
single C++ unit of my project with also 200 units and header files what is
the advantage of a clear separation in 2 files ?


It would be nice if that were so, but in my experience, it isn't. One
project I work on regularly is a C# application consisting of around 2000
classes (and files). The fact that the time to do a Build after a minor
change of a leaf class is nearly the same as the time to do a Rebuild of the
entire app deomnstrates that C# does not have an effective incremental build
system.

The same application in C++ would, I strongly suspect, handle incremental
builds after minor changes much more quickly than C# does, while a full
rebuild would likely take significantly longer due to the increased language
complexity.

I too hope that some day a good clean module concept is created for C++ and
promulgated through the standards organization. Personally, I don't hold
out much hope that it'll ever happen, but you never know. There's so much
tradition in C and C++ that's based around the idea of sequential processing
of text files to produce a compiled applicaiton that it'll be hard to break
away. I expect that we'll see a new language with the expressiveness of C++
but with a clean module concept before we see such featues in standar C++.

-cd
Nov 17 '05 #4

P: n/a
Carl Daniel [VC++ MVP] wrote:

I too hope that some day a good clean module concept is created for
C++ and promulgated through the standards organization. Personally,
I don't hold out much hope that it'll ever happen, but you never
know.


There is still some hope! See
http://www.open-std.org/JTC1/SC22/WG...2005/n1778.pdf (I
hacven't read it thoroughly yet, but it is a proposition for the next C++
comitee meeting.)

Arnaud
MVP - VC
Nov 17 '05 #5

P: n/a
Andre Kaufmann wrote:
Arnaud Debaene wrote:
_R wrote:
Given that VS2005 has made an effort to clean up the syntax of VC++
(in C++/CLI), is there any future plans to do away with function
protos, ala C#/VB?
You mean remove the header files? I hope they will never do it!


I hope they will (try to) support that in a future standard, since
that could drastically improve compilation speed.

Uhh???
- Clean separation of interface and implementation (not clear enough
IMHO, but still better than in C# or VB).


For that purpose, you donīt need any header file. C++ doesnīt offer
any better separation than the other languages. If you make heavy use
of templates you effectively cannot separate the interface from the
implementation, or have to use code separation "tricks" like the pimpl
idiom.

At least you've got the posibility to use some tricks like the pimpl idiom!
In C#, you've got nothing to separate a class interface from implementation.
I agree that the headers are not ideal in C++, but it's a first step in the
good direction. 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).

Some languages are separating their code files into 2 halves. One
interface section and one implementation section. Do you have any examples please?
I donīt see any
reason, why that cannot be done in C++ and AFAIK IBM has offered a
proprietary C++ solution. I think that would offer a much better
handling and for template interfaces there wouldnīt be a need for an
export keyword. I agree that the current compiler handling of templates is not satisfactory.

<snip> If you have a large C++ project, youīll have to use sooner or later
precompiled header files to speed up compilation. And when you touch a single header file, the C++ compiler has to recompiled the whole
project. Not much better than in other languages. First of all, precompiled headers are not available in all implementations
and they aren't defined in the C++ standard. Next, you're supposed to put in
precompiled headers fairly stable headers file that don't change often, if
they change at all.If you put in precompiled headers files that you change
often, then it's your fault if you get bad compile times.
The syntax of the C++ compiler is complex, but itīs not the only
reason why a C++ compiler needs so much more time, than a C# or VB
compiler.
Besides better optimization, the main reason is the separation into
header and implementation files.
Yes - normally there should be only the interface in the header file,
but effectively you will have also implementation code (templates,
stl, windows.h) to include in the header files. I agree concerning templates, but there is no implementation in Windows.h
(except some ugly macros)...
And if the project
grows, you have to permanently think of code separation, so that
the compilation speed wonīt be too slow. At least you *can* think of code separation. You've got no such opportunity
in C#. The C++ model is far from ideal (mainly because of non-exported
template handling, of macros and of syntax uggliness IMHO), but it offers
some room for improvements in this area, while there is nothing in C#.
Donīt get me wrong, i love C++ in many aspects, but sometimes i still
prefer other languages because of compilation speed.
If my C# project with 200 units compiles faster completely than a
single C++ unit of my project with also 200 units and header files what is
the advantage of a clear separation in 2 files ? 200 files are not a huge project by a long shot IMHO.
The C++ compiler could automatically detect (ok not an easy task for a
C++ compiler) if the implementation or the interface has changed and
mark the object file if the implementation or the interface has
changed. Each other C++ file including the changed unit (header +
implementation) file could then simply check if the interface has
changed or not. If not there wouldnīt be a need to recompile the unit.

I don't get you there. It's exactly what is happening right now (except
that, as there is still some implementation details in the headers, things
don't work so smootly all the time), but this is the basic idea of
headers...

Arnaud
MVP - VC
Nov 17 '05 #6

P: n/a
Arnaud Debaene wrote:
Andre Kaufmann wrote:
Some languages are separating their code files into 2 halves. One
interface section and one implementation section.

Do you have any examples please?


Turbo Pascal/Delphi, starting 10 years ago or so. I believe the idea is
much older than that though.

-cd
Nov 17 '05 #7

P: n/a
_R
On Sun, 27 Mar 2005 11:26:41 -0800, "Carl Daniel [VC++ MVP]"
<cp*****************************@mvps.org.nospam > wrote:
Arnaud Debaene wrote:
Andre Kaufmann wrote:
Some languages are separating their code files into 2 halves. One
interface section and one implementation section.

Do you have any examples please?


Turbo Pascal/Delphi, starting 10 years ago or so. I believe the idea is
much older than that though.


I'm personally not as concerned with purity of concept as with
practicality. When I change a function name or its parameters, I
simply block copy the function name/params and copy it into the
header. That seems an unnecessary duplication of effort, considering
that a C# or Java compiler is smart enough to look in the main source
files.

In my own experience the tedious parallel maintenance of .H files
results in needless complexity and errors. It's one of the main
reasons that I prefer coding in C#.

Nov 17 '05 #8

P: n/a
Carl Daniel [VC++ MVP] wrote:
Andre Kaufmann wrote:
Arnaud Debaene wrote:
_R wrote:

[...]

I hope they will (try to) support that in a future standard, since
that could drastically improve compilation speed.

Of course it wouldn't. The thing that can (and does) drastically improve
compilation time is a clean separation of interface from implementation.
This separation can be accomplished through properly designed header files,
but it's really an extra-lingual hack.
[...]


Yes. Currently the only things that improve compilation speed in a C++
project are separation (e.g. pimpl idiom) of code modules and
precompiled header files.
But i donīt see a reason, why the compiler shouldnīt be able to do that
automatically for me (with some restrictions) ? All whatīs needed is
more information in the object files itself. Itīs not an easy task,
because a simple macro
might change the complete header file, therefore a module concept would
be much better to handle than a separation in header and implementation
file.

Donīt get me wrong, i love C++ in many aspects, but sometimes i still
prefer other languages because of compilation speed.
If my C# project with 200 units compiles faster completely than a
single C++ unit of my project with also 200 units and header files what is
the advantage of a clear separation in 2 files ?

It would be nice if that were so, but in my experience, it isn't. One
project I work on regularly is a C# application consisting of around 2000
classes (and files). The fact that the time to do a Build after a minor
change of a leaf class is nearly the same as the time to do a Rebuild of the
entire app deomnstrates that C# does not have an effective incremental build
system.


Hm. Perhaps itīs not an easy task in C# because thereīs no include
statement and the compiler has to check the dependencies by itself. *g*
I havenīt written a large C# project yet, but iīm still impressed by the
compilation speed and i tend to use C# or any other language for the GUI
part of my applications, because i feel much more productive in C# if i
donīt have to wait each time for the compiler to compile my application,
even if i have only moved a simple button.
The same application in C++ would, I strongly suspect, handle incremental
builds after minor changes much more quickly than C# does, while a full
rebuild would likely take significantly longer due to the increased language
complexity.
Not only the language complexity. Yes most languages arenīt that complex
,but i think the C++ compiler compiles small projects very fast, at
least it would be sufficient for me.
But if the project grows and if you donīt separate the modules well or
if you canīt (e.g. templates) the compilation speed is exponentially
reduced by the count of header files included, while most other
languages scale linearly in compilation speed.
Each included header file is simply added to the .cpp file and then the
compiler starts to compile that huge code file.
But why is the same header file recompiled, when included in the next
..cpp file. Yes - macro definitions could be changed in the next .cpp
file, but with some restrictions (e.g. new import keyword added to the
standard) the compiler could assume that it wonīt be changed and that it
can use an automatically created precompiled header file.

I too hope that some day a good clean module concept is created for C++ and
promulgated through the standards organization. Personally, I don't hold
out much hope that it'll ever happen, but you never know. There's so much
tradition in C and C++ that's based around the idea of sequential processing
of text files to produce a compiled applicaiton that it'll be hard to break
away. I expect that we'll see a new language with the expressiveness of C++
but with a clean module concept before we see such featues in standar C++.

-cd


Yes i hope that too. I wouldnīt give up the traditional separation in
header and .cpp files, since that would mean introducing a complete new
language, but i think that wouldnīt be necessary.
A C++ compiler supporting a module concept could also support the
traditional separated code modules.

Andre
Nov 17 '05 #9

P: n/a
Arnaud Debaene wrote:
Carl Daniel [VC++ MVP] wrote:

I too hope that some day a good clean module concept is created for
C++ and promulgated through the standards organization. Personally,
I don't hold out much hope that it'll ever happen, but you never
know.

There is still some hope! See
http://www.open-std.org/JTC1/SC22/WG...2005/n1778.pdf (I
hacven't read it thoroughly yet, but it is a proposition for the next C++
comitee meeting.)


:-) Thanx for the link.
But i hope they wonīt be that restrictive in introducing new keywords.
( 8-( )

At least i would prefer something like

import std;

than

namespace << std;

The introduction of context sensitive new keywords, donīt affect
backwards compatibility that much.
Arnaud
MVP - VC


Andre
Nov 17 '05 #10

P: n/a
Carl Daniel [VC++ MVP] wrote:
Arnaud Debaene wrote:
Andre Kaufmann wrote:
Some languages are separating their code files into 2 halves. One
interface section and one implementation section.
Do you have any examples please?

Turbo Pascal/Delphi, starting 10 years ago or so. I believe the idea is
much older than that though.


Yes. Delphi is an example for code separation in a single file. But that
alone wouldnīt help the C++ compiler that much. Additionally macro usage
has to be restricted to the module file. So that the macros wonīt affect
other unit (header) files.
-cd


Andre
Nov 17 '05 #11

P: n/a

"_R" <_R@nomail.org> skrev i meddelandet
news:8f********************************@4ax.com...
On Sun, 27 Mar 2005 11:26:41 -0800, "Carl Daniel [VC++ MVP]"
<cp*****************************@mvps.org.nospam > wrote:
Arnaud Debaene wrote:
Andre Kaufmann wrote:
Some languages are separating their code files into 2 halves. One
interface section and one implementation section.
Do you have any examples please?
Turbo Pascal/Delphi, starting 10 years ago or so. I believe the idea
is
much older than that though.


I'm personally not as concerned with purity of concept as with
practicality. When I change a function name or its parameters, I
simply block copy the function name/params and copy it into the
header. That seems an unnecessary duplication of effort, considering
that a C# or Java compiler is smart enough to look in the main source
files.


What if there is another person working on the implementation?
What if there is yet no person working on the implementation?

In both cases C++ allows you to have a stable .h file to compile your
code against.
In my own experience the tedious parallel maintenance of .H files
results in needless complexity and errors. It's one of the main
reasons that I prefer coding in C#.


In larger projects you are supposed to design the interface up front.
After that, most of the .h files don't change.
Bo Persson
Nov 17 '05 #12

P: n/a

"Andre Kaufmann" <an****************@t-online.de> skrev i meddelandet
news:ON**************@TK2MSFTNGP15.phx.gbl...
Carl Daniel [VC++ MVP] wrote:
Andre Kaufmann wrote:
Arnaud Debaene wrote:

_R wrote:

[...]

I hope they will (try to) support that in a future standard, since
that could drastically improve compilation speed.

Of course it wouldn't. The thing that can (and does) drastically
improve compilation time is a clean separation of interface from
implementation. This separation can be accomplished through properly
designed header files, but it's really an extra-lingual hack. [...]


Yes. Currently the only things that improve compilation speed in a C++
project are separation (e.g. pimpl idiom) of code modules and
precompiled header files.
But i donīt see a reason, why the compiler shouldnīt be able to do
that automatically for me (with some restrictions) ? All whatīs needed
is more information in the object files itself. Itīs not an easy task,
because a simple macro
might change the complete header file, therefore a module concept
would be much better to handle than a separation in header and
implementation file.


Or, we could simply ban macros from header files. :-)
Seriuosly, are we treating the symptoms or the illness?
Bo Persson
Nov 17 '05 #13

P: n/a
Bo Persson wrote:
"Andre Kaufmann" <an****************@t-online.de> skrev i meddelandet
news:ON**************@TK2MSFTNGP15.phx.gbl...
Carl Daniel [VC++ MVP] wrote:
Andre Kaufmann wrote:
Arnaud Debaene wrote:
>_R wrote:
>
>

[...]

I hope they will (try to) support that in a future standard, since
that could drastically improve compilation speed.
Of course it wouldn't. The thing that can (and does) drastically
improve compilation time is a clean separation of interface from
implementation. This separation can be accomplished through properly
designed header files, but it's really an extra-lingual hack. [...]

Yes. Currently the only things that improve compilation speed in a C++
project are separation (e.g. pimpl idiom) of code modules and
precompiled header files.
But i donīt see a reason, why the compiler shouldnīt be able to do
that automatically for me (with some restrictions) ? All whatīs needed
is more information in the object files itself. Itīs not an easy task,
because a simple macro
might change the complete header file, therefore a module concept
would be much better to handle than a separation in header and
implementation file.

Or, we could simply ban macros from header files. :-)
Seriuosly, are we treating the symptoms or the illness?


Hm. If you mean that merging header and implementation file to a single
one wouldnīt help that much regarding compilation speed then i would
agree, that we only would treat the symptoms, without much success.
Though it would help to fix some other problems: E.g. if the compiler
finds multiple header files with the same name and happily chooses them
randomly in each project, depending on the include paths set - good joke
to spoof coworkers till they find out thatīs not the debugger which has
gone mad ;-)

A restriction of macros - either globally or as you suggested only to
the implementation files (cpp) would surely help the compiler to make
certain assumptions and precompile the header files automatically.
Effectively that is already done, when oneīs using precompiled header
files. And AFAIK even Stroustroup said afterwards it wasnīt a good idea
to allow macros in C++ files.
Ok - i use them too and perhaps would miss them sometimes, but i would
prefer to live without them if such restrictions would help the compiler
to compile large projects much faster.
Bo Persson


Andre
Nov 17 '05 #14

P: n/a
_R
On Mon, 28 Mar 2005 10:42:04 +0200, "Bo Persson" <bo*@gmb.dk> wrote:

"_R" <_R@nomail.org> skrev i meddelandet
news:8f********************************@4ax.com.. .
I'm personally not as concerned with purity of concept as with
practicality. When I change a function name or its parameters, I
simply block copy the function name/params and copy it into the
header. That seems an unnecessary duplication of effort, considering
that a C# or Java compiler is smart enough to look in the main source
files.


What if there is another person working on the implementation?
What if there is yet no person working on the implementation?


I have to admit that this thread is a bit of a surprise. I've never
thought of the necessity of .H files as an advantage; I've always
regarded it as more of a stop-gap for compilers that didn't have the
intelligence to parse the .CPP or .CS file and pull info from the
actual function.

I'm not denying the validity of your argument, but if someone is
working purely on interface design, that could be done outside of the
program's source code, right? Like UML diagrams or even a written but
non-compiled equivalent of a .H file could serve as a spec.
In both cases C++ allows you to have a stable .h file to compile your
code against.
I guess I can understand that, but then you probably don't like the
syntax of Java or C#.
In larger projects you are supposed to design the interface up front.
After that, most of the .h files don't change.


I wish that were true for projects I've worked on, Bo. There's often
refactoring of functions, changes to argument types, etc. that require
parallel editing of the .H file.

Maybe it's just a difference in style, but I've always thought
prototypes were a (once-necessary) pain, even before C#/Java.
Interesting to hear the converse view. Not that you have me convinced
yet. <g>

In any event, it sounds like there won't be future changes in C++
syntax given the two separate philosophical camps.
Nov 17 '05 #15

P: n/a

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.

That said, I've relatively recently proposed a module system for
C++ that would simplify the issue for templates, and additionally
extend the benefits of modularity (including build speed benefits)
to all of the C++ constructs. You can examine the proposal at:

http://www.open-std.org/JTC1/SC22/WG...2005/n1778.pdf

Daveed

Nov 17 '05 #16

P: n/a

"_R" <_R@nomail.org> skrev i meddelandet
news:f4********************************@4ax.com...
On Mon, 28 Mar 2005 10:42:04 +0200, "Bo Persson" <bo*@gmb.dk> wrote:

"_R" <_R@nomail.org> skrev i meddelandet
news:8f********************************@4ax.com. ..
I'm personally not as concerned with purity of concept as with
practicality. When I change a function name or its parameters, I
simply block copy the function name/params and copy it into the
header. That seems an unnecessary duplication of effort,
considering
that a C# or Java compiler is smart enough to look in the main
source
files.


What if there is another person working on the implementation?
What if there is yet no person working on the implementation?


I have to admit that this thread is a bit of a surprise. I've never
thought of the necessity of .H files as an advantage; I've always
regarded it as more of a stop-gap for compilers that didn't have the
intelligence to parse the .CPP or .CS file and pull info from the
actual function.

I'm not denying the validity of your argument, but if someone is
working purely on interface design, that could be done outside of the
program's source code, right? Like UML diagrams or even a written but
non-compiled equivalent of a .H file could serve as a spec.

Sure you could need that too.
In both cases C++ allows you to have a stable .h file to compile your
code against.


I guess I can understand that, but then you probably don't like the
syntax of Java or C#.


Not much, no. :-)
In larger projects you are supposed to design the interface up front.
After that, most of the .h files don't change.


I wish that were true for projects I've worked on, Bo. There's often
refactoring of functions, changes to argument types, etc. that require
parallel editing of the .H file.

Maybe it's just a difference in style, but I've always thought
prototypes were a (once-necessary) pain, even before C#/Java.
Interesting to hear the converse view. Not that you have me convinced
yet. <g>


Ok, so you have never thought about the advantage of distributing and
compiling against windows.h rather than the complete Windows source?
Bo Persson
Nov 17 '05 #17

P: n/a

_R wrote:
On Mon, 28 Mar 2005 10:42:04 +0200, "Bo Persson" <bo*@gmb.dk> wrote:

"_R" <_R@nomail.org> skrev i meddelandet
news:8f********************************@4ax.com.. .
I'm personally not as concerned with purity of concept as with
practicality. When I change a function name or its parameters, I
simply block copy the function name/params and copy it into the
header. That seems an unnecessary duplication of effort, considering that a C# or Java compiler is smart enough to look in the main source files.


What if there is another person working on the implementation?
What if there is yet no person working on the implementation?


I have to admit that this thread is a bit of a surprise. I've never
thought of the necessity of .H files as an advantage; I've always
regarded it as more of a stop-gap for compilers that didn't have the
intelligence to parse the .CPP or .CS file and pull info from the
actual function.


That cannot be the case: Once you're able to parse a declaration,
it's trivial to drop the "definition" part of that declaration and
hence
obtain a declaration suitable for a header file. In fact, there are
quite a few shops out there that operate that way: They don't
generally manually write header files, but generate them from the
implementation files.

I'm not denying the validity of your argument, but if someone is
working purely on interface design, that could be done outside of the
program's source code, right? Like UML diagrams or even a written but non-compiled equivalent of a .H file could serve as a spec.
That's not enough: You need something you can compile against.
Without it, you cannot easily do parallel development.
In both cases C++ allows you to have a stable .h file to compile yourcode against.


I guess I can understand that, but then you probably don't like the
syntax of Java or C#.
In larger projects you are supposed to design the interface up front.After that, most of the .h files don't change.


I wish that were true for projects I've worked on, Bo. There's often
refactoring of functions, changes to argument types, etc. that

require parallel editing of the .H file.
Yes, but the version-stamped interface file (.h file in C/C++)
should always be compilable.

The issue here is not mainly whether a human-written .h file (or
similar device) is possible, but whether it is easy enough to write
a compiler-readable interface file. The advantages of having that
use a source-based form (as with C/C++ headers, and no doubt
the reason for things being like that in those languages):
- it's human-readable (including comments and the like)
- it's human-writable
- it's quite portable
- it's easily extensible
The disadvantages include:
- it's cumbersome
- it's slow to parse
The disadvantages weren't that big of an issue in the days that
100 KLOC was consider a "large project", but with project now
routinely reaching 10 or 100 MLOC and with the ratio of .hpp
size to .cpp size increasing, the approach seem suboptimal.

What I find surprising about some newer compiled languages
isn't that they have dropped the notion of a header file, but that
they have dropped the notion of a separate interface file (of
which a header file is but a special case). In Java, for example,
the .class file contains both the interface and the implementation.
If you modify the implementation, chances are that you have to
rebuild the whole world. And as mentioned, there is no mechanism
to only produce an interface file: A compilable implementation
("definition" in C/C++ lingo) is always required.
Maybe it's just a difference in style, but I've always thought
prototypes were a (once-necessary) pain, even before C#/Java.
Interesting to hear the converse view. Not that you have me convinced yet. <g>

In any event, it sounds like there won't be future changes in C++
syntax given the two separate philosophical camps.


See my other post in this thread and

http://www.open-std.org/JTC1/SC22/WG...2005/n1778.pdf

Daveed

Nov 17 '05 #18

P: n/a
Bo Persson wrote:
"_R" <_R@nomail.org> skrev i meddelandet
news:f4********************************@4ax.com...
On Mon, 28 Mar 2005 10:42:04 +0200, "Bo Persson" <bo*@gmb.dk> wrote:

"_R" <_R@nomail.org> skrev i meddelandet
news:8f********************************@4ax.com ...
I'm personally not as concerned with purity of concept as with
practicality. When I change a function name or its parameters, I
simply block copy the function name/params and copy it into the
header. That seems an unnecessary duplication of effort,
considering
that a C# or Java compiler is smart enough to look in the main
source
files.

What if there is another person working on the implementation?
What if there is yet no person working on the implementation?


I have to admit that this thread is a bit of a surprise. I've never
thought of the necessity of .H files as an advantage; I've always
regarded it as more of a stop-gap for compilers that didn't have the
intelligence to parse the .CPP or .CS file and pull info from the
actual function.

I'm not denying the validity of your argument, but if someone is
working purely on interface design, that could be done outside of the
program's source code, right? Like UML diagrams or even a written but
non-compiled equivalent of a .H file could serve as a spec.


Sure you could need that too.

In both cases C++ allows you to have a stable .h file to compile your
code against.


I guess I can understand that, but then you probably don't like the
syntax of Java or C#.

Not much, no. :-)
[...]
Ok, so you have never thought about the advantage of distributing and
compiling against windows.h rather than the complete Windows source?


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

Bo Persson


Andre
Nov 17 '05 #19

P: n/a
go****@vandevoorde.com wrote:
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.
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 ?!)

I think they should think it all over, since IMHO a modular system and
breaking the strict isolation between compiler and linker would speed up
the compilation for templated and non templated code.
That said, I've relatively recently proposed a module system for
C++ that would simplify the issue for templates, and additionally
extend the benefits of modularity (including build speed benefits)
to all of the C++ constructs. You can examine the proposal at:

http://www.open-std.org/JTC1/SC22/WG...2005/n1778.pdf

Daveed


Andre
Nov 17 '05 #20

P: n/a

Andre Kaufmann wrote:
Bo Persson wrote:


Ok, so you have never thought about the advantage of distributing and compiling against windows.h rather than the complete Windows source?
.... 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

Nov 17 '05 #21

P: n/a
Andre Kaufmann wrote:
.... 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
Nov 17 '05 #22

P: n/a

"Andre Kaufmann" <an****************@t-online.de> skrev i meddelandet
news:ud***************@TK2MSFTNGP09.phx.gbl...
go****@vandevoorde.com wrote:
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
Nov 17 '05 #23

P: n/a
Carl Daniel [VC++ MVP] wrote:
Andre Kaufmann wrote:
.... 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).


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/de...l/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
Nov 17 '05 #24

P: n/a
ad******@club-internet.fr wrote:
Andre Kaufmann wrote:
Bo Persson wrote:

Ok, so you have never thought about the advantage of distributing
and
compiling against windows.h rather than the complete Windows

source?
.... 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).


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


Andre
Nov 17 '05 #25

P: n/a
Bo Persson wrote:
"Andre Kaufmann" <an****************@t-online.de> skrev i meddelandet
news:ud***************@TK2MSFTNGP09.phx.gbl...
go****@vandevoorde.com wrote:
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.
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.


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
Nov 17 '05 #26

P: n/a
Andre Kaufmann wrote:

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
Nov 17 '05 #27

This discussion thread is closed

Replies have been disabled for this discussion.