CLass members; public, private, protected and ???

[Chris Mantoulidis]

Forgive me if I'm wrong but I think there is something like an extra
member scope in classes.

for example:

class abc {
ostream & operator << (ostream &, const abc &);
istream & operator >> (istream &, abc &);

private:
//...

public:
//...
};

-------

Now when I implement operator << and >>, note that I mustn't say they
are part of abc...

ostream & operator << (ostream & os, const abc & ABC) {
//but not ostream & abc:perator << (.............) {
//.......
}

-------

So when putting members in the part of the class with no specified
scope, they are not exactly part of the class anymore?

When I try to put those (<< and >>) in public scope, it won't work;
plus it wouldn't make sence to say (in the "complicated form")
ABC.operator << (cout, ABC);...

So am I right? Is there something like an extra scope? Wouldn't it be
the same if I just defined ostream & operator << (ostream &, const abc
& ABC); outside the class? Isn't it just overloading?

Of course all of the above might be wrong, but it is worth asking.

TIA,
cmad

 

[Peter Koch Larsen]

Forgive me if I'm wrong but I think there is something like an extra
member scope in classes.

for example:

class abc {
ostream & operator << (ostream &, const abc &);
istream & operator >> (istream &, abc &);

friend ostream & operator << (ostream &, const abc &);
friend istream & operator >> (istream &, abc &);

private:
//...

public:
//...
};

-------

Now when I implement operator << and >>, note that I mustn't say they
are part of abc...

ostream & operator << (ostream & os, const abc & ABC) {
//but not ostream & abc:perator << (.............) {
//.......
}

Yes they are - they are private.

When I try to put those (<< and >>) in public scope, it won't work;
plus it wouldn't make sence to say (in the "complicated form")
ABC.operator << (cout, ABC);...

So am I right? Is there something like an extra scope? Wouldn't it be
the same if I just defined ostream & operator << (ostream &, const abc
& ABC); outside the class? Isn't it just overloading?

"friend" designates that the operator or function is not part of the class
but is allowed access to the class' internals.
You could define it in the class to: for very simple functions this makes
sense. Eg:

friend ostream & operator << (ostream &os, const abc &elem) { return os <<
elem.a; }

Of course all of the above might be wrong, but it is worth asking.

TIA,
cmad

Kind regards
Peter

 

[Dan W.]

Forgive me if I'm wrong but I think there is something like an extra
member scope in classes.

for example:

class abc {
ostream & operator << (ostream &, const abc &);
istream & operator >> (istream &, abc &);

private:
//...

public:
//...
};

-------

Now when I implement operator << and >>, note that I mustn't say they
are part of abc...

ostream & operator << (ostream & os, const abc & ABC) {
//but not ostream & abc:perator << (.............) {
//.......
}

-------

So when putting members in the part of the class with no specified
scope, they are not exactly part of the class anymore?

When I try to put those (<< and >>) in public scope, it won't work;
plus it wouldn't make sence to say (in the "complicated form")
ABC.operator << (cout, ABC);...

So am I right? Is there something like an extra scope? Wouldn't it be
the same if I just defined ostream & operator << (ostream &, const abc
& ABC); outside the class? Isn't it just overloading?

Of course all of the above might be wrong, but it is worth asking.

TIA,
cmad

You can declare non-member functions inside a class by declaring them
friend. In this case, it doesn't matter whether they come under
public, private or protected. It doesn't apply to them. You can even
define them inline, within the class, and yet they are still
non-member functions. Non-member functions that do not need access to
private members of a class should be declared non-friend, which
implies that they must be declared outside of the class.

Non-member declarations within a class declaration are useful when
functions are closely related to the class, and needing access to
private members, but not strongly enough to warrant membership.
Streaming ops are one example. Binary, relational operators, such as
<, ==, !=, etc., some argue, are better off not beintg member
functions, since they pertain to a relationship where neither side is
worthier than the other to officially evaluate it.

After the opening brace of a class declaration, there's an implicit
'private:'; just as there's an implicit 'public:' after the opening
brace of a struct declaration. So, it's not a 'no man's land' ;-)

Cheers!

 

[Gary Labowitz]

On 28 Dec 2003 23:11:56 -0800, (e-mail address removed) (Chris Mantoulidis)
wrote:

You can declare non-member functions inside a class by declaring them
friend. In this case, it doesn't matter whether they come under
public, private or protected. It doesn't apply to them. You can even
define them inline, within the class, and yet they are still
non-member functions. Non-member functions that do not need access to
private members of a class should be declared non-friend, which
implies that they must be declared outside of the class.

Non-member declarations within a class declaration are useful when
functions are closely related to the class, and needing access to
private members, but not strongly enough to warrant membership.
Streaming ops are one example. Binary, relational operators, such as
<, ==, !=, etc., some argue, are better off not beintg member
functions, since they pertain to a relationship where neither side is
worthier than the other to officially evaluate it.

More importantly, and in this case, if the function signature doesn't
include the hidden this pointer, you can't have the overloaded operator
function unless it is a non-member function that has been made a friend of
the class. The operator>> and operator<< functions that you are overloading
for the iostream classes has a left-hand operand of stream type and a
right-hand operand of the overloaded type. A this pointer would mess up the
signature.

 

[Jeff Schwab]

Forgive me if I'm wrong but I think there is something like an extra
member scope in classes.

for example:

class abc {
ostream & operator << (ostream &, const abc &);
istream & operator >> (istream &, abc &);

private:
//...

public:
//...
};

-------

Now when I implement operator << and >>, note that I mustn't say they
are part of abc...

ostream & operator << (ostream & os, const abc & ABC) {
//but not ostream & abc:perator << (.............) {
//.......
}

-------

So when putting members in the part of the class with no specified
scope, they are not exactly part of the class anymore?

When I try to put those (<< and >>) in public scope, it won't work;
plus it wouldn't make sence to say (in the "complicated form")
ABC.operator << (cout, ABC);...

So am I right? Is there something like an extra scope? Wouldn't it be
the same if I just defined ostream & operator << (ostream &, const abc
& ABC); outside the class? Isn't it just overloading?

Of course all of the above might be wrong, but it is worth asking.

TIA,
cmad

I see friend functions used frequently in responses to your original
query, and in other code posted here. Imho, there are very few valid
uses for "friend." If operators or functions outside the class need to
manipulate the class's member data, just provide the appropriate
accessor functions.

ostream & operator << ( ostream & os, const Complex& c ) {
return os << '(' << c.real_part( ) << ','
<< c.imaginary_part( ) << ')';
}

 

[Chris Mantoulidis]

the same if I just defined ostream & operator << (ostream &, const abc

I see friend functions used frequently in responses to your original
query, and in other code posted here. Imho, there are very few valid
uses for "friend." If operators or functions outside the class need to
manipulate the class's member data, just provide the appropriate
accessor functions.

ostream & operator << ( ostream & os, const Complex& c ) {
return os << '(' << c.real_part( ) << ','
<< c.imaginary_part( ) << ')';
}

Yeah, that's what I was thinking about

There's no need for friend, since I DO provide accessor functions in all my classes.

But still, thank you all cuz I now do understand more about friend...

But I like Jeff's way more... Plain overloading

 

[Grimble Gromble]

Yeah, that's what I was thinking about

There's no need for friend, since I DO provide accessor functions in all my classes.

hmm.
"accessor" functions - are accessible by *ANYONE* from 'outside', on the
other hand friendship gives the access *ONLY* to those who really need it.