What's the standard say about this code?
Daniel T.
class Foo {
public:
virtual void fnA() = 0;
virtual void fnB() = 0;
};
int main() {
assert( &Foo::fnB );
assert( &Foo::fnA );
}
What does the standard say about the above code? In the compiler I'm
using now, the first assert will not fire, but the second one will. I
expected that neither assert would fire...
Maxim Yegorushkin
Are you sure that the second assert is failing?
Both &Foo::fnB and &Foo::fnA should yield a non-NULL member function
pointer, which gets converted to bool(true) when passed into assert().
--
Max
Daniel T.
wrote:
Yes, I am sure that the second assert is failing. If this is a
compiler bug, then I will submit it to the vendor, but I want to make
sure it actually *is* a compiler bug first.
James Kanze
> #include <cassert>
> class Foo {
> public:
> virtual void fnA() = 0;
> virtual void fnB() = 0;
> };
> int main() {
> assert( &Foo::fnB );
> assert( &Foo::fnA );
> }
> What does the standard say about the above code?
There should be no problem with it.
> In the compiler I'm using now, the first assert will not fire,
> but the second one will. I expected that neither assert would
> fire...
It's guaranteed by the standard. It works with the three
compilers I have access to (Sun CC, g++ and VC++), at least when
you compile in standard conformant mode. (Note that by default,
pointers to member functions do not work in VC++. You must use
the option /vmg. Not that I think that their non-conformity
otherwise would play a role here.)
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Daniel T.
> > #include <cassert>
>
> > class Foo {
> > public:
> > virtual void fnA() = 0;
> > virtual void fnB() = 0;
> > };
>
> > int main() {
> > assert( &Foo::fnB );
> > assert( &Foo::fnA );
> > }
>
> > What does the standard say about the above code?
>
> There should be no problem with it.
>
> > In the compiler I'm using now, the first assert will not fire,
> > but the second one will. I expected that neither assert would
> > fire...
>
> It's guaranteed by the standard. It works with the three
> compilers I have access to (Sun CC, g++ and VC++), at least when
> you compile in standard conformant mode. (Note that by default,
> pointers to member functions do not work in VC++. You must use
> the option /vmg. Not that I think that their non-conformity
> otherwise would play a role here.)
Can I get chapter and verse from the standard on this? It sounds like I
need to submit a bug report to the compiler vender.
(For those who may be interested in tracking these things, I'm using
CodeWarrior Development Studio for NintendoDS.)
Triple-DES
> James Kanze <james.ka...@gmail.com> wrote:
> > "Daniel T." <danie...@earthlink.net> wrote:
> > > #include <cassert>
>
> > > class Foo {
> > > public:
> > > virtual void fnA() = 0;
> > > virtual void fnB() = 0;
> > > };
>
> > > int main() {
> > > assert( &Foo::fnB );
> > > assert( &Foo::fnA );
> > > }
>
> > > What does the standard say about the above code?
>
> > There should be no problem with it.
>
> > > In the compiler I'm using now, the first assert will not fire,
> > > but the second one will. I expected that neither assert would
> > > fire...
>
> > It's guaranteed by the standard. It works with the three
> > compilers I have access to (Sun CC, g++ and VC++), at least when
> > you compile in standard conformant mode. (Note that by default,
> > pointers to member functions do not work in VC++. You must use
> > the option /vmg. Not that I think that their non-conformity
> > otherwise would play a role here.)
>
> Can I get chapter and verse from the standard on this? It sounds like I
> need to submit a bug report to the compiler vender.
I believe it is disallowed by 4.11/1 [conv.mem]:
"A null pointer constant (4.10) can be converted to a pointer to
member type; the result is the null member pointer value of that type
and is distinguishable from any pointer to member not created from a
null pointer constant.(...)"
Therefore, an rvalue obtained by using address-of on a member shall
not yield a null pointer constant.
> (For those who may be interested in tracking these things, I'm using
> CodeWarrior Development Studio for NintendoDS)
Maxim Yegorushkin
In the original question a member function pointer gets converted to
bool. Is 4.11/1 applicable here?
--
Max
Erik Wikström
No, 4.12 is probably the correct section:
"An rvalue of arithmetic, enumeration, pointer, or pointer to member
type can be converted to an rvalue of type bool. A zero value, null
pointer value, or null member pointer value is converted to false; any
other value is converted to true."
--
Erik Wikström
Triple-DES
Of course, but the problem is that taking the address of a function
yields a null member pointer value, not the fact that it is
subsequently converted to false. The OP might as well have written:
assert( &Foo::fnB != 0);
assert( &Foo::fnA != 0);
And 4.12 would be completely irrelevant, but the result of the second
assert would still violate 4.11/1
DP