Sign in to follow this  
RadicalOne

"stdafx.h"???

Recommended Posts

I had been using other compilers but recently i moved to vc++.net express edition. All went fine but when i go to just create a console application to test some stl things, it adds "stdafx.h" and it uses a very odd main definition instead of the standard. Why is it changing things around so much?

Share this post


Link to post
Share on other sites
the stdafx.h is your precompiled header. You don't have to use it. Just turn it off in project settings C++/Precompiled headers.

I believe the main definition vs.net uses now is standards compliant. you might be looking at _tmain(..). That's a microsoft macro that expands to the Unicode or ansi version of main depending on which you compile under.

If you cretated a windowed app though you'd end up with winmain instead.

Cheers
Chris

Share this post


Link to post
Share on other sites
Stdafx.h is the "precompiled header" file (well actually its the header file that the PCH is generated from).

Basically every C or CPP file in your project has to include this file as the first line in its file (unless you explicitally turn off precompilied headers for that file). All the includes listed in this file will be precompiled to a binary PCH file which speeds up compile time.

The file Stdafx.cpp is just stub that is tells .NET to compile Stdafx.h into a PCH file.

Its a pretty dumb system IMO, but it can really speed up compile times. Personally I generally don't use the automatic PCH generation feature (it never quite worked correctly for me, though I've not tried in 2005 it may be better). If you want to turn off completely and delete Stdafx.c/.h then the option is in properties->C/C++->Precompiled headers, change "Create/Use precompiled headers" to "not using precompiled headers".

Share this post


Link to post
Share on other sites
Quote:
Original post by griffin2000
Its a pretty dumb system IMO, but it can really speed up compile times.


What don't you like about precompiled headers??

Cheers
Chris

Share this post


Link to post
Share on other sites
also note it doesn't have to be named stdafx either... sometimes i name mines pch.h... if i recall right stdafx is just old-time MFC lingo for its precompiled headers...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
what about the weird setup of main wheny ou create a new console project?

Share this post


Link to post
Share on other sites
Quote:

What don't you like about precompiled headers??


Its not PCH per-se. Its the way they are implemented on .net is very crap. The automatic generation process is just busted as far as I can work out. You can get them to work by setting them up manually, but the mechanism is very clunky (the way it forces you to make the PCH header the first line in all your source files is very irritating).

Share this post


Link to post
Share on other sites
Quote:
Original post by griffin2000
Basically every C or CPP file in your project has to include this file as the first line in its file (unless you explicitally turn off precompilied headers for that file). All the includes listed in this file will be precompiled to a binary PCH file which speeds up compile time.


Quick note about adding the precompiled header to each c/cpp file. Visual studio has an option that will allow you to force an include on all of your files if you wish to use it. You can find it under project properties, c/c++->advanced. Enter in your .h file to the force includes and it should be good to go without explicitly adding the .h to each file.

Share this post


Link to post
Share on other sites
I don't like how MS does PCH either. It breaks the ANSI standard, which is never a good compiler feature. Anything defined before you include the header is forgotten, and it forces an order to your includes. The PCH must come first. Take the same file, including the same headers, and defining the same defines, with PCH turned off, and it SHOULD compile the same, just slower. Not so in MSVC. It breaks the compile.

ie:

#define MAX_PLAYERS 4
#include "stdafx.h"
// MAX_PLAYERS has magically disappeared by here.

or

#if defined TOOL
#include "toolheader.h"
#elif defined GAME
#include "gameheader.h"
#endif
// forgets that it's inside #ifs. Compile breaks.


Also, while you CAN change it's name from stdafx.h, don't. Please, don't. Why? Because your cpp files MUST include it first. Have you made a nice AVLTree you'd like to use in multiple projects? If you call your header stdafx.h you can add a generic version into all the projects you want. If you name your header differently per project, you must make copies and edit them, or you must disable PCH for shared CPP files.

Share this post


Link to post
Share on other sites
If you don't want to deal with all the precompiled header stuff, the easiest thing to do is to select the "empty project" option when you create your project.

Share this post


Link to post
Share on other sites
Quote:
Original post by griffin2000
Personally I generally don't use the automatic PCH generation feature (it never quite worked correctly for me, though I've not tried in 2005 it may be better)

From a VC++ developer:
Quote:
Buggy features
It may come as a shock, but some of the features we've released in Visual C++ haven't had the level of quality that we wish it would have. The most notable of all is automatic precompiled header (PCH) files. The YX switch was used to tell the compiler to automatically select and create a PCH file. Developers would use this to speed up a build, but in practice it slowed the build down. Only in a few test cases did it benefit the build time. Given that information, we decided to remove the switch. If you do want to use a PCH, the Yc and Yu switch still exist and, when used correctly, they will dramatically improve build times.

so automatic PCH generation is no longer accessible in VC++ 2005 and you should use the manual settings instead (which is what VS2005 defaults to when you create a new C++ project, with stdafx as the PCH file). In my experience, PCH is definitely worthwhile when it's set up correctly.

Quote:
Original post by griffin2000
the mechanism is very clunky (the way it forces you to make the PCH header the first line in all your source files is very irritating)

GCC does sort of the same - the precompiled header must be included before any C tokens, and before any relevant preprocessor definitions that weren't exactly the same when you did the precompilation step - except that it sounds like it silently ignores the PCH if you do it wrong.

Quote:
Original post by Namethatnobodyelsetook
Have you made a nice AVLTree you'd like to use in multiple projects? If you call your header stdafx.h you can add a generic version into all the projects you want. If you name your header differently per project, you must make copies and edit them, or you must disable PCH for shared CPP files.
You could compile AVLTree into a static library (.lib), and then link that into all the projects that use it - and those projects can have completely different PCH settings. Or you can have all the code in the same project but use different PCH settings for each source file, particularly if you have an automatic project-generation tool (like Premake, although you have to hack it a bit to get proper PCH support). But it's far from a perfect situation.

In a largish project I've been working on, we have the game engine split into six static libraries. All the source files start with '#include "precompiled.h"', and we add the directory 'source/pch/$projectname' into each project's include path (using Premake to generate the VS projects and GCC Makefiles). Each of those directories contains a precompiled.h, which first includes a common .h file (which disables unhelpful warnings, then pulls in all the C/C++/STL headers) and then any extra headers which can be usefully precompiled for that project. Seems to work alright, and makes things much faster than with PCH disabled - but it's not a magic solution to build times, and it doesn't beat the avoidance of giant templated headers and dozens of dependencies per file...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this