Re: Dynamically choosing what to "new" (Aside)
On 6/11/07 4:37 PM, in article Z0lbi.405$bP5.393@newssvr19.news.prodigy.net,
"JohnQ" <johnqREMOVETHISprogrammer@yahoo.com> wrote:
"Pat" <none@none.none> wrote in message
news:Xns994CA696125BDnone@140.99.99.130...
Interesting thread... The efficiency of the "GetName()" method wasn't
really a concern, because it was just a function I made up to illustrate
my
problem.
But in response to the comments about passing by addres vs passing by
reference vs passing by value, I really don't understand the arguments
against passing pointers as a parameter.
I don't either. Passing a pointer is fine, but you'll probably have to do
precondition checking for null with a pointer while for a reference that is
eliminated because references cannot be null. (I wonder if the standard will
eventually incorporate null references?).
The argument is against passing any parameter at all to a routine that needs
no input. In particular a class object's GetName() method requires no data
from the callee in order to return the object's name, and therefore has no
reason to accept a parameter.
It's guaranteed to be fast,
without requiring tricky compiler optimizations. And if you do it as a
rule, you don't really have a problem with it "adding complexity."
But the unneeded parameter does add complexity - which you may not mind -
but what about other programmers who might be responsible for maintaining
this code in the future? Are they likely to welcome anything that makes this
code (which after all they did not write and are not familiar with) any more
difficult to understand?
But complexity issues aside (I don't really see what they are, anyway), as
I initially said, in "real world" functions, I don't see a way around
passing pointers. If you've got a function that takes several large
objects as parameters, accesses various members of each, then returns some
value as a result, I think you'd be crazy to pass in the objects as
copies.
The added complexity is simple to identify: there is a function that should
not need a parameter - but that requires one nonetheless. So, before writing
code to call this method, the programmer has to figure out what this
mysterious parameter does - and how to use it in ways that will satisfy the
function's preconditions. And all of this work (and the opportunities for
mistakes it creates) provides no benefit that might justify these costs.
Agreed, but references were created for that very scenario I think. Nothing
wrong with pointers though either.
There are numerous reasons to avoid pointers as I/O parameters. For one, a
pointer might be NULL - a possibility that the caller or callee may not be
prepared to handle. Pointers are also likely raise issues of allocation and
deallocation as well as object lifetimes - all issues that may be difficult
to coordinate and debug.
I've really never given it much thought. It has just been an accepted
rule
of thumb at places where I've worked -- mainly game development, where
performance is crucial.
I'm willing to believe that a smart compiler might be able to optimize
pass-by-value to be *as good* as pass-by-reference, in some cases, but I
don't really see what you gain, besides maybe a longer compile time.
I don't think most will make a case for passing object instances by value.
Clearly whenever the object instance itself is the same size or smaller than
a pointer or a reference to that object would be - it makes sense to pass
the object by value. Pointers themselves are an obvious example of this
principle. Passing a pointer to a pointer (or a pointer by const reference)
for efficiency reasons would make little sense - since it is clear in the
case of a pointer object that no additional efficiency will be attained by
any calling convention other than passing the pointer by value.
And what holds for a pointer type also applies equally as well to any object
the same size or smaller than a pointer - built-in integral types for
example usually fall into this category. In fact passing a short by
reference or pointer is much more likely to be less efficient than passing
the short by value. In fact, boost even has a library "call_traits" that
pretty much automates the selection of a parameter's calling convention for
optimal efficiency based on its type.
Greg