Precompiled header question

My code uses large set of libraries that I don't want to be compiled everytime I compile my program, so I want to use a precompiled header to include the libraries. I currently use visual studio 2008 as my IDE. The following is what I have tried so far.

stdafx.h (precompiled header)

Code:

---

#include <library1.h>
#include <library2.h>
.
.
.
#include <libraryN.h>

---

MyProg.h

Code:

---

#include "stdafx.h"

class MyProg
{
...
}

---

MyProg.cpp

Code:

---

#include "stdafx.h"
#include "MyProg.h"

MyProg::MyProg()
{
...
}
.
.
.

---

client.cpp

Code:

---

#include "stdafx.h""
#include "MyProg.h"

int main()
{
  MyProg myProg;
  ...
}

---

The above code compiles fine, but then as soon as I remove #include "stdafx.h" from MyProg.cpp, I get the following compile error.

1>MyProg.cpp : warning C4627: '#include "MyProg.h"': skipped when looking for precompiled header use
1> Add directive to 'stdafx.h' or rebuild precompiled header
1>MyProg.cpp : fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include "stdafx.h"' to your source?

I want to remove #include "stdafx.h" from the cpp file because I am including MyProg.h already which includes stdafx.h, and I thought that including it again in the cpp file would be redundant. Also, the similar errors occur when I remove the same line from the client.cpp. I tried compiling stdafx.h and then compiling MyProg.cpp, but the error still occured. What is happening? Is there a fault in my logic? Thanks in advance.

If you set your project to have a precompiled header, the internal build thingy will demand that it is setup with stdafx.h,cpp. There might be a quick settings fix, but whenever I encounter this problem I just create a new project without the precompiled header.

Precompiled headers are more of a pain than they are worth. I would highly recommend you select Do no use precompiled headers in your project options.

I haven't worked with precompiled headers but:

If you have a precompiled header it must be the first thing in the file. Otherwise whatever is above the precompiled header may change the meaning of the header content. I imagine that although including a header in the first line that includes the precompiled header in the header's first line has no chance of causing a problem, the compiler is not smart enough to check for this condition. Ergo the precompiled header must go in the source file.

Quote:

---

Originally Posted by King Mir

the compiler is not smart enough to check for this condition. Ergo the precompiled header must go in the source file.

---

Thank you guys for the help. Yes, it seems that that might be the case. It's weird though, since if it were a regular header file instead of the precompiled header, not including the header (because it's already included in other header file that is included in the source file) in the source file would have been fine.

Quote:

---

Originally Posted by Bubba

Precompiled headers are more of a pain than they are worth. I would highly recommend you select Do no use precompiled headers in your project options.

---

Well, that's fine. Myself, I think they are not a pain and a great feature and highly recommend them.
And as for the question, if you use precompiled headers, the PCH must be included as the first line in every source file. Or it won't compile. No way around that.

Quote:

---

Originally Posted by Bubba

Precompiled headers are more of a pain than they are worth. I would highly recommend you select Do no use precompiled headers in your project options.

---

I would like to specify that you should not use precompiled headers in a production version of your software. Overall, however, if you are using CVS or something similar precompiled headers muck up the process when another user is changing something that makes your header need to be recompiled, or worse yet, sometimes it doesn't recompile when it should have and problems present themselves from that point.

Quote:

---

Originally Posted by sphynxter

I would like to specify that you should not use precompiled headers in a production version of your software. Overall, however, if you are using CVS or something similar precompiled headers muck up the process when another user is changing something that makes your header need to be recompiled, or worse yet, sometimes it doesn't recompile when it should have and problems present themselves from that point.

---

That points to a need to write your own makefiles.

Quote:

---

Originally Posted by Bubba

Precompiled headers are more of a pain than they are worth. I would highly recommend you select Do no use precompiled headers in your project options.

---

I disagree. My current project at work needs about two minutes to rebuild after a change to an important header without PCH, about 30 seconds with PCH. Individual files go from 3-4 second to just under a second. This is worth a lot, especially as the project hasn't even reached its final size yet.
No problems so far. Just remember to do a full rebuild, including the PCH, when something changes related to the libraries.

I am not allowed to use them. I would assume you do not submit these to SCM since they get rebuilt.

I always turn them off. Any project large enough to make a meaningful difference in its compile time, is also complex enough to not want inconsistences due to bad versioning.

Its really just not worth it IMO.

Quote:

---

Originally Posted by abachler

I always turn them off. Any project large enough to make a meaningful difference in its compile time, is also complex enough to not want inconsistences due to bad versioning.

Its really just not worth it IMO.

---

That's a false dichotomy -- most official build processes are from clean, anyway, so all precompiled headers will be rebuilt during an official build. Yeah, the dev areas can get out of whack, but if you suspect that's happening you just do a clean build.

If zillions of developers are flying around making breaking changes to header files and APIs then you need to get control of your process.

I'm not saying that they dont improve the build time, only that in my experience the savings isnt significant enough to matter.

If its a 2 second build and they save 1 second its irrelevant.

If its a 2 minute build and they reduce the build time by 30 seconds, I wont be back from getting coffee anyway.

If its a 2 hour build and it saves 30 minutes I wont be back from lunch unless maybe I left immediately after starting the build.

If its a 2 day build and it saves 12 hours, then I wont be back from the weekend.

Now a corporate bean counter may find a 30 second * 1000 employee time savings to be a big deal, except when you factor in the human cost of driving people to the point of not taking a break after an accomplishment, which is usually when they recompile, and its undeniable effect on efficiency and moral.

Quote:

---

Originally Posted by Bubba

I am not allowed to use them. I would assume you do not submit these to SCM since they get rebuilt.

---

Of course. Just as I don't submit object files to the SCM.