need for friend function

[subramanian100in]

Stroustrup, in his book TC++PL 3rd Edition, in page 16, under the
section '1.8 Advice' has mentioned the following:
[2] [a] Don't use global data(use members)
[b] Don't use global functions
[c] Don't use public data members.
[d] Don't use friends, except to avoid [a] or [c].

Consider the following scenarios:

Scenario 1:
----------------
class Test
{
friend ostream & operator<<(ostr eam &os, const Test &ref);
}

Here the friend ostream &operator<<( ) can be avoided by providing a
Test::print_out put() function and expect the user to explicitly call
Test_obj.print_ output(os) for an object Test_obj of type Test.

Scenario 2:
----------------
class Test
{
friend Test operator+(const Test &arg1, const Test &arg2);
}

This friend function can be avoided as follows:

class Test
{
Test &operator+=(con st Test &ref);
}

Test operator+(const Test &arg1, const &arg2)
{
Test temp(arg1);
return temp += arg2;
}

Scenario 3:
----------------
Consider invert(m) for inverting a 'Matrix m' to the alternative
m.invert()
By providing Matrix::invert( ), here also the friend function can be
avoided.

I want to know if there are some guidelines and examples where the
need for using a friend function is unavoidable.

Kindly explain.

Thanks
V.Subramanian

[Victor Bazarov]

su************* *@yahoo.com wrote:

[..]
I want to know if there are some guidelines and examples where the
need for using a friend function is unavoidable.

Here is the thing: absence of evidence is not evidence of absence.
If I've never encountered in my whole life any guidelines and/or
examples where using a friend function is unavoidable, it does not
mean there isn't any. However, consider this: if there are better
ways of doing something, and you have no reason for *not* using one
of the better ways, then the "not so good" mechanism is avoidable.
Invert that, and you get this: if there are compelling reasons not
to use any of the ways to avoid something, then this something
becomes unavoidable. If for some reason you cannot grant access
to some private data to everybody (declare the data public or
protected), *and* you cannot make certain function a member of the
class containing the private data, then you are stuck with making
the function a friend. I know, it's not concrete, but that's the
essence, AFA I'm concerned.

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

[terminator]

On Dec 4, 3:56 pm, "subramanian10. [e-mail], India"
<subramanian10. [e-mail] te:

Stroustrup, in his book TC++PL 3rd Edition, in page 16, under the
section '1.8 Advice' has mentioned the following:
[2] [a] Don't use global data(use members)
[b] Don't use global functions
[c] Don't use public data members.
[d] Don't use friends, except to avoid [a] or [c].

Consider the following scenarios:

Scenario 1:
----------------
class Test
{
friend ostream & operator<<(ostr eam &os, const Test &ref);

}

Here the friend ostream &operator<<( ) can be avoided by providing a
Test::print_out put() function and expect the user to explicitly call
Test_obj.print_ output(os) for an object Test_obj of type Test.

Scenario 2:
----------------
class Test
{
friend Test operator+(const Test &arg1, const Test &arg2);

}

This friend function can be avoided as follows:

class Test
{
Test &operator+=(con st Test &ref);

}

Test operator+(const Test &arg1, const &arg2)
{
Test temp(arg1);
return temp += arg2;

}

Scenario 3:
----------------
Consider invert(m) for inverting a 'Matrix m' to the alternative
m.invert()
By providing Matrix::invert( ), here also the friend function can be
avoided.

I want to know if there are some guidelines and examples where the
need for using a friend function is unavoidable.

Kindly explain.

class A;
class B;
class C

C foo(A a,B b){
//I need to access private members of A,B and C.
//I must be a friend of at least two of them.
};

regards,
FM.

[GArlington]

On Dec 4, 2:23 pm, terminator <farid.mehr...@ gmail.comwrote:

On Dec 4, 3:56 pm, "subramanian10. [e-mail], India"

<subramanian10. [e-mail] te:

Stroustrup, in his book TC++PL 3rd Edition, in page 16, under the
section '1.8 Advice' has mentioned the following:
[2] [a] Don't use global data(use members)
[b] Don't use global functions
[c] Don't use public data members.
[d] Don't use friends, except to avoid [a] or [c].

Consider the following scenarios:

Scenario 1:
----------------
class Test
{
friend ostream & operator<<(ostr eam &os, const Test &ref);

}

Here the friend ostream &operator<<( ) can be avoided by providing a
Test::print_out put() function and expect the user to explicitly call
Test_obj.print_ output(os) for an object Test_obj of type Test.

