Accessing private methods of nested classes

[earthwormgaz]

Is the following legal?

class Outer
{
class Inner
{
private:
Inner() { }
};

Outer()
{
Inner inner;
}
};

Should people trying to do something similar be using the friend
keyword?

[mlimber]

earthwormgaz wrote:

Is the following legal?

class Outer
{
class Inner
{
private:
Inner() { }
};

Outer()
{
Inner inner;
}
};

Should people trying to do something similar be using the friend
keyword?

No, and yes (or a virtual constructor or similar).

Cheers! --M

[Victor Bazarov]

earthwormgaz wrote:

Is the following legal?

class Outer
{
class Inner
{
private:
Inner() { }
};

Outer()
{
Inner inner;
}
};

Should people trying to do something similar be using the friend
keyword?

I am not sure it's legal. I would be if the situation were reversed,
i.e. 'Inner' tried accessing 'Outer's private members. Yes, using
'friend' is the simplest work-around.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[earthwormgaz]

mlimber wrote:

No, and yes (or a virtual constructor or similar).

Well, maybe its better to consider this, I mean any old method, not
just constructors et etcetera.

class Outer
{
class Inner
{
private:
void Method();
};

Outer()
{
Inner inner;
inner.Method(); // is this legal?
}
};

For the record, VC++ 2005/8.0 says yes, Metrowerks says no, g++ 3.4.4
says no.

[Emmanuel Deloget]

Victor Bazarov a écrit :

earthwormgaz wrote:

Is the following legal?

class Outer
{
class Inner
{
private:
Inner() { }
};

Outer()
{
Inner inner;
}
};

Should people trying to do something similar be using the friend
keyword?

I am not sure it's legal. I would be if the situation were reversed,
i.e. 'Inner' tried accessing 'Outer's private members. Yes, using
'friend' is the simplest work-around.

It's definitely not legal - accessing a private member that is not
yours is not legal C++, even if you "own" the class. That's the whole
principle of encapsulation using an access control mechanism.

There is also no point on making Inner private members public to Outer
using the friend keyword. If Inner is supposed to be hidden from any
class but Outer (ie Inner is defined as private in Outer), just define
Inner members as public. However, I strongly advise you to avoid doing
so, as there is also no point in putting a bunch of public members in a
inner class so that they can be accessed only by the owner - just add
private members to your Outer class then. If you want to create an
inner class that actually have some added value, think about it twice:
what should it expose, and how should it expose it? Remember that an
inner class is just another class, which happens to have a particular
semantic in the sense that it is strongly tied to its Outer class. It
is subject to the same design principles as all the other classes.

Regards,

-- Emmanuel Deloget, Artware

[earthwormgaz]

Emmanuel Deloget wrote:

There is also no point on making Inner private members public to Outer
using the friend keyword. If Inner is supposed to be hidden from any

class Outer
{
public: // I presume this changes everything?
class Inner
{
private:
void Method();
};

Outer()
{
Inner inner;
inner.Method(); // is this legal?
}

};

That is actually a better representation of what I have come across. It
is something somebody has done in VC++ code, and its knackered me in a
porting effort.

It appears as though I am within my rights to tell them they shouldn't
have made the method in question in the Inner class private.

[Emmanuel Deloget]

earthwormgaz a écrit :

Emmanuel Deloget wrote:

There is also no point on making Inner private members public to Outer
using the friend keyword. If Inner is supposed to be hidden from any

class Outer
{
public: // I presume this changes everything?
class Inner
{
private:
void Method();
};

Outer()
{
Inner inner;
inner.Method(); // is this legal?
}

};

No, it doesn't change anything - Method() is still a private method of
Outer::Inner, and as such is only acessible from Outer::Inner, friend
classes and friend functions of Outer::Inner. It does change something
in the design of the application, as Inner is now accessible from the
outside of Outer.

That is actually a better representation of what I have come across. It
is something somebody has done in VC++ code, and its knackered me in a
porting effort.

It appears as though I am within my rights to tell them they shouldn't
have made the method in question in the Inner class private.

You're right - it is definitely a bad thing to do. It would have been
far better to publish the correct, public methods in Inner and to
encapsulate the internal of Inner using these methods.

Regards,

-- Emmanuel Deloget, Artware