dubious use of friendship

[pauldepstein]

I saw some code where a struct is declared with all members public
(not explicitly so but by omission -- the word private never
appears). Then some operators are declared as friends of this
struct. Is there ever any reason to do this? Obviously, from a legal
and algorithmic standpoint, such code is redundant. However, I don't
feel ready to condemn it right away. For example, a future programmer
might want to declare some of the members private which would make the
friendship necessary. Furthermore, it signals that the named
operators will operate on the members of the struct which may be an
aid to understanding.

Any opinions?

Paul Epstein

[Victor Bazarov]

pa**********@att.net wrote:

I saw some code where a struct is declared with all members public
(not explicitly so but by omission -- the word private never
appears). Then some operators are declared as friends of this
struct. Is there ever any reason to do this?

You mean, aside from not paying attention and just following the
habit of making non-member operators friends?

Obviously, from a legal
and algorithmic standpoint, such code is redundant. However, I don't
feel ready to condemn it right away. For example, a future programmer
might want to declare some of the members private which would make the
friendship necessary. Furthermore, it signals that the named
operators will operate on the members of the struct which may be an
aid to understanding.

Any opinions?

It is _conceivable_ that some code is written to be refactored later.
Like making something a struct and expecting to make it a class after
some testing/debugging is over. Is that a good idea? I do not think
so. But that's just my opinion.

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

[Daniel T.]

pa**********@att.net wrote:

I saw some code where a struct is declared with all members public
(not explicitly so but by omission -- the word private never
appears). Then some operators are declared as friends of this
struct. Is there ever any reason to do this? Obviously, from a legal
and algorithmic standpoint, such code is redundant. However, I don't
feel ready to condemn it right away. For example, a future programmer
might want to declare some of the members private which would make the
friendship necessary. Furthermore, it signals that the named
operators will operate on the members of the struct which may be an
aid to understanding.

Any opinions?

I have to agree with Victor Bazarov. My guess is that the person who
wrote the code made the operators friends because that is what the
example code he was using had.

As to writing code so some future programmer might make it better. I'll
do that, but only if the "future" is in the next few hours, before I
check the code into CVS. (For example, when moving a member-variable
from one class to another, I will initially make the member-variable
public in its new home, fix all the compile errors, then start moving
parts of member-functions into the new home, then make the
member-variable private. Only after all the steps are done would I let
someone else look at the code. :-)

[pauldepstein]

On Jan 2, 1:53*am, "Daniel T." <[e-mail]:

[e-mail] wrote:

I saw some code where a struct is declared with all members public
(not explicitly so but by omission -- the word private never
appears). *Then some operators are declared as friends of this
struct. *Is there ever any reason to do this? *Obviously, from a legal
and algorithmic standpoint, such code is redundant. *However, I don't
feel ready to condemn it right away. For example, a future programmer
might want to declare some of the members private which would make the
friendship necessary. *Furthermore, it signals that the named
operators will operate on the members of the struct which may be an
aid to understanding.

Any opinions?

I have to agree with Victor Bazarov. My guess is that the person who
wrote the code made the operators friends because that is what the
example code he was using had.

As to writing code so some future programmer might make it better. I'll
do that, but only if the "future" is in the next few hours, before I
check the code into CVS. (For example, when moving a member-variable
from one class to another, I will initially make the member-variable
public in its new home, fix all the compile errors, then start moving
parts of member-functions into the new home, then make the
member-variable private. Only after all the steps are done would I let
someone else look at the code. :-)

Thanks to you and Victor for the feedback. Re "My guess is that the
person who

wrote the code made the operators friends because that is what the
example code he was using had."

I happen to know the programmer and I would make a different guess. I
think Victor was right to suggest he was making non-member operators
friends out of habit.

Paul Epstein

[pauldepstein]

On Jan 2, 12:09*am, "Victor Bazarov" <[e-mail]:

[e-mail] wrote:

I saw some code where a struct is declared with all members public
(not explicitly so but by omission -- the word private never
appears). *Then some operators are declared as friends of this
struct. *Is there ever any reason to do this?

You mean, aside from not paying attention and just following the
habit of making non-member operators friends?

*Obviously, from a legal
and algorithmic standpoint, such code is redundant. *However, I don't
feel ready to condemn it right away. For example, a future programmer
might want to declare some of the members private which would make the
friendshipnecessary. *Furthermore, it signals that the named
operators will operate on the members of the struct which may be an
aid to understanding.

Any opinions?

It is _conceivable_ that some code is written to be refactored later.
Like making something a struct and expecting to make it a class after
some testing/debugging is over. *Is that a good idea? *I do not think
so. *But that's just my opinion.

V

I have found out the reason, and it seems that it was deliberate. The
practice here is use the keyword struct for a simple class with a few
data items but no methods. The keyword class is used for more
complicated classes. The coder made some operators friends of the
struct because he envisaged the struct becoming more complex, and
therefore (according to the above naming convention), being renamed a
class. The coder was ensuring that such a renaming would not result
in illegal code.

Paul Epstein

[Pete Becker]

On 2008-01-07 07:01:01 -0500, pa**********@att.net said:

>
I have found out the reason, and it seems that it was deliberate. The
practice here is use the keyword struct for a simple class with a few
data items but no methods. The keyword class is used for more
complicated classes. The coder made some operators friends of the
struct because he envisaged the struct becoming more complex, and
therefore (according to the above naming convention), being renamed a
class. The coder was ensuring that such a renaming would not result
in illegal code.

Seems like programmers today love to spend time solving non-problems.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)