references and pointers

[MQ]

Can someone tell me where I should use pointers and where I should use
references? In his book, Stroustrup says that you should use pointers
for passing arguments that are to be modified, not references. Yet,
in an interview, he laments the overuse of pointers and such in code.
It seems contradictory to me. Why should we not use references
instead of pointers? Can someone give me an idea of best practices in
this respect?

regards,
B.

[Juha Nieminen]

MQ wrote:

Can someone tell me where I should use pointers and where I should use
references? In his book, Stroustrup says that you should use pointers
for passing arguments that are to be modified, not references. Yet,
in an interview, he laments the overuse of pointers and such in code.
It seems contradictory to me. Why should we not use references
instead of pointers? Can someone give me an idea of best practices in
this respect?

Think about the basic difference between references and pointers:
Pointers can be made to point to something else than what they were
initialized to point to (including null) while references can't.

This, IMO, gives a good rule of thumb for the decision: If you don't
need to change where the thing is pointing, use references, else use
pointers.

[borophyll]

On Nov 4, 11:20 am, Juha Nieminen <nos...@thanks. invalidwrote:

MQ wrote:

Can someone tell me where I should use pointers and where I should use
references? In his book, Stroustrup says that you should use pointers
for passing arguments that are to be modified, not references. Yet,
in an interview, he laments the overuse of pointers and such in code.
It seems contradictory to me. Why should we not use references
instead of pointers? Can someone give me an idea of best practices in
this respect?

Think about the basic difference between references and pointers:
Pointers can be made to point to something else than what they were
initialized to point to (including null) while references can't.

This, IMO, gives a good rule of thumb for the decision: If you don't
need to change where the thing is pointing, use references, else use
pointers.

Why then does Stroustrup make the following statement in his book:

"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"

This says to me that we in fact should *not* use references in this
way

[Ian Collins]

bo*******@gmail .com wrote:

On Nov 4, 11:20 am, Juha Nieminen <nos...@thanks. invalidwrote:

>MQ wrote:

>>Can someone tell me where I should use pointers and where I should use
references? In his book, Stroustrup says that you should use pointers
for passing arguments that are to be modified, not references. Yet,
in an interview, he laments the overuse of pointers and such in code.
It seems contradictory to me. Why should we not use references
instead of pointers? Can someone give me an idea of best practices in
this respect?

Think about the basic difference between references and pointers:
Pointers can be made to point to something else than what they were
initialized to point to (including null) while references can't.

This, IMO, gives a good rule of thumb for the decision: If you don't
need to change where the thing is pointing, use references, else use
pointers.

Why then does Stroustrup make the following statement in his book:

"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"

He made a mistake? Or possibly idiomatic style has changed over time.

--
Ian Collins.

[borophyll]

On Nov 4, 12:00 pm, Ian Collins <[e-mail] mwrote:

boroph...@gmail .com wrote:

On Nov 4, 11:20 am, Juha Nieminen <nos...@thanks. invalidwrote:

MQ wrote:
Can someone tell me where I should use pointers and where I should use
references? In his book, Stroustrup says that you should use pointers
for passing arguments that are to be modified, not references. Yet,
in an interview, he laments the overuse of pointers and such in code.
It seems contradictory to me. Why should we not use references
instead of pointers? Can someone give me an idea of best practices in
this respect?
Think about the basic difference between references and pointers:
Pointers can be made to point to something else than what they were
initialized to point to (including null) while references can't.

This, IMO, gives a good rule of thumb for the decision: If you don't
need to change where the thing is pointing, use references, else use
pointers.

Why then does Stroustrup make the following statement in his book:

"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"

He made a mistake? Or possibly idiomatic style has changed over time.

--
Ian Collins.

Are you serious? This is in the most recent version of "The C++
programming language", and he mentions this point in several
locations. Hardly an editing mistake. Let me just state that I am
not debating that the point he makes seems right, it does not seem
right to me, but it seems to be more than just a mistake.

[Ian Collins]

bo*******@gmail .com wrote:

On Nov 4, 12:00 pm, Ian Collins <[e-mail] mwrote:

>boroph...@gmai l.com wrote:

>>Why then does Stroustrup make the following statement in his book:
"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"

He made a mistake? Or possibly idiomatic style has changed over time.

*Please* don't quote signatures.

>
Are you serious? This is in the most recent version of "The C++
programming language", and he mentions this point in several
locations. Hardly an editing mistake. Let me just state that I am
not debating that the point he makes seems right, it does not seem
right to me, but it seems to be more than just a mistake.

http://www.research.att.com/~bs/bs_f...and-references

Puts a different view across, so one of my guesses was probably true.

I'd only recommend using pointers when the argument can meaningfully be
NULL, or when interfacing with legacy code.

--
Ian Collins.

[Tim H]

On Nov 3, 8:15 pm, Ian Collins <[e-mail] mwrote:

I'd only recommend using pointers when the argument can meaningfully be
NULL, or when interfacing with legacy code.

Or when you need to store a "reference" (for lack of a better term) to
a shared object in a class that must be STL container-compatible
(assignable).

