What's the standard say about this code?
 

#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? 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...

Re: What's the standard say about this code?
 

On Sep 30, 4:40*pm, "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? 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...

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

Re: What's the standard say about this code?
 

On Sep 30, 11:53*am, Maxim Yegorushkin <maxim.yegorush...@gmail.com>
wrote:
> On Sep 30, 4:40*pm, "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? 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...
>
> 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().

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.

Re: What's the standard say about this code?
 

On Sep 30, 5:40 pm, "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.)

--
James Kanze (GABI Software) email:james.kanze@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

Re: What's the standard say about this code?
 

On 1 Okt, 12:50, "Daniel T." <danie...@earthlink.net> wrote:
> 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)

Re: What's the standard say about this code?
 

On Oct 1, 12:49*pm, Triple-DES <DenPlettf...@gmail.com> wrote:
> On 1 Okt, 12:50, "Daniel T." <danie...@earthlink.net> wrote:
>
>
>
> > 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.

In the original question a member function pointer gets converted to
bool. Is 4.11/1 applicable here?

--
Max

Re: What's the standard say about this code?
 

On 2008-10-01 17:11, Maxim Yegorushkin wrote:
> On Oct 1, 12:49 pm, Triple-DES <DenPlettf...@gmail.com> wrote:
>> On 1 Okt, 12:50, "Daniel T." <danie...@earthlink.net> wrote:
>>
>>
>>
>> > 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.
>
> In the original question a member function pointer gets converted to
> bool. Is 4.11/1 applicable here?

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

Re: What's the standard say about this code?
 

On 1 Okt, 19:14, Erik Wikström <Erik-wikst...@telia.com> wrote:
> On 2008-10-01 17:11, Maxim Yegorushkin wrote:
>
>
>
>
>
> > On Oct 1, 12:49 pm, Triple-DES <DenPlettf...@gmail.com> wrote:
> >> On 1 Okt, 12:50, "Daniel T." <danie...@earthlink.net> wrote:
>
> >> > 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.
>
> > In the original question a member function pointer gets converted to
> > bool. Is 4.11/1 applicable here?
>
> 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."
>

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