Re: [tlug] lojza.h: release early, release often . . . . . . . .

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Ian" == Ian Wells <ijw@example.com> writes:

    sjt> Really, you should be aiming at exactly the necessary number
    sjt> of parentheses.

    Ian> I think it's safer to put [parens around #define values] in
    Ian> than not, because you're reducing the number of circumstances
    Ian> where you get bitten.  Generally a good idea to stick
    Ian> brackets around parameters used in defines too...

    #define thing(a, b, c) a&b|c  /* let's say this is exactly what you
    meant, with the minimum number of parentheses */
    retval=thing(x|y, z&w, v)&e|f  /* however, this almost certainly isn't
    what you meant at all */

Hey, that's cheating!  I didn't write "minimum", I wrote "necessary".
If "thing" is intended to have inline function semantics, then a layer
of parenthesis *is* necessary to implement those semantics in this case.

But Jim is putting parens around manifest constants defined as
literals.  This is absolutely unnecessary unless you've got a
non-tokenizing preprocessor, and even then you have to work pretty
hard to hurt yourself.

BTW, Ian, wouldn't you get fired for submitting code like that?  Even
(maybe especially ;-) if you're self-employed!

    >> If it starts turning into work to get them right, it's time to
    >> think about strategies for avoiding use of #define.

    Ian> This is what made me bite.  #define is crufty, I agree, but
    Ian> inline is not C89

"Premature optimization is the root of all error."  If you must port
to a C that sucks so bad that it doesn't at least ignore "inline"

#define inline

is a perfectly reasonable way to deal with it ex post.

    Ian> (and most compilers aren't C99, and since I'm on a project
    Ian> with no fixed processor or toolchain at the moment I'm quite
    Ian> appreciative of people who keep their code portable).

Hey, XEmacs runs on more platforms than NetBSD ever has (although I'm
cheating here because I'm counting CPU x OS x
window-system-or-lack-thereof, I think in context the point stands).
I appreciate portable code, too, and where portability matters it's
worth getting the defines right.

But Michal is writing project-specific code for two platforms: GNU C
on i386, and the Many Eyes Simulator.  Especially for the latter,
clarity counts.  Even on portability grounds, it's not obviously a bad
way to go.  It's much easier to port clear code than it is to verify
that obscure code is portable.

    Ian> And enum {x=1.23} simply doesn't work.

I did mention ints, did I not?


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.