 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Jiang
Guest
|
 Posted: Mon Sep 18, 2006 12:07 am Post subject: Why no access specifiers for friends? |
 |
|
As we know the friend declarations introduce the tightest coupling
relationships between a class and its friends, even tighter than
inheritance.
This is strange because the coupling for relationship "is-a" should
be much tighter than relationship "friend-of-a", even in real life.
Why we do not have access specifiers to control the protected
friends or private friends?
Maybe I should post this message in comp.std.c++, but I decided
to post it here because this issue is derived from a related thread.
( Sanity check: public/private
http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/f59e8500e81cba2d/786987f601ffd131?hl=en#786987f601ffd131
)
Any comments are welcome.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
Thomas Maeder
Guest
|
| Posted: Mon Sep 18, 2006 3:46 am Post subject: Re: Why no access specifiers for friends? |
|
|
"Jiang" <goo.mail01 (AT) yahoo (DOT) com> writes:
| Quote: | As we know the friend declarations introduce the tightest coupling
relationships between a class and its friends, even tighter than
inheritance.
This is strange because the coupling for relationship "is-a" should
be much tighter than relationship "friend-of-a", even in real life.
Why we do not have access specifiers to control the protected
friends or private friends?
|
What would it mean for a function or class to be a "protected friend"
or a "private friend"?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Jiang
Guest
|
| Posted: Tue Sep 19, 2006 12:08 am Post subject: Re: Why no access specifiers for friends? |
|
|
Timo Geusch wrote:
| Quote: | Jiang was seen penning the following ode to ... whatever:
As we know the friend declarations introduce the tightest coupling
relationships between a class and its friends, even tighter than
inheritance.
This is strange because the coupling for relationship "is-a" should
be much tighter than relationship "friend-of-a", even in real life.
Why we do not have access specifiers to control the protected
friends or private friends?
What is it you're trying to achieve here?
Given that one of the main purposes of 'friend' is to override the
access control on a class, it doesn't really make much sense to me,
even when I'm assuming that 'protected friend' would only allow access
to public and proctected members of the class and the 'private friend'
would allow access to everything, like the current friend declaration.
|
Yes, your assumption is exactly what I meant.
| Quote: | At the end of the day, 'friend' in my opinion is a bit of a hack to
get around mistakes and/or limitations in the design.
|
Well, that's what I am waiting for ... :-)
In another post I explained this problem a little bit more.
I wont say there are obvious mistakes in the C++ language,
but the access control for "friend" did confused me when
I educated myself C++ long time ago. Even now I do not
have an satisfactory answer to this question.
Now may I say that since friend is a workaround for member
access granting, there is no need to add extra complexity
to control friend declarations themselves.
For some reasons I think "partner/assistant" are better here. ;-)
| Quote: | For that reason it should be used as rarely as possible anyway.
|
Agree.
Actually I find "friend" is quite difficult to deal with, I use
it mainly for operator overloading.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Jiang
Guest
|
| Posted: Tue Sep 19, 2006 12:11 am Post subject: Re: Why no access specifiers for friends? |
|
|
kanze wrote:
| Quote: | Jiang wrote:
As we know the friend declarations introduce the tightest coupling
relationships between a class and its friends, even tighter than
inheritance.
This is strange because the coupling for relationship "is-a" should
be much tighter than relationship "friend-of-a", even in real life.
Why we do not have access specifiers to control the protected
friends or private friends?
I think you're confused by very simplified expressions which
describe the relationship. Inheritance would be more accurately
described by is-an-implementation-of, or
can-be-replaced-in-all-contexts by. Friend, on the otherhand,
means something along the lines of
is-an-intimate-part-of-the-implementation-of.
|
Thanks for the nice wording, I think the new C++ books
should use above words, at least in footnote. :-)
But it was not my intention to compare inheritance and
friend. I just want to now what is the rationale for ignoring
access control for friend declarations.
Yes, I agree with you, and in my another post I said it explicitly.
I do not how you gurus think about this issue, but when I came
across to this keyword, I felt that it is not flawless, since the
access granting is too generous.
And now I think I partly agree with Timo's words, "friend" is a
trade-off.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Dave Harris
Guest
|
| Posted: Tue Sep 19, 2006 12:18 am Post subject: Re: Why no access specifiers for friends? |
|
|
goo.mail01 (AT) yahoo (DOT) com (Jiang) wrote (abridged):
| Quote: | Why we do not have access specifiers to control the protected
friends or private friends?
|
Because they are not really needed. The key point is that "friend" names a
single class rather than an open group of classes. In C++, if you want to
see how private members are used you have a lexically limited list of
places to look at - the class's members. "Friend" doesn't change that. It
just adds a few more places to look.
Inheritance is different to friendship in that there can be unboundedly
many subclasses. This is why subclasses can't be allowed access to private
members, and friends can.
To put it another way, to say that a friend can only access part of a
class's representation would be like saying the class's own members can
only access part of the representation. It defeats the purpose of the
class as the unit of access. If that's what you want, split it up into
multiple classes.
-- Dave Harris, Nottingham, UK.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Greg Herlihy
Guest
|
| Posted: Tue Sep 19, 2006 12:29 am Post subject: Re: Why no access specifiers for friends? |
|
|
Jiang wrote:
| Quote: | Why we do not have access specifiers to control the protected
friends or private friends?
|
We already do. For example, this program declares main() a "protected"
friend of class A:
class A
{
protected:
static void protectedMethod() {}
private:
static void privateMethod() {}
};
class B : public A
{
friend int main();
};
int main()
{
A::protectedMethod(); // OK
A::privateMethod(); // Error
}
In other words, just declare a useless subclass of the target class and
have the subclass nominate the "protected" friend. In practical terms,
this kind of nuanced access control simply is not worth the trouble.
Either a class (or a function) implements an interface - or it is (at
least, a potential) client of that inteface. In other words, all code
falls either "inside" or "outside" of a class interface. There is no
half-way state worth mentioning.
Greg
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Tue Sep 19, 2006 10:15 pm Post subject: Re: Why no access specifiers for friends? |
|
|
Jiang wrote:
| Quote: | But it was not my intention to compare inheritance and
friend. I just want to now what is the rationale for ignoring
access control for friend declarations.
|
Probably because friendship is really a way of making a member
of something that could not otherwise be declared as a member:
there's really very little difference between a friend function
and a static member function, for example. As I tried to say, a
friend function belongs to your implementation.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Jiang
Guest
|
| Posted: Wed Sep 20, 2006 9:39 pm Post subject: Re: Why no access specifiers for friends? |
|
|
kanze wrote:
| Quote: | Jiang wrote:
But it was not my intention to compare inheritance and
friend. I just want to now what is the rationale for ignoring
access control for friend declarations.
Probably because friendship is really a way of making a member
of something that could not otherwise be declared as a member:
there's really very little difference between a friend function
and a static member function, for example. As I tried to say, a
friend function belongs to your implementation.
|
Yes, the friend function is part of my interface, that's why
I believe the access specifiers are necessary to specifiy
who is my "private friend", and who is my "protected friend".
The problem is, do we really need expose *all* my internal
states to all my friends?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Thu Sep 21, 2006 10:23 pm Post subject: Re: Why no access specifiers for friends? |
|
|
In article <1158767575.237906.116060 (AT) d34g2000cwd (DOT) googlegroups.com>,
Jiang <goo.mail01 (AT) yahoo (DOT) com> writes
| Quote: | Yes, the friend function is part of my interface, that's why
I believe the access specifiers are necessary to specifiy
who is my "private friend", and who is my "protected friend".
|
Please provide a real-world use-case where the distinction would be
helpful. Without this you are just 'had waving'.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions:
http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Seungbeom Kim
Guest
|
| Posted: Thu Sep 21, 2006 11:16 pm Post subject: Re: Why no access specifiers for friends? |
|
|
Jiang wrote:
| Quote: | Thomas Maeder wrote:
What would it mean for a function or class to be a "protected friend"
or a "private friend"?
Well, a "protected friend" shall not be able to access the private
members, and there is no such limitation for a "private friend".
Although senmatics are slight different from the access specifiers
for normal members, but it is maybe useful if we want to expose
our internal details as little as possible. And the friend declaration
is private friend if no access specifiers specified. In this sense,
the public friend is not really meaningful.
|
Protected members are for derived classes; friendship doesn't have to do
with derivation. In which cases do you want a friend to be able to access
protected members but not private members? Can you give an example?
--
Seungbeom Kim
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Lourens Veen
Guest
|
| Posted: Fri Sep 22, 2006 12:29 am Post subject: Re: Why no access specifiers for friends? |
|
|
kanze wrote:
| Quote: | The first remark was really about the fact that control is on a
class basis. Be it friendship or the fact of being a member
functions, access is granted automatically to the entire class,
and not to parts of it. And there are times when one would like
to be more restrictive.
|
So then apparently there is a subset of the class members that forms
some sort of logical unit. Shouldn't that be a separate (or perhaps
inner) class then? Why can we not simply conclude in that case that
the granularity of the classes isn't small enough? Can you give an
example?
| Quote: | In the end, one can imagine many different levels of access: in
large applications, it is not unusually to define any number of
different "roles", to assign each user to one or more roles, and
each role to a different set of rights (access or modification).
And it's not unusual to want something more or less along these
lines for a class. The question is simple: how much extra
complexity would it entail, and is it worth it? For the moment,
I've not seen any concrete proposals to judge, but my impression
is that would introduce a lot of extra complexity. And that
given the relatively small size of classes, the benefits would
be minor.
|
Again, I don't really see the problem. Can't we just define a bunch of
abstract interfaces, derive from all of them, and pass around
references or pointers of the interface types to the users of the
class?
Lourens
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Jiang
Guest
|
| Posted: Fri Sep 22, 2006 5:26 pm Post subject: Re: Why no access specifiers for friends? |
|
|
Francis Glassborow wrote:
| Quote: | In article <1158767575.237906.116060 (AT) d34g2000cwd (DOT) googlegroups.com>,
Jiang <goo.mail01 (AT) yahoo (DOT) com> writes
Yes, the friend function is part of my interface, that's why
I believe the access specifiers are necessary to specifiy
who is my "private friend", and who is my "protected friend".
Please provide a real-world use-case where the distinction would be
helpful. Without this you are just 'had waving'.
|
OK, for the following example
class A
{
public:
// public interace
protected:
// protected members
friend void proteced_friend();
private:
// private members
friend void private_friend();
};
Suppose we have "protected friend" in the language, and
the free function protect_friend is specified as a protected
friend of class A. Now if I want to rearrange my internal
states (private members), I will not bother to check the
implementation of protected_friend, because it can not
access the private stuff at all. It saves my time and I will
be happy because the encapsulation rule works.
It will benefit more for friend classes, since the friend classes
could have many member functions for this kind of checking.
Please note here when and how to use friend is an
different issue, and I am just talking about the language.
BTW, as I said in another post (also Seungbeom Kim and
other said the same thing) , the "protected" keyword has
its own semantic and it is strange to use it together with
friend. But I can not find other way to explain my idea
without use it as an example.
I will try to make it clearer: I want to arrange my interfaces
with different access levels. And for my friend interfaces,
I have 0-1 granularity only and I hope someone will show
me what is the rationale for this granularity.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Fri Sep 22, 2006 5:45 pm Post subject: Re: Why no access specifiers for friends? |
|
|
Lourens Veen wrote:
| Quote: | kanze wrote:
The first remark was really about the fact that control is
on a class basis. Be it friendship or the fact of being a
member functions, access is granted automatically to the
entire class, and not to parts of it. And there are times
when one would like to be more restrictive.
So then apparently there is a subset of the class members that
forms some sort of logical unit. Shouldn't that be a separate
(or perhaps inner) class then?
|
Maybe. I don't recall the exact cases where I had this
impression, and it's quite possible that your solution could
have applied to them (and might have been cleaner).
In the end, it boils down to my basic point concerning finer
granularity: how much extra complexity is it worth. In all
cases, the friend was part of the implementation; I controled it
just as much as I controled member functions. So a simple
implementation comment as to what it might change seemed
sufficient. Anything more would have been more complexity than
it was worth.
| Quote: | Why can we not simply conclude
in that case that the granularity of the classes isn't small
enough? Can you give an example?
In the end, one can imagine many different levels of access: in
large applications, it is not unusually to define any number of
different "roles", to assign each user to one or more roles, and
each role to a different set of rights (access or modification).
And it's not unusual to want something more or less along these
lines for a class. The question is simple: how much extra
complexity would it entail, and is it worth it? For the moment,
I've not seen any concrete proposals to judge, but my impression
is that would introduce a lot of extra complexity. And that
given the relatively small size of classes, the benefits would
be minor.
Again, I don't really see the problem. Can't we just define a
bunch of abstract interfaces, derive from all of them, and
pass around references or pointers of the interface types to
the users of the class?
|
Introducing roles that way. We probably could, but again, is it
worth the bother.
Don't take my comments too literally. I was doing a bit of
brainstorming. Trying to look at the problem from different
points of view. In practice, classes are a lot smaller than
applications, and each class has a lot less functionality. So
adding some concept of roles is almost certainly a lot of excess
complexity for very little benefit. At the sub-system level, it
often does become interesting, and there, having the sub-system
present several different fassades, depending on the user, is a
more or less standard technique.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Seungbeom Kim
Guest
|
| Posted: Fri Sep 22, 2006 11:04 pm Post subject: Re: Why no access specifiers for friends? |
|
|
Jiang wrote:
| Quote: |
I will try to make it clearer: I want to arrange my interfaces
with different access levels. And for my friend interfaces,
I have 0-1 granularity only and I hope someone will show
me what is the rationale for this granularity.
|
Friends are supposed to have the same privilege as members. In other
words, friends and members are equivalent with regards to privileges.
Do you think that (function) members should also have different
privileges to its own members; e.g. a protected member function of class
X should not be able to access private members of class X? We don't have
such a distinction, and I believe that's why friends also have access to
all of the members.
And as others said, friends are part of the class implementation, so you
don't need to protect members from friends, just as you don't need to
protect members from other members. I don't see what you mean by the
phrase "friend interfaces"; an interface is for outsiders, and friends
are insiders.
--
Seungbeom Kim
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Fri Sep 22, 2006 11:07 pm Post subject: Re: Why no access specifiers for friends? |
|
|
In article <1158894846.012031.42370 (AT) m73g2000cwd (DOT) googlegroups.com>, Jiang
<goo.mail01 (AT) yahoo (DOT) com> writes
| Quote: | Please provide a real-world use-case where the distinction would be
helpful. Without this you are just 'had waving'.
OK, for the following example
|
No, you did not give me what I asked for. All you did was to express
your intentions in code not give an example of how that would be useful
in a practical way.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions:
http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
