.NET Forum / Languages / Managed C++ / January 2007
Is #include inside stdafx.h a bad idea?
|
|
Thread rating:  |
Chris Shearer Cooper - 24 Jan 2007 19:52 GMT In our Visual Studio 2005 application, we have several of our application's H files that are #included into stdafx.h.
What is odd, is that when we change those application H files, VS2005 doesn't trigger a rebuild of the entire app (or of anything, for that matter).
Is this a setting somewhere?
Thanks! Chris
Victor Bazarov - 24 Jan 2007 21:11 GMT > In our Visual Studio 2005 application, we have several of our > application's H files that are #included into stdafx.h. I thought that it is exactly what the precompiled headers are for.
> What is odd, is that when we change those application H files, VS2005 > doesn't trigger a rebuild of the entire app (or of anything, for that > matter). > > Is this a setting somewhere? Aren't you supposed to have 'stdafx.cpp' added to your project as well as 'stdafx.h'? That's what should trigger re-creation of the precompiled headers and further recompilation of the modules...
Or just turn them precompiled headers off (are they on?)
V
 Signature Please remove capital 'A's when replying by e-mail I do not respond to top-posted replies, please don't ask
Chris Shearer Cooper - 24 Jan 2007 21:57 GMT Both stdafx.h and stdafx.cpp are included in the project.
>> In our Visual Studio 2005 application, we have several of our >> application's H files that are #included into stdafx.h. [quoted text clipped - 14 lines] > > V Bruno van Dooren [MVP VC++] - 26 Jan 2007 12:27 GMT > Aren't you supposed to have 'stdafx.cpp' added to your project as > well as 'stdafx.h'? That's what should trigger re-creation of the > precompiled headers and further recompilation of the modules... > > Or just turn them precompiled headers off (are they on?) the precompiled header is generated through StdAfx.cpp. only when that is recompiled, is the precompiled header re-generated.
If your cpp files do no include the changed header file directly, they will not see the changes. Rather, they will see what used to be in the header when StdAfx.cpp was last compiled.
This is one of the gotchas of precompiled headers. A full rebuild will solve this, since StdAfx will be compiled first. Other than that you can only solve this by manually recompiling StdAfx.cpp after a change.
 Signature Kind regards, Bruno van Dooren bruno_nos_pam_van_dooren@hotmail.com Remove only "_nos_pam"
Nathan Mates - 24 Jan 2007 21:45 GMT >In our Visual Studio 2005 application, we have several of our application's >H files that are #included into stdafx.h.
>What is odd, is that when we change those application H files, VS2005 >doesn't trigger a rebuild of the entire app (or of anything, for that >matter). I've seen a lot of projects not compile every dependent cpp file when Resource.h is changed. Is this the kind of header file you're changing? Btw, you can rename your precompiled headers to something that's a lot more meaningful - no need to keep up with MS-DOS 8.3 filenames or a bad keyboard splattering that became a (lousy) standard.
Nathan Mates
-- <*> Nathan Mates - personal webpage http://www.visi.com/~nathan/ # Programmer at Pandemic Studios -- http://www.pandemicstudios.com/ # NOT speaking for Pandemic Studios. "Care not what the neighbors # think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Chris Shearer Cooper - 24 Jan 2007 22:21 GMT Yeah ... and I was wondering where the setting was, that said "don't rebuild just because resource.h changed" ... but no, the header files I'm changing are not resource.h, they contain real live C++ class definitions ...
>>In our Visual Studio 2005 application, we have several of our >>application's [quoted text clipped - 19 lines] > # think. What are the facts, and to how many decimal places?" -R.A. > Heinlein Doug Harrison [MVP] - 24 Jan 2007 22:46 GMT >>>In our Visual Studio 2005 application, we have several of our >>>application's [quoted text clipped - 13 lines] >Yeah ... and I was wondering where the setting was, that said "don't rebuild >just because resource.h changed" ... That setting is expressed in the comment at the very top of the file:
//{{NO_DEPENDENCIES}}
>but no, the header files I'm changing >are not resource.h, they contain real live C++ class definitions ... Where are the files located, and what are their names? VC++ has gotten smarter about excluding files from dependency checking. In VC6 and earlier, there was a file (sysincl.dat, IIRC) that contained many hundreds of names of system (C, C++, Windows) headers, and the compiler would exclude any file with one of these names, wherever it was located. Nowadays, the compiler excludes whole directories, which makes a lot more sense. You should also make sure the relevant .obj files aren't dated far into the future.
 Signature Doug Harrison Visual C++ MVP
