Differences between these three signatures....

[xz]

I just wanna confirm my understanding about the differences between
the signatures as follows, which are called all in the same way:

void foo(Vertex a, Vertex b, Vertex c);
void foo(Vertex & a, Vertex & b, Vertex & c);
void foo(const Vertex & a, const Vertex & b, const Vertex & c);

In the first one, the function actually works on the local copies of
a, b and c. Whatever happens inside foo does not change anything in
the outside world.

In the second one, the function operates on the original copies of a,
b and c. Whatever foo does to a, b and c inside the function
immediately applies on the a, b and c in the outside world.

In the third one, the function operates on the original copies of a, b
and c. However it cannot change anything about a, b or c.

Is that always true, no matter how the copy-constructor of Vertex is
defined?

Basically, people use the first way when they need to only locally
change something of a, b, c but do not want that change influence the
original a, b, and c in the outside world.

People use the second way when they do want the changes to a, b, and c
apply to the original a, b, and c in the outside world. In this case,
a, b, c are actually like returned result.

People use the third way when they don't need to change anything about
a, b, and c in the function, i.e. they only read a, b, and c, and
meanwhile, they want to promote the memory-efficiency.

Is that understanding correct?

[Neelesh Bodas]

On Mar 15, 10:18*pm, xz <[e-mail]:

I just wanna confirm my understanding about the differences between
the signatures as follows, which are called all in the same way:

void foo(Vertex a, Vertex b, Vertex c);
void foo(Vertex & a, Vertex & b, Vertex & c);
void foo(const Vertex & a, const Vertex & b, const Vertex & c);

In the first one, the function actually works on the local copies of
a, b and c. Whatever happens inside foo does not change anything in
the outside world.

Yes, provided that the copy constructor for Vertex is accessible.

In the second one, the function operates on the original copies of a,
b and c. Whatever foo does to a, b and c inside the function
immediately applies on the a, b and c in the outside world.

yes, if by "outside world" you mean the objects in the caller
function. Further, if the caller function has these objects as const /
temporaries, they cannot be used as arguments to foo - since foo takes
non-const references.

In the third one, the function operates on the original copies of a, b
and c. However it cannot change anything about a, b or c.

true.

Is that always true, no matter how the copy-constructor of Vertex is
defined?

Provided it is accessible. (2) and (3) use references, and hence donot
need a copy constructor.

Basically, people use the first way when they need to only locally
change something of a, b, c but do not want that change influence the
original a, b, and c in the outside world.

People use the second way when they do want the changes to a, b, and c
apply to the original a, b, and c in the outside world. In this case,
a, b, c are actually like returned result.

People use the third way when they don't need to change anything about
a, b, and c in the function, i.e. they only read a, b, and c, and
meanwhile, they want to promote the memory-efficiency.

Is that understanding correct?

AFAIK, yes.

[James Kanze]

On 15 mar, 18:18, xz <[e-mail]:

I just wanna confirm my understanding about the differences
between the signatures as follows, which are called all in the
same way:

void foo(Vertex a, Vertex b, Vertex c);
void foo(Vertex & a, Vertex & b, Vertex & c);
void foo(const Vertex & a, const Vertex & b, const Vertex & c);

In the first one, the function actually works on the local copies of
a, b and c. Whatever happens inside foo does not change anything in
the outside world.

In the second one, the function operates on the original copies of a,
b and c. Whatever foo does to a, b and c inside the function
immediately applies on the a, b and c in the outside world.

In the third one, the function operates on the original copies of a, b
and c. However it cannot change anything about a, b or c.

Sort of. That's generally the intent, but from a language point
of view: it can modify mutable elements, it can cast away the
const (which is generally considered very bad programming
style), and it can modify the object through other expressions
which refer to it---if e.g. the function is called with a
referring to a global variable, it can always access the global
variable.

Is that always true, no matter how the copy-constructor of Vertex is
defined?

Sort of. If the copy-constructor isn't accessible, you can't
call the first at all, and you can't call the third with a
temporary (although this restriction is being dropped, I think).

Basically, people use the first way when they need to only
locally change something of a, b, c but do not want that
change influence the original a, b, and c in the outside
world.

People use the second way when they do want the changes to a,
b, and c apply to the original a, b, and c in the outside
world. In this case, a, b, c are actually like returned
result.

People use the third way when they don't need to change
anything about a, b, and c in the function, i.e. they only
read a, b, and c, and meanwhile, they want to promote the
memory-efficiency.

Is that understanding correct?

Basically. They also use one of the last two when the object
doesn't support copy, which is a fairly frequent case in many
applications.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]