• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: C question for you old guys ;-)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C question for you old guys ;-)


  • Subject: Re: C question for you old guys ;-)
  • From: Jay Vaughan <email@hidden>
  • Date: Wed, 11 Jun 2003 17:00:42 +0200

Only in your opinion, which is not shared by many on this list.


That nobody else is arguing against "#define is ==" on this list only means to me that nobody else is arguing against it, not that nobody shares my opinion...

I've known plenty of programmers who have been fired for habits like this, who have lost serious project responsibilities because their 'smartass use of macros to make things easier' cost countless weeks of debugging and hassle at the expense of big, big projects. Any pro programming shop worth its salt has programming guidelines that outlaw this sort of behaviour; and for good reason!

Okay, so the sole hacker on the edge of the cocoa fringe can #define his language into oblivion for all I care. But doing so in a group-development situation is *dangerous*, and this is why I object to Apple professionals promoting the habit among the cocoa-dev crowd ... If I see "(val is NULL)" in code from Apple in the future, I'm gonna consider switching back to Windows! (just kidding, just kidding, sheesh!)

You might want to consider the case that he *does* understand the
"problems" and found them to be outweighed by the advantages in this
particular case. This is what is called an engineering trade-off,
which is always involved, especially when using the pre-processor.


Look at it this way. I could never write code like this with #define's such as yours around:

void sector_trans(int os, int is, int ts)
{
sector_copy_trans(is, os, ts, 512);
}

And before you change the subject to one of "bad names for C vars", I'll note that a casual 'grep -ir " is;" *c' in a /usr/src containing some 20 or so various untarballed projects from freshmeat/linux and Apple themselves, including device drivers and media API's, yields *plenty* of vars named "is" ... and not a single #define making "is" = "==" ...

#grep -ir " is;" *.c
drivers/md/lvm-snap.c: lv_block_exception_t *be = lv_snap->lv_block_exception + is;
drivers/isdn/isdn_ppp.c: rs->is = is;
drivers/isdn/isdn_ppp.c: ri = is;
drivers/isdn/isdn_ppp.c: mis = is;
drivers/isdn/isdn_ppp.c: mis = is;
drivers/sound/sa1100-audio.c: audio_stream_t *s = (cmd == SNDCTL_DSP_GETOPTR) ? os : is;

[etc...]

My point is: do "#define is ==" if you're lazy and like it, but it's a bad habit, and you shouldn't promote it as a habit among fellow programmers, especially if you are responsible for ensuring those programmers are able to use C-based API's developed for and intended for use by as wide a market as possible.

Anyway, as you said, this thread is getting 'embarrassing', so lets just drop it and move along with some nice cocoa, eh?

--

;

Jay Vaughan
r&d>>music:technology:synthesizers - www.access-music.de/
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: C question for you old guys ;-)
      • From: Sujal Shah <email@hidden>
    • Re: C question for you old guys ;-)
      • From: Jeff Harrell <email@hidden>
    • Re: C question for you old guys ;-)
      • From: Prachi Gauriar <email@hidden>
References: 
 >Re: C question for you old guys ;-) (From: Marcel Weiher <email@hidden>)

  • Prev by Date: Re: troubling article
  • Next by Date: Re: Thread question (volatile needed?)
  • Previous by thread: Re: C question for you old guys ;-)
  • Next by thread: Re: C question for you old guys ;-)
  • Index(es):
    • Date
    • Thread