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

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

 

[Arnaud Debaene]

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

 

[Andre Kaufmann]

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.

- 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

 

[Carl Daniel [VC++ MVP]]

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

 

[Arnaud Debaene]

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/WG21/docs/papers/2005/n1778.pdf (I
hacven't read it thoroughly yet, but it is a proposition for the next C++
comitee meeting.)

Arnaud
MVP - VC

 

[Arnaud Debaene]

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


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.

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

 

[Carl Daniel [VC++ MVP]]

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

 

[_R]

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

 

[Andre Kaufmann]

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

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

 

[Andre Kaufmann]

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/WG21/docs/papers/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

 

[Andre Kaufmann]

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

 

[Bo Persson]

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

 

[Bo Persson]

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

 

[Andre Kaufmann]

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

 

[_R]

"_R" <[email protected]> skrev i meddelandet


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.

 

[google]

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/WG21/docs/papers/2005/n1778.pdf

Daveed

 

[Bo Persson]

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.

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

Not much, no.

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

 

[google]

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.

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


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/WG21/docs/papers/2005/n1778.pdf

Daveed

 

[Andre Kaufmann]

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.

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

 

[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.
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/WG21/docs/papers/2005/n1778.pdf

Daveed

Andre