 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Le Chaud Lapin
Guest
|
 Posted: Sun Jun 29, 2003 10:16 pm Post subject: Pointers vs References: Judicious Choice Of Parameter Names |
 |
|
One very nice improvement of C++ over C is that C++ facilitates
judicious choice of parameter names. Consider:
void move (int x, int y, Puck *puck);
Looking at the variable 'puck', one might ask, "Is it a puck or a
pointer to puck." Of course, the answer is, "It is a pointer to
puck.", but nevertheless the chosen name implies that it is a puck.
Perhaps those who subscribe to this style of coding seriously
underestimate the liberating power of judiciously chosen parameter
names.
Before the advent of C++, a better choice of name might have been
'pointer_to_puck', but C++ references obviates this type of long
naming and allows us to achieve strong parity between the name chosen
and the abstraction represented.
Now, we can write:
void move (int x, int y, Puck &puck);
All is clear. 'puck', indeed, refers to a puck. Had we used the
former method, we would have written inside of move':
{
....
puck-> .... //...
}
....which implies that 'puck' is not a puck but a pointer to a puck.
I am not being pedantic here. Our power to reason about large systems
actually increases when one can write instead:
{
....
puck. //...
....
}
It seems that the use of references in this manner is often overlooked
or underemphasized in books and teachings on C++. I believe that it
is so important that *not* programming using this style ultimately
hinders object-oriented thinking.
To all C++ progammers, especially those who had deep exposure to C
prior to C++, I ask..
Do you prefer the pointer method or the reference method?
-Chaud Lapin-
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Andy Sawyer
Guest
|
| Posted: Mon Jun 30, 2003 9:14 am Post subject: Re: Pointers vs References: Judicious Choice Of Parameter Na |
|
|
In article <fc2e0ade.0306290913.627d8fcc (AT) posting (DOT) google.com>,
on 29 Jun 2003 18:16:44 -0400,
[email]unoriginal_username (AT) yahoo (DOT) com[/email] (Le Chaud Lapin) wrote:
| Quote: | To all C++ progammers, especially those who had deep exposure to C
prior to C++, I ask..
Do you prefer the pointer method or the reference method?
|
The crucial difference is that a pointer may point to something other
than the 'value type' - specifically, it might be a null pointer which
indicated the abscence of an object:
void foo( Puck *puck )
{
if( puck )
{
puck->do_something();
}
else
{
do_something_else();
}
}
This cannot be represented by passing a reference.
In general, I prefer reference parameters *UNLESS* there is a need to
deal with the absence of the parameter object.
--
"Light thinks it travels faster than anything but it is wrong. No matter
how fast light travels it finds the darkness has always got there first,
and is waiting for it." -- Terry Pratchett, Reaper Man
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Siemel Naran
Guest
|
| Posted: Mon Jun 30, 2003 9:41 am Post subject: Re: Pointers vs References: Judicious Choice Of Parameter Na |
|
|
"Le Chaud Lapin" <unoriginal_username (AT) yahoo (DOT) com> wrote in message
| Quote: | To all C++ progammers, especially those who had deep exposure to C
prior to C++, I ask..
Do you prefer the pointer method or the reference method?
|
Pass by pointer when the object may be null. Pass by reference when the
object must be non-null.
My own style is for create functions to return new objects by value or smart
pointer (and throw exceptions in case of an error), rather than construct a
new empty object and pass it by reference (or pointer) to the create
function.
--
+++++++++++
Siemel Naran
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Jack Klein
Guest
|
| Posted: Mon Jun 30, 2003 9:43 am Post subject: Re: Pointers vs References: Judicious Choice Of Parameter Na |
|
|
On 29 Jun 2003 18:16:44 -0400, [email]unoriginal_username (AT) yahoo (DOT) com[/email] (Le Chaud
Lapin) wrote in comp.lang.c++.moderated:
| Quote: | One very nice improvement of C++ over C is that C++ facilitates
judicious choice of parameter names. Consider:
void move (int x, int y, Puck *puck);
Looking at the variable 'puck', one might ask, "Is it a puck or a
pointer to puck." Of course, the answer is, "It is a pointer to
puck.", but nevertheless the chosen name implies that it is a puck.
Perhaps those who subscribe to this style of coding seriously
underestimate the liberating power of judiciously chosen parameter
names.
Before the advent of C++, a better choice of name might have been
'pointer_to_puck', but C++ references obviates this type of long
naming and allows us to achieve strong parity between the name chosen
and the abstraction represented.
Now, we can write:
void move (int x, int y, Puck &puck);
All is clear. 'puck', indeed, refers to a puck. Had we used the
former method, we would have written inside of move':
{
....
puck-> .... //...
}
...which implies that 'puck' is not a puck but a pointer to a puck.
|
More than implies. It absolutely, positively guarantees that it is a
pointer to an object, not the object itself.
| Quote: | I am not being pedantic here. Our power to reason about large systems
actually increases when one can write instead:
{
....
puck. //...
|
Perhaps not pedantic, but obscure. How does "out power to reason
about large systems actually increase" just because we write
puck.member as opposed to puck->member? I don't see any significant
gain.
| Quote: | ....
}
It seems that the use of references in this manner is often overlooked
or underemphasized in books and teachings on C++. I believe that it
is so important that *not* programming using this style ultimately
hinders object-oriented thinking.
To all C++ progammers, especially those who had deep exposure to C
prior to C++, I ask..
Do you prefer the pointer method or the reference method?
|
I can certainly speak as one with deep exposure to C before C++.
Personally, I prefer pointers to references if the function will
modify the object.
When I read the call to the function, seeing:
some_function(&my_puck);
.....immediately tells me I am passing a pointer, and warns me the
function may modify the object, without even looking for the
prototype.
Whereas:
some_function(my_puck);
.....does not immediately me if the function is being called by value,
and therefore can't modify the value of my_puck, or is being called by
reference and just might change my object on me. I need to look up
the function prototype to know for sure.
Similarly, it easy to spot a function modifying an object to which it
received a pointer, less so with the syntax for a reference. That's
one of the reasons I am not in favor or modifying C++ to allow the .
operator notation to be used on pointers.
If the parameter is not modified by the function, I have no issue with
passing by constant reference.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Mirek Fidler
Guest
|
| Posted: Mon Jun 30, 2003 9:46 am Post subject: Re: Pointers vs References: Judicious Choice Of Parameter Na |
|
|
| Quote: | To all C++ progammers, especially those who had deep exposure to C
prior to C++, I ask..
Do you prefer the pointer method or the reference method?
|
Long ago I came into similiar question and my not definitive, but
somewhat reasonable answer is: Is the parameter allowed to be NULL ? If
it is, you must use pointer, if it is not, prefer reference.
Mirek
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
llewelly
Guest
|
| Posted: Mon Jun 30, 2003 4:00 pm Post subject: Re: Pointers vs References: Judicious Choice Of Parameter Na |
|
|
[email]unoriginal_username (AT) yahoo (DOT) com[/email] (Le Chaud Lapin) writes:
[snip]
| Quote: | Do you prefer the pointer method or the reference method?
[snip] |
They are overlapping, but not interchangeable.
(a) A pointer can be assigned to, making it point to a different
object.
(b) A pointer is a random access iterator.
(c) A pointer may be a null pointer, indicating it does not point
to any object.
If you need (a), (b), or (c), you need a pointer, and a reference will
not be acceptable.
If you do not need any of (a), (b), or (c), a reference is preferred,
as accidental misuse of (a), (b), or (c) can result in hard to
find bugs.
w.r.t. to OO programming:
- IMO it is uncommon (and unsafe) to use arrays of polymorphic
objects. (Though arrays of pointers to polymorphic objects are
used.) So (b) is not often needed in OO programming.
- Often, only functions dealing with the creation and destruction
of objects need to use (a) or (c).
So OO code should rely largely on references though pointers or
smart pointers are usually needed in a few places.
However, IMO polymorphism naturally implies (and in C++ requires) a
layer of indirection, and a pointer is just as good a
representation of that layer as a reference. I don't believe using
pointers instead of references 'hinders' OO thinking directly,
though it may make your code a bit more error-prone.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Le Chaud Lapin
Guest
|
| Posted: Mon Jun 30, 2003 9:03 pm Post subject: Re: Pointers vs References: Judicious Choice Of Parameter Na |
|
|
Jack Klein <jackklein (AT) spamcop (DOT) net> wrote
| Quote: | {
....
puck-> .... //...
}
...which implies that 'puck' is not a puck but a pointer to a puck.
More than implies. It absolutely, positively guarantees that it is a
pointer to an object, not the object itself.
I am not being pedantic here. Our power to reason about large
systems
actually increases when one can write instead:
{
....
puck. //...
Perhaps not pedantic, but obscure. How does "out power to reason
about large systems actually increase" just because we write
puck.member as opposed to puck->member? I don't see any significant
gain.
|
Because 'puck.member' gives the impression that puck is an aggregate
and 'member' is a portion of the aggregate. So if we were to drop the
'puck' on the floor, it would disintegrate into pieces, with 'member'
being one of the pieces. Furthermore, putting the pieces back together
should allow us to reconstruct 'puck'. This is the way the mind of an
architect works best.
Now if we are building a large system that has thousands of pucks, and
at some point in the code we see....
puck-> ...
we can no longer allow the name "puck" to invoke in our minds an image
of an aggregate object that can be dropped on the floor. Instead, we
have to rethink our notion and say, "Ok...scracth what I thought
before. Now, 'puck' is not really a puck at all, but a small piece of
information point to something that I *could* drop on the floor." To
resue Bjarne's quote....
"Language shapes the way we think, and determines what we can think
about."
- B. J Whorf
| Quote: | Personally, I prefer pointers to references if the function will
modify the object.
When I read the call to the function, seeing:
some_function(&my_puck);
....immediately tells me I am passing a pointer, and warns me the
function may modify the object, without even looking for the
prototype.
Whereas:
some_function(my_puck);
....does not immediately me if the function is being called by value,
and therefore can't modify the value of my_puck, or is being called by
reference and just might change my object on me. I need to look up
the function prototype to know for sure.
|
In the vast majority of your code, you should be able to infer the
consequences argument passing by reference from the context on your
code. One should not engineer rely on the syntax of a language to
provide insight into how the system works.
| Quote: | Similarly, it easy to spot a function modifying an object to which it
received a pointer, less so with the syntax for a reference. That's
one of the reasons I am not in favor or modifying C++ to allow the .
operator notation to be used on pointers.
|
Eeeeh!!! Allow the . operator to be used on pointers? You're joking
right?
| Quote: | If the parameter is not modified by the function, I have no issue with
passing by constant reference.
|
That's what 'const' is for.
-Chaud Lapin-
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
llewelly
Guest
|
| Posted: Tue Jul 01, 2003 8:05 am Post subject: Re: Pointers vs References: Judicious Choice Of Parameter Na |
|
|
[email]unoriginal_username (AT) yahoo (DOT) com[/email] (Le Chaud Lapin) writes:
| Quote: | Andy Sawyer <andys (AT) despammed (DOT) com> wrote
The crucial difference is that a pointer may point to something other
than the 'value type' - specifically, it might be a null pointer which
indicated the abscence of an object:
void foo( Puck *puck )
{
if( puck )
{
puck->do_something();
}
else
{
do_something_else();
}
}
Hi Andy,
Your is essentially equivalent to that given by several other
responders to my post, so I ask them and you the following question:
Now that you have determined that the parameter 'puck' refers to a
pointer to a puck and not a puck, do you change the name from 'puck'
to something else or do you leave it alone.
[snip] |
If the object is typically manipulated via pointers, I name the
pointer 'puck', on the grounds that the normal way of referring to
something should not have a special wart or naming convention.
If the object is typically manipulated by value, I name the pointer
according to its purpose (and not according to object's purpose);
since the pointer is not the normal way of referring to the
object, it should not have a name that might be used for the
object.
I don't know if this is 'best practice' but I haven't found any major
pitfalls in it.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Dave Harris
Guest
|
| Posted: Tue Jul 01, 2003 8:10 am Post subject: Re: Pointers vs References: Judicious Choice Of Parameter Na |
|
|
[email]unoriginal_username (AT) yahoo (DOT) com[/email] (Le Chaud Lapin) wrote (abridged):
| Quote: | Now that you have determined that the parameter 'puck' refers to a
pointer to a puck and not a puck, do you change the name from 'puck'
to something else or do you leave it alone.
|
I'd rename it, probably to "pPuck".
-- Dave Harris, Nottingham, UK
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
llewelly
Guest
|
| Posted: Tue Jul 01, 2003 8:13 am Post subject: Re: Pointers vs References: Judicious Choice Of Parameter Na |
|
|
[email]unoriginal_username (AT) yahoo (DOT) com[/email] (Le Chaud Lapin) writes:
[snip]
| Quote: | Eeeeh!!! Allow the . operator to be used on pointers? You're joking
right?
[snip] |
Why the shriek of horror? Do you know of a concrete problem that might
be caused allowing the . operator to act as a synonym for -> in
the case where the lhs is a pointer?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Shannon Barber
Guest
|
| Posted: Tue Jul 01, 2003 8:22 am Post subject: Re: Pointers vs References: Judicious Choice Of Parameter Na |
|
|
Ed Avis <ed (AT) membled (DOT) com> wrote
| Quote: | Jack Klein <jackklein (AT) spamcop (DOT) net> writes:
some_function(my_puck);
....does not immediately me if the function is being called by value,
and therefore can't modify the value of my_puck, or is being called
by reference and just might change my object on me. I need to look
up the function prototype to know for sure.
It seems unfortunate that the syntax for initializing a reference
looks different for that for initializing a pointer. If references
were used like
int i = 55;
int& ir = &i;
std::cout << 7 * ir; // etc
then your function call would be
some_function(my_puck);
for pass by value, and
some_function(&my_puck);
for pass by reference (whether implemented using C++ references or C++
pointers).
Alas it's too late to fix this now  .
|
I agree completely - this fixes the 'references produce write-only-code' problem.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Shannon Barber
Guest
|
| Posted: Tue Jul 01, 2003 8:22 am Post subject: Re: Pointers vs References: Judicious Choice Of Parameter Na |
|
|
Jack Klein <jackklein (AT) spamcop (DOT) net> wrote in message
| Quote: | ...which implies that 'puck' is not a puck but a pointer to a puck.
More than implies. It absolutely, positively guarantees that it is a
pointer to an object, not the object itself.
|
I think that's too strong, -> could be overloaded and pathologically
return a copy. Somewhat ironically, this is the case where references
need to be used (and IMHO the only non-const case, returns to meet
syntactic goals).
| Quote: | I am not being pedantic here. Our power to reason about large systems
actually increases when one can write instead:
{
....
puck. //...
Perhaps not pedantic, but obscure. How does "out power to reason
about large systems actually increase" just because we write
puck.member as opposed to puck->member? I don't see any significant
gain.
|
I agree, I don't see instric value in either -> or . (other than . is
easier to type). However, move(uck) and move(&uck) is a different
story.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Tue Jul 01, 2003 7:31 pm Post subject: Re: Pointers vs References: Judicious Choice Of Parameter Na |
|
|
In message <memo.20030630211147.33911F (AT) brangdon (DOT) madasafish.com>, Dave
Harris <brangdon (AT) cix (DOT) co.uk> writes
| Quote: | unoriginal_username (AT) yahoo (DOT) com (Le Chaud Lapin) wrote (abridged):
Now that you have determined that the parameter 'puck' refers to a
pointer to a puck and not a puck, do you change the name from 'puck'
to something else or do you leave it alone.
I'd rename it, probably to "pPuck".
|
Well I would prefer puck_ptr but I expect that I would rarely need such
names having just written an entire book using C++ without once using an
explicit pointer :-)
--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow ACCU
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Tue Jul 01, 2003 7:32 pm Post subject: Re: Pointers vs References: Judicious Choice Of Parameter Na |
|
|
In message <de001473.0306301724.6653fb55 (AT) posting (DOT) google.com>, Shannon
Barber <shannon.barber (AT) myrealbox (DOT) com> writes
| Quote: | It seems unfortunate that the syntax for initializing a reference
looks different for that for initializing a pointer. If references
were used like
int i = 55;
int& ir = &i;
std::cout << 7 * ir; // etc
then your function call would be
some_function(my_puck);
for pass by value, and
some_function(&my_puck);
for pass by reference (whether implemented using C++ references or
C++
pointers).
Alas it's too late to fix this now .
I agree completely - this fixes the 'references produce
write-only-code' problem. |
Are you serious? Have I missed some sarcasm. One of the most important
motivations for references was support for operator overloading. The
above syntax would cripple that use. It was always too late to fix that
feature of the language and it is also why C cannot provide operator
overloading (unless it also adopts references)
--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow ACCU
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Le Chaud Lapin
Guest
|
| Posted: Wed Jul 02, 2003 12:49 am Post subject: Re: Pointers vs References: Judicious Choice Of Parameter Na |
|
|
[email]shannon.barber (AT) myrealbox (DOT) com[/email] (Shannon Barber) wrote in message news:<de001473.0306301731.34be58a2 (AT) posting (DOT) google.com>...
| Quote: | I agree, I don't see instric value in either -> or . (other than . is
easier to type). However, move(uck) and move(&uck) is a different
story.
|
Keep in mind that my objective here is not illustrate whether
pass-by-pointer or pass-by-reference is better, nor is it to
excessively reflect on the -> and . operators.
My objective is something perhaps more subtle. It is to illustrate
that there are fundamenatal operations on data in any object oriented
system, and those operations are applied to objects, but because a
human's ability to conceive of abstract objects in an object space is
highly influenced by names chosen to represent those objects, poor
choice of names may lead to obfuscation.
The operations I am referring to are member selection and dereference,
(typically) denoted by . and ->, respectively, in C++. To ensure that
we do not become overly burdened with syntax of C++ in our argument,
let us rename these operations to be {S} and {D} for "select" and
"derefernce", so that {S}=. and {D}=->.
I would also like to change from the "puck" of our original example,
to "camera", for better illustration.
Given a camera, the lens would be selected as:
camera{S}lens
Similary, the battery would be selected as camera{S}battery.
A programmer reasoning abstractly about these operations would think.
"Ok, I get it. If I have a thing, and I want to yield a member of the
thing, I should apply the {S} operator to the thing to get the
member."
Next, we perform an experiement. We take an ordinary individual,
someone who has never programmed a computer before, and ask him to
draw on a piece of paper the image that comes to mind when a certain
word is uttered. We say "horse", and the individual draws a horse.
We say "car", and the individual draws a car. We say, "camera", and
the individual draws a camera. We proceed to explain to this
individual the notion of member selection on an object in the general
sense, and ask the individual to select various members of the camera
using the selection operator. After, say, 5 minutes of practice, the
individual is able to consistently select members of the objects using
the {S} operator. We say, "Show us how to get to the film from the
camera", and the individual correctly writes "camera{S}film"
We go the programmer, who is also human, and ask him the same
questions, but at the age of 15, before he has any computer
experience, and he responds similarly.
Ten years later, after the programmer gains computer experience, we
repeat the same experiment, to prove to ourselves he is still able to
reason abstractly about selection, and it presents him no difficulty.
Next, we take a group of individuals in room, perhaps 20, including
the programmer, and ask them to participate in a similar experiment.
The moderator will say a word, and the their goal is to draw as
quickly as possible an image of whatever word is uttered. We say,
"pencil", "frog", "tree", "atom", "dodecahedron", "golgi apparatus",
"airplane", and "snake". After the image is drawn, we ask them to
select members of the drawn object by outlining it. For the "atom",
the participants will outline the nucleus.
We ask everyone to leave except the programmer. With him alone., we
subject him to 500 iterations of this experiment, but with a twist.
Instead of saying a word, we show two images, one image to show an
object, and a second that is a member of the object. We ask him to
express using the {S} operator how one might get to the second object
via the first. We show the images with lightning speed:
"coat/collar", "house/kitchen", "coffe maker/filter", "jack
hammer/bit", each time asking him write a word for the first object,
the {S} operator, and a word for the second object. After he has done
500 iterations, we ask him to revert to C++ syntax for the selection
operator.
Finally we show a camera followed by a flash, and he writes:
camera.flash
"Good", we say. We ask him if he is sure of his answer, and he says,
"Well, yes.."
Then we pull out some C++ code that he had written a year earlier that
looks like this:
camera->flash ...;
And ask him, "Why did you write that?"
He says, "I wanted to get to the flash of the camera"
We ask, "Why did you not write 'camera.flash'"?
His response: "Because camera is not a camera."
-Chaud Lapin-
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
