Friend vs. Static

[Samee Zahur]

Question: How do friend functions and static member functions differ in
terms of functionality? I mean, neither necessarily needs an object of
the class to be created before they are called and either has access
only to static members of the class (ie. assuming no object of the
class is in scope - neither by arguments recieved nor by local
declarations). Any static member function like this:

//accessing static member i
static void cls::func(int funny){i=funny;}

would perform functions very similar to this function, assuming it
is a friend of cls:

//accessing static member i
void func(int funny){cls::i=funny;}

So I'd like to know more about the differences between the two uses.
Differences that I have come to think of:
statics can be hidden behind access priveleges, while anyone may call a
friend.
Statics access members with a slightly cleaner syntax
Many classes may grant friendship to the same function, not possible
with statics.
Friendship is not inherited to derived classes - statics are.
And probably (I'm not sure though) static members may become virtual,
supporting run-time polymorphism.

Now I just jotted these points down from five-minutes' thought, so it
would be nice if someone went through it to see if they are right, and
if some could be added to the list.

And another question ...
I've had numerous functions being declared static in my code while
their purpose really is being friends - reason: they needed to be
hidden by a protected privilege! This even happenned when my class
didn't even have a static member ... quite bewildering for someone
trying to read my codes! Can anyone tell me what is a nice way of
getting around this? (I have even hoped that one day static and friend
would become synonymous ... LOL)

Samee

Samee

 

[John Carson]

Differences that I have come to think of:
statics can be hidden behind access priveleges, while anyone may call
a friend.

Not necessarily. A private member function of class A can be made a friend
of class B.

Statics access members with a slightly cleaner syntax
Many classes may grant friendship to the same function, not possible
with statics.

It is possible for classes B, C, D... to grant friendship to a static
function in A, though of course the static function then gets access because
it is a friend, not because it is static.

Friendship is not inherited to derived classes - statics are.

Yes, but if you wanted to access a member variable in a derived class, then
a static function defined in the base class won't be any use unless you
anticipated this in defining the static function. By contrast, you can
define the friend function after the derived class has been defined (of
course, you could also define a new static function in the derived class).

And probably (I'm not sure though) static members may become virtual,
supporting run-time polymorphism.

Static functions cannot be virtual. Since they are not bound to any class
object, the class within an inheritance hierarchy to which an object belongs
cannot be used to select between different static functions.

 

[John Carson]

I think that the fundamental point is that any function at all can be made a
friend --- non-member functions, regular member functions or static member
functions --- and can be made a friend of any class willing to grant
friendship.

 

[Nadina]

Hi

Friend classes are used to define iterators through containers. IAnd
you can do that with a static member funct.

Nadina

 

[Nadina]

*** You can NOT define iterators with static member functions.

 

[John Carson]

Hi

Friend classes are used to define iterators through containers. IAnd
you can do that with a static member funct.

Nadina

No indeed, but the question was about static *functions* vs friend
*functions*, not about static functions vs friend *classes*.

 

[Howard]

Question: How do friend functions and static member functions differ in
terms of functionality? I mean, neither necessarily needs an object of
the class to be created before they are called and either has access
only to static members of the class (ie. assuming no object of the
class is in scope - neither by arguments recieved nor by local
declarations).

The two concepts are not related. A friend function is a function that has
been granted access to the private and protected members of the class that
declares it a friend. A static function is a member of the class, but one
which is restricted to using the static members of the same class.

Any static member function like this:

//accessing static member i
static void cls::func(int funny){i=funny;}

would perform functions very similar to this function, assuming it
is a friend of cls:

//accessing static member i
void func(int funny){cls::i=funny;}

This shows a friend function that is similar to a static member function,
but it's certainly not the only way to use a friend function. The friend
function *may* have access to a specific instance of the class.

So I'd like to know more about the differences between the two uses.
Differences that I have come to think of:
statics can be hidden behind access priveleges, while anyone may call a
friend.

Anyone may call *any* free function, regardless of whether it's a friend of
any specific class.

Statics access members with a slightly cleaner syntax
Many classes may grant friendship to the same function, not possible
with statics.

Does this matter? They're unrelated concepts. If you want another class to
be able to access your members, you can grant friendship to that class.
Certainly, many classes can grant friendship to a given class, and thus to
its static member functions (as well as non-static member functions).

Friendship is not inherited to derived classes - statics are.
And probably (I'm not sure though) static members may become virtual,
supporting run-time polymorphism.

No, a static function cannot also be virtual. A virtual function requires
an instance, in order to be able to determine its specific run-time type. A
static function, by definition, carries no such run-time information.

Now I just jotted these points down from five-minutes' thought, so it
would be nice if someone went through it to see if they are right, and
if some could be added to the list.

And another question ...
I've had numerous functions being declared static in my code while
their purpose really is being friends - reason: they needed to be
hidden by a protected privilege!

What needed to be hidden? The function itself? If it's a member function,
then why do you say its purpose was to be a friend? Conversely, if it was
intended to be a friend function, why was any access protection needed for
it?

This even happenned when my class
didn't even have a static member ... quite bewildering for someone
trying to read my codes!

Again, access to static members is unrelated to friendship. Granting
friendship grants access to protected and private members. Anyone who can
access a public non-static member can also access a public static member,
regardless of friendship. There is no difference between access to static
and non-static members, as far as friendship goes. Granting friendship
merely bypasses the protected/private access restrictions.

Can anyone tell me what is a nice way of
getting around this? (I have even hoped that one day static and friend
would become synonymous ... LOL)

I'd suggest you read up more on both subjects, as it seems you're confusing
two quite distinct concepts.

-Howard

 

[Samee Zahur]

John Carson's post was specially helpful ... I'd like to know if anyone
can add to this list if possible. As for Howard's post, I think you
misunderstood my question:

I know that the original *concepts* behind the two keywords are
different - but my question was about the similarity/differences
of the ultimate *effects* these keywords have ... hence the example
I gave on func ... neither has a this pointer or any instance
associated with the function call, but they both can access private
members of any associated class object in their scopes (introduced
by auto variables or arguements). In practical life, we often need to
use features of a language in ways very different from the original
concepts behind those features ... e.g. in a recent post in
comp.std.c++
I used inheritence to achieve the effect of a typedef!! I didn't have
a choice. So I'm more concerned here about what the differences of the
effects of the keywords are - I already know that their original
concepts are different.

What needed to be hidden? The function itself? If it's a member function,
then why do you say its purpose was to be a friend? Conversely, if it was
intended to be a friend function, why was any access protection needed for
it?

I believe an example would clear this up:
class base{
int i;
protected:
static void addto(base& a,const base& b){a.i+=b.i;}
};

Now let's say that
I want addto to be accessible to any class derived from base, and
no one else. With my limited skills, I really couldn't find a simpler
way to do something like this. I can't turn it into a member function,
since that will either pass a redundant this pointer to it, OR make
it useless. I cannot make it a simple "outside" function and declare
it as a friend, since that would make it publicly visible. Now the
function addto serves suits the concept behind the keyword friend, but
I just can't use it here ... not simply, anyway. So I have to declare
it a static, even though there is no static member here. I'd like it
if you can clean up this code to something less confusing - but I have
so far failed in that.

Although it may not be much in comparision with your expertise, but
after almost 6 years since my first introduction to C++, I doubt if
further reading can help me - with my limited patience, I'm more likely
to skim through the matter *thinking* that I already know this stuff.
The best I can do is learn from this group here

Samee

 

[Mark P]

I believe an example would clear this up:
class base{
int i;
protected:
static void addto(base& a,const base& b){a.i+=b.i;}
};

Now let's say that
I want addto to be accessible to any class derived from base, and
no one else. With my limited skills, I really couldn't find a simpler
way to do something like this. I can't turn it into a member function,
since that will either pass a redundant this pointer to it, OR make
it useless.

Why do you think the "this" pointer is any more or less redundant than
passing a reference to "a"? You want to operate on two objects--
somehow you need to specify them.

I cannot make it a simple "outside" function and declare

it as a friend, since that would make it publicly visible. Now the
function addto serves suits the concept behind the keyword friend, but
I just can't use it here ... not simply, anyway. So I have to declare
it a static, even though there is no static member here. I'd like it
if you can clean up this code to something less confusing - but I have
so far failed in that.

Write a member function which is invoked as a.add(b):
void add(const base& b) {i += b.i;}

 

[Samee Zahur]

Ok ... you are stepping into the exactly SAME trap I did ...hehehe

If I write it up like a member function like that, I would be able to
call obj1.add(obj2)
from a derived member if and only if obj1 is of the derived type -
while I would be able to call add(obj1,obj2) no matter what the types
are ... derived or base!

See the difference?

Samee

 

[Mark P]

Ok ... you are stepping into the exactly SAME trap I did ...hehehe

If I write it up like a member function like that, I would be able to
call obj1.add(obj2)
from a derived member if and only if obj1 is of the derived type -

What? Why do you think that? The add function is defined in the base
class and knows nothing about any derived classes. Try it yourself-- it
works fine.

 

[Samee Zahur]

What? Why do you think that? The add function is defined in the base
class and knows nothing about any derived classes. Try it yourself-- it
works fine.

No it does not ... if obj1 is of the base type, the derived member
functions will not be able to access the .add method - it is protected!
I'm sorry I do not have a copy of the standard ... but I can give you
some other reference ... wait for my next post. Meanwhile, I assure you
that obj1.add(obj2) will not compile if you write this statement inside
a derived member function.

Samee

 

[Samee Zahur]

Take a look at an old post at c.l.c++.mod:
http://groups-beta.google.com/group...read/thread/233ed2811fd38c5b/7ce40d1b9e38143b

Samee

 

[Mark P]

No it does not ... if obj1 is of the base type, the derived member
functions will not be able to access the .add method - it is protected!
I'm sorry I do not have a copy of the standard ... but I can give you
some other reference ... wait for my next post. Meanwhile, I assure you
that obj1.add(obj2) will not compile if you write this statement inside
a derived member function.

Samee

You're right. I misread your comment and didn't see that you wanted to
call baseObj.add from _within_ a derived class member function.

 

[Howard]

No it does not ... if obj1 is of the base type, the derived member
functions will not be able to access the .add method - it is protected!
I'm sorry I do not have a copy of the standard ... but I can give you
some other reference ... wait for my next post. Meanwhile, I assure you
that obj1.add(obj2) will not compile if you write this statement inside
a derived member function.

Samee

But why are you trying to write obj1.add(obj2)? Is one instance of the
[derived] class trying to add the values of two OTHER objects together? If
not, in other words, if obj1 is the CURRENT object, then just call
add(obj2). Certainly, the derived object that makes that call can see the
protected function of its own base class, right? If that's not what you
want. I guess I'd have to see a more complete example of the problem.

-Howard

 

[Samee Zahur]

Well, I was just giving an example ... there really isn't any complete
problem.
In my example, I wanted to design a base class such that any class
derived from it would be able to add two objects of the derived class
.... hence those symantecs. But, aren't we moving away from the original
discussion here?

I just wanted to know if there are more differences to the effects of
friend and static keywords than the ones I already know of, remember?

Samee