I think this might be a compiler bug, what do you think?

I think this might be a compiler bug, what do you think?

Post by Katherine » Sun, 09 Nov 2003 11:36:20



Lately I've developed a new stupid programmer's trick of leaving out
parentheses when referencing class methods, for instance, instead of
GetRepeatType() I'll type GetRepeatType. Usually the compiler will scream
*** y blue blazes about this grevious error, but if you do that within an
if statement in a method within the same class the compiler will accept it
without a peep. Below is a really small class that reproduces the behavior
on my system - the offending statement is inside TestMethod, at the bottom
of the post. Do y'all think this is a bug in the compiler, and if so, how
do I report it?


Thanks,

Katherine


Foo.h:

//////////////////////////////////////////
#pragma once

// Foo command target

class Foo
{
public:
Foo();
virtual ~Foo();
void TestMethod();
int GetRepeatType();

protected:
int m_Repeat;

};

///////////////////////////////////////////////////////////


Foo.cpp:
//////////////////////////////////////////////////////////

// Foo.cpp : implementation file
//

#include "StdAfx.h"
#include "Foo.h"


Foo::Foo()
{
}

Foo::~Foo()
{
}


// Foo member functions


int Foo::GetRepeatType()
{
return 1;
}


void Foo::TestMethod()
{
// should generate a warning or error, but doesn't
if (GetRepeatType == 0 ) {
int x = 0;
}

}

////////////////////////////////////////////////////////////////////////////
/////////
 
 
 

I think this might be a compiler bug, what do you think?

Post by Joseph M. » Sun, 09 Nov 2003 13:11:20

The compiler accepts it because it is legal C/C++ code. This is not a bug; this is how the
language is DEFINED to behave. It compares the address of the function to the constant 0,
and returns TRUE, because the address of the function is nonzero. What would you expect it
to do? You wrote a perfectly syntactically correct (although semantically nonsensical,
relative to what you expected) statement! In fact, if the compiler gave an error message,
it would be an incorrectly-implemented compiler. THAT would be a compiler bug!
joe




Joseph M. Newcomer [MVP]
email: XXXX@XXXXX.COM
Web: http://www.yqcomputer.com/
MVP Tips: http://www.yqcomputer.com/

 
 
 

I think this might be a compiler bug, what do you think?

Post by Alexander » Sun, 09 Nov 2003 14:09:28

ctually, member function name alone doesn't make a pointer in ANSI C++. An
ampersand and a fully qualified name is required, like
&Foo::GetRepeatType. But MS compiler relaxes this restriction (I don't
really understand what is rationale behind it). So this code example is not
valid ANSI C++.

For non-member functions, the compiler usually gives a warning when a
function name is used in context where a call would be more appropriate.

"Joseph M. Newcomer" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
this is how the
the constant 0,
would you expect it
nonsensical,
error message,
bug!
< XXXX@XXXXX.COM > wrote:
scream
an
it
behavior
bottom
how
/


 
 
 

I think this might be a compiler bug, what do you think?

Post by Doug Harri » Sun, 09 Nov 2003 14:22:16

oseph M. Newcomer wrote:


Whether or not it's a bug really depends on your point of view. See below
for details.


Uh, it can't be legal C code, because it uses various features of classes.
:)


Actually, this is a language extension, albeit an error-prone one. In
Standard C++, a non-static member function name has no meaning when used as
above. It's not like a static member function or non-member function, for
which the name decays into a pointer to the function. The only way to form a
pointer to non-static member function in Standard C++ is with the syntax:

&Foo::GetRepeatType

If you compile with -Za, VC7.1 detects the error and emits:

b.cpp(38) : error C2475: 'Foo::GetRepeatType' : forming a pointer-to-member
requires explicit use of the address-of operator ('&') and a qualified name
b.cpp(38) : warning C4253: 'Foo::GetRepeatType' : forming a
pointer-to-member requires explicit use of the address-of operator ('&') and
a qualified name
b.cpp(38) : error C2475: 'Foo::GetRepeatType' : forming a pointer-to-member
requires explicit use of the address-of operator ('&') and a qualified name
b.cpp(38) : warning C4253: 'Foo::GetRepeatType' : forming a
pointer-to-member requires explicit use of the address-of operator ('&') and
a qualified name

As you can see, under -Za, the compiler really, really hates this code. :)
It allows it without -Za to avoid invalidating existing code, including all
MFC message maps, most every line of which relies on the extension.
Actually, I guess they could compromise and reject the OP's code but allow
the incorrect syntax for bare member function names used as the source
operand in cast expressions. That would allow MFC message maps to compile
unchanged, while still detecting most cases of forgetting the argument list.

--
Doug Harrison
Microsoft MVP - Visual C++
 
 
 

I think this might be a compiler bug, what do you think?

Post by Joseph M. » Mon, 10 Nov 2003 01:54:05

ou're right: I missed the fact that this was a nonstatic member function. The VS7
compiler is much more uptight about compliance (and it's about time!).
joe

On Fri, 07 Nov 2003 23:22:16 -0600, "Doug Harrison [MVP]" < XXXX@XXXXX.COM > wrote:


Joseph M. Newcomer [MVP]
email: XXXX@XXXXX.COM
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
 
 
 

I think this might be a compiler bug, what do you think?

Post by Doug Harri » Mon, 10 Nov 2003 05:29:38


But VC7 is not usefully more uptight on this particular issue. For it to
complain, you have to use /Za, which is incompatible with <windows.h> and
/clr. Things are ever so slightly better in this area on Whidbey, but it
still doesn't detect the OP's problem, which I've gone ahead and reported.

--
Doug Harrison
Microsoft MVP - Visual C++