Re: Debug my program please.
- From: glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx>
- Date: Sun, 30 Oct 2005 18:57:20 -0800
Richard E Maine wrote:
Jugoslav Dujic <jdujic@xxxxxxxxx> wrote:
(snip)
they're pretty safe as long
as you stick to returning a pointer to an already existing target. Actually, I don't see any gotchas with such approach.
If you do, please enlighten me.
1) I rarely see people doing that. Certainly it is possible and presumably happens, but I just don't see it much. Pretty much every sample I see involves allocating new memory, at least as one of the options. I prefer to simplify my message instead of having to add the footnote that they are ok as long as you do such functions that way. Pointers have enough caveats already, and that one gets lost in the noise, particularly for novice users. Or you write a function with that rule and then later it gets modified when you (or someone else) is no longer thinking about that aspect.
Well, one that I know of in some other languages is a hash table routine. You pass a pointer to your object, along with the value to be hashed. You an later see if something is in the hash table and it will return a pointer to the object, as passed previously.
It allows one to write the routine independent of the data structure needed by the user.
2) The observed error rate for such functions is really, really bad. Seems like almost every time I see a code that uses them, there's a bug in the usage. To me, this justifies a pretty big hammer for swatting the bugs. I'd rather overstate the problem if that's what it takes to get people's attention.
It isn't any better in other languages. In C if you return a pointer to newly allocated memory then the caller is expected to free it later.
3) Not so much a gotcha as a "what is the benefit?" To me, the whole
point of a function is that you can use it as part of an expression.
Life would be far uglier if, for example, instead of
x = 2.0*sin(t)
you had to write something like
real :: temp
...
call subroutine_version_of_sin(temp,t)
x = 2.0*temp
And, of course, it gets far, far worse than this for more complicated
expressions with multiple function references. For a function that
returns a pointer, you are almost always going to reference it like
p => the_function(whatever)
in which case, you could jut as well have written
call a_subroutine(p, whatever)
Both do work, but I just nee no advantage to the function form that
outweighs the number of errors I see.
It is a little more convenient in C. With call by value, you have to pass a pointer to a pointer variable as an argument, but a pointer return value is fine.
4) There is a sort of strange footnote that you can add to most of my personal recommendations, including this one. If someone is enough of an expert to fully understand why I make the recommendation and to conclude that the facts of his or her particular situation merit something contrary to my recommendation, then that is fine. On (rare) occasion I draw such conclusions myself. I don't think I recall having any code that violates this one (largely because point 3 above leaves me with little motivation to), but I've certainly violated some of my other recommendations when I thought I had enough reason to in a special case. But.... I figure that if someone needs my advice, then this is the recommendation they get. Someone who is adequately equipped to understand and deal with all the caveats shouldn't be needing my advice. (But then someone so equipped also shouldn't end up needing my help in debugging any problems that result).
That sounds about right to me.
-- glen
.
- References:
- Debug my program please.
- From: TC
- Re: Debug my program please.
- From: Richard E Maine
- Re: Debug my program please.
- From: Richard E Maine
- Debug my program please.
- Prev by Date: Re: IMPLICIT NONE (F2k8+/-)
- Next by Date: Re: cariage control (was IMPLICIT NONE (F2k8+/-))
- Previous by thread: Re: Debug my program please.
- Next by thread: Re: Debug my program please.
- Index(es):
Relevant Pages
|