Chris Shearer Cooper - 25 Jan 2007 00:20 GMT stdafx.h looks like this (it's the "..\otherproject\superfile.h", and similar lines immediately following, that are my concern): * neither stdafx.h nor superfile.h start with //{{NO_DEPENDENCIES}} * I do a complete rebuild, and the problem doesn't go away (so it's not obj files being dated in the future)
// stdafx.h : include file for standard system include files,
// or project specific include files that are used frequently, but
// are changed infrequently
//
#if !defined(AFX_STDAFX_H__213DF6DA_EB6C_11D5_9E8D_000000000000__INCLUDED_)
#define AFX_STDAFX_H__213DF6DA_EB6C_11D5_9E8D_000000000000__INCLUDED_
#if _MSC_VER >= 1000
#pragma once
#endif // _MSC_VER >= 1000
// Lowest operating system you need your app to run on
// WINVER 0x0400 is Windows 95 and Windows NT 4.0
// WINVER 0x0410 is Windows 98
// WINVER 0x0500 is Windows Me, 2000
// WINVER 0x0501 is Windows XP
// RTL features like WS_EX_LAYOUTRTL only appeared in version 0x0500
#if _MSC_VER >= 1400 // VS 2005
#define _WIN32_WINDOWS 0x0410
#define WINVER 0x0410
#define _WIN32_WINNT 0x0500
#endif
// Internet Explorer 5.0, 5.0a, 5.0b
#define _WIN32_IE 0x0500
#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
#include <afxwin.h> // MFC core and standard components
#include <afxext.h> // MFC extensions
#include <afxdtctl.h> // MFC support for Internet Explorer 4 Common Controls
#include <afxtempl.h> // MFC support for Internet Explorer 4 Common Controls
#include <afxdisp.h> // For Drag & Drop
#include <afxole.h> // For Drag & Drop
//#include <afxadv.h> // For Drag & Drop
#ifndef _AFX_NO_AFXCMN_SUPPORT
#include <afxcmn.h> // MFC support for Windows Common Controls
#include <afxcview.h>
#endif
#ifndef WS_EX_NOINHERITLAYOUT
#define WS_EX_NOINHERITLAYOUT 0x00100000
#endif
#ifndef WS_EX_LAYOUTRTL
#define WS_EX_LAYOUTRTL 0x00400000
#endif
#define countof(x) (sizeof(x) / sizeof(x[0]))
#include "Resource.h"
#include "..\OtherProject\SuperFile.h"
>>>>In our Visual Studio 2005 application, we have several of our >>>>application's [quoted text clipped - 31 lines] > should also make sure the relevant .obj files aren't dated far into the > future. Chris Shearer Cooper - 25 Jan 2007 13:51 GMT Interesting thing I just discovered ... in the stdafx.h, I include a lot of other files (the listing I gave in this previous post was deliberately incomplete) ... It appears that files that are in the same folder as stdafx.h do cause a complete rebuild, but files that are in other folders (like ..\OtherProject) are not. Does this jibe with what you said about the compiler excluding whole directories? And if so, how do I tell the compiler to not exclude the ..\OtherProject directory?
Thanks Chris
> stdafx.h looks like this (it's the "..\otherproject\superfile.h", and > similar lines immediately following, that are my concern): [quoted text clipped - 127 lines] >> should also make sure the relevant .obj files aren't dated far into the >> future. David Ching - 25 Jan 2007 17:05 GMT > Interesting thing I just discovered ... in the stdafx.h, I include a lot > of other files (the listing I gave in this previous post was deliberately [quoted text clipped - 4 lines] > compiler excluding whole directories? And if so, how do I tell the > compiler to not exclude the ..\OtherProject directory? It shouldn't matter what directory the header is in. But VC++ maintains dependency info on a very fine basis. For example, if you change a protected member of a class in the .h, it won't compile the .cpp files that include the class because it knows that protected members can't be accessed outside of the class so there is no need to recompile code outside of the classs. Maybe that's why changing some .h files for you doesn't build anything.
-- David (MVP)
Alex Blekhman - 26 Jan 2007 12:11 GMT >> It appears that files that are in the same folder as >> stdafx.h do cause a complete rebuild, but files that are [quoted text clipped - 7 lines] > accessed outside of the class so there is no need to > recompile code outside of the classs. It looks like quite dangerous decision. Protected members, while being inaccessible, are perfectly visible for user's code and participate in member call resolution. Access rights are apllied afterwards. For example:
class X { public: void f(double) {}
protected: void f(const char*) {} };
int main() { X x;
x.f(42); x.f(3.14);
return 0; }
The code above compiles as expected. Now if I change protected `f' from
void f(const char*) {}
to
void f(int) {}
The `x.f(42);' statement won't compile anymore since protected member function `void f(int)' participates in call resolution and matches better than `void f(double)'.
Now, if compiler doesn't recompile corresponding .CPP file, then the above compilation error will lurk untill full rebuild. So, developer can continue with other tasks for a long time without even knowing that there is an error.
Alex
David Ching - 26 Jan 2007 14:45 GMT > It looks like quite dangerous decision. Protected members, while being > inaccessible, are perfectly visible for user's code and participate in > member call resolution. Access rights are apllied afterwards. For example: Yes, you're right of course. I'm not sure how the decision of what to compile is made in this instance, maybe VC++ handles it correctly. There are times when I make changes, build my app, and the result crashes with a disassembly window that doesn't match the source, or some other weird result. Then I have to a Rebuild Solution in order to make sure everything is in sync. So VC++ decision to compile certain things can and does get confused at times. I'm sure we've all experienced this.
Thanks, David (MVP)
Alex Blekhman - 26 Jan 2007 15:37 GMT > [...] There are times when I make changes, build my app, > and the result crashes with a disassembly window that [quoted text clipped - 3 lines] > certain things can and does get confused at times. I'm > sure we've all experienced this. Yes, this is well known problem in the project I currently work on. We have quite a big amount of code and developers already lost their faith in "Build" command. Almost everybody does full rebuild after code sync and changes in headers.
Nathan Mates - 26 Jan 2007 17:25 GMT >Yes, this is well known problem in the project I currently work >on. We have quite a big amount of code and developers already lost >their faith in "Build" command. Almost everybody does full rebuild >after code sync and changes in headers. Do you have minimal rebuild turned on? That's under right click on project -> Properties -> C/C++ -> Code Generation -> Enable Minimal Rebuild. If that's set to Yes, try flipping the setting.
Nathan Mates -- <*> Nathan Mates - personal webpage http://www.visi.com/~nathan/ # Programmer at Pandemic Studios -- http://www.pandemicstudios.com/ # NOT speaking for Pandemic Studios. "Care not what the neighbors # think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Alex Blekhman - 26 Jan 2007 17:56 GMT >>Yes, this is well known problem in the project I currently >>work [quoted text clipped - 5 lines] > > Do you have minimal rebuild turned on? That's a good question. I'll check it when I'll get to office. Thanks
Doug Harrison [MVP] - 25 Jan 2007 20:49 GMT >Interesting thing I just discovered ... in the stdafx.h, I include a lot of >other files (the listing I gave in this previous post was deliberately [quoted text clipped - 4 lines] >whole directories? And if so, how do I tell the compiler to not exclude the >..\OtherProject directory? The setting is at (menu drilling down into dialog box):
Tools/Options/Projects and Solutions/VC++ Directories/Exclude Directories
I have VC2005 SP1 here, and I just created a console application and put the following into stdafx.h:
#include "../../other/zzz.h"
This file contains:
#pragma message("2")
When I change the message and recompile, stdafx.cpp and everything else is rebuilt. I did not add zzz.h to the project, so apparently it's not necessary to do so. If David is right, and minimal compilation is behind it, then you should see messages like this in the output window:
1>Skipping... (no relevant changes detected)
 Signature Doug Harrison Visual C++ MVP
Dan Baker - 25 Jan 2007 16:59 GMT > stdafx.h looks like this <snip>
> #include "Resource.h" <snip>
I don't think you want to #include "resource.h" ... Resource.h changes all the time. Files in stdafx.h are compiled and placed in the pre-compiled header, which means if you change your resources, you will not get those changed.
I don't think this is the problem you are describing... Just a note.
DanB
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 ...
|
|
|