nested friend syntax?
Is this legal and sensible?
class Outer
{
friend struct Inner
{
...
};
...
};
Basically I want to define the struct Outer::Inner and simultaneously
make it a friend to give it access to private details of Outer. My
compiler (gcc) accepts this, but then it also gives Inner private access
to Outer always so I can't tell if it does what I want it to do.
- Mark P
posted by Midhun @ 10:15 AM
7 comments
7 Comments:
More compilers grant access to private parts for nested classes these
days. Not doing so, while standard, makes no sense.
The strict way to do this would be:
class Outer
{
struct Inner;
friend struct Inner;
struct Inner {};
};
Huh?!? You want to give 'Inner' private access to 'Outer', but, the compiler
gives 'Inner' private access to 'Outer'? And you want it to do what?
Try it this way:
class Outer{
public:
struct Inner; // declare it.
friend Inner; // make it a friend.
struct Inner{ // define it.
...
};
...
private:
int DuckSoup;
};
'Inner' should now have access to 'DuckSoup'.
Ref: B. Eckel 'Thinking in C++' v1, chap 5 //: C05:NestFriend.cpp
Sorry, I wasn't very clear. On my compiler this is a non-issue, but I
asked in the interest of portability. I know I can make a separate
friend declaration-- I just savored the idea of making my source code
one line shorter by combining this with the struct definition :)
Evidently that's not permissible though.
To be honest, I have never been a big advocate of such constructs
(nesting or embedding classes in this way), and I'm not convinced
that I have ever seen a real need for real it.
I would much rather pass the 'Inner' object to 'Outer' via specialised
if need be, or visa versa.
Imo, this not only adds clarity, but provides a finer control of access
and security between objects.
Cheers,
Chris Val
There are two distinct answers here.
1) The Standard as written pulled a major boo-boo because the actual
wording does not allow granting of friendship inwards only outwards or
sideways.
class x;
class y {
friend class x; // OK
class z;
friend class z; // technical error
class a {
friend class z; // OK
// ...
};
The problem is that as written the Standard also prohibits inner classes having access to an outer class' non-public interfaces.
This problem has now been fixed (but I cannot remember if that fix has
been published in a TC yet. It has been resolved in favour of granting
inner classes unconditional access to an enclosing class' members. That
means that the technical error above will remain an error but it will
not be necessary to write such a statement.
2) All current compilers allow the technical error above and I do not
know of any that even give a diagnostic for it. I suspect that it will remain acceptable for the foreseeable future except when compilers are acting in the strictest conforming mode. If you want your code to be portable, continue to write such declarations, though increasingly they will be unnecessary as compilers adopt the new requirement (that a nested class be a full member of its enclosing class with full access privileges.)
I guess it's my Java heritage (where I began OOP) that made me partial
to this construct. In Java the difference is that non-static inner
classes have access to a specific instantiation of an outer class
object. This is something that I find frequently useful-- in my case,
Inner is a comparison functor with local state maintained (implicitly)
by a pointer to an Outer object. In C++, AFAIK, this relationship has
to be explicitly set up, but logically I find it sensible to group the class definitions.
Still, I've only been at C++ for about 9 months so I'm sure my world
view is bound to change a lot more :)
Standards-wise: there's no legal way to grant friendship "inwards",
but with a suitably amended standard it won't be necessary; the
intent is that members (including member classes) all have access
to the private parts of a class, and if the 2003 standard doesn't
say that (I don't recall), a future version is very likely to do
so, in my opinion.
Practically speaking, for compilers that don't automatically handle
access for nested classes in this manner, the inward friend
declaration is accepted (incorrectly), and all works out fine.
Post a Comment
<< Home