nonmember vs member?

E

Erik Haugen

From reading gotw#84 (http://www.gotw.ca/gotw/084.htm), I'm convinced that
I should try to make functions nonfriend nonmembers when practical, but
then I came across this:

Bruce Eckel says about operator overloads in Thinking In C++ (2nd Ed -
http://www.codeguru.com/cpp/tic/tic0129.shtml)
"In general, if it doesn't make any difference, they should be members, to
emphasize the association between the operator and its class."

That seems like a valid point, but probably not as convincing as the ones
Sutter gives. For example, a nonmember nonfriend might be generic enough
to be usable outside of the class; no reason to unnecessarily hide the
logic inside the class.

Does Eckel's argument ever outweigh Sutter's?


-Erik
 
D

David B. Held

Erik Haugen said:
[...]
Does Eckel's argument ever outweigh Sutter's?

I don't like Eckel's argument at all. Scott Meyers also
talks about member vs. non-member, and sums it up more
or less like this: "non-member when it can, member when
it must". For instance, assignment operators have to be
members. Comparison operators don't. With free
functions, you get implicit conversions. With member
functions, *this will never get an implicit conversion.
There's more arguments, but that's enough for now.

Dave
 
J

jeffc

Erik Haugen said:
From reading gotw#84 (http://www.gotw.ca/gotw/084.htm), I'm convinced that
I should try to make functions nonfriend nonmembers when practical, but
then I came across this:

Bruce Eckel says about operator overloads in Thinking In C++ (2nd Ed -
http://www.codeguru.com/cpp/tic/tic0129.shtml)
"In general, if it doesn't make any difference, they should be members, to
emphasize the association between the operator and its class."

That seems like a valid point, but probably not as convincing as the ones
Sutter gives. For example, a nonmember nonfriend might be generic enough
to be usable outside of the class; no reason to unnecessarily hide the
logic inside the class.

Does Eckel's argument ever outweigh Sutter's?

I think it's a matter of connotations. I think Eckel's advice is good: "If
it doesn't make any difference....". That seems vague enough that it's
pretty safe :) On the other hand, I think the GotW advice is not so good:
"Where possible, prefer writing functions as nonmember nonfriends." That
seems too far reaching for me. If you read Eckel's book, you'll see that
one of the points of OO programming is to reduce the number of functions
that you have to call with a bunch of parameters, when encapsulation reduces
the need for parameters. The GotW advice seems to be consistent with
"generic programming" (similar principles to some of the template and STL
stuff.) But after all, can't almost *everything* be a nonmember nonfriend
function, if you send it enough parameters? I don't like their phrase
"where possible".
 
J

jeffc

David B. Held said:
Erik Haugen said:
[...]
Does Eckel's argument ever outweigh Sutter's?

I don't like Eckel's argument at all. Scott Meyers also
talks about member vs. non-member, and sums it up more
or less like this: "non-member when it can, member when
it must".

"more or less"? I don't agree. I think you're taking it out of context.
Here is what he says, more or less.

If the function is virtual, of course it must be a member. If the function
is the << or >> operator, make it non-member. If the function needs type
conversion on its left most argument, make it non-member (note this is
common in operators). Everything else should be a member function.

That's hardly "non-member when it can". In fact, the vast majority of
functions will be member by that rule. In fact, in Item 19 of "Effective
For instance, assignment operators have to be
members. Comparison operators don't.

You're using operators as an example. The vast majority of OO functions
written are non-operator. The OP didn't ask anything about operators
specifically, just functions.
 
A

Alf P. Steinbach

From reading gotw#84 (http://www.gotw.ca/gotw/084.htm), I'm convinced that
I should try to make functions nonfriend nonmembers when practical, but
then I came across this:

Bruce Eckel says about operator overloads in Thinking In C++ (2nd Ed -
http://www.codeguru.com/cpp/tic/tic0129.shtml)
"In general, if it doesn't make any difference, they should be members, to
emphasize the association between the operator and its class."

That seems like a valid point, but probably not as convincing as the ones
Sutter gives. For example, a nonmember nonfriend might be generic enough
to be usable outside of the class; no reason to unnecessarily hide the
logic inside the class.

Does Eckel's argument ever outweigh Sutter's?

I do hope someone authoritative will clarify once and for all whether
two, three, four or eight character positions is best for indentation, and
also which indentation style to follow. In this regard, should I heed the
advice of Bjarne, Herb or Bruce? It's frustrating not to have clear
leadership in this important matter.

I am sure that with the correct, officially approved indentation everything
else will just fall into place of its own accord.
 
?

=?iso-8859-1?Q?Juli=E1n?= Albo

"Alf P. Steinbach" escribió:
I do hope someone authoritative will clarify once and for all whether
two, three, four or eight character positions is best for indentation, and
also which indentation style to follow. In this regard, should I heed the
advice of Bjarne, Herb or Bruce? It's frustrating not to have clear
leadership in this important matter.

Were is the importance? I can read code written with any reasonable
standard without problem. And if you need to adapt foreign code to your
own standard you can use indent or something similar.

Regards.
 
A

Alf P. Steinbach

"Alf P. Steinbach" escribi=F3:


Were is the importance? I can read code written with any reasonable
standard without problem. And if you need to adapt foreign code to your
own standard you can use indent or something similar.

Ah, you're probably American.
 
J

jeffc

Alf P. Steinbach said:
I do hope someone authoritative will clarify once and for all whether
two, three, four or eight character positions is best for indentation, and
also which indentation style to follow. In this regard, should I heed the
advice of Bjarne, Herb or Bruce? It's frustrating not to have clear
leadership in this important matter.

What on earth are you talking about? Is this some kind of weird troll?
 
U

Unforgiven

jeffc said:
What on earth are you talking about? Is this some kind of weird
troll?

I think he is trying to say that what the OP asked is a similar kind of
political debate, i.e. there's not one answer, and you can simply use your
personal preference.
 
D

David B. Held

jeffc said:
[...]
If the function is virtual, of course it must be a member. If
the function is the << or >> operator, make it non-member.
If the function needs type conversion on its left most
argument, make it non-member (note this is common in
operators). Everything else should be a member function.

Ok, so I was thinking of Andrei's "intepretation" of Meyers'
rule, which is: "Make everything a free function". ;)
[...]
You're using operators as an example. The vast majority of
OO functions written are non-operator. The OP didn't ask
anything about operators specifically, just functions.

That's ambiguous. He first asked about functions, and then
mentioned what Eckel's had to say about *operators*. So
I assumed he was talking primarily about operators. In
which case, I think Meyers mostly agrees with my summary
(since most binary operators, for instance, benefit from
implicit conversion, and most of the operators that you want
to be members couldn't be free anyway).

Dave
 
J

jeffc

David B. Held said:
That's ambiguous. He first asked about functions, and then
mentioned what Eckel's had to say about *operators*. So
I assumed he was talking primarily about operators. In
which case, I think Meyers mostly agrees with my summary
(since most binary operators, for instance, benefit from
implicit conversion, and most of the operators that you want
to be members couldn't be free anyway).

Yes, I suppose.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top