Macの型  ここで型と言えば袈裟固めとか(実は得意)、一本背負い(まともに出来たことがない) などということを言いたいのではなくて(んなこと誰が思うか!という人もいるでしょう けど、それ何?という方に説明しますと、柔道の業。。。ありゃ?*技*です。*技*。  んで「柔よく剛を制す」なんて嘘です。「剛よく柔を制す」が本当。奇麗に技が入る なんて余程実力差とか隙がないと無理。相手だってむざむざと素直に投げられる訳は ないもん。  相手の技が決まったと思った瞬間に一切の抵抗をやめると、奇麗に投げ飛ばされる んで、そーすれば投げ飛ばされるこっちもちゃんと受け身ができるんですが。  まぁその。そーすると自動的に「一本。それまで。」で負けちゃうんですが。  でも、体落としとかに抵抗してもつれて倒れるとかすると、受け身もできんから痛い。 また、内股をかわし損ねる(あるいは相手がヘマする)と、野郎なら必ず分かる痛みに 飛び跳ねる。なんてことになるんですが。。。  えーとぉ。何の話だっけか?そうそう。  Cという言語は移植性の高い言語とか言われることもありますが、実質はとんでもない じゃじゃ馬です。intと宣言した数値が実質、どこまでの範囲で有効なのか誰にも分かり ません(大げさ)。16 bitかもしれないし、32 bitかもしれません。また、エンディアンも 不明ですんで、キャストしてアクセスした結果がどーなるかは予測不能と思って良いです。  後、構造体のアラインにも気を付けないと逆襲を喰らいます。エルアラインの戦い。 なんちって(それはエル・アラメインだ〜)。 #他機種に移植した時の話よ。念のため。でも自分が今使っているCのshortとintが何bit  なのか。ってなのを全く知らない。って人は問題あります。  ってことを言うと、そーゆーのを気にしないとだめなCプログラムはだめだ。とか言われる  気もしますが、まぁそれはそーだけどねー。とか言って見ます #…だからこそJavaはあんな規定をしたのだ。…っと、私は思っている。  んで、OSベンダーはCに一定の足枷をはめることにした。  C言語としてintの大きさが時と場合によって違うなら、それはしょうがない。では  我々のOSのプログラムを書いている時にはせめて安定した変数を提供しようではないか。  …か、どーかはしらないが、こーゆーのが定義されてる(MacTypes.h): #思いっきり抜粋してるので、生のヘッダを是非参照されたし。お願い、プリーズ(笑) #define nil NULL // こいつはPascalとの互換性のためでしょう。多分。 整数系ではこんな感じ: UInt8 8-bit unsigned integer SInt8 8-bit signed integer UInt16 16-bit unsigned integer SInt16 16-bit signed integer UInt32 32-bit unsigned integer SInt32 32-bit signed integer UInt64 64-bit unsigned integer SInt64 64-bit signed integer 派生してこう: typedef SInt16 OSErr; typedef SInt32 OSStatus; typedef UInt8 * BytePtr; enum { noErr = 0 }; 文字関係だとこんな感じ: typedef UInt16 UniChar; typedef UniChar * UniCharPtr; typedef UInt32 UniCharCount; typedef UniCharCount * UniCharCountPtr; typedef unsigned char Str255[256]; typedef unsigned char Str63[64]; typedef unsigned char Str32[33]; typedef unsigned char Str31[32]; typedef unsigned char Str27[28]; typedef unsigned char Str15[16]; こういうのもある: StringPtr  Pointer to a pascal string CStringPtr Pointer to a C string (in C: char*) 論理演算だと: Boolean A one byte value, holds "false" (0) or "true" (1) false The Boolean value of zero (0) true The Boolean value of one (1)  で、色々なヘッダを見ているともう気でも違ったのか。と言いたいほどtypedefで再定義  しまくってます。追跡してると嫌になります。2重3重は当たり前で名前の入れ替えやって  ますんで……。  だって、意味ないもん。例えばOSErr。ソース書く時にOSErrと書いてもSInt16と書いても  shortでも同じこと。本来、コンパイラが変わってもソースは同じで良い。ってのが趣旨な  はずだけど、OSErrと書くべき所をshortと書いて何の問題もなくコンパイルが通るようでは  説得力は何もありません。  コンパイルして、(現在は同じ型なのだが、将来は違う可能性があるので)エラーで落ちる。  という仕様でないとねぇ。  DialogPtrとWindowPtrが同じ?この野郎。とか思ったけど、かんじょうのおもむくままに  ぶらうんかんにケリ入れてあいてが爆縮すると、いたい。では済まないけっかを招くきが  とてもするので、しませんでした。わたしって、よいこ?  とかいう内部事情を喚起したため、やらなかったりしてます。その昔、古いTVのCRTを  石投げて破壊したら「ボーン!! - 間 - バラバラバラ(破片が落ちる音)」とかして、  すげー迫力を堪能したし。  *危険だし迷惑なので、今はやらないように。*  現在の都市圏のごみ収集状況を考えると、そーゆーことをすると破片を我が身に喰らう  とか、通りすがりの他人を巻き込む覚悟が多分、必要です。まぁ、そこまでの覚悟がある  なら止めませんが(まかり間違った場合、莫大な損害賠償は覚悟してね)。  そういう意味ではMSDNなヘッダではSTRICTを定義すると今のWindowsでは結局同じ型になる  宣言でもわざとややこいことしてコンパイルエラーになる。という仕組みが盛り込まれて  おり、納得できます。  本来、そうなるべきであり、今のAppleなヘッダは無意味な複雑さをプログラマに強要  してるだけです。努力するだけ馬っ鹿ぢゃん。とゆーことで、私は気が向いた時だけ  Apple定義な宣言に準拠。という立場を取ります。 # SInt16 i; OSErr err; i = (OSErr) err;  なんてのを一生懸命書いてですね、これが実は: short i, err; i = err;  と、全く同じです。ってのはねー。何か馬鹿にされてる気がしません? #過去との互換性の絡みで海より深い理由があるのかもしれませんが…… (EOF)