 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / March 2005New versions of VC++ still stuck with function prototypes?
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? > 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 >>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 [quoted text clipped - 3 lines] > 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 >>> 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 [quoted text clipped - 4 lines] > 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 > 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 >>I too hope that some day a good clean module concept is created for >>C++ and promulgated through the standards organization. Personally, [quoted text clipped - 5 lines] > 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 >[...] >> [quoted text clipped - 6 lines] > 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. [quoted text clipped - 8 lines] > 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 [quoted text clipped - 5 lines] > > -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 >>[...] >>> [quoted text clipped - 16 lines] > 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 >>>[...] >>> [quoted text clipped - 20 lines] > > 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 >>> 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 [quoted text clipped - 4 lines] > 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). [quoted text clipped - 4 lines] > 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 [quoted text clipped - 4 lines] > 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 >> 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 >>> 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#. >>>> Some languages are separating their code files into 2 halves. One >>>> interface section and one implementation section. [quoted text clipped - 10 lines] > 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 >> I'm personally not as concerned with purity of concept as with >> practicality. When I change a function name or its parameters, I [quoted text clipped - 5 lines] >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. >>> I'm personally not as concerned with purity of concept as with >>> practicality. When I change a function name or its parameters, I [quoted text clipped - 18 lines] > 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. [quoted text clipped - 7 lines] > 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 >>>>I'm personally not as concerned with purity of concept as with >>>>practicality. When I change a function name or its parameters, I [quoted text clipped - 33 lines] > 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 > > 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 >>>Ok, so you have never thought about the advantage of distributing > [quoted text clipped - 13 lines] > 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 > [quoted text clipped - 6 lines] > Arnaud > MVP - VC Andre > .... 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 >>.... other languages which have no header files don´t need the >>complete Windows sources either ;-). [quoted text clipped - 5 lines] > fraction of what's made available through <windows.h> - far less than 10% in > most cases if I had to guess (and that's exactly what it is). I´ve not yet missed anything of windows.h in other languages. Normally you need only the import definitions for the windows dll´s. And some libraries do that declarations of their own, e.g. boost. But may be we should compare the windows.h header with a .NET language like C#. All functions of the windows.h header are available through the .NET framework, though they have not the same name or parameters. Win32->.NET: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/w in32map.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 [quoted text clipped - 5 lines] > 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 > Additionally the framework has much more functions and classes than > the windows.h header. [quoted text clipped - 3 lines] > 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 > >> I'm personally not as concerned with purity of concept as with > >> practicality. When I change a function name or its parameters, I [quoted text clipped - 11 lines] > 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 your > >code against. [quoted text clipped - 8 lines] > 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. [quoted text clipped - 3 lines] > 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 >>>Some languages are separating their code files into 2 halves. One >>>interface section and one implementation section. [quoted text clipped - 3 lines] > 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 [...] > 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 > [...] > [quoted text clipped - 14 lines] > 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 [quoted text clipped - 4 lines] > > Daveed Andre >> [...] >> [quoted text clipped - 21 lines] > 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 >>>[...] >>> [quoted text clipped - 29 lines] > 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
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.