Xref: utzoo comp.sys.mac.programmer:5858 comp.sys.mac:30714 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!prism!loligo!pepke From: pepke@loligo.cc.fsu.edu (Eric Pepke) Newsgroups: comp.sys.mac.programmer,comp.sys.mac Subject: Re: CopyBits in MPW C 3.0 Keywords: CopyBits , MPW C Message-ID: <594@loligo.cc.fsu.edu> Date: 17 Apr 89 19:58:13 GMT References: <225@uw-apl.UUCP> <98709@sun.Eng.Sun.COM> <580@loligo.cc.fsu.edu> <99141@sun.Eng.Sun.COM> Reply-To: pepke@loligo.UUCP (Eric Pepke) Distribution: na Organization: Supercomputer Computations Research Institute Lines: 65 In article <99141@sun.Eng.Sun.COM> wert@sun.UUCP (Robert Scott Comer) writes: >But, his real question isn't about CopyBits!! His real problem is that >he doesn't understand C types and MPW and the Mac. If he understood those >things he wouldn't have to ask. What he really needs is just what I gave >him: directions on how to answer his question himself. I think we will have to agree to disagree. I find the description of CopyBits on p. 70 of IM V to be incomplete and misleading in this case. In the past, when a function accepted several different types, the types were designed in such a way that you don't generally need type casts. Take as an example GrafPtr, WindowPtr, and DialogPtr. Most people don't worry about doing explicit type casts. This need not mean that they don't understand type checking; it may simply mean that they do not want to use a dangerous cast mechanism, which has the effect of overriding type checking. When handles are used the situation is doubly dangerous, as a misplaced cast can lead to an improper handle reference. In the case of CopyBits, however, no such mechanism was provided, and no mention was made of the need to cast. The IM writers IMHO are generally very careful to warn about known gotchas, so this omission is surprising. It is true that he, or anybody else, has all the information needed to answer the question. All he had to do was open the appropriate header files, search for the appropriate prototype, determine that it really expected a BitMap, search for the declarations of BitMap and PixMap, and determine that they were not defined in such a way as to obviate explicit type casts. This is what I did to satisfy my own curiosity. He probably did in fact figure it out in time, which is why I did not respond to the original note. However, it isn't quite fair to say RTFM when the FM is unclear, which is why I responded to your note. > This is just the >same as the old proverb: Give a hungry man a meal and he will still be >hungry tomorrow, but give him _____ (fill in the blank with your favorite >enabling technology, like confidence, a shovel, a cow, some seed, etc.) >and he will eat for the rest of his life. Well, I think that examples are good things, and most people can generalize from them, which is why I did not give general rules. I do now: 1) Avoid needless type casts. 2) Take the easiest possible interpretation of the documentation as a first cut. Apple is generally on the side of the programmer, but everyone sometimes makes mistakes. 3) When 1 and 2 fail, and type casts are unavoidable, cast as close to the object with the wrong type as possible to avoid losing the cast in a maze of pointers and parentheses. For example, ** (char **) bork is preferable to * (char *) *bork All of this is IMHO, of course. I tend to be very paranoid. For example, I try to keep constant expressions on the left side of == just in case I mess up and type = instead. >scott out Eric Pepke ARPA: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: pepke@scri Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.