Comment by dustmop | Hacker News Reader

Comment by dustmop | Hacker News Reader

Parent Full thread

Well the term is not very precise if the way that you're using it and the way the article is using it are completely different. The article makes it clear that the term "pass-by-value" refers to the fact that the callers' references cannot be unseated by the function call; but it does not mean deep copies are made, like by copy constructor, hence that's why it applies to Java. Allow me to illustrate:

vector<int> numbers; void f(vector<int> args);

Due to C++'s copying, args[0] has a different address than numbers[0], because a deep copy of the vector was made. As the article states, this is not what pass-by-value is referring to, otherwise it would be false that Java / Python / Ruby et al are pass-by-value. So I disagree that the terms are clear, but rather that there is confusion around these terms. As for wanting immutability, it's almost always better for C++ code to write functions not like f but instead like this:

void g(const vector<int>& args);

And apologies for the editorializing, but I do consider this a language design flaw, one inherited from the backwards compatibility for C, which already allowed struct's to be passed (non-pointer) as args and then copied to keep the caller untouchable. It makes C++ code more verbose and more error prone, and is quite difficult for new programmers to grasp.

The value being passed in java is the value of the pointer, where the original pointer value cannot be changed by the function. This is pass-by-reference. Think of pass-by-reference as a special case of pass by value where the value of the pointer to an object is passed rather than the object itself.

If I wanted to write a function that accepted a vector and returned a slightly altered version of that vector I would make a function that does a deep copy and would return that - without ever needing to call the copy constructor myself. I think that it is nice that C++ gives me that option. I don't think that any language is flawless and it's clear that one programmer's feature is, in this case, another programmer's flaw. Keep in mind that this applies to your favorite languages as well.

Edit:

It occurs to me that the distinction is important in multithreaded programs as well. Beyond just worrying about whether or not the underlying data structure is thread safe, passing something by reference might mean sharing memory between two CPUs which can easily lead to a slowdown as the CPUs need to repeatedly flush and resynchronize what's in their cache. Thus unless I have specifically built a thread-safe class whose data has a real need to be shared between between threads I would send data from one thread to another by value rather than by reference.

You just described why I believe pythons 'implicit is always better than explicit' is the most important language design fundamental ever conceived of.

The problem with the C++ approach is that it's default (pass by copy-constructor really) is rather implicit. Your doing a potentially a ton of work with a very innocent function call, with possible side-effects. At least the 'pass a reference by value' behaves the same way EVERY time.

For example, in C++:

myobj a; somefunction(a);

That copy constructor might trigger a database hit to create a new object if myobj was some sort of ORM. It might call 23 other constructors to fully complete it's deep copy. Who knows, as it all happens rather implicitly. In python, that would look like:

a = myobj() somefunction(a)

def somefunction(p): p = copy.deepcopy(p)

In that version I'm now implicitly providing that copy. In your multi-threaded example this is still better, as I get the best of both worlds. Ya, I might lose a bit of convenience... but that explictness is worth the trade-off IMHO.

Reply on news.ycombinator.com