Scenario 2:
----------------
class Test
{
friend Test operator+(const Test &arg1, const Test &arg2);

}

This friend function can be avoided as follows:

class Test
{
Test &operator+=(con st Test &ref);

}

Test operator+(const Test &arg1, const &arg2)
{
Test temp(arg1);
return temp += arg2;

}

Scenario 3:
----------------
Consider invert(m) for inverting a 'Matrix m' to the alternative
m.invert()
By providing Matrix::invert( ), here also the friend function can be
avoided.

I want to know if there are some guidelines and examples where the
need for using a friend function is unavoidable.

Kindly explain.

class A;
class B;
class C

C foo(A a,B b){
//I need to access private members of A,B and C.
//I must be a friend of at least two of them.

};

regards,
FM.

Most of the time you can use public methods instead...

[Christopher]

On Dec 4, 8:23 am, terminator <farid.mehr...@ gmail.comwrote:

On Dec 4, 3:56 pm, "subramanian10. [e-mail], India"

<subramanian10. [e-mail] te:

Stroustrup, in his book TC++PL 3rd Edition, in page 16, under the
section '1.8 Advice' has mentioned the following:
[2] [a] Don't use global data(use members)
[b] Don't use global functions
[c] Don't use public data members.
[d] Don't use friends, except to avoid [a] or [c].

Consider the following scenarios:

Scenario 1:
----------------
class Test
{
friend ostream & operator<<(ostr eam &os, const Test &ref);

}

Here the friend ostream &operator<<( ) can be avoided by providing a
Test::print_out put() function and expect the user to explicitly call
Test_obj.print_ output(os) for an object Test_obj of type Test.

Scenario 2:
----------------
class Test
{
friend Test operator+(const Test &arg1, const Test &arg2);

}

This friend function can be avoided as follows:

class Test
{
Test &operator+=(con st Test &ref);

}

Test operator+(const Test &arg1, const &arg2)
{
Test temp(arg1);
return temp += arg2;

}

Scenario 3:
----------------
Consider invert(m) for inverting a 'Matrix m' to the alternative
m.invert()
By providing Matrix::invert( ), here also the friend function can be
avoided.

I want to know if there are some guidelines and examples where the
need for using a friend function is unavoidable.

Kindly explain.

class A;
class B;
class C

C foo(A a,B b){
//I need to access private members of A,B and C.
//I must be a friend of at least two of them.

};

regards,
FM.

Sorry term, I think that is a very bad example. you may give the OP
the idea that any constructor with an argument will have to be a
friend of the argument type, which is quite false.

A and B should have public accessors, which the constructor of C can
use. If for some reason A and B cannot provide accessors, than that is
the reason for making them friends to C. However, the example does not
illustrate that unknown reason for A and B not having accessors.

[robertwessel2]

On Dec 4, 8:09 am, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:

subramanian10.. [e-mail] wrote:

[..]
I want to know if there are some guidelines and examples where the
need for using a friend function is unavoidable.

Here is the thing: absence of evidence is not evidence of absence.
If I've never encountered in my whole life any guidelines and/or
examples where using a friend function is unavoidable, it does not
mean there isn't any. However, consider this: if there are better
ways of doing something, and you have no reason for *not* using one
of the better ways, then the "not so good" mechanism is avoidable.
Invert that, and you get this: if there are compelling reasons not
to use any of the ways to avoid something, then this something
becomes unavoidable. If for some reason you cannot grant access
to some private data to everybody (declare the data public or
protected), *and* you cannot make certain function a member of the
class containing the private data, then you are stuck with making
the function a friend. I know, it's not concrete, but that's the
essence, AFA I'm concerned.

My complaint about friendship is that its too coarse grained. I
almost never see the situation where one class actually needs to
access the private data members of another (and that's usually pretty
easy to design around, even if you just add some getters and
setters). What I have run into is the situation where two or more
classes need to share some interfaces within the group, but not with
classes outside that group.

While there are ways around that (notably making the semi-public
interfaces part of derived classes, although that brings other
problems, particularly the need to use a factory method), none of the
workarounds are all that clean (of course, neither is excessively
permissive friendship).

[Victor Bazarov]

ro***********@y ahoo.com wrote:

[..]
My complaint about friendship is that its too coarse grained. I
almost never see the situation where one class actually needs to
access the private data members of another (and that's usually pretty
easy to design around, even if you just add some getters and
setters). What I have run into is the situation where two or more
classes need to share some interfaces within the group, but not with
classes outside that group.

While there are ways around that (notably making the semi-public
interfaces part of derived classes, although that brings other
problems, particularly the need to use a factory method), none of the
workarounds are all that clean (of course, neither is excessively
permissive friendship).

