Subject: RE: gsfr

From: "Moore, Paul" <[email-masked]>
Date: Tue, 17 Nov 1998 16:23:25 -0000

>From: 	[email-masked][SMTP:[email-masked]]
>
>On Tue, Nov 17, 1998 at 01:31:01PM +0000, [email-masked] wrote:
>> And I strongly advise against macros like
>> 
>>     #define MyMacro()  stmt1; \
>>                       stmt2; \
>>                       stmt3;
>> 
>> These simply don't work like functions in all contexts. Use comma
>> expressions, and ?: for conditions, and remember to cast to void any
>> macro expression which is intended to act like a void function. And go
>> no further...
>
>Blargh, that's exactly what I'm talking about. Obscure macros with
>lots of code doing intransparent things. It does not matter it you
>use commas or not.

Agreed. To write good macros, you have to be careful and convoluted. But
that's a write-once problem (and macros where it's a *real* issue are
already getting too big, IMHO). The big read-many benefit is in
encapsulation (that *doesn't* just mean it's easier to read, it also,
and more importantly, means it's easy to change low-level implementation
decisions).

And none of this applies for a simple

    #define SetSticky(w) (void)((w)->sticky = 1)

>> That's simply a badly written macro. What's wrong with
>> 
>>     #define SETCHARPOINTER(c,p) (void)((p) = &(c))
> 
>That is not better in any way. You can STILL use ints without a
>warning. The point is: you use the macro correctly at first, then
>change the data type someday --> crash.

As I pointed out, I *don't* support macros which aren't semantically
equivalent to functions, except in special cases (which this isn't -
it's a hypothetical example). But here, I don't have the spec for your
SETCHARPOINTER. What is it supposed to do? Why do you want it
encapsulated like that (when there is no non-macro equivalent construct
in C)? There is no safe equivalent. In your macro (with a cast) you can
assign the address of a non-char to a char *. In mine, you can assign
the address of an int to an int *. Neither is how the macro was intended
to be used (you state). Remember, I agree with you that this sort of
(ill-defined, semantically different from a C function) macro is not
good. But if you have a real use in mind, specify it and we can discuss
cases. [BTW, if you want to insist that p is a (char *), I think you're
out of luck, as you can't express that constraint in C!]

But I won't continue this, as it just turns into an exercise in me
showing off how I can write *really* tricky macros which do fancy things
- which, as I say are a silly theoretical exercise which I wouldn't do
in real code. I would, on the other hand, write a macro to emulate an
inline function for performance reasons. But that's generally not hard
(assuming the function is small enough to *want* to inline).

Hope this helps,
Paul.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].