トップページ

本棚


両手で1000まで数えられますか?:2進法の話
数値 - 危険物取り扱い注意
100 × 200 =32?:変数のオーバーフローの話
パリティビット
小数の扱いについて
ぽいんた
ぽいんた2
ぽいんた3
ジ・オリジン
ジ・オリジン:補足
かっこつける話
かっこつける話2
文字列のこと
タイミングの話
拡張性の話
取り込む話
staticな話

コンパイルの話1
コンパイルの話2:止まらぬビルド
コンパイルの話3:マシン語に落ちるということ1:メモリの話
コンパイルの話4:マシン語に落ちるということ2:最適化
コンパイルの話5:マシン語に落ちるということ3:変数とスタック
コンパイルの話6:コンパイラはそもそも何をやってくれるのか??
リンクの話
プリプロセッサの話

OS、というもの

オブジェクト指向1
オブジェクト指向:2
オブジェクト指向:3

オブジェクト指向:番外 C言語のソースファイルの話
オブジェクト指向:番外 C言語での「再利用性」と「カプセル化」データ構造とアルゴリズム


抽象的な話

寝込んで布団の中で考えたこと
こんなの、常識??
お仕事プログラミング
ソフトでハードなプログラム
プログラムするということ
お勉強
プログラムを学ぶということの補足
C言語:「学問」と「実務」
統合開発環境
C言語ってポータブルですか?
C言語ってポータブルですか?:2
あなたは、どう読みますか?
ああ勘違い
試してガッテン
低級品
質問をするということ
ポカ
「何もしない」 != 「無駄」
エディタの話
もっと手を抜こう

いまどきの、アセンブラ

VisualStudio2005
VisualStudio2005:2

戦争の防ぎ方、に対する私の考え
身近な差別
改革
地球に優しいなんて大嘘
統計で嘘をつく方法

言葉について
言葉について:2

神が死んだということ
善悪の彼岸から、力への意思を目覚めさせるということ

本を読むということ
本を読むということ:2

絵を描く話
地図
地球儀

オカルトのお話
がんだむさん
RPGソフトウェア
記紀神話の不思議



メニュー

※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

続き。

「先っぽ」だけしか管理しないのは、いくつかの利点がある。

まず、でかい領域を関数に渡したいときなど、いちいち中身をコピーしていたら同じサイズの領域が必要になるし、コピー処理にとられる時間も馬鹿にならなくなる。ポインタを使えば、「ここにあるよ」っていう情報を渡してやればすむ。実に、合理的でしょ?

文字列だってそう。何文字あるかなんていちいち管理するより、「先っぽ」だけもらってNULLまでが文字列だよ、といわれた方が楽。

また、ポインタの真価はキャストと組み合わせることで発揮されるといっても・・・言い過ぎかな?でも本当にキャストと組み合わせることで様々な便利な使い方できる。

例えば、通信やファイルなどのデータをある領域に読み込むとき、読み込んでからじゃないとそれがどんなデータか判らないことがある。

・・・判りにくいですか?

BITMAPの読み込み、なんていい具体例かもしれない。BITMAPは読み込んでみて、ファイルのヘッダをチェックしないとサイズも色深度(白黒、256色、65536色、1677万色といったその画像が表現できる情報)が判らない。かつ、色深度によって、実際のデータ部分の配列が異なる。

そんな時、とりあえずファイルサイズ分のバッファを確保し、そこにデータを読み込む。

当然、この時点で管理しているのはファイルを読み込んだバッファの「先っぽ」。

そこからファイルの情報、画像の情報、256色とかなら色の情報、最期に画像データそのものを切り分けていかなくてはいけないんだけど、いちいちバイト単位でオフセットとってその位置のデータを解析して・・・なんてやってられない。

ここで型キャストの登場。まず、バッファの先頭に入ってるのはファイル情報だから、バッファの「先っぽ」にそのつもりになってもらうのである。

【例】
/* バッファ確保 */
unsigned char* ucBuf = malloc(sizeof(BMPFile));
    ・
/* ここでファイル読み込み */
    ・
BITMAPFILEHEADER* lpBitMapFileHeader = 
  (BITMAPFILEHEADER*)ucBuf; /* フリをしてもらう */

Size = lpBitMapFileHeader->bfSize; /* 画像サイズ */
    ・
/* その他の情報を取得 */
    ・

のように、「そのつもり」になってもらうことで格段に処理が楽になるし、第一見た目にわかりやすい。

逆に、ファイルに書き出す時も同じことを逆向きにしてやればいいだけ。

ポインタとキャストのおかげで、無味乾燥なバイトの列をいともたやすく意味のあるデータとして料理できるのである。

ただし、フレキシブルで効率的な反面、なめると痛い目を見るのも事実。

・・・実際、なんども領域破壊されたし(前に書いたけど)・・・

そのメモリ領域がどれだけのサイズかを把握して使わないと、確保した領域の次には別の領域があるわけで、調子に乗ってその辺を気にしないでいると、全然関係の無い変数を破壊してしまうこともある。これは、不具合として現れてくる部分と実際にバグってる部分とに関係がないので非常に見つけるのは困難。

なので、というかだからこそC言語が得意なつもりで何でもポインタアクセスにする人は嫌い(w

それなりの用途があるならその構造体を定義して、ちゃんとキャストしてメモリさんにもその気になっていただいてから使ったほうが、より安全なプログラムが書ける。もちろん、可変長のデータ(上の例なら実際の画像データ部分)などもあるので一概には言えないけれども。

便利な道具は諸刃の剣。

ポインタが素晴らしい道具となるかそれとも凶悪な凶器となるかは、プログラマ次第ということだ。




| 新しいページ | 編集 | 差分 | 編集履歴 | ページ名変更 | アップロード | 検索 | ページ一覧 | タグ | RSS | ご利用ガイド | 管理者に問合せ |
@wiki - 無料レンタルウィキサービス | プライバシーポリシー