[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

What's the standard say about this code?

Daniel T.

9/30/2008 3:41:00 PM

#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...
8 Answers

Maxim Yegorushkin

9/30/2008 3:53:00 PM

0

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

Daniel T.

9/30/2008 4:21:00 PM

0

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.

James Kanze

10/1/2008 8:56:00 AM

0

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

Daniel T.

10/1/2008 10:50:00 AM

0

James Kanze <james.kanze@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.

(For those who may be interested in tracking these things, I'm using
CodeWarrior Development Studio for NintendoDS.)

Triple-DES

10/1/2008 11:50:00 AM

0

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)

Maxim Yegorushkin

10/1/2008 3:12:00 PM

0

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

Erik Wikström

10/1/2008 5:14:00 PM

0

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

Triple-DES

10/2/2008 5:26:00 AM

0

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