Message from discussion Function questions?
Received: by 10.180.82.226 with SMTP id l2mr2501750wiy.1.1346168961190;
Tue, 28 Aug 2012 08:49:21 -0700 (PDT)
From: nos...@see.signature (Richard Maine)
Subject: Re: Function questions?
Date: Tue, 28 Aug 2012 08:49:19 -0700
References: <email@example.com> <1kpfr0o.ykzota1bisho8Nfirstname.lastname@example.org> <ron-shepard-CE8DCF.email@example.com> <firstname.lastname@example.org> <aa06vrFvddU1@mid.individual.net> <email@example.com> <ron-shepard-FFDBCF.firstname.lastname@example.org> <1kph9a0.10o0f321nh0ho8Nemail@example.com> <firstname.lastname@example.org> <email@example.com>
X-Trace: individual.net CuALMSi6CQr/L3dJ5to4fQ/gycAT4KgU3SFpsvFnRQcmrCLTI6gaJaFr67qxI5USL5
User-Agent: MacSOUP/2.8.3 (Mac OS X version 10.6.8 (x86))
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> There are a few things that are much easier with pointers,
> such as linked lists and trees. For those cases, I don't see much
> wrong with functions returning pointers.
I disagree. Strongly. To the extent that my personal opinion is that
pointer function results should have never been added to the language.
> It is not good for a function to return the only pointers to
> something, such that the caller is responsible for deallocating it.
> Returning an element of a linked list or a node of a tree,
> as a pointer, shouldn't be so bad, though. There should be a
> list or tree deallocator, though.
Again, I disagree. Deallocation is not the only problem.
It is also far too easy to make a simple typo by writing = instead of =>
for the invocation of such a function. You end up with a statement that
is legal, but code that doesn't work.
I'll repeat my prior more general observation about functions, which
directly applies to those returning pointers.
If you have a function whose only references are in the simple form
x = f(arguments)
without ever involving evaluation of an expression other than the
trivial one that consists of just the function reference as the only
primary, then you are not taking advantage of the procedure being a
function. It might as well be a subroutine. The same argument applies to
the pointer form
p => pointer_function(arguments)
But with the pointer form, all invocations pretty much have to be of
that form to avoid problems. If you reference the pointer function in
the middle of an expression, you just get the dereferenced target
anyway, so that might as well just have been the result instead of the
Yes, there are rare special cases where you can get by with it. But
those are far more rare than the buggy cases, and do not, in my opinion,
justify using the error-prone form. You can always get by without the
function. Posting some example where you think the use safe is not going
to convince me that the practice is wise.
Heck, I have seen relatively experienced people in this forum post
examples of special cases where they considered pointer-valued functions
to be safe, but instead managed to illustrate my point by having a
related bug in the posted example (namely by typing = instead of =>).
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain