Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > What's the standard say about this code?

Reply
Thread Tools

What's the standard say about this code?

 
 
Daniel T.
Guest
Posts: n/a
 
      09-30-2008
#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...

 
Reply With Quote
 
 
 
 
Maxim Yegorushkin
Guest
Posts: n/a
 
      09-30-2008
On Sep 30, 4:40*pm, "Daniel T." <(E-Mail Removed)> 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



 
Reply With Quote
 
 
 
 
Daniel T.
Guest
Posts: n/a
 
      09-30-2008
On Sep 30, 11:53*am, Maxim Yegorushkin <(E-Mail Removed)>
wrote:
> On Sep 30, 4:40*pm, "Daniel T." <(E-Mail Removed)> 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.

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      10-01-2008
On Sep 30, 5:40 pm, "Daniel T." <(E-Mail Removed)> 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:(E-Mail Removed)
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

 
Reply With Quote
 
Triple-DES
Guest
Posts: n/a
 
      10-01-2008
On 1 Okt, 12:50, "Daniel T." <(E-Mail Removed)> wrote:
> James Kanze <(E-Mail Removed)> wrote:
> > "Daniel T." <(E-Mail Removed)> 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)

 
Reply With Quote
 
Maxim Yegorushkin
Guest
Posts: n/a
 
      10-01-2008
On Oct 1, 12:49*pm, Triple-DES <(E-Mail Removed)> wrote:
> On 1 Okt, 12:50, "Daniel T." <(E-Mail Removed)> wrote:
>
>
>
> > James Kanze <(E-Mail Removed)> wrote:
> > > "Daniel T." <(E-Mail Removed)> 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
 
Reply With Quote
 
Erik Wikström
Guest
Posts: n/a
 
      10-01-2008
On 2008-10-01 17:11, Maxim Yegorushkin wrote:
> On Oct 1, 12:49 pm, Triple-DES <(E-Mail Removed)> wrote:
>> On 1 Okt, 12:50, "Daniel T." <(E-Mail Removed)> wrote:
>>
>>
>>
>> > James Kanze <(E-Mail Removed)> wrote:
>> > > "Daniel T." <(E-Mail Removed)> 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
 
Reply With Quote
 
Triple-DES
Guest
Posts: n/a
 
      10-02-2008
On 1 Okt, 19:14, Erik Wikström <(E-Mail Removed)> wrote:
> On 2008-10-01 17:11, Maxim Yegorushkin wrote:
>
>
>
>
>
> > On Oct 1, 12:49 pm, Triple-DES <(E-Mail Removed)> wrote:
> >> On 1 Okt, 12:50, "Daniel T." <(E-Mail Removed)> wrote:

>
> >> > James Kanze <(E-Mail Removed)> wrote:
> >> > > "Daniel T." <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
You Say “Fragmentation”, I Say “Differentiation” Lawrence D'Oliveiro NZ Computing 2 10-06-2010 04:44 AM
You say SIM, I say SEM Anon Computer Security 1 03-18-2006 01:49 PM
What does the standard say about this Xenos C++ 1 07-10-2004 03:48 PM
Integer value wraparound -- what does the C++ standard say? Dave Rahardja C++ 5 07-18-2003 06:46 PM
what does the standard say about parameter passing? Tobias Oed C Programming 11 06-30-2003 02:05 PM



Advertisments