VC++ Express edition question!
Robby
As I did in my previous post, (with difficulty) I was able to create a pure
.c file to test some C code in an older VC++ compiler version.
Now I am trying to do the same thing with VC++ 2008 Express edition. I don't
know why I have such difficulty with doing C in VC++, there is just too much
types of projects to choose from, and I get confused. Can someone please
guide me on this.
I have done:
File>New>Project.... Then, I clicked on "WIN32 Console application" icon in
the right pane of this window.
I then entered a project name called "xxx" and then clicked browse to put my
project in the folloing directory:
C:\DTS_VISUALC++\xxx
I then clicked [OK].
I was then prompted with the applications wizard window.
I then clicked on "application settings"
Clicked on "Console application" and then clicked on finish.
I then deleted all source and header files that were automatically created
and added my own .c file.
I included the "stdio.h" file like I did in the older VC++ version(which
works) and tried to compile the following code:
========================================
#include <stdio.h>
void main()
{
int x = 0;
x++;
}
==============================================
I got the following error:
.\ccc.c(79) : fatal error C1010: unexpected end of file while looking for
precompiled header. Did you forget to add '#include "stdafx.h"' to your
source?
Build log was saved at "file://c:\DTS_VISUAL_C++\xxx\xxx\Debug\BuildLog.htm"
xxx - 1 error(s), 0 warning(s)
====== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
What I don't understand is if I just want to do C code, I should I include
the "stdafx.h" as specified in the error above?
So *I tried* to solve this by going to:
Tools>Options:
Selected "Projects and solutions" and selected "General"
and changed the [Projects location] to:
C:\DTS_VISUAL_C++\xxx\xxx
That didn't work, so before I make a mess of things, I figure I rather ask
someone to help me.
Thanking all in advance !
--
Best regards
Roberto
Nathan Mates
=?Utf-8?B?Um9iYnk=?= <Ro...@discussions.microsoft.com> wrote:
>Now I am trying to do the same thing with VC++ 2008 Express edition. I don't
>know why I have such difficulty with doing C in VC++, there is just too much
>types of projects to choose from, and I get confused. Can someone please
>guide me on this.
[...]
>.\ccc.c(79) : fatal error C1010: unexpected end of file while looking for
>precompiled header. Did you forget to add '#include "stdafx.h"' to your
>source?
This is because Microsoft assumes that (1) everyone wants to use a
precompiled header -- which is really useful if and only if you know
what you're doing, and (2) people will recognize 'stdafx.h' as the
name of the file to use as a precompiled header. I've commented on
this before -- it's a decade overdue to get out of the MS-DOS 8.3
overabbreviated filename paradigm, and rename the *default* setting
here to something reasonable like '{$Project}PrecompiledHeader.h".
Two possible solutions:
1) When you create your project in DevStudio, after entering the
name, directory, etc, on the page that says "Click Finish to accept
the current settings," do **NOT** hit Finish. It's a trap. Instead,
go to the 'Application Settings' item, and unclick the [x] Precompiled
Header item. (Or, click on [x] Empty Project, which does the same, and
more.)
2) If you don't want to recreate your project, then right click on the
project in the Solution Explorer, and select Properties. Then, select
Configuration: All Configurations (at top-left), then go to
Configuration Properties -> C/C++ -> Precompiled Headers, and set
Create/Use Precompiled Header to "Not Using Precompiled Headers."
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
Mark Salsbery [MVP]
news:DACFCCE4-7D5C-43A1...@microsoft.com...
>...
> I got the following error:
>
> .\ccc.c(79) : fatal error C1010: unexpected end of file while looking for
> precompiled header. Did you forget to add '#include "stdafx.h"' to your
> source?
You need to configure precompiled headers for your needs.
You have a couple choices...
1) Use precompiled headers:
Add a .h file to your project - you can call it StdAfx.h or anything you
want
Go to Project properties | Configuration Properties | C/C++ | Precompiled
Headers and set the Create/Use Precompiled Header to "Use Precompiled
Header".
Set the Create/Use PCH through file to the name of the file you created
above
Add #include "StdAfx.h" (use whatever you called the file above) to
the top of any C files you have configured to use precompiled headers.
In your precompiled header file, you can put any global declarations and
#includes that are common to all source files.
2) Don't use precompiled headers - can make for long build times on large
projects:
Go to Project properties | Configuration Properties | C/C++ | Precompiled
Headers and set the Create/Use Precompiled Header to "Not using Precompiled
Header".
All the above settings can be applied project-wide or to individual C files.
Mark
--
Mark Salsbery
Microsoft MVP - Visual C++
>
> --
> Best regards
> Roberto
Robby
Oh dear, I was told to do this earlier for the older VC++ compiler.
Basicaly, I have included the <stdio.h> file and did the precompiled header
modification and now it compiles. I thankyou for your help.
So I have never really questioned myself about precompiled headers when I
was doing some VC++ programming, I just included it because it was shown to
include it in the sample code.
So in a nutshell, what is so special about these precompiled headers? And
should I worry to know more about them?
Thanks!
--
Best regards
Roberto
Robby
--
Best regards
Robert
Nathan Mates
=?Utf-8?B?Um9iYnk=?= <Ro...@discussions.microsoft.com> wrote:
>So in a nutshell, what is so special about these precompiled
>headers? And should I worry to know more about them?
Basically, precompiled headers make medium to large sized projects
build a lot faster. They do this by caching the results of #including
a user-selected set of headers in a binary format that is far faster
to load, as it doesn't have to re-parse all the ascii headers. To
use them, you should do the following:
1) Set up your project to use precompiled headers. As before, I
*cannot stand* the default name of 'stdafx.h.' I make a 'common.h' or
'precompiled.h' or somesuch, and a matching .cpp file. I then set the
entire project to use precompiled headers from 'common.h', and for
common.cpp, I set it to create the precompiled header via common.h.
[Remember to do this for all configurations, rather than just debug
or release.]
2) In common.h, I put in lines to #include any system header
(i.e. #include <...>) that is used by more than 2-5% of the files in
the project. This includes things like <stdio.h>, <windows.h>, or
other big addons, such as DirectX. I also #include any header I wrote
(e.g. #include "..") used by more than about 25-33% of the project.
3) In all the rest of the .cpp files, the first #include *MUST* be
'#include "common.h"'. This can *not* be '#include "..\foo\common.h"',
even if that's the correct relative path to common.h.
As above, the upside of a precompiled header is that it's *much*
faster to include after it's created. The downside is that it becomes
a 'header of death' where any change to it (or anything #included by
it) forces a 100% rebuild of your project. If you use it for 'system'
headers, those should not change except for what you upgrade your
compiler, DirectX SDK, etc, and you'll do a rebuild anyhow.
So, my gut rule of thumb is this: for any project more than about
3-4 source files that #includes <windows.h> (or a bunch of the other
system headers), a precompiled header pulling that in is a BIG
win. For non-system headers, use your judgment. If it's used by a lot
of your .cpp files, then include it in the precompiled header, because
most of your .cpp files would be rebuilt anyhow when that header
changes. As I said above, if a non-system header is used more than
about 25-33% of the .cpp files, I'll consider it a win to put it in
the precompiled header.
Robby
I thankyou for sharing your insights on how to use precompiled headers.
I should try this one day!
Have a nice evening Nathan!
--
Best regards
Roberto
Alex Blekhman
> For non-system headers, use your judgment. If it's used by a
> lot of your .cpp files, then include it in the precompiled
> header, because most of your .cpp files would be rebuilt anyhow
> when that header changes.
There is interesting quirk when precompiled headers (PCH) and
IncrediBuild used together. If PCH grows too big, then using it
actually slows down the build, since IncrediBuild apparently
distributes it across building machines. So, LAN starts to choke
and a build lasts much longer. For our project the optimal PCH
size is about 50-70MB. Anything bigger than that makes PCH usage
worthless.
Alex
Nathan Mates
Alex Blekhman <tkfx....@yahoo.com> wrote:
>"Nathan Mates" wrote:
>> For non-system headers, use your judgment. If it's used by a
>> lot of your .cpp files, then include it in the precompiled
>> header, because most of your .cpp files would be rebuilt anyhow
>> when that header changes.
>There is interesting quirk when precompiled headers (PCH) and
>IncrediBuild used together. If PCH grows too big, then using it
>actually slows down the build, since IncrediBuild apparently
>distributes it across building machines.
Fair enough, but I should note that incredibuild is an commercial
add-on, and therefore not part of most people's installs. That
definitely applies to the original poster asking about the Express
Edition of DevStudio -- which can't do addons.
I've used Incredibuild for years at work, but with DevStudio 2008
doing multi-core builds, and quad-core (or dual-quadcore) boxes, I
feel that the benefits of Incredibuild are somewhat diminishing.
Frankly, with 8 local cores at my desk, I'd rather let Windows do the
caching of big PCH files and not needlessly saturate the network.
Plus, I've still had *too many* "wtf" moments in debugging code that
*should* work, that were fixed by cleaning the project and and making
Incredibuild start from scratch. I demand accuracy out of my compiles,
and Incredibuild is only "close."
Alex Blekhman
> Fair enough, but I should note that incredibuild is an
> commercial add-on, and therefore not part of most people's
> installs. That definitely applies to the original poster asking
> about the Express Edition of DevStudio -- which can't do addons.
Yes, my post was rather a side note for future readers.
Alex