To provide the functionality where only members of the group have
access to each other's privates ("family"? :-)) you can define
a "shared" class which will be the friend of them all and though
which they will request the access. Kind of like this:

class A {
int a;
friend class P;
public:
void foo();
};

class B {
int b;
friend class P;
public:
void foo();
};

class P { // everything is private
friend class A;
friend class B;
static int &a(A& ai) { return ai.a; }
static int &b(B& bi) { return bi.b; }
};

void A::foo() {
B myb;
a = P::b(myb);
}

void B::foo() {
A mya;
b = P::a(mya);
}

int main() {
A a;
B b;
a.foo();
b.foo();
}

Note that 'A' is not a friend of 'B', nor 'B' is a friend of 'A'.

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

[robertwessel2]

On Dec 4, 3:04 pm, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:

robertwess...@y ahoo.com wrote:

[..]
My complaint about friendship is that its too coarse grained. I
almost never see the situation where one class actually needs to
access the private data members of another (and that's usually pretty
easy to design around, even if you just add some getters and
setters). What I have run into is the situation where two or more
classes need to share some interfaces within the group, but not with
classes outside that group.

While there are ways around that (notably making the semi-public
interfaces part of derived classes, although that brings other
problems, particularly the need to use a factory method), none of the
workarounds are all that clean (of course, neither is excessively
permissive friendship).

To provide the functionality where only members of the group have
access to each other's privates ("family"? :-)) you can define
a "shared" class which will be the friend of them all and though
which they will request the access. Kind of like this:

class A {
int a;
friend class P;
public:
void foo();
};

class B {
int b;
friend class P;
public:
void foo();
};

class P { // everything is private
friend class A;
friend class B;
static int &a(A& ai) { return ai.a; }
static int &b(B& bi) { return bi.b; }
};

void A::foo() {
B myb;
a = P::b(myb);
}

void B::foo() {
A mya;
b = P::a(mya);
}

int main() {
A a;
B b;
a.foo();
b.foo();
}

Note that 'A' is not a friend of 'B', nor 'B' is a friend of 'A'.

Yes, I've seen that pattern (more precisely with accessor classes for
each class in the family, rather than one big one for the whole
family), but it's far from pretty. At least with the derived class
approach you can call the functions with the normal type resolution
and syntax, although it's difficult to extend that to multiple
families (although that's only been an issue on a couple of occasions).

[Rahul]

On Dec 5, 2:04 am, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:

robertwess...@y ahoo.com wrote:

[..]
My complaint about friendship is that its too coarse grained. I
almost never see the situation where one class actually needs to
access the private data members of another (and that's usually pretty
easy to design around, even if you just add some getters and
setters). What I have run into is the situation where two or more
classes need to share some interfaces within the group, but not with
classes outside that group.

While there are ways around that (notably making the semi-public
interfaces part of derived classes, although that brings other
problems, particularly the need to use a factory method), none of the
workarounds are all that clean (of course, neither is excessively
permissive friendship).

To provide the functionality where only members of the group have
access to each other's privates ("family"? :-)) you can define
a "shared" class which will be the friend of them all and though
which they will request the access. Kind of like this:

class A {
int a;
friend class P;
public:
void foo();
};

class B {
int b;
friend class P;
public:
void foo();
};

class P { // everything is private
friend class A;
friend class B;
static int &a(A& ai) { return ai.a; }
static int &b(B& bi) { return bi.b; }
};

static functions accessing non-static member variables?

void A::foo() {
B myb;
a = P::b(myb);
}

void B::foo() {
A mya;
b = P::a(mya);
}

int main() {
A a;
B b;
a.foo();
b.foo();
}

Note that 'A' is not a friend of 'B', nor 'B' is a friend of 'A'.

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

[Abhishek Padmanabh]

On Dec 5, 8:18 am, Rahul <sam_...@yahoo. co.inwrote:

On Dec 5, 2:04 am, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:

To provide the functionality where only members of the group have
access to each other's privates ("family"? :-)) you can define
a "shared" class which will be the friend of them all and though
which they will request the access. Kind of like this:

class A {
int a;
friend class P;
public:
void foo();
};

class B {
int b;
friend class P;
public:
void foo();
};

class P { // everything is private
friend class A;
friend class B;
static int &a(A& ai) { return ai.a; }
static int &b(B& bi) { return bi.b; }
};

static functions accessing non-static member variables?

Would that be a problem? Note that the static functions belong to
class P and the non-static members are of classes A and B.