Part 12.メモリレイアウト(5)


結局、プログラマは自分で好きなようにルールを作ることが出来る。メモリの使用のされ方について好きなように設計できる。頭のなかでルールを思い描いたあとは、実際にそのルールに基づいてコードを書いていけば良い。


頭のなかで思い描いた様子がコードとして如実に見てとれたほうが良いが、それは実装するときの理想であって、実際のところプログラミング言語自体の表現力が乏しければそんなことは出来ない。無論、(プログラミング言語の)言語デザイナは、誰かが「頭のなかで思い描いた様子」をなるべくコードとしてストレートに表現出来る言語仕様を考えるべきである。


もしプログラマが設計段階においてデータ構造(struct)やオブジェクト(class)をいしずえとして思考するなら、それらを言語として直接的に取り扱えたほうがプログラマの意志を素直にコードとして記することが出来るだろう。


また、プログラミング言語の表現力が十分にあったとしても相手に伝達するという観点から言えば、相手がある程度の知識を有することを仮定しなければいけない。また、時には自分自身が何かしら勘違いしているかも知れない。(前回書いたようにUCS2ではなくwchar_tと書いてしまうように)


それらのケースに対応するためは、コメントを残す必要があるのだと言える。プログラミングにおけるコメントはコードと自分の頭のなかで定めたルールとの差異を埋め合わせるために必要不可欠なのだ。


しかしこれ以上、哲学的な考察をここで続けるつもりはない。ここから、いくつか実際的な問題に応用していく。


(つづく)