Prev: Help needed to overload function template.
Next: Help With TR1 regex_match()
From: Dearlove on 6 Oct 2009 00:12
On 5 Oct, 23:44, Francis Glassborow
<francis.glassbo...(a)btinternet.com> wrote:
> Neil Butterworth wrote:
> > Neil Butterworth wrote:
> >> Dearlove wrote:
> >>> Can I. and if so how, achieve
>
> >>> class X
> >>> {
> >>> private:
> >>> void f();
> >>> friend void Y::g();
> >>> };
>
> >>> class Y
> >>> {
> >>> private:
> >>> void g();
> >>> friend void X::f();
> >>> };
>
> >>> Obviously I can forward declare class Y before X, but that's not
> >>> sufficient.
>
> >>> The obvious workaround is class friendship. And a design that doesn't
> >>> need the above is also a solution. But if for some reason I want the
> >>> above, what's the closest I can get?
>
> >> You appear to be asking how a class can grant itself friendship to
> >> another class. The answer is, there is no way of doing that, as it
> >> would completely negate the whole point of having private members.
>
> > Actually, I just re-read the question and maybe you are not asking that.
> > But I'm not sure. When you say:
>
> > class Y
> > {
> > private:
> > void g();
> > friend void X::f();
> > };
>
> > Are you trying to say that any member of Y should be able to call X::f()
> > or that X::f() should be able to call any member of Y?

I'm meaning the one already well-defined by C++ - see any good
textbook. There's
nothing new there. It's the limitations on forward declarations that
I'm trying
(and Francis is confirming my failure to find) that is the issue, not
who is
granted access to what by that syntax.

> > Whichever, the
> > call would not be recursive, per your questions title.
>
> > Neil Butterworth
>
> No he used the wrong term, I am not sure what the right one would be.
> Mutual dependence perhaps.

It's not unrelated to recursive, but mutual friendship is closer, but
even that term needs to be qualified by that it's at the function
level.

> He clearly wants to grant X::f() access to
> Y's internals and Y::g() access to X's internals.

Precisely.

> I am not sure why he
> wants to do that. Perhaps if the OP explains the problem he is trying to
> solve we could find a way to solve it. C++ will not let him do what he
> is trying directly and the indirect solutions seem far too heavyweight.

I couldn't see a direct solution, but I thought it worth checking if
one
existed. It's hard to prove a negative.

As for what I am trying to achieve - that is exactly what I am trying
to
achieve. That's the minimum level of access I need, and keeping it to
the minimum was of interest. In many ways the question why is not
important, but FWIW it arises in a multiple dispatch optimisation
problem.

Of course I can, as I indicated do it with mutual class friendship and
there is no loss in capability, just a (mostly theoretical) loss of
safety. And I am of course using that approach. But the ideal was what
I asked about and it's all part of a learning process.

> As he owns both X and Y I cannot see what the problem is with allowing
> both access to the other's private parts.

The only issue (and it is mostly theoretical) is protecting myself
against
my own errors. In terms of owning code, I own the entire application
(not
even an employer for this one) and I could make absolutely everything
public. Of course I don't, I make what should be private, private and
limit access sensibly. But the problem I posed is the one I would have
to solve for the ideal access control. If I can't do it, I can't do
it,
it's far from the only thing like that (a more fundamental issue is
choosing a multiple dispatch workaround in the first place - one of
the
ones in Alexandrescu's MC++D in this case).

But I'd be interested in the heavyweight indirect solutions, not
because
I will use one now, but they might reveal something interesting.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3
Prev: Help needed to overload function template.
Next: Help With TR1 regex_match()