12

Possible Duplicate:
How expensive is it to dereference a pointer in C++?

If I've got a pointer to an object, let's say Object *ptr;, and I want to pass that to a method of the form void foo(Object& obj) I understand that I need to write:

foo(*ptr);

But why dereference ptr? Wouldn't it make sense to just pass it foo(ptr);? I'm worried *ptr might be making a copy of the original object, or at the least not merely passing to foo the address to work with.

Can anyone clear this up for me? Is passing *ptr a potential bottleneck, for code that expects this to behave just as fast as if the function had been void foo(Object *obj); and called via foo(ptr)?

Community
  • 1
  • 1
Mr. Smith
  • 4,288
  • 7
  • 40
  • 82

5 Answers5

14

I'm worried *ptr might be making a copy of the original object.

You're wrong. Dereferencing a pointer doesn't make any copy!

void f(Object & obj); //note it takes the argument by reference

Object *ptr = get();

foo(*ptr);

At the last line of this code there is no copy. The Standard gives you that guarantee.

However, if f takes the argument by value, then there will be copy.

The bottomline: the reference in the function parameter is used to avoid copy (often) or as ouput parameter (occasionally)!

Nawaz
  • 353,942
  • 115
  • 666
  • 851
14

Whether passing *ptr does make a copy or not depends on whether the called function expects an Object or an Object &.

In the former case, a copy would be made. In the latter case (i.e., your case), no copy would be made.

DevSolar
  • 67,862
  • 21
  • 134
  • 209
  • So dereferencing via `Object a = *ptr;` results in a copy (as I had expected), but dereferencing via `Object &a = *ptr;` does not result in a copy? Interesting. – Mr. Smith Jan 07 '13 at 10:25
  • 3
    @Mr.Smith: Exactly. `ptr` is a pointer to an object. `*ptr` is the object pointed to. Up to that point, no-one requires a copy. Assigning `*ptr` to a *different* object (`Object a`) requires a copy. *Referencing* the original object (via `Object & a`) doesn't. – DevSolar Jan 07 '13 at 10:47
  • 1
    @Mr.Smith: I just realized my comment above could have been worded better. Assigning `*ptr` to a different object requires a copy *because afterwards you have two objects*. Referencing the original object doesn't require a copy *because you still have only that one object*. (That's also the reason why dereferencing a pointer in itself isn't costly.) – DevSolar Jan 08 '13 at 06:58
1

Passing an object by reference just passes the pointer so foo(*ptr) is correct and won't copy the object. Why dereference it? Because the function signature wants an object, not a pointer to an object. C++ is a strongly typed language.

TheMathemagician
  • 968
  • 9
  • 21
  • C++ is not strongly typed – it’s actually not at all; but it’s static, you made a confusion. – phaazon Jan 07 '13 at 10:11
  • it’s weakly typed since you can write such a function: `short add(int x, int y) { return x+y; }` – phaazon Jan 07 '13 at 10:15
  • @sehe I think the problem is that "strongly typed" lacks a proper definition. – Andreas Brinck Jan 07 '13 at 10:16
  • C++ is *static*, put that deep in your brains. Go learn Haskell, Caml or F#, then come back with a _proper_ definition – phaazon Jan 07 '13 at 10:18
  • @skp what *exactly* is weakly typed in that function `add`? – Bartek Banachewicz Jan 07 '13 at 10:18
  • So. C++ is strongly typed, but inherits weak implicit conversions from C. I agree – sehe Jan 07 '13 at 10:20
  • Hmm .. well it's strongly typed for a suitable definition of strong and compiler settings :) Anyway that's irrelevant to the question. – TheMathemagician Jan 07 '13 at 11:02
  • 1
    @skp the existence of implicit conversions does not necessarily mean a language isn't strongly-typed. You seem to be using the strong v weak typing nomenclature in a fundamentalist way. Here's a discussion on the merits of strong v weak with Guido van Rossum and everyone seems to agree C/C++/Java are all strongly typed. http://www.artima.com/intv/strongweakP.html – TheMathemagician Jan 07 '13 at 11:17
  • @skp C++ is strongly typed because you can enforce strong type checks for custom-defined types. It’s weakly typed (only) for built-in types and conversions inherited from C. *That subset* of the language is weakly typed. Everything else is only as weakly typed as the implicit casts that you (the programmer) put into your type definitions. – Konrad Rudolph Jan 07 '13 at 11:27
0

To pass reference to a function, you have to pass the object like you do in value semantics. Pointers are not references since they are entity semantics (addresses).

If you dereference a pointer, you get an actual value, that can be embedded as a reference.

phaazon
  • 1,972
  • 15
  • 21
0

References and Pointers are the same. But References have their own advantage and that is they can not be null ( though they can but it's kinda hard to make a null reference ) so you can omit the check against the nullptr. You can use . instead of -> which is a character shorter xD. About your question since the pointers are references are the same in the end there won't be any gains choosing one over the other. I mean the codes bellow are the same when compiled.

void foo(int &r) {}

and

void foo(int *p) {}

when you use a reference there will be a dereferencing in the background. Hope it helped.

Mohsen Khaki
  • 26
  • 2
  • "pointers a[nd] references are the same in the end [when compiled]" - er, only in most (or is it all?) known implementations. The standard does not _require_ this. While maybe unlikely, it's _possible_ some platform could implement them in different ways, in which case, it might end up false that "there won't be any gains choosing one over the other" on such a system. Don't make statements like this about implementation-defined behaviour. – underscore_d Dec 07 '15 at 22:20