472,111 Members | 1,896 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,111 software developers and data experts.

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.

Thanks,
Mark
Jul 23 '05 #1
7 1836
Ian
Mark P wrote:
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.

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 {};
};

Ian
Jul 23 '05 #2

Mark P wrote in message <4_***************@newssvr14.news.prodigy.com>.. .
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.

Thanks,
Mark


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
--
Bob R
POVrookie
Jul 23 '05 #3
BobR wrote:
Mark P wrote in message <4_***************@newssvr14.news.prodigy.com>.. .
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.

Thanks,
Mark

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?


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.
Jul 23 '05 #4


Mark P wrote:
BobR wrote:
Mark P wrote in message <4_***************@newssvr14.news.prodigy.com>.. .
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.

Thanks,
Mark

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?


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

Jul 23 '05 #5
In article <4_***************@newssvr14.news.prodigy.com>, Mark P
<no*@my.real.email> writes
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.

Thanks,
Mark

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.)

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Jul 23 '05 #6
Chris ( Val ) wrote:

Mark P wrote:
BobR wrote:
Mark P wrote in message <4_***************@newssvr14.news.prodigy.com>.. .
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.

Thanks,
Mark
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?


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


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 :)
Jul 23 '05 #7
Ian wrote:
Mark P wrote:
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.

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 {};
};


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.

-- James
Jul 23 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Alexander Stippler | last post: by
1 post views Thread by Chris Schadl | last post: by
10 posts views Thread by nimmi_srivastav | last post: by
6 posts views Thread by B0nj | last post: by
8 posts views Thread by Etienne Boucher | last post: by
4 posts views Thread by Mr Dyl | last post: by
3 posts views Thread by jdurancomas | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.