tags:

views:

78

answers:

3

Is the following code legal in C++. Accessing a friend class member public method? I know this sounds confusing, and the best way to show it is in code. I was wondering if the TestClassC::Method() is valid in the code below?

I've compiled (g++) and it works, however, I run into a situation, where it produces a segmentation fault on other machine/distros at TestClassC::Method(). Which is making me wonder if this->classA_Ptr->classB.Method(); is legal in C++.

#include <iostream>

using namespace std;

class TestClassB
{
   public:
      TestClassB(void){};
      ~TestClassB(void){};
      void Method(void){
         cout << "Hello Again" << endl;
      }
};


class TestClassC; //Forward Declaration
class TestClassA
{
   friend class TestClassC;

   public:
      TestClassA(void){};
      ~TestClassA(void){};

   private:
      TestClassB  classB;
};


class TestClassC
{
   public:
      TestClassC(TestClassA* a_Ptr){
         this->classA_Ptr = a_Ptr;
      }
      ~TestClassC(void){};

      void Method(void){
         //Is this Valid/Legal ???
         this->classA_Ptr->classB.Method();
      }

   private:
      TestClassA*  classA_Ptr;
};



int main()
{
    cout << "Hello world!" << endl;

    TestClassA testClassA;
    TestClassC classC(&testClassA);

    classC.Method();

    return 0;
}
+1  A: 

Calling public methods of any class is valid/legal as long as the class is unambiguously accessible, and we have a valid object expression to access it. In fact that's why it was made public in the first place. Your code looks to be fine to me.

Chubsdad
+2  A: 

Yes. The friend specification gives TestClassC access to any protected or private members of TestClassA. So that means it gets access to the classB member. After that, normal rules apply to what TestClassC can do with that member. And since Method() is public TestClassC is allowed to call it, just as if it had gotten ahold of a TestClassB instance through any other means.


Regarding the seg fault:

Public/protected/private/friend are all compile-time restrictions. They should have no affect on the operation of the code at runtime.

Is it this exact code that seg faults? Or is it just something similar in concept? If it's not the exact same code, then have you verified that all the pointers are actually valid in the problematic code?

TheUndeadFish
The code is something similar, but the concept is the same. I just wanted to make sure it was valid because I was unsure. I think Michael has it correct. There is got to be something due to illegal memory address. I'm doing a DMA call earlier, it must be affecting something shortly after, and just happens to segfaults at the line I was referring too. Since the code is running on an embedded board, I don't have access to a good debugger like gdb, and can only rely on using a whole bunch of cout to narrow the offending code.
Dennis Miller
+4  A: 

The public/private/protected accessor modifiers are enforced at compile-time, not at runtime. The SEGFAULT is a runtime error, not a compile-time error. So, in the future, if you get a SEGFAULT, you can be sure that it is not related to the level of access. It sounds like your confusion is based on whether the access modifiers are applied directly, indirectly, transitively, etc. The access modifiers work in the most simple and straight-forward way: they apply only directly, to the functions or variables that have been declared in that class and control access through the given class to those items. Once you have access to such an item, further access is determined purely by that item's own access modifiers.

A SEGFAULT is typically indicative of an illegal memory access. If you experience SEGFAULTS, look at where you dereference pointers (whenever you have *X or X->Y). Common causes of SEGFAULTS include dereferencing NULL, off-by-one array access, and using an object through a pointer where the object in question has already been deleted by going out of scope.

Michael Aaron Safyan