#### Archived

This topic is now archived and is closed to further replies.

# int& value vs. int* pValue???

This topic is 6082 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Can someone tell me what the point in defining a function like this is:
int fnA(int& value)
{
value = 10;
}

instead of doing it like this:
int fnB(int* pValue)
{
*value = 10;
}

As far as I can see they both do the same thing. -René

##### Share on other sites
I only use references when I want to pass in-only structures. Passing structures by value is inefficient and passing them by pointer if you''re not going to be changing them is annoying, so you pass them by const reference instead.

e.g. void func(const HugeStruct &hs);

Then I can call it as func(hs) instead of func(&hs) and not lose efficiency.

Passing something by a non-const reference (like you''re doing with fnA) is generally bad because it''s not obvious from the code that fnA will change the value or not. e.g. If I say fnA(x) I''d be really annoyed if x came back different.

-Mike

##### Share on other sites
Just a note, you could get a nasty exception if you pass NULL
to that second function. Consider that. They are similar but
not really the equal.

##### Share on other sites
The exception can get even nastier if it is an uninitialized pointer instead of NULL. But I think that would be one of the main advantages of references. You don''t have to test for NULL in your functions and still be able to feel safe about it

You can also access structure data members as if it was a local data structure. i.e.: myStruct.member as opposed to myStruct->member

Seeya
Krippy

##### Share on other sites
On the other hand, pointer input arguments can act as a tri-state (in digital design-speak), so they can have benefits too. Example:
  void Widget::setColor (COLORREF *fg, COLORREF *bg){ if (fg) m_clrFg = *fg; if (bg) m_clrBg = *bg;}

Obviously, if I want to just set the foreground or just the background and leave the other the way it was, I can do so with the above code. You can't do that with references.

I like to use pointers where I'd like the option of not specifying a parameter, and references when the parameter must exist. However, I have heard that you should never use references in the parameter list because it confuses those who haven't quite left their C roots behind. I don't agree, but I have heard it; if you're working in a team environment, you might consider the style of your coworkers before deciding to go reference-happy.

Edited by - Stoffel on June 29, 2001 12:11:59 PM

##### Share on other sites
Pathological example to defy the logic of the last few post:
Why & is not any more-or-less exception proof than *.
  int A;int* p=0;fnA(A); //no problem, not nullfnB(&A); /no problem, it can''t be null either.fnB(p); //BOOM!fnA(*p); //Whoops, also BOOM!

The only difference is what you type; they even work the same way beneath the code.
With the exception of operator overloads, you should only pass by const&, a-mon-avis. If you''re going to change it, clue them in with a *.

##### Share on other sites
actually you can use both ways
it''s just for when one reads the code he will understand it better!

hmm now another thing is that
when you use a & you HAAAAAVVVVVEEEEE to refere some object

and when you use * you can point a null
but your function will have to check for it before using it

in references you MUST refer to something
otherwise......CRAP

Arkon
[QSoft Systems]

##### Share on other sites
int A;
int* p=0;
fnA(A); //no problem, not null
fnB(&A); //no problem, it can''t be null either.
fnB(p); //BOOM!
fnA(*p); //Whoops, also BOOM!

Well that last line is not gonna boom inside of fnA, so it''s not really the same. It is going to boom when trying to come up with an answer for *p to push onto the stack before calling fnA. *p means ''what is at the address of p'' which the system will never let you know since p is null.

Seeya
Krippy

##### Share on other sites
Don''t forget the all-important reason, the one why references were added to C++: return references for function chaining.

For those that use it anyway. It''s how

cout << "Hello " << "world!";

works. The << operator for cout returns a reference to itself. So after each call you''re left with ''cout'' again. Imagine this using pointers:

*(cout << "Hello ") << "world!";

All this to replace printf-style formatting. Go figure.

##### Share on other sites
Ahhhhhhhhhhh!

I was mistaken.

It does not actually try to resolve *p before calling fnA. So you would need to test if (&value != NULL) in Magmais example.

Oops

Seeya
Krippy

##### Share on other sites
So unless you''re dealing with pathological programmers, you should never have to check if the address of a reference is 0. Don''t have my ARM on me, but I''m 98% sure that the code MKH posted has undefined behavior, meaning it''s the caller''s fault, not the function''s fault, if something breaks.

##### Share on other sites
Yes, definitely the callers fault. If the function took a standard int argument instead of a reference the code would still crash. The difference is this time you WILL crash trying to resolve *p for the function call instead of crashing inside the function.

Seeya
Krippy

##### Share on other sites
Methinks references vs. pointers is another one of them style arguments. I don''t like references because they are inherently ambiguous.

However, if you''re using C++ as an adapter language for scripting (for instance), you don''t want your designers to worry about indirection.