Re: OT: Language War (Re: "C" Manual)
On Thu, 3 Jan 2002 09:31:16 -0500, dman <dsh8290@rit.edu> wrote:
[snip]
> | > If you wrote a wrapper around free() that took a pointer to a pointer
> | > you _could_ then assign NULL to the second pointer, but that, of
> | > course, assumes that inside free() you have a valid pointer to
> | > dereference in the first place.
> |
> | A macro is easier (vile things that they are...)
>
> Well, yeah, I was forgetting about them.
>
> | #define FREE(p) {if(p){free(p); (p)=NULL;}}
>
> However the thing to remember about macros is that they are textual
> substituation. It is effectively the same thing as writing the
> assignment yourself.
Yes, but for a little block of code that you'd use often, you don't
have to repeat it gadzillion times, and the result should be easier
to read. Problem is, these things can be abused. Add a bunch of
global data structs, and you've got a nearly impossible to maintain
chunk of code...
> | I've had occasion to use some replacement macros for malloc and realloc as
> | well. The realloc being the more useful. Inline functions are
> | cleaner though...
>
> inline functions are really no better than macros, and can even cause
> bugs (though surely that's just a sign of a buggy compiler).
>
> For a particular school project (C++ required) the profs had a working
> demo that we could run to verify our output (and clarify anything in
> the specs). They compiled it without debug symbols so we couldn't
> look at it in a debugger and reverse-engineer it. Their demo would
> crash with certain malformed input. One of the profs tried to figure
> it out, but once it was recompiled with debug symbols (which also
> turns off inlining, for that compiler at least) the program worked
> correctly. They had used inline functions extensively in their
> code.
I think there are some subtle differences between inlining C++ and
inlining C. Since, I haven't done any C++ for a couple years, I
was thinking in C. Anyway, the type of bug you describe sounds
more like the kind of bugs that are real, but somehow you got away
with it until you switched compilers or turned on some optimizations.
> There's no real point to an inline function, just make it a regular
> function. The overhead of a function call isn't very big, especially
> nowadays.
Well, can't say I've ever gotten into the habit of using "inline". It's
just not portable enough in C, without going through a bunch of configure
feature tests and macro substitutions (when it's not recognized). But I
expect it could make a substantial difference when the function in
question is often used in looping constructs. But, you know what they
say about premature optimization...
--
Eric G. Miller <egm2@jps.net>
Reply to: