Nested class accessing it's parent...

I have a class, which defines a new nested class as well as a single member of that class.
This nested class has an operator that needs access to the parent.

The nested class won't be used outside of these confines. (I can even prevent this by making the class definition private).

What is the "clean" way to make this nested class access it's parent ?

Code:

---

struct X
{
private: // Make Y unaccessible for anything but X.
        struct Y
        {
                int operator()() const
                {
                        return yy * x; // This doesn't compile as it is shown here.
                }
                int yy;
        };

public: // Data members are public.
        int                x;
        Y                y;
        double        x2;
};

// In the rest of the code it would be accessed as:
static const X x = { 2, 4, 1.24 };  // Both X and X::Y need to be aggregate (by contract)
int test = x.y();        // should return 8. with above sample.

---

I can solve it with some messy casting, but I was wondering if there is a cleaner way to do this than:

Code:

---

int operator()() const
{
        const X* dummy = (X*)NULL;
        const X* px = (X*)((char*)this - (char*)&dummy->y);
                       
        return yy * px->x;
}

---

Can you change Y's operator() to take an X argument?

Unfortunately... no. The whole "trick" about getting this to work is that the X::Y class is part of a rather elaborate template system and the deeper innards of the templates and up calling this without parameters. The deeper stuff doesn't even know about 'X' anymore.

Hmm... the thing is, like any other member variable, y does not have any way to access the object of the enclosing class unless you provide for it, e.g., when constructing y or as an argument to the member function of y. Therefore, it seems to me that what you are asking for cannot be done, at least not safely (your "messy casting" hack is of course brittle).

I use inner classes quite often to encapsulate implementation. In Java it's no problem because the inner class has access to the outer class. In C++ I emulate this situation by passing in the this pointer of the outer class to the inner class upon construction. That's how it must be implemented in Java in principle so I consider it clean.

With your requirement that X and Y are aggregate there can be no constructors so this must be passed in differently but the result is the same, the inner class holds a pointer to its enclosure,

Code:

---

struct X {
private: // Make Y unaccessible for anything but X.
        struct Y {
                int operator()() const {
                        return yy * enclosure->x; // compiles.
                }
                int yy;
                const X* enclosure;
        };

public: // Data members are public.
        int        x;
        Y        y;
        double        x2;
};

void test() {
        static const X x = { 2, 4, &x, 1.24 };  // Both X and X::Y need to be aggregate (by contract)
        int test = x.y();        // should return 8. with above  sample
        std::cout << test << std::endl; // is 8 indeed
}

---

What about making Y a friend of X?

Code:

---

struct X
    {
    struct Y
        {
        /*
        ...
      */
        };

    friend Y;
    /*
    ...
    /
    };


    };

---

Quote:

---

Originally Posted by greve

What about making Y a friend of X?

---

No use: Y can already access the non-public members of X, and the members of X that matter are already public. The problem is that Y's operator() needs to work with the X object somehow.

Quote:

---

Originally Posted by OReubens

I can solve it with some messy casting, but I was wondering if there is a cleaner way to do this than:

Code:

---

int operator()() const
{
        const X* dummy = (X*)NULL;
        const X* px = (X*)((char*)this - (char*)&dummy->y);
                       
        return yy * px->x;
}

---

---

Instead of the "messy casting" you can just use the offsetof macro. It is only guaranteed to work on POD types, but many compilers support it correctly with non-POD types as well.
If you want full portability, you'll need to store a pointer to the class in Y.

Looks like I'm stuck with the messy casting then...
The enclosure solution nuzzle posted, while interesting, isn't possible because I cannot require the changes in the data layout. In fact part of the reason of needing the nested class to access it's parent was to avoid duplication of data.