Thread: Config MVS to complie C

Just name the file as yourname.c instead of yourname.cpp, and it will compile as C instead of C++.

--
Mats

Or you can keep the cpp extension and change some of the project properties. Depending on what version you have it may be different, but in Visual C++ 2005/2008 I think you can right-click on the project in the "Solution Explorer" and go to "Properties" then in the window that pops-up go to Configuration Properties->C/C++->Advanced. Once there in the section of the window on the right there should be an option that states something along the lines of "Compile As". You can highlight that and then select from a drop down option change that from "Compile as C++" to "Compile as C".

Originally Posted by hk_mp5kpdw

Or you can keep the cpp extension and change some of the project properties. Depending on what version you have it may be different, but in Visual C++ 2005/2008 I think you can right-click on the project in the "Solution Explorer" and go to "Properties" then in the window that pops-up go to Configuration Properties->C/C++->Advanced. Once there in the section of the window on the right there should be an option that states something along the lines of "Compile As". You can highlight that and then select from a drop down option change that from "Compile as C++" to "Compile as C".

Whilst that technically works, it is "the wrong solution" in the sense that it will not work if the files are then transferred to another system where another compiler is used - gcc for example also uses the extension to differentiate between C and C++ files.

--
Mats

Of course you can add them either in the stdafx.h file or in your .c files.
Usually, it is an advantage to add them into the stdafx.h file since it's a precompiled header which will speed up compilation.

stdafx.h is used as a "precompiled header". My suggestion is that you go to your project properties and turn "precompiled header" off, and ignore precompiled headers - at least until such a point that your project is dozens of source files that all include at least half a dozen files in common.

Otherwise, visual studio's C compiler uses headers in the same way as other compilers. <somethign.h> in an include means system directories are searched only, whilst "something.h" means that the file is searched for in the same directory as the source code is in first, then in the system include directories.

--
Mats

Originally Posted by matsp

stdafx.h is used as a "precompiled header". My suggestion is that you go to your project properties and turn "precompiled header" off, and ignore precompiled headers - at least until such a point that your project is dozens of source files that all include at least half a dozen files in common.

My advice is the contrary, because you will gain nothing from doing so and potentially also add compilation time.
When using precompiled headers, you only have to add #include "stdafx.h" at the beginning of every sourcefile. No more.
If you don't, you will get a compile error--that's quite friendly, btw--telling you that you forgot to do so.

Originally Posted by Elysia

My advice is the contrary, because you will gain nothing from doing so and potentially also add compilation time.

As a beginner, you may gain from not using precompiled headers: it would be a reminder to associate functions with the headers that they are declared in.

Learn to remember to include headers and potentially learn what headers what is stored inside, you mean?
Hmmmm. That is the first good argument against using precompiled headers I've heard.

Originally Posted by Elysia

Learn to remember to include headers and potentially learn what headers what is stored inside, you mean?
Hmmmm. That is the first good argument against using precompiled headers I've heard.

You mean the fact that forgetting to put #include "stdafx.h" gives strange error messages is not bad enough? And then the user goes to school where they use Unix/Linux, and wonder why including stdafx.h doesn't work - or why the code (s)he wrote at school and compiled fine there won't work at home, etc.

Yes, it's a good argument that you understand the relationship between header files and functions, but the complications of using precompiled headers are also quite apparent.

And unless we're talking fairly large projects (or perhaps projects that include Windows.h or some such), there is no real benefit. Take one of your small projects (no more than 5 source files), do a complete build of it and time the time it takes to build with and without precompiled headers. How much is the difference? Two seconds or less is my guess, and a total time of mayeb 10 seconds.

--
Mats

Originally Posted by matsp

You mean the fact that forgetting to put #include "stdafx.h" gives strange error messages is not bad enough?

Not bad at all.

And then the user goes to school where they use Unix/Linux, and wonder why including stdafx.h doesn't work - or why the code (s)he wrote at school and compiled fine there won't work at home, etc.

That's basic course - to separate local files in your project and library headers.
There should be no confusion or the user seriously needs to re-learn the language.

Yes, it's a good argument that you understand the relationship between header files and functions, but the complications of using precompiled headers are also quite apparent.

No, I fail to see them.

And unless we're talking fairly large projects (or perhaps projects that include Windows.h or some such), there is no real benefit. Take one of your small projects (no more than 5 source files), do a complete build of it and time the time it takes to build with and without precompiled headers. How much is the difference? Two seconds or less is my guess, and a total time of mayeb 10 seconds.

I would not want to wait 10 seconds to compile my project. Absolutely not.
2 seconds is acceptable, but I'd rather be without.

Originally Posted by jwenting

Another excellent argument is that they're compiler specific and can cause confusion.
Using Borland C++ you don't have any stdafx.h for example, and having it as an #include will cause trouble.
gcc is similar.
MSVC requires it to be included as the first thing in every single source, even if that source doesn't need any #includes at all.

Strangely, if you create a project to not use precompiled headers in MSVC 2008, it still creates stdafx.h and stdafx.cpp, it just doesn't complain if you delete them (and all references to them) from the project.

That old argument is just as untrue as it was then.
stdafx.h is not a special header - it is a header created for the project, and thus is a normal header that you can include and which works on every compiler.
And I cannot see confusion stemming from that, since it is a header tied to the project - a project header if you will, not a library header.

Originally Posted by jwenting

You've lived a sheltered life, and probably a short one.
I've dealt with compile cycles that took literally days to perform a full build, and that on hardware that was above standard for the time.

And for large projects today you can expect a compile cycle to take minutes to hours, it keeps you on your toes to make darn sure your code is correct before you start compiling

For such projects, saving a few seconds or even minutes by using a compiler-specific precompiled header that otherwise causes more trouble than it's worth is just not worth it.

Perhaps. I've had projects that might take a minute to build, but nothing really big. I am, after all, not a hired software developer. All my projects are private.
But nevertheless, where there is time to be saved, I feel like I want it. Especially if compiling it done a lot.