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? 26 1916
_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
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
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
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
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
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
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#.
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
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
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
"_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
"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
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
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.
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
"_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
_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
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 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
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
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
"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
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 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
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Glenn M |
last post by:
I have visual c++ 6.0 and i want to use a function
(setupuninstalloeminf) in setupapi.h that was not part of the original
setupapi.h shipped with vsc++ but was added later.
how do i go about...
|
by: Harry Whitehouse |
last post by:
I'm porting an application from Borland C++ to VS .NET 2003. The VC++
compiler doesn't want to deal with declarations like this in my code:
LONG FAR PASCAL _export StdPVDlgProc(HWND hWnd, UINT...
|
by: junky_fellow |
last post by:
Can a function have two different prototypes ? If not , then how can
main() have
two different prototypes ?
int main(void)
and
int main argc(int argc, char *argv)
I mean to say, if I declare...
|
by: Robbie Hatley |
last post by:
I'm maintaining a software project with 134 C++ files, some of
them huge (as much as 10,000 lines each), and very few prototypes.
The author's attitude towards prototypes was like this:
...
|
by: Une bévue |
last post by:
I'm still a neby in C, i do have two versions of about the same algo.
The first one works fine but de second. I don't see what's the prob with
the second.
the purpose to cut out in sections a...
|
by: Cliff |
last post by:
Greetings,
I have been trying to teach myself C++ over the past few weeks and
have finally came across a problem I could not fix. I made a simple
program that prints out a square or rectangle...
|
by: Steph Barklay |
last post by:
Hi, I'm currently taking a data structures course in C, and my teacher
said that function prototypes are not allowed in any of our code. He
also said that no professional programmers use function...
|
by: Ravishankar S |
last post by:
Dear C Experts,
While prepating a content for a C course,I made section on function
prototypes.
Could you kindly provide me your comments on its correctness. Thank you !
Q12: What is the...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM).
In this month's session, the creator of the excellent VBE...
|
by: MeoLessi9 |
last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, youll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
by: Aftab Ahmad |
last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below.
Dim IE As Object
Set IE =...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: Vimpel783 |
last post by:
Hello!
Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
|
by: jfyes |
last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
|
by: ArrayDB |
last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
|
by: PapaRatzi |
last post by:
Hello,
I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
| |