I admit that I am newish to C++, but the pattern I have found is that
I only use references when passing arguments. I try hard never to use
"out" variables, but when I do, I use pointers.

[Jim Langston]

"Ian Collins" <ia******@hotma il.comwrote in message
news:5p******** *****@mid.indiv idual.net...

bo*******@gmail .com wrote:

>On Nov 4, 12:00 pm, Ian Collins <[e-mail] mwrote:

>>boroph...@gma il.com wrote:

>>>Why then does Stroustrup make the following statement in his book:
"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"
He made a mistake? Or possibly idiomatic style has changed over time.

*Please* don't quote signatures.

>>
Are you serious? This is in the most recent version of "The C++
programming language", and he mentions this point in several
locations. Hardly an editing mistake. Let me just state that I am
not debating that the point he makes seems right, it does not seem
right to me, but it seems to be more than just a mistake.

http://www.research.att.com/~bs/bs_f...and-references

Puts a different view across, so one of my guesses was probably true.

I'd only recommend using pointers when the argument can meaningfully be
NULL, or when interfacing with legacy code.

I was actually debating this with myself 2 days ago. Someone gave me some
code work on, he was using pointers to modify the parameters. I started to
change them to references, then realized that in mainline, there is no
indication if the parameter was going to be changed or not.

Consider.

void foo( int* Val )
{
*Val = 23;
}

void bar( int& Val )
{
Val = 23;
}

int main()
{
int MyInt = 10;
foo( &MyInt );
bar( MyInt );
}

Becaue Foo forces us to take the address of MyInt, it is fairly obvious in
mainline that MyInt is probably going to be changed, else why pass the
address of a simple int? bar however gives no indication in mainline that
MyInt will be changed.

Maybe that is the reasoning behind it.

Reguardless, I did go ahead and change them all to references anyway.

[Ian Collins]

Jim Langston wrote:

"Ian Collins" <ia******@hotma il.comwrote:

>http://www.research.att.com/~bs/bs_f...and-references

Puts a different view across, so one of my guesses was probably true.

I'd only recommend using pointers when the argument can meaningfully be
NULL, or when interfacing with legacy code.

I was actually debating this with myself 2 days ago. Someone gave me some
code work on, he was using pointers to modify the parameters. I started to
change them to references, then realized that in mainline, there is no
indication if the parameter was going to be changed or not.

Consider.

void foo( int* Val )
{
*Val = 23;
}

void bar( int& Val )
{
Val = 23;
}

int main()
{
int MyInt = 10;
foo( &MyInt );
bar( MyInt );
}

Becaue Foo forces us to take the address of MyInt, it is fairly obvious in
mainline that MyInt is probably going to be changed, else why pass the
address of a simple int? bar however gives no indication in mainline that
MyInt will be changed.

A good example of why you should give functions meaningful names.

--
Ian Collins.

[Kira Yamato]

On 2007-11-04 01:52:26 -0400, "Jim Langston" <ta*******@rock etmail.comsaid:

>
"Ian Collins" <ia******@hotma il.comwrote in message
news:5p******** *****@mid.indiv idual.net...

>bo*******@gmail .com wrote:

>>On Nov 4, 12:00 pm, Ian Collins <[e-mail] mwrote:
boroph...@gm ail.com wrote:

>>>>Why then does Stroustrup make the following statement in his book:
"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"
He made a mistake? Or possibly idiomatic style has changed over time.

*Please* don't quote signatures.

>>>
Are you serious? This is in the most recent version of "The C++
programming language", and he mentions this point in several
locations. Hardly an editing mistake. Let me just state that I am
not debating that the point he makes seems right, it does not seem
right to me, but it seems to be more than just a mistake.

http://www.research.att.com/~bs/bs_f...and-references

Puts a different view across, so one of my guesses was probably true.

I'd only recommend using pointers when the argument can meaningfully be
NULL, or when interfacing with legacy code.

I was actually debating this with myself 2 days ago. Someone gave me some
code work on, he was using pointers to modify the parameters. I started to
change them to references, then realized that in mainline, there is no
indication if the parameter was going to be changed or not.

Consider.

void foo( int* Val )
{
*Val = 23;
}

void bar( int& Val )
{
Val = 23;
}

int main()
{
int MyInt = 10;
foo( &MyInt );
bar( MyInt );
}

Becaue Foo forces us to take the address of MyInt, it is fairly obvious in
mainline that MyInt is probably going to be changed, else why pass the
address of a simple int? bar however gives no indication in mainline that
MyInt will be changed.

Maybe that is the reasoning behind it.

Reguardless, I did go ahead and change them all to references anyway.

I think you made a good call to change them to references anyway.
Otherwise, you would have to worry about people passing invalid pointer
like in foo(0).

So, like Ian Collins had stated in another post, use pointers only if
there is a need to include NULL as a possible value. But even in that
case, perhaps it is cleaner for the class to implement a singleton
object that represents the "NULL" object of the class anyway.

I'm still a newbie in C++, but I'm getting the sense that proper use of
STL should eliminate all needs of pointers. However, for efficiency
purposes, perhaps pointers should sometimes be employed, just like
'goto' is theoretically not needed but may be practically needed.

--

-kira