Rebuild problem [modified]
-
Hi everybody Being a c++ coder for so long, i should not make this question... but ei... it dosen't hurt. I have become aware of a serius problem on one medium project. To many rebuilds I have to many files (that need to be changed often) fireing to many outher files to rebuild. Imagine the pain... I know its a design problem, and i preparing miself to a major rework. However, i was thinking if someone could redirect me to a good article on this topic before i get my hands on the problem. Where can i find the "What to do... and What not to do..." stuff? I am trying to complement my knoledge on this. Thanks -- modified at 13:58 Monday 14th August, 2006
-
Hi everybody Being a c++ coder for so long, i should not make this question... but ei... it dosen't hurt. I have become aware of a serius problem on one medium project. To many rebuilds I have to many files (that need to be changed often) fireing to many outher files to rebuild. Imagine the pain... I know its a design problem, and i preparing miself to a major rework. However, i was thinking if someone could redirect me to a good article on this topic before i get my hands on the problem. Where can i find the "What to do... and What not to do..." stuff? I am trying to complement my knoledge on this. Thanks -- modified at 13:58 Monday 14th August, 2006
So what is your question, exactly? :confused:
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
-
So what is your question, exactly? :confused:
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
Hi. The question is , where cant i get more information on this topic? The "What to do... and What not to do..." stuff :) Thanks
-
Hi. The question is , where cant i get more information on this topic? The "What to do... and What not to do..." stuff :) Thanks
Max Santos wrote:
The question is , where cant i get more information on this topic?
I don't suspect you'll find much about it from CNN.
Max Santos wrote:
The "What to do... and What not to do..." stuff
The brute-force method involves commenting out one
#includedirective at a time and rebuilding. If it builds successfully, you know that that#includedirective is not required.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
-
Max Santos wrote:
The question is , where cant i get more information on this topic?
I don't suspect you'll find much about it from CNN.
Max Santos wrote:
The "What to do... and What not to do..." stuff
The brute-force method involves commenting out one
#includedirective at a time and rebuilding. If it builds successfully, you know that that#includedirective is not required.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
DavidCrow wrote:
The brute-force method involves commenting out one #include directive at a time and rebuilding. If it builds successfully, you know that that #include directive is not required.
Yeap, but before i go shooting everyone of the 370 header files, i would like to read something good before trying to aim. :-D
-
Hi everybody Being a c++ coder for so long, i should not make this question... but ei... it dosen't hurt. I have become aware of a serius problem on one medium project. To many rebuilds I have to many files (that need to be changed often) fireing to many outher files to rebuild. Imagine the pain... I know its a design problem, and i preparing miself to a major rework. However, i was thinking if someone could redirect me to a good article on this topic before i get my hands on the problem. Where can i find the "What to do... and What not to do..." stuff? I am trying to complement my knoledge on this. Thanks -- modified at 13:58 Monday 14th August, 2006
I always like "Large Scale C++ Software Design" by John Lakos; it has a couple of good chapters that talks about compile and link time dependencies.
Maximilien Lincourt Your Head A Splode - Strong Bad
-
I always like "Large Scale C++ Software Design" by John Lakos; it has a couple of good chapters that talks about compile and link time dependencies.
Maximilien Lincourt Your Head A Splode - Strong Bad
thanks for the tip. i went to amazon.com but the book is temporarily unavailable :(
-
Hi everybody Being a c++ coder for so long, i should not make this question... but ei... it dosen't hurt. I have become aware of a serius problem on one medium project. To many rebuilds I have to many files (that need to be changed often) fireing to many outher files to rebuild. Imagine the pain... I know its a design problem, and i preparing miself to a major rework. However, i was thinking if someone could redirect me to a good article on this topic before i get my hands on the problem. Where can i find the "What to do... and What not to do..." stuff? I am trying to complement my knoledge on this. Thanks -- modified at 13:58 Monday 14th August, 2006
To be blunt, a book is a giant waste of time. Take a cut of your project and start experimenting. You will learn far more in a week of deliberate tests than in reading all the books you can find. It's a whole lot cheaper too. (I speak from experience; I have been the build engineer on many projects and have always improved them measurably.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
So what is your question, exactly? :confused:
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
The question would seem to be, "How do I minimize dependencies". It's clear enough in the post.
Steve
-
Hi everybody Being a c++ coder for so long, i should not make this question... but ei... it dosen't hurt. I have become aware of a serius problem on one medium project. To many rebuilds I have to many files (that need to be changed often) fireing to many outher files to rebuild. Imagine the pain... I know its a design problem, and i preparing miself to a major rework. However, i was thinking if someone could redirect me to a good article on this topic before i get my hands on the problem. Where can i find the "What to do... and What not to do..." stuff? I am trying to complement my knoledge on this. Thanks -- modified at 13:58 Monday 14th August, 2006
Here's a set of techniques in order of increasing risk and diminishing returns: Start in StdAfx.h, assuming you're using precompiled headers (and the precompiled header has the default configuration; if you're using a different header for PCH, edit that instead). Leave only #includes in this file which are stable (e.g. dependencies on external libraries) or which really do need to be included in absolutely every file. I often see StdAfx.h used as a dumping ground for all headers in a project, which, since all source files include StdAfx.h, causes every file to be recompiled even if a tiny change to an inconsequential header occurs. If you're not using precompiled headers, consider doing so. The amount of time taken to parse
<windows.h>is huge because it includes most of the files in the Platform SDK Include directory, which as of VS2005 is 46MB. MFC and ATL headers include windows.h. Once you've edited down StdAfx.h, you'll probably have a load of compilation errors. Just get it to compile for now, by including only those headers you actually need. For class members, in the header, forward-declare those classes which are only referenced by pointer or by reference; #include those which you must. In each header, look for uses of classes and structs defined outside that header. If a class only appears in pointer and/or reference declarations, it can be forward-declared rather than the corresponding header being #included. The source file that actually implements the functions manipulating the pointer or reference will need to #include the header declaring the class. Look out for implementation of methods in class declarations. These should be a) trivial and b) stable, and ideally not reference the implementation of other classes. Any that aren't should be stripped out and placed in a source file. Method implementations in class declarations have the additional semantics of being considered for inlining. Generally you can get away with not inlining most of this code with very little performance impact. MFC uses a trick of keeping performance-critical routines in files with a .inl extension: in debug builds, the matching _AFXxxx_INLINE macro expands to nothing and the file is #included in the corresponding .cpp file, while in release builds the macro expands toinlineand the file is #included in the corresponding header, which causes the code to be inlined if required. If an otherwise stable class has a class member which is unstable (the declaration constantly changin -
Here's a set of techniques in order of increasing risk and diminishing returns: Start in StdAfx.h, assuming you're using precompiled headers (and the precompiled header has the default configuration; if you're using a different header for PCH, edit that instead). Leave only #includes in this file which are stable (e.g. dependencies on external libraries) or which really do need to be included in absolutely every file. I often see StdAfx.h used as a dumping ground for all headers in a project, which, since all source files include StdAfx.h, causes every file to be recompiled even if a tiny change to an inconsequential header occurs. If you're not using precompiled headers, consider doing so. The amount of time taken to parse
<windows.h>is huge because it includes most of the files in the Platform SDK Include directory, which as of VS2005 is 46MB. MFC and ATL headers include windows.h. Once you've edited down StdAfx.h, you'll probably have a load of compilation errors. Just get it to compile for now, by including only those headers you actually need. For class members, in the header, forward-declare those classes which are only referenced by pointer or by reference; #include those which you must. In each header, look for uses of classes and structs defined outside that header. If a class only appears in pointer and/or reference declarations, it can be forward-declared rather than the corresponding header being #included. The source file that actually implements the functions manipulating the pointer or reference will need to #include the header declaring the class. Look out for implementation of methods in class declarations. These should be a) trivial and b) stable, and ideally not reference the implementation of other classes. Any that aren't should be stripped out and placed in a source file. Method implementations in class declarations have the additional semantics of being considered for inlining. Generally you can get away with not inlining most of this code with very little performance impact. MFC uses a trick of keeping performance-critical routines in files with a .inl extension: in debug builds, the matching _AFXxxx_INLINE macro expands to nothing and the file is #included in the corresponding .cpp file, while in release builds the macro expands toinlineand the file is #included in the corresponding header, which causes the code to be inlined if required. If an otherwise stable class has a class member which is unstable (the declaration constantly changinhi , thanks for you complete reply I did not reply before because i was allready in war with the compiler. and i only read the foruns at home The project suffers from 6 years of "allways on" changes and to many people have passed there... Is one of those projects that never ends, allways getting new features. (Realestate business by the way) After all this time, the project was suffering from to many misplaced headers. Solved the problem with forward-declares and pimpl. Complies in half of the time, but the best thing is that changing one file dosent fires rebuild in 100 outher files anymore. :-D However, i have missed stdafx.h ;P, after reding your mail, i whent back and removed 18 MS headers. (no longer needded). One outher problem is that we are not using DLL, so the linking time is to big. :( thanks for your help