Sunday, November 1, 2009

Cannot open precompiled header file: 'Debug/.pch': No such file or directory

I am working on a Managed C++ project and I get the following error:

TestThread.cpp(3) : error C2859: c:\projects\ProjectName\debug\vc70.pdb
is not the pdb file that was used when this precompiled header was
created, recreate the precompiled header.

Why would I get this error? How do I rebuild the precompiled header?
Clean Solution, Rebuild Solution, don't help.

If I manually delete the vc70.pdb, it doesn't seem to recompile. I've
also tried manually compiling stdafx.cpp. I get:

fatal error C1083: Cannot open precompiled header file:
'Debug/ProjectName.pch': No such file or directory

Any help is appreciated.

Managed C++ gets more and more frustrating every day.

This should not be caused, I think, by your use of MC++. Seems like your
project settings got hosed somehow. First, try if you like to disable
precompiled headers (it's in the compiler options in the project settings).
See if that helps at first. If it does, then try setting your settings for
stdafx.cpp to "Create precompiled Header" (/Yc) with stdafx.h, and then set
the rest of the files to "Use Precompiled Header" (/Yu) with stdafx.h. See
if that helps

C2447: missing function header (old-style formal list?) blog

The following error messages may appear if you try to use the function-try-block syntax.
error C2143: syntax error : missing ';' before 'try'
error C2143: syntax error : missing ';' before 'try'
error C2065: 'ii' : undeclared identifier
error C2143: syntax error : missing ';' before 'try'
error C2448: 'Unknown' : function-style initializer appears to be a function definition
error C2143: syntax error : missing ';' before 'catch'
error C2143: syntax error : missing ';' before '{'
error C2447: missing function header (old-style formal list?)

Back to the top
CAUSEThe compiler does not support the function-try-block syntax as specified in the...The compiler does not support the function-try-block syntax as specified in the C++ Standard (section 15) quoted below:

-3- A function-try-block associates a handler-seq with the ctor-initializer, if present, and the function-body. An exception thrown during the execution of the initializer expressions in the ctor-initializer or during the execution of the function-body transfers control to a handler in a function-try-block in the same way as an exception thrown during the execution of a try-block transfers control to other handler.
Back to the top
STATUSMicrosoft has confirmed that this is a bug in the Microsoft products that are li...Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article.
Back to the top
MORE INFORMATIONSteps to Reproduce BehaviorThe following code example demonstrates the error: //...Steps to Reproduce Behavior
The following code example demonstrates the error:
//test.cpp
// compiler option needed: /GX
int f(int);
class C {
int i;
public:
C(int);
};

C::C(int ii)
try
: i(f(ii))
{
// constructor function body
}
catch (...)
{
// handles exceptions thrown from the ctor-initializer
// and from the constructor function body
}

C2065: '' : undeclared identifier blog

Today, I'm going to talk about decltype, which allows perfect forwarding functions to have arbitrary return types. It's of interest to people who are writing highly generic code.





the return type problem



C++98/03 has an interesting blind spot - given an expression like x * y, where x and y have arbitrary types, there's no way to say "the type of x * y". If x is of type Watts and y is of type Seconds, then x * y might be of type Joules. Given print(const T& t), you can call print(x * y), and T will be deduced to be Joules, but this doesn't work in reverse: when writing multiply(const A& a, const B& b), you can't name its return type while preserving full generality. Even though when multiply() is instantiated, the compiler knows the type of x * y, that information is unavailable to you here. The C++0x keyword decltype removes this blind spot, allowing you to say "multiply() returns the type of x * y". (decltype is an abbreviation of "declared type"; I pronounce it as rhyming with "speckle type".)





decltype: the pattern



Here's how to write a completely generic functor that wraps operator+(). This Plus functor is not a template, but it has a templated function call operator that takes two arguments of arbitrary (and possibly different) types, adds them together, and returns the result, which can be of arbitrary (and possibly different from both of the arguments) type.



C:\Temp>type plus.cpp

#include

#include

#include

#include

#include

#include

#include

using namespace std;



struct Plus {

template

auto operator()(T&& t, U&& u) const

-> decltype(forward(t) + forward(u)) {

return forward(t) + forward(u);

}

};



int main() {

vector i;

i.push_back(1);

i.push_back(2);

i.push_back(3);



vector j;

j.push_back(40);

j.push_back(50);

j.push_back(60);



vector k;



vector s;

s.push_back("cut");

s.push_back("flu");

s.push_back("kit");



vector t;

t.push_back("e");

t.push_back("ffy");

t.push_back("tens");



vector u;



transform(i.begin(), i.end(), j.begin(), back_inserter(k), Plus());

transform(s.begin(), s.end(), t.begin(), back_inserter(u), Plus());



for_each(k.begin(), k.end(), [](int n) { cout << n << " "; });

cout << endl;



for_each(u.begin(), u.end(), [](const string& r) { cout << r << " "; });

cout << endl;

}



C:\Temp>cl /EHsc /nologo /W4 plus.cpp

plus.cpp



C:\Temp>plus

41 52 63

cute fluffy kittens



Compare this to C++98/03 's std::plus (which is unchanged in C++0x). Because it's a class template, you'd have to pass plus() and plus(), repeating the element types. Its non-templated function call operator has the form T operator()(const T& x, const T& y) const, making it unable to deal with 2 different types, much less 3 different types, without resorting to implicit conversions. (You can feed plus() a string and a const char *. That will construct a temporary string from the second argument, before concatenating the two strings. The performance of this is not especially desirable.) Finally, because it takes const T&, it can't take advantage of C++0x move semantics. Plus avoids all of this: Plus() doesn't repeat the element type, it deals with the "3 different types" case, and because it uses perfect forwarding, it respects move semantics.





trailing return types



Now, let's look at that templated function call operator again:



template

auto operator()(T&& t, U&& u) const

-> decltype(forward(t) + forward(u)) {

return forward(t) + forward(u);

}



Here, auto has a different meaning from for (auto i = v.begin(); i != v.end(); ++i), where it says "make the type of this thing the same as the type of whatever initializes it". When used as a return type, auto says "this function has a trailing-return-type; after I declare its parameters, I'll tell you what its return type is". (The C++0x Working Draft N2857 calls this a late-specified return type, but this is being renamed to trailing-return-type; see paper N2859.) If this seems suspiciously similar to how lambdas are given explicit return types, that's because it is. A lambda's return type has to go on the right in order for its lambda-introducer [] to appear first. Here, the decltype-powered return type has to go on the right in order for the function parameters t and u to be declared first. Where the auto appears on the left, the template parameters T and U are visible, but the function parameters t and u are not yet visible, and that's what decltype needs. (Technically, decltype(forward(*static_cast(0)) + forward(*static_cast(0))) could go on the left, but that's an abomination.)



As for the expression given to decltype, giving it the same expression as the return statement ensures correctness in all cases. (Pop quiz: why would decltype(t + u) be wrong?) The repetition here is unavoidable but centralized - it appears exactly once, on adjacent lines, so it is not dangerous.





another example



For completeness, here's that "3 different types" example:



C:\Temp>type mult.cpp

#include

#include

#include

#include

#include

#include

using namespace std;



struct Multiplies {

template

auto operator()(T&& t, U&& u) const

-> decltype(forward(t) * forward(u)) {

return forward(t) * forward(u);

}

};



class Watts {

public:

explicit Watts(const int n) : m_n(n) { }

int get() const { return m_n; }

private:

int m_n;

};



class Seconds {

public:

explicit Seconds(const int n) : m_n(n) { }

int get() const { return m_n; }

private:

int m_n;

};



class Joules {

public:

explicit Joules(const int n) : m_n(n) { }

int get() const { return m_n; }

private:

int m_n;

};



Joules operator*(const Watts& w, const Seconds& s) {

return Joules(w.get() * s.get());

}



int main() {

vector w;

w.push_back(Watts(2));

w.push_back(Watts(3));

w.push_back(Watts(4));



vector s;

s.push_back(Seconds(5));

s.push_back(Seconds(6));

s.push_back(Seconds(7));



vector j;



transform(w.begin(), w.end(), s.begin(), back_inserter(j), Multiplies());



for_each(j.begin(), j.end(), [](const Joules& r) { cout << r.get() << endl; });

}



C:\Temp>cl /EHsc /nologo /W4 mult.cpp

mult.cpp



C:\Temp>mult

10

18

28



You might ask, "is all of this generality really necessary?" The answer is yes, yes it is. I've already mentioned how perfect forwarding and decltype make arithmetic operation functors easier to use (by removing the need to repeat element types), more flexible (by dealing with mixed argument and return types), and more efficient (by respecting move semantics). Essentially, perfect forwarding and decltype allow you to write more "transparent" code. Inflexible code and inefficient code are not transparent - their presence can't be ignored.





advanced rules



decltype is powered by several rules. However, if you stick to the pattern above, they don't matter and it just works. I rarely get to say that about C++, but it's true in this case.



Although the vast majority of decltype uses will follow the pattern above, decltype can be used in other contexts. In that case, you've activated expert mode, and you should read the rules in their entirety. In the C++0x Working Draft N2857, they're given by 7.1.6.2 [dcl.type.simple]/4.





but wait, there's more



decltype is the fifth and final C++0x Core Language feature being added to VC10. While it wasn't in the VC10 CTP, it's in VC10 Beta 1. Also in VC10 Beta 1 are many C++0x Standard Library features, which I'll be blogging about soon!

fatal error C1010 - unexpected end of file while looking for precompiled header directive

Once when i was trying to compile a program with Visual C++ .NET (dot-net) which was originally written for the Apple Macintosh for Objective-C. I keep getting the following error message:

"fatal error C1010 - unexpected end of file while looking for precompiled header directive"

I looked into the header file but cannot find anything to be missing.


Actually the answer was simple i solved it by the following way

MFC programs use many libraries, requiring the use of many header files. To save time, the compiler tries to precompile most of these header files, and use the predigested data instead of reading through all of these header files on every compilation. There are a number of ways to do this. The standard method for MFC programs is to lump all of these common header file references into one header file ("stdafx.h"). If you just have to ask what "stdafx" means, it comes from the early name of MFC, which was AFX (application framework).

When compiling each source (.cpp) file, the compiler skips through the source code, looking for the directive:


#include "stdafx.h"


Once it finds this directive, it substitutes the precompiled header information and then begins compiling the rest of the file. If your source file doesn't contain this directive, you get the C1010 error described above.

The simple solution is to insert the include directive to your source file, before any other library references or other code.