So,
I've got this code I'm trying to update. It was written for visual studio 6, and I'm trying to get it to compile in visual studio 2010.
In stdafx.h, it includes afx.h and afxwin.h and a few other things necessary for the program to work. Notably, there's usage of CString in other header files.
At the top of the includes in stdafx.h, I added in a #pragma message, to verify that it was being compiled first. There's one at the top of the header file which throws the error, as well. I can see from the compiler output that stdafx.h was being compiled first, so that's good.
However, there was the error. (CString wasn't being recognized as a type.) So, I decided to make sure that it got through all of the includes. So, I put another #pragma message after #include and that message is not printed.
Does that mean is not actually being included?
Your explanation is a little hard to follow, but I think you're running into the differences between normal compilation and pre-compiled headers.
With pre-compiled headers, the compiler processes the first file normally (the new project wizard sets up stdafx.cpp for this). After processing the include file (typically stdafx.h) set in project options for pre-compilation control, the compiler saves its state to a .pch file.
For every other file, the compiler skims over the file without any processing, just looking for the include file. Then it reads the .pch file, loads the saved state, and continues parsing and compiling normally.
One consequence of this design is that any lines above #include "stdafx.h" in stdafx.cpp become part of the state and are seen by all other files. And lines above #include "stdafx.h" in other files are simply ignored.
Passing my comment to an answer.
CString in VS 6 times was a class and it changed afterwards to be a template. Maybe it has something to due with that?
The problem had to do with using
typedef with CString. Post VS 6,
that's not possible. I just changed
references by hand, and it compiles
now.
The problem had to do with using typedef with CString. Post VS 6, that's not possible. I just changed references by hand, and it compiles now.
Related
I've been using code blocks for a long time, but never really made my programs into actual code blocks projects. I tried to do it today, and I kept getting errors due to code blocks not recognizing my files. Here is what I have : ---->
CodeBlocks Include Error
When I try to buiild my project I get that cout,cin and my class objects are not defined in my menu.cpp file. So I can only guess code blocks is not properly handling the files.
I would love if someone could help me out as to why this is happening.
Thanks a ton in advance :)
When I try to buiild my project I get that cout,cin and my class objects are not defined in my menu.cpp file.
That's because they're not. You #included neither iostream nor class.h in menu.cpp, so you can't access the declarations therein.
Note that Code Blocks (just like any properly set up build tools) will compile each cpp file separately. This means that not only will it compile menu.cpp as part of the compilation of main.cpp (because you include it), it will also compile it on its own. In the latter case the includes from main.cpp will not be available, so menu.cpp needs its own includes.
This also means that once it does compile (i.e. once you added the includes), you'll get a linker error because the definitions from menu.cpp are now defined twice (once in main.o -- because you included menu.cpp in main.cpp -- and once in menu.o). That's the reason why you should never include cpp files into each other.
PS: This is unrelated to your problem, but it's considered bad practice to use using namespace in a header file. You should put that in your cpp files instead (if you want to use it at all). You should also put the #include <iostream> in those files where you actually need it, rather than the header file.
First of all i want to say that I read about precompiled headers and I understand that this is an optimization that saves me the time of compiling headers over and over on every built.
I'm reading the documentation of boost and I see that in the instructions they say:
In Configuration Properties > C/C++ > Precompiled Headers, change Use Precompiled Header (/Yu) to Not Using Precompiled Headers
And then they explain it:
There's no problem using Boost with precompiled headers; these instructions merely avoid precompiled headers because it would require Visual Studio-specific changes to the source code used in the examples.
Can some explain me the sentence I marked in bold? which visual studio specific changes they are talking about ? (Here is the link to the documentation I'm reading: http://www.boost.org/doc/libs/1_55_0/more/getting_started/windows.html#pch)
Why and when I would want to turn off the precompiled headers?
what is the difference between "Create" and "Use" in the precompiled header options.
Originally a comment, but I may as well post it. Note: this is specific to VC++:
The bold sentence is their way of saying the samples don't follow the mantra of a unified use-this-lead-in-header-for-pch-generation model. IOW, their samples aren't PCH-friendly, but you can still use pch with boost in your projects if properly configured.
You would turn them off for a variety of reasons. Some source modules, particularly ones from 3rd-parties, don't follow the PCH model of including "the" pch-through-header at their outset. Their samples are such code (and thus the advise to turn them off for their samples). Sometimes source files require different preprocessor configurations only for this files and not all files int he project; another reason to disable PCH for those files.
You typically use a source/header pair to generate "the One"; the precompiled header image. This header file typically includes:
Any system standard lib headers used by your project
3rd-party SDK headers
Just about everything else that is NOT in active development for your project.
The single source file tagged as Create typically includes one line of code : #include "YourHeaderFile.h", where YourHeaderFile.h is the header you filled with stuff from the list above. Tagging it as "Create" through header YourHeaderFile.h tells VC it is the file needed for rebuilding the PCH through that header when compiling other source files. All other source files are tagged as Use (except the ones where PCH is turned off) and should include, as their first line of code, the same #include "TheHeaderFile.h".
In short (hard to believe), <boost> is telling you their samples aren't setup like described above, and as such you should turn PCH off when building them.
When you use pre-compiled headers, you need to do something like:
#include <foo>
#include <bar>
#include <baz>
#pragma hdrstop
// other code here
Everything before the #pragma goes into the precompiled header. Everything after it depends on the precompiled header. The VC++ specific "magic" to make pre-compiled header work is that #pragma.
There's a little more to the story than just that though. To make pre-compiled headers work well, you want to include exactly the same set of headers in exactly the same order in every source file.
That leads to (typically) creating one header that includes all the other common headers and has the #pragma hdrstop right at its end, then including that in all the other source files.
Then, when the compiler does its thing, there are two phases: first you need to create a pre-compiled header. This means running the compiler with one switch. The compiler only looks at what comes before the #pragma hdrstop, builds a symbol table (and such) and puts the data into a .pch file.
Then comes the phase when you do a build using the pre-compiled header. In this phase, the compiler simply ignores everything in the the file up to the #pragma hdrstop. When it gets to that, it reads the compiler's internal state from the .pch file, and then starts compiling that individual file.
This means each source file typically includes a lot of headers it doesn't actually need. That, in turn, means that if you don't use pre-compiled headers, you end up with compilation that's much slower than if you hadn't done anything to support pre-compiled headers at all.
In other words, although the only part that's absolutely required is the #pragma hdrstop, which is fairly innocuous, a great deal more file re-structuring is needed to get much benefit from them--and those changes are likely to actively harmful to compilation time if you're using anything that doesn't support pre-compiled headers (and in the same way VC++ does them at that).
When precompiled headers is on every cpp source file must start with #include "stdafx.h"
So you would turn it off if you do not want to edit all the boost source files.
When precompiled headers is on stdafx.cpp "creates" the precompiled header. All other files "use" the precompiled header.
In our company sometimes we write .cpp and .h files, which are used in projects for old WM (we use Embedded Visual C++ 3.0 or something for this) and in more modern code (VS 2010).
This Embedded Visual C++ does not support STL.
So if one of developers, who works in VS2010, changes a file, which is shared, and adds some function, which uses std::vector, for instance, on his side everything will be OK, but the build (which is quite long) will fail.
So to see this mistake sooner, I would like to add something like
#if defined(%%STL%%)
#error("!!!!")
#endif
in all files, which are compiled with old toolset. In this case the developer could see compile time error even in VS2010.
But I could not find what I can put instead %%STL%% there.
Any ideas? Or maybe someone knows a better way how I can do this?
Based on a comment to the question, you could go through each of the header files that aren't supported and see what symbols they define for their include guard. Then check for those symbols being defined.
E.G. The Microsoft C++ header <algorithm> defines _ALGORITHM_ so you can check for that:
#ifdef _ALGORITHM_
#error("<algorithm> included")
#endif
A bunch of these could be collected up and put into a single header file that you could include in each shared source file, at the end.
There is quite a nice solution (at least I do not see pitfalls)
%%STL%% should be _STD_BEGIN
this macro is used for "namespace std {" in VS stl implementation
I'm working under Visual Studio 2008, maybe that's important.
In a larger project I decided to split one of my .cpp files into two. As I moved some of the functions to a new file, let's call it new.cpp, and tried to compile, I got errors that new.cpp doesn't know definitions of fstreams, setw(), etc. Now, at the very top of the new file I included my own header, let's call it main_header.h, which in turn includes all the necessary <iostream>, <iomanip>, etc. This works just fine all throughout older files used in this project, but for some reason doesn't in new.cpp.
If I add
#include <fstream>
#include <iomanip>
// and all the rest
in new.cpp then all works just fine, but that's not how I want to solve it.
I thought maybe content of main_header.h doesn't get appended to new.cpp on compilation, but that's not true, I tried using in new.cpp an external variable declared in main_header.h and defined in yet different .cpp, and got no errors on compilation, linking, or running. Yet it seems like <fstream> and <iomanip> included in main_header.h do not make it to new.cpp file.
I'm relatively new to Visual Studio, so the solution to my problem is likely something silly I'm not aware of, but I spent a good while trying to figure this one out and to no avail. The new file is definitely part of the project, since building projects attempts to compile it, plus once I include iostream and iomanip in this new.cpp I can call its routines in other parts of the project. Any ideas what I might be doing wrong?
main_header.h looks like that
#ifndef MAIN_HEADER
#define MAIN_HEADER
#include <iomanip>
#include <fstream>
// loads of other stuff
#endif // for MAIN_HEADER
Update: Ok, so the day after I created a whole new project using the same files and now all works fine, I don't need to include iomanip nor anything else in new.cpp. It sure as heck was to do with some oddities of VS not code itself, but still beats me what exactly was the issue.
This could be caused by prefix headers or precompiled headers, which can be set across the whole project, or could be set just on your new.cpp file, which might explain why there's some difference. Here's a few things to try:
Properties -> C++ -> Precompiled headers: check the setting for the whole project and for the individual files
Properties -> C++ -> Advanced -> Force includes: check this is the same for both
Open the vcproj file in a text editor and find the new.cpp node -- this is a quick way of finding if this individual file has different compiler settings
Properties -> C++ -> Preprocessor -> Generate Preprocessed file: this will generate an intermediate new.i file with all #includes and macros resolved. Compare the result of this for both files and look for the diffs -- this might show why one works and the other doesn't
Do you have another header somewhere that also has #define MAIN_HEADER?
It's an easy mistake to make when creating a new header by copying an old one, and leads to mysterious symptoms like this.
Problem
In CodeGear C++Builder 2009 we are using the pre-compiled header injection to greatly reduce our compile times. We have the same header file being injected into multiple projects. When compiling some projects, the compiler kicks out the following warning:
[BCC32 Warning] Dateutils.hpp(43): W8058 Cannot create pre-compiled header: initialized data in header
In this example, the Dateutils.hpp is the file it's complaining about (CodeGear's header). I've seen this happen with other headers as well. What makes this interesting is that this only happens with some projects (same header being injected).
In the past, I've had to just find the header who ultimately included this errant file and remove it from my pre-compiled header file. Does anyone know what's going on here and the best way to fix it?
Update
I ended up performing a process of elimination approach to the header file and came up with an interesting finding that I cannot explain. Out of the 50+ headers that get included, when I removed vcl.h I no longer get the W8058 warnings. I do not understand this as I would imagine that this header file in particular is a prime candidate for pre-compiliation. Can anyone explain that?
One thing that may be related is the way default string parameters are handled by BCB 200x.
Functions declared like this give the "can't generate precompiled header" message.
void myFunc(const AnsiString ¶m="");
However, change it to this, and the precompiled header can be generated.
void myFunc(const AnsiString ¶m = AnsiString(""));
In my experience, that warning message is misleading. It seems that the compiler identifies "candidates" where a header might have initialized data, then when it determines that the file is actually ok, it goes on. If it doesn't find another candidate, it won't show the message. If it finds another candidate that turns out to be a real problem, it then shows the message about the first candidate.
This makes identifying the real culprit extremely difficult.
There are VCL header files that have this known issue: QC 23002. The marked severity on this item though is a "minor failure."
So the workaround options are limited:
Not using those header files (which, yes, does defeat the idea)
Modify the header files (not advisable -- hard to track changes, keep them current).
Either way, make sure that of the ones you come across, CodeGear has knowledge of those header files having that issue. That will certainly be the best way to address it long term -- let the vendor fix their problem. Supposedly CodeGear has DateUtils.hpp in their internal tests for this, but that was posted (for QC 2781) in July 2007. If the problem or certain header files affect you considerably, contact them about it.
I get this warning message when the code shows:
#include <vcl.h>
#pragma hdrstop
I found a simple fix by swapping these lines to:
#pragma hdrstop
#include <vcl.h>
Warning no longer appears.