Precompiled Headers problem

[lbrandewie]

Hey All,

I've been building a bunch of command-line executables without issue. I've been wanting to turn them into GUIs. So, I created a new project using MFC, selected a Dialog-based app, generated the starter code and verified that it compiled. No problem so far.

However, when I try to add the first file of my app, I get the following error:

Error C1010 unexpected end of file while looking for precompiled header. Did you forget to add '#include "pch.h"' to your source? GUItest1 C:\projects\GUITools\Class Files\GlobalProcs3.cpp 748

It appears to think this file should be precompiled, but I have no clue why. So, I tried adding pch.h to it, but that didn't fix it. Why did it in the first place thing this file should be precompiled? Did I do something to cause this?

I've been making CLI exes for some time and haven;t run into this at all, so I have no real clue what's wrong or how to fix it. The only fix MSoft suggests is turning off precompiled headers entirely, which would hurt performance a lot.

Thanks in advance,

Lars

[salem c]

> The only fix MSoft suggests is turning off precompiled headers entirely, which would hurt performance a lot.
No it wouldn't.

For the sizes of projects you're ever likely to create for yourself, it's not going to make a difference.

It's the sort of thing that only really mattered for large, badly organised projects in the 1990's, when machines were slow and disks even slower.

Besides, not having pch teaches a bit of discipline on your part by not getting into the habit of #include <all_the_headers> because you can't be bothered to figure out what headers you actually need.

Oh, and this is purely a compile time 'performance' issue, it has zero effect on the run-time performance of your code.

[lbrandewie]

Thanks, but I'm having trouble even doing that! When I turn off PCH I get strange errors in the generated code. Not sure what's going on with that. Still at the tearing-my-hair-out stage. But you're right, compile performance isn't too bad.

[salem c]

After you've turned it off, a 'clean' and a 'rebuild all' should sort things out.

[lbrandewie]

Thanks!

[jonnin]

In my experience it rarely worked right and was actually slower. It was slower because it didn't work: you had to stop, manually delete the .pch file, and then the stupid compiler had to rebuild it, and that took more time than just compiling the headers each time. Its kind of a neat idea (when it came out) that was not actually useful in practice.

[George P]

When precompiled headers actually work, big if there, about the only time using them will save time is with large projects that take several hours or more to compile.

Compiling the Windows kernel reportedly takes over a day.

I have never bothered after trying several years ago, the effort and angst from using PCHs overrode the alleged time savings.

[lbrandewie]

Still having the same sorts of problems. I can get it to compile after turning PCH off, and can mod the code and it still compiles, but as soon as I add in any other source file I start getting inexplicable errors. For example, the following lines in my app's InitInstance() method:

INITCOMMONCONTROLSEX InitCtrls;
InitCtrls.dwSize = sizeof(InitCtrls);

produce an error on the first line saying the variable InitCtrls is not initialized. Wasn't a problem *before* I added in my source file, which I didn't even call. So I'm not getting this at all.

Frustratedly,

Lars

[George P]

It sounds like you are not adding the Common Controls library to the project/.

If this were a Win32 SDK project I'd add comctl32.lib via #pragma to a single source file:

#pragma comment (lib, "comctl32.lib")

No need to muck with the project settings, Visual Studio adds the library as needed.

I don't know if there is a similar way for MFC. You might have to add the lib via the project/solution settings.

https://docs.microsoft.com/en-us/cpp/mfc/isolation-of-the-mfc-common-controls-library?view=msvc-160

Or I could be just gaslighting myself in understanding the issue.

[lbrandewie]

Hmmmm, not sure. As I explained, the error started when I added a separate source file, which I hadn't even called any functions in. Why that would cause working code to fail, I dunno. But, I added your pragma nonetheless. It seems to have fixed the one bad line of code, but now I'm getting other errors. Specifically I'm being told I've redefined some operators that are defined in a .lib file:

"void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCMTD.lib(delete_scalar.obj) GUItest3 C:\projects\GUITools\GUItest3\uafxcwd.lib(afxmem.obj) 1

and

"void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in LIBCMTD.lib(new_scalar.obj) GUItest3 C:\projects\GUITools\GUItest3\uafxcwd.lib(afxmem.obj) 1

and

"void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) already defined in LIBCMTD.lib(delete_array.obj) GUItest3 C:\projects\GUITools\GUItest3\uafxcwd.lib(afxmem.obj) 1

... despite not redefining any new or delete operators in my code. To say the least, I'm confused. TIA for any further help.

Lars

[lbrandewie]

It occurs to me that it might be this lib redefining the operators, but I don't know how to check or to fix it.

Lars