What are the differences between parameter definitions as (type& name), and (type* name)?

StackOverflow https://stackoverflow.com/questions/948947

  •  09-09-2019
  •  | 
  •  

Question

A very basic question, but still, it would be good to hear from C++ gurus out there.

There are two rather similar ways to declare by-reference parameters in C++.

1) Using "asterisk":

void DoOne(std::wstring* iData);

2) Using "ampersand":

void DoTwo(std::wstring& iData);

What are implications of each method? Are there any gotcha's in any case?

Bonus #1: What would be a formal way to call method in #1 and #2? Are they both called "by-reference"?

Bonus #2: std::wstring is used deliberately. What would be implications towards standard library classes in each case?

Was it helpful?

Solution

#1 uses a pointer parameter ('passing a pointer to'), #2 uses a reference parameter ('passing by reference'). They are very similar, but note that the calling code looks different in the two cases:

std::wstring s;

DoOne(&s); // pass a pointer to s
DoTwo(s); // pass s by reference

Some people prefer #1, using a convention that passing by pointer indicates that the function might change the value of s (even though either function could). Other people (myself included) prefer #2, since passing by reference does not allow NULL to be passed.

There is another important difference when passing by const pointer or reference. A temporary variable can only be passed to a const reference parameter:

void ByConstPointer(const std::wstring&);
void ByConstReference(const std::wstring*);

void test()
{
  ByConstPointer(&std::wstring(L"Hello")); // error: cannot take address of temporary
  ByConstReference(std::wstring(L"Hello")); // fine
}

OTHER TIPS

Rule number one for this: If NULL is a valid value for the function parameter in the context of the function, then pass it as pointer, otherwise pass it as reference.

Rationale, if it cannot (should not!) ever be NULL, then don't put yourself through the trouble of checking for NULL.

While writing examples, I came up with my own answer. Anything other than below?

The result of each of them is quite similar: a reference to an object in the memory ends up within method's scope. There seem to be no strict memory requirements for any of them. The object can be either on stack or in heap.

In case of stack each of the methods would be called like this:

{
    std::wstring data;
    DoOne(&data);
    DoTwo(data);
}

Yet, when it comes to the heap, the second approach would require that the object must exist before calling the method. If the object does not exist, the caller would cause exception, not the callee.

{
    std::wstring* pData = new std::wstring();
    DoOne(pData);
    DoTwo(*pData);
}

In the above, if out-of-memory condition occurs and pData ends up NULL, the crash would happen before DoTwo, but DoOne would swallow the NULL and might crash some time later.

I wouldnt call myself a C++ gure (except for on my CV), but i'd say; unless theres any use of passing the parameter as a pointer (i.e the function wants to check for null), always use a reference.

That also goes for functions returning objects, returning a pointer is somehow telling the user of the class that it might be null.

In DoOne, iData can be assigned NULL. If you use that after calling DoOne, the application will crash.

Something like

void DoOne(std::wstring* iData)
{
   //Use iData
   delete iData;
   iData = NULL;
}

and

{
    std::wstring* pData = new std::wstring();
    DoOne(pData);
    pData->someFunction(); //Crash
}

Your answer is completely wrong when you say:

The result of each of them is quite similar: a reference to an object in the memory ends up within method's scope. There seem to be no strict memory requirements for any of them.

connsider:

void f( int * p1 ) {
   int ** p2 = & p1;
}

here p1 has a definite "memory requirement" - it must exist and I must be able to take its address. Contrast this with

void f( int & r ) }
   int * p = & r;
}

here r has no existence of its own, it is merely a reference. Whem I take its address I am taking the address of the thing that r refers to.

Your remarks regarding the NULL pointer are also mistaken. Derefrencing the NULL pointer causes undefined behaviour - this may or may not result in a crash.

If you write a function that gets a variable by pointer, you'll most probably have to check if the pointer is valid (eg not NULL), else you risk program crash.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top