ポインタという考え方

ポインタを使わなくてよいのは素晴らしいことだ、という風潮がある。最近のプログラミング言語では、ポインタを排除するのが流行のようだ。また、それを歓迎する人も多い。

しかし、「ポインタが理解できないから」という理由で、こうした新しい言語を歓迎している人はちょっと待ってほしい。ポインタについては、きちんと理解できるまで学んでもらいたいのである。

確かに、Visual Basic や Java にはポインタがないが、プログラミングするのに困ることはない。であるならば、ポインタを理解する必要などないではないか、と思うかもしれない。

しかし、問題は、実際にポインタを使った開発をするかどうかではない。ポインタという考え方が身についているかどうかだ。

ポインタという考え方は、メモリ操作の基本であり、これが身についているのといないのとでは、コンピュータの世界で起こる様々な現象の理解度に違いが出てくる。

では、そんなに重要なポインタが、なぜ排除されていくのか。それは、ポインタに関するバグが致命傷になりやすいからである。勘違いのないようにしていただきたいが、ポインタの考え方が難解なためにバグが出やすいから、というわけではない。ましてや、ポインタを理解できない人が多いからではない。

ポインタが難しいとされている大きな原因は、Ｃ言語の「*」や「&」といった記号にあるのではないかと思う。初心者にとって、こうした記号は不気味なものである。しかし、そんなものに騙されてはいけない。ポインタの考え方自体はシンプルなものだ。あきらめずに学んでほしいものである。

C言語ポインタが理解できない理由

posted with amazlet on 06.04.01

朝井淳
技術評論社 (2002/03)
売り上げランキング: 212,839

おすすめ度の平均:

初心者向け

バグ出して、これを読むと身につきます

初心者がポインタの知識をあと一歩進めるために

Amazon.co.jp で詳細を見る

C言語のポインタがゼッタイにわかる本―最初からそう教えてくれればいいのに!

posted with amazlet on 06.04.01

立山秀利
秀和システム (2005/12)

Amazon.co.jp で詳細を見る

限りある資源を大切に

プログラムの世界では、ファイルを開く処理を書いたら、責任を持って閉じる処理も書く、というのが常識である。

ファイルやメモリのような「リソース」と呼ばれるものは、こうしたマナーが必要なものがほとんどである。なぜかといえば、コンピュータのリソースには限りがあるからだ。

限りある資源は、使いたい人が好き放題に使えるわけではない。しかるべき手続きをして、一時的に借りてきてから使う。そして、使い終わったら速やかに返却し、他の人が使えるようにするのである。

限りある資源を大切に使おう、という大変エコロジカルな考え方である。

★

さて、Java や .NET など、最近のプログラミング言語には、「ガーベージ・コレクション」という仕組みがある。直訳すると「ごみ収集」だが、これは、プログラマが確保したメモリを自動的に開放する仕組みである。借りたものを自分で返さなくても、放置しておいたら勝手に回収される、というわけだ。

つまり、ガーベージ・コレクションが行われる言語では、確保したメモリの開放し忘れ（メモリリークというバグ）がなくなるわけである。プログラマはメモリ管理に気をとられずに、ビジネスロジックの実装に専念できるというわけだ。

というと、良いことばかりのようだが、そうでもない。

開放し忘れを防止するというだけならよいのだが、最初から開放することを考えないプログラマを容認するということでもあるからだ。

ガーベージ・コレクションはメモリの開放、つまり、借りたものを返すという行為自体を隠蔽する。このことで、コンピュータのリソース管理が本来的に持っている、エコロジカルな考え方までもが失われてしまうのである。

★

これは、特に、新しくプログラムを学ぶ人にとっては、重大な損失である。

実際、最近のプログラマには、「メモリは限りある資源である」という意識が欠落している者が少なからずいる。メモリの大切さを知らないので、好きなだけ消費する。そして彼らのシステムは異常に遅くなるか、メモリ不足で停止するのである。

プログラミングをビジネスという観点で考えれば、あらゆるリスクは遠ざけた方が良い。そういう意味では、ガーベージ・コレクションは優れた技術かもしれない。

しかし、教育という観点で考えるならば、危険なものだからといって、何でも遠ざけてやればよいというものでもないだろう。

省メモリプログラミング―メモリ制限のあるシステムのためのソフトウェアパターン集

posted with amazlet on 06.04.01

ジェイムズノーブルチャールズウィアー James Noble Charles Weir 安藤慶一
ピアソンエデュケーション (2002/06)
売り上げランキング: 50,050

おすすめ度の平均:

すべての設計者・プログラマに必須

Amazon.co.jp で詳細を見る

C言語文字列操作+ファイル入出力完全制覇

posted with amazlet on 06.04.01

山地秀美
技術評論社 (2002/11)
売り上げランキング: 241,373

おすすめ度の平均:

難しいです。

Amazon.co.jp で詳細を見る

足跡の作り方（後編）

あるプロジェクトで、サーバーの設定や、新しい言語に慣れていない作業者たちが四苦八苦していると聞いたので、最も先行しているメンバーをつかまえて提案した。

「今やってる作業の手順や注意点を Wiki に書いておいてはどう？」
「今は忙しいので、時間ができたら書きます。」

私のプロジェクトではなかったし、本当に忙しそうだったので、それ以上勧めることはしなかったが、プロジェクトが終わっても彼が Wiki に何かを書き込むことはなかった。

私の話し方が悪かったのかもしれないが、彼は「Wiki へ書き込むこと」を現在の作業とは独立した仕事として捉えたようだ。そのため、きちんとした文章にまとめようとして、身構えてしまったような気がする。また、余計な仕事が増える、という意識にも繋がったかもしれない。

しかし、ここで要求されるのは、報告書やマニュアルではない。単なる作業記録である。独立した仕事としてではなく、今行っている作業の一部と考えるべきだ。システム的に言えば「自分の作業のログ」であり、文学的に言えば「自分の歩いた足跡」である。

つまり、彼はテキストエディタを立ち上げておいて、作業を行いながら、何につまづき、どう対処したかを淡々とメモしていけばよい。最後に Wiki に貼り付けて終りだ。心配するほどの時間は必要ないだろう。それに比べて、結果的に残るものは大きいはずだ。

逆に、作業記録を後から書く、ということはいろいろな面で難しい。細部を忘れてしまって書けなくなってしまったり、書くこと自体を忘れてしまったり、時間的余裕ができた頃にはプロジェクトから抜けてしまったり。とにかく、作業しているその時に書かなければ、十中八九は書かれないまま終わってしまうのである。

足跡は歩いているその時にしか作れないのだ。

(前編を読む )

■関連記事
・ログとしてのメール

Wikiでつくるかんたんホームページ

posted with amazlet on 06.04.01

ケイズプロダクション
九天社 (2005/12)

Amazon.co.jp で詳細を見る

ブログ・オン・ビジネス企業のためのブログ・マーケティング

posted with amazlet on 06.04.01

シックス・アパート株式会社
日経BP社 (2005/12/28)

Amazon.co.jp で詳細を見る

足跡の作り方（前編）

システム開発に限らず、何か問題にぶつかったときは、色々と調べたり、人に聞いたり、試したりして、苦労の末にその問題を解決すると思う。

しかし、喉元を過ぎれば熱さも忘れるもので、問題が解決してしばらくすると、何につまづいたのか、どうやって解決したのか、細かいことは忘れてしまうことも多いのではないだろうか。

このような状態では、自分が再度同じ問題に直面した場合にも困ってしまうし、他の人が同じ問題に直面した場合にも、同じ苦労をさせることになる。

プロジェクトで新しい開発環境を導入する場合などは、多くのメンバーが同じ作業を行うことになる。そこで、私のプロジェクトでは、先行して開発環境を構築しているメンバーに、行った作業をプロジェクト用の Wiki （※）に記録してもらうことにしている。後続のメンバーは、それを参考にすれば、効率的に作業を行うことができる。

問題は、作業記録を書いていくタイミングである。忘れないために書くのだし、他のメンバーに見てもらうわけだから、早ければ早いほうがいい。つまり、作業しながらリアルタイムに書いていくのが最も良いだろう。

(後編へつづく )

※Wiki は Blog に似たシステムだが、Blog よりも自由度が高い。文章内の単語が既存のページ名に一致したら、自動的にリンクされるのが特徴（例: ウィキペディア / エクリプス）

Wiki Way―コラボレーションツールWiki

posted with amazlet on 06.04.01

ボウルーフウォードカニンガム Bo Leuf Ward Cunningham yomoyomo
ソフトバンククリエイティブ (2002/09)
売り上げランキング: 25,800

おすすめ度の平均:

少々古くなったけど・・・

そろそろWikiを使ってもいいんじゃないか？

Amazon.co.jp で詳細を見る

結城浩のWiki入門 ~YukiWikiではじめるみんなで作るWebサイト~

posted with amazlet on 06.04.01

結城浩
インプレス (2004/03/30)
売り上げランキング: 16,626

おすすめ度の平均:

Wikiはなかなか普及しませんが・・・・

てっとり早く導入したい方へ

これは面白い

Amazon.co.jp で詳細を見る

プログラムに操られた男

ソースコードをチェックするためのプログラムというのがある。

ソースコードを読み込ませて、プロジェクトチームで設けたルールを違反していないか、などのチェックを行うものだ。市販のものもあるし、チーム内で作る場合もある。

あるプロジェクトでは、プログラミングのルールに、以下のようなものがあった。

クラスのメンバ変数（フィールド）に名前をつけるときのルール

1. "m_" で始める
2. その後は型を表すキーワード（文字列型なら "str"）
3. その後はアルファベット大文字で始める

Microsoft が MFC などで使っているルールで、賛否両論はあるにせよ、珍しいものではない。

例えば、"name" という名前をつけたい場合、メンバ変数であれば、"m_strName" とするのである。

そのプロジェクトでは、夜の間に、自動的にソースコードのチェックプログラムを走らせていた。結果は Web ページの形で出力される。プログラマ達は、毎朝 Web ブラウザを立ち上げ、自分の書いたソースのチェック結果を確認していた。

ある日、プロジェクトのメンバーがソースコードを眺めていると、

　m_strM_data

という奇妙なメンバ変数を発見した。確かにルール違反ではないが、おかしな名前である。何でこんな変な名前にしたのだろう？

おそらく真相はこうだ。

１日目
"m_data" という変数を作った。

２日目
チェックプログラムから「"m_str" で始まっていない」という警告を受けたので、"m_str" を追加して、"m_strm_data" とした。

３日目
「m_str の後ろが大文字になっていない」という警告が出ていたので、大文字にした。

というわけで、"m_strM_data" という奇妙な変数名が出来上がったのである。

お分かりかと思うが、彼は２日目に "m_strData" とすべきだったのだ。

このプログラマは素直であるがゆえに、チェックプログラムに操られてしまった、というわけである。

あるいは、鬼上司からの警告をゼロにするようにというプレッシャーと、残業続きの睡眠不足とで、ちょっとおかしくなっていたのかもしれないが。。。