| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | #defines |
G'Day David,
-=> Quoting David Nugent to Frank Adam <=-
> DN> if (*MK_FP(here,there)) /* Or VAL if this is your preferred
> DN> obfuscation */ fptr = func1;
> Me?Obfuscate?Never!:-)
DN>The correct syntax is:
DN> Me ? Obfuscate : !Ever; /* :-) */
I should've known that:-)
DN> Don't worry about me - I'm a little jaded on gratuitous use of
DN> #define. Some folks want to write C in other languages (like
DN> Pascal) and tend to get #define happy, which more often than not
DN> makes the code incredibly difficult to read by anyone else but
DN> themselves.
Or not even.:-)
DN> pleasing, or perhaps an accomplishment in itself, but unless
DN> there is some intrinsic *technical* value in using a #define
DN> (like a manifest constant or some other common value used in
DN> many source places that may be subject to change at some future
DN >date), then it should be avoided at all costs. IMVHO.
In this case i was looking at my getch() function, which uses INT16.
Unfortunately, there are at least three types of k/boards commonly in
use, and they're read with different values in AH 0x01,0x11,i forget the
third . So in order to make this function realize, which one to use i have
to access the CMOS to get the KB IDbyte, and set AH accordingly.
A #define would've been beutiful, but the way it is, the IDbyte has to be
fetched on each call or placed in a static char on the first call, but that
still adds an if statement. I think the #define (had it worked),would've
been justified for this one ?
L8r Frank (fadam{at}ozemail.com.au).
___ Blue Wave/DOS v2.21
---
* Origin: Melbourne PC User Group BBS (3:632/309)SEEN-BY: 633/267 270 @PATH: 632/309 107 635/503 50/99 635/728 633/267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.