Re: 'academic' problem ( speed/memory efficiency vs. human readability and
Dave Harris wrote:
SeeWebsiteForEmail@erdani.org (Andrei Alexandrescu (See Website For
Email)) wrote (abridged):
Which is why I generally advocate pass by const reference and make the
copy internally if I need to.
How about nonvirtual (including free) functions? Let's not forget going
the other way is just as short and simple (actually simpler as we
eliminate the copy). I call it premature optimization when time is
spent to implement something that may also become less understandable
in the process. In this case the code makes me feel good
performance-wise at no cost. I do recommend trying it.
Let's say we design the interface for the function before we design its
implementation. So when we are writing the function signature, we don't
know if the body will make a copy. So we make it use a const reference.
Does all this sound reasonable so far?
Now we implement the function body. We discover we do need to make a copy.
As I understand it, you are saying that we should go back and edit the
function signature to use pass-by-copy. To me this is more work,
especially as the function signature will typically be repeated in two
places, one of them a header.
It's not a big deal, obviously, but technically I think it is premature
optimisation. It's doing extra effort for the sake of performance without
profiling data to justify it.
I'm sympathetic to this argument. I myself seldom go back and change
interfaces for the sake of an optimization that's not arguably needed.
Often, however, the first implementation of a function (at least the way
I do it) involves some "negotiation" of its interface as well, for
various reasons orthogonal to optimization; not all function signatures
are as simple and clear as bool IsSorted(Iter, Iter)---which of course
in the implementation looks like bool IsSorted(Iter b, const Iter e).
:o) That little interface negotiation period is often enough to figure
out whether the function will mutate a copy of some arguments or not.
Also, the optimal signature is often quite clear from the desired
semantics. For example, it was clear to me when I sat down to write
Dirname and Basename that Dirname will be happy to mutate its argument
(for it returns a truncated version of it), while Basename will better
create its returned value from scratch, as that returned value is an
arbitrarily-positioned substring of its argument.
I also think the resulting code is less understandable, but that may be
because I am not used to your convention. Currently whenever I see someone
passing, say, a vector, by value, a mental red-flag goes up. I wonder
whether the author doesn't know how expensive copying a vector can be,
compared to passing a const reference to one. This at best distracts me
from what I am doing. At worst I'll investigate, find the function's
definition and see what it is doing.
This is partly about violating the principle of least surprise, where what
is surprising depends on local conventions. However, your convention does
make it harder to spot where someone has used pass-by-value by mistake. It
is a fairly common mistake for people new to the language. I almost want
every use of pass-by-value to have a documenting comment explaining the
optimisation :-)
I'm sympathetic to this argument too :o). Only a couple of weeks ago, I
was talking to a colleague (very bright guy) and I was appalled to learn
he doesn't use const. He said that he doesn't ever remember having a bug
because he changed something he wasn't supposed to. He did say that he
has bugs with uninitialized members - he puts them in the class and
forgets to initialize them. I found this real funny because I myself
_do_ have bugs due to changing data, so I do use const, but I don't ever
remember having had trouble with uninitialized members. It's just in the
neurons that when I add member variables, I update the constructor
"atomically" :o).
Our conclusion was that one should first protect thyself against
problems they are likely to have, and that it's hard to motivate someone
to use a feature that protects them against a nonexistent problem. By
that judgment, given that I can't remember of my accidentally passing
things by value, I'm not exposed to the problem you mention.
For all of the aforementioned reasons, I find my own convention easy to
follow, while I do understand how others might be less happy with it.
But after all, am I not paying enough (by being in grad school) for the
privilege of working independently? :o)
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]