Date: Wed, 4 Sep 2002 16:04:51 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Bruce Evans <bde@zeta.org.au>, Julian Elischer <julian@elischer.org> Cc: <arch@FreeBSD.ORG> Subject: Re: Process/thread states. Message-ID: <p05111702b99c127a7e2c@[128.113.24.47]> In-Reply-To: <20020905041751.F2483-100000@gamplex.bde.org> References: <20020905041751.F2483-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 4:30 AM +1000 9/5/02, Bruce Evans wrote: >On Wed, 4 Sep 2002, Julian Elischer wrote: > > > > The reason I consider using Macros to test and set these states is > > that several people suggested it as a way to abstract away the > > possible complications of the states. I'm kind of curious that > > almost no-one seems to have comments on this consider it's what > > I would consider to be prime arguing material. > > >> apparently no-one cares any more.. > >Macros are easier to write and maintain but harder to read and debug. >Especially the maintain and debug parts. Speaking for myself, in my own little tiny corner of the world (printing), one of the biggest problems I have with LPRng is that it has so many macros for everything. You effectively end up with a specialized language which is using cpp as the "compiler", instead of reading plain C code. Every time you're reading along, you have to stop and go back to see "what is this macro REALLY doing?". That's just me, of course -- ymmv. Chances are that I will never ever be debugging the kernel-level code that you're working on, so in that sense I don't want to annoy you with a debate over what you're doing (aka "I don't care"). And obviously I am happy to define the occasional macro when I'm writing code for lpr, but in general I find it frustrating when I'm debugging any code which resorts to macros for too many things. It is particularly bad if the code *sometimes* uses macros to fiddle with a given value, and other times it will operate directly on the value. Thus, the problem isn't that the macro itself is wrong, but that the macro hides a bug which is caused by some *other* code around the macro, which is manipulating the same variables but has no obviously-visible connection to the macro. This is just a matter of me rambling though. At the moment I'm fighting a samba server (running on linux...) which has suddenly decided to crash every six hours (now that our semester has started up), and this topic is a welcome diversion from that extreme irritation... Cheerio. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05111702b99c127a7e2c>