雑記
ぽいんた2
最終更新:
匿名ユーザー
-
view
続き。
「先っぽ」だけしか管理しないのは、いくつかの利点がある。
まず、でかい領域を関数に渡したいときなど、いちいち中身をコピーしていたら同じサイズの領域が必要になるし、コピー処理にとられる時間も馬鹿にならなくなる。ポインタを使えば、「ここにあるよ」っていう情報を渡してやればすむ。実に、合理的でしょ?
文字列だってそう。何文字あるかなんていちいち管理するより、「先っぽ」だけもらってNULLまでが文字列だよ、といわれた方が楽。
また、ポインタの真価はキャストと組み合わせることで発揮されるといっても・・・言い過ぎかな?でも本当にキャストと組み合わせることで様々な便利な使い方できる。
例えば、通信やファイルなどのデータをある領域に読み込むとき、読み込んでからじゃないとそれがどんなデータか判らないことがある。
・・・判りにくいですか?
BITMAPの読み込み、なんていい具体例かもしれない。BITMAPは読み込んでみて、ファイルのヘッダをチェックしないとサイズも色深度(白黒、256色、65536色、1677万色といったその画像が表現できる情報)が判らない。かつ、色深度によって、実際のデータ部分の配列が異なる。
そんな時、とりあえずファイルサイズ分のバッファを確保し、そこにデータを読み込む。
当然、この時点で管理しているのはファイルを読み込んだバッファの「先っぽ」。
そこからファイルの情報、画像の情報、256色とかなら色の情報、最期に画像データそのものを切り分けていかなくてはいけないんだけど、いちいちバイト単位でオフセットとってその位置のデータを解析して・・・なんてやってられない。
ここで型キャストの登場。まず、バッファの先頭に入ってるのはファイル情報だから、バッファの「先っぽ」にそのつもりになってもらうのである。
【例】
/* バッファ確保 */ unsigned char* ucBuf = malloc(sizeof(BMPFile)); ・ /* ここでファイル読み込み */ ・ BITMAPFILEHEADER* lpBitMapFileHeader = (BITMAPFILEHEADER*)ucBuf; /* フリをしてもらう */ Size = lpBitMapFileHeader->bfSize; /* 画像サイズ */ ・ /* その他の情報を取得 */ ・
のように、「そのつもり」になってもらうことで格段に処理が楽になるし、第一見た目にわかりやすい。
逆に、ファイルに書き出す時も同じことを逆向きにしてやればいいだけ。
ポインタとキャストのおかげで、無味乾燥なバイトの列をいともたやすく意味のあるデータとして料理できるのである。
ただし、フレキシブルで効率的な反面、なめると痛い目を見るのも事実。
・・・実際、なんども領域破壊されたし(前に書いたけど)・・・
そのメモリ領域がどれだけのサイズかを把握して使わないと、確保した領域の次には別の領域があるわけで、調子に乗ってその辺を気にしないでいると、全然関係の無い変数を破壊してしまうこともある。これは、不具合として現れてくる部分と実際にバグってる部分とに関係がないので非常に見つけるのは困難。
なので、というかだからこそC言語が得意なつもりで何でもポインタアクセスにする人は嫌い(w
それなりの用途があるならその構造体を定義して、ちゃんとキャストしてメモリさんにもその気になっていただいてから使ったほうが、より安全なプログラムが書ける。もちろん、可変長のデータ(上の例なら実際の画像データ部分)などもあるので一概には言えないけれども。
便利な道具は諸刃の剣。
ポインタが素晴らしい道具となるかそれとも凶悪な凶器となるかは、プログラマ次第ということだ。