Does anyone know of a way to suppress compiler error c3867 (Pointer-to-member now require qualified name and &) in visual C++ 2005 I am trying to convert multiple projects from visual C++ 2003 to 2005. I know this was listed as one of the breaking changes made to the 2005 compiler. I get this error hundreds of times....
Any help or suggestions is greatly appreciated, thanks!

Breaking changes in the Visual C++ 2005 Compiler
Mrrenzo
I believe you're going to have to bite the bullet and fix each instance. What you had before was non-standard C++, and in most (or all ) cases, there is no way to tell the compiler to not be C++ conformant.
jebz171339
cgian31
Does anybody know of a way to automatically change the errors
I've got about 500 or so of them to do in my project and some automation would be very nice.
Thanks!
-Brian
PriyaM
Ok, thanks.
I didn't know if there was some obscure function that might be able to convert all of them. (Seeing as they tell me what the code should be, I thought they might include something.)
Thanks anway. Now I just have to get motivated to actually do it. *shudders*
- Brian
kalinkula
The problem is that without the explicit '&' the compiler cannot tell exactly what you mean. When we changed this and dropped it to some of our internal users they found some code like below in a large application that I won't name.
class X {
public:
static Something* smf();
};
// ...
void f() {
if (X::smf != NULL) {
// ...
}
else {
DoSomethingImportant();
}
}
The compiler was interrepting 'X::mf' as '&X::mf' while instead the user had meant the code to be 'X::mf()'. So while this breaking change may be a pain to fix in the long run it really is right thing to do.
Jiongxiong Chen
500 can be done in several hours work. I've gone through about that amount myself.
I doubt someone has automated this: it's a one-time circumstance, and if it's automatable, it's easy to do by hand. If it requires careful consideration, then you wouldn't want automation in the first place.
ostsee