Question regarding conversion operators

efn .. thank you for your illuminating comments. However I have been trying a few test programs and they have added to my confusion. In order to learn more about pointer to members I tried out the following program:

struct C {  int i; };

int C::* f1()  {  return &C::i;  }

int C::* f2()  {  return 0;  }

int main() {
    int C::* mp1 = f1();
    int C::* mp2 = f2();
    int value_mp1 = *(( int * )&mp1);
    int value_mp2 = *(( int * )&mp2);
    printf("%x %x\n", value_mp1, value_mp2 );
    if( f1() ) printf("f1 return value valid\n");
    else printf("f1 return value invalid\n");
    if( f2() ) printf("f2 return value valid\n");
    else printf("f2 return value invalid\n");
}

Let me explain ... I first tried to print the value of mp1 and mp2 using printf("\x") but that was not allowed. So I had to resort yo some pointer wizardry in order to peek at the values being returned by the f1() and f2(). Now the outfup that I get is:

0 ffffffff
f1 return value is valid
f2 return value is invalid

!!

If anything I would have expected the output to be non-zero, zero instead of the opposite. Also given that the value returned by f1 is 0 how come the output says that the f1 return value is valid??

I am using MS VS.NET C++ compiler and haven't yet tested the code on gcc.

Hi Priyendra,

The only problem is your assumption that the compiler will represent a null member pointer with a binary value of zero.  In fact, it is not required to do so, and the compiler with which you tested does not do so.  Note that the if statements are working correctly.  The compiler implementation apparently uses a value of -1 to represent a null member pointer.

I compiled a test program with Visual C++ 6.0 using a class similar to the Ptr class you posted before.

      Ptr<int> p;
      if (p)

I looked at the disassembly and sure enough, the implementation of the if condition test compared the member pointer value to -1:

33:       if (p)
0040D442   lea         ecx,[ebp-4]
0040D445   call        @ILT+20(Ptr<int>::operator int Ptr<int>::PointerConversion::*) (00401019)
0040D44A   cmp         eax,0FFFFFFFFh
0040D44D   je          main+41h (0040d451)

Although perhaps confusing to those who peer behind the scenes, this is actually a reasonable implementation decision.  A member pointer is effectively an offset into the data of an object, so it will be convenient and efficient to use an offset of zero for the first data element.  If the compiler implementer chooses to do this, he then needs to define some other magical value to serve as the null member pointer value denoted by 0 in the source code, and -1 (or unsigned 4294967295) is an offset that is unlikely to be needed in any real object.

--efn