言語の部屋

多分大丈夫だと思いますが、真剣な言語学習には利用しないで下さい。日本のどこかに必ずいるであろう同じような境遇の人を勇気付けるためのコーナーです。もしかしたら、プログラミングに詳しい方がこれを見て救いの手を差し伸べてくれないかな、という他力本願コーナーでもあります。あとはダイエット日記をネット上にアップすることでモチベーションを維持しようみたいな発想もややなきにしもあらずんば虎子を得ず的な雰囲気。

7月第一週　　　C++との遭遇
今週からC++を勉強することになった。これまでに勉強してきたJava、VBA、COBOLはひとまず(半永久的に？)お休み。ＰＧ言語に対する深い造詣がないため、ＣこそＰＧ言語の王者のような思いを抱いており、少し厳粛な気分。
とは言え、最初にやったことは「クラスの概念について理解する」。まだオブジェクト指向という言葉が新鮮だった時代に誕生した言語らしく、いろいろな関連サイトを除いてみても、わりあいこの部分に重きがおかれていることが多いようだ。すでに勉強したことのあるJavaはかなりオブジェクト指向を意識した言語だったということもあり、概念自体は比較的すんなり理解できた。派生、継承、オーバーロードくらいまでは。オーバーライドがちょっときついなぁ。Javaのオーバーライドとはなんか違うような気がする。
しかし、クラス云々以前の部分を実はほとんど知らない事に気づいた。変数に関する事や、if、forの書き方など。もっとも、ifに関してはJavaとまったく同じ書き方で通ってしまった。変数･･････はbooleanとかあるのかな。intやcharなどはコードを書いてる時に自動的に色が変わったが(Visual　C++使用)boolanは変化がない･･･。
事前情報ではJavaと似ているという話だったが、確かにJavaの蓄えでしばらくはいけそうだ。もちろん違うところも多々ある。現段階で思い当たったところでは、C++にはガーベッジコレクションがなさそうだ。細かい?
実はVisual　C++も混乱を招く一つの原因。そういう独立した言語なのか単なる実行環境なのか、そういったところから理解していかねば。
ま、実働二日だしこんなもんでしょ。

作成プログラム・・・・・・親亀子亀孫亀
クラス学習の王道(笑)。継承元を作っておき、継承先には元を発展させた機能を持たせるというアレ。それを亀でやりました。

7月第二週　　　破壊神、降臨
先週に引き続きC++の勉強。
C++に対する理解は、実用レベルではCにオブジェクト指向が入ってきたものだと思えばいいらしい。というわけでCに関する知識は必然的に勉強しなければならなくなる。
Cの根幹をなす概念･･････（大袈裟?）、ポインタをついに学ぶことになった。俗にややこしい概念だと言われているが、やはりわかりづらい。
プログラムでは必要な情報を一時的にメモリに保存しておく必要がある。ポインタはその情報の保存場所（アドレス）を入れとくためのもの。要約すればこういうことなのだが、有効利用の方法が良くわからない。無駄なメモリを使わなければプログラムが軽くなるので、メモリを「動的」に確保する場合に使うとのこと。前回Javaのガーベッジコレクションの事を書いたが、要するにこの作業を勝手にやってくれるものがガーベッジコレクションではなかったか。
まぁ、クラスもはじめてみたときはそんな感じだったからそのうちわかってくるかもしれないが、もっと困った問題がある。
存在しないアドレスに対して何らかの処理をしようとすると、思いがけないエラーが出るらしい。往々にしてそのエラーは致命的なものとのこと。プログラムが止まるだけならどうということはないのだが、他アプリケーションの領域まで破壊し、時にハードウェアそのものにまで致命的なダメージを与えることがあるとか無いとか。恐ろしい･･････。
今週もう一つ困ったのはVC++6.0の『外部シンボルが未解決』。なんじゃ、そりゃ？

作成プログラム･･････ダイアログ型アプリケーション他多数
VBAで作ってた、ボタンを押した場合に実行されるコードを書くやつ。Accessより面倒くさく、手打ちでやったJavaより簡単。Jビルダーがないので･･･。

今週の成果
・C++の場合、true/falseの入れ物はbool型。
・乱数処理の使い方
・関数（Javaで言うメソッド）のプロトタイプ宣言
・関数の引数なしは何も書かないかvoidで。voidのほうが明示的。
細かいことが多い・・・・・・。ある程度のバックグラウンドがあるので、勉強の内容はかなり細かくなっている。

7月第3週　　　オブジェクト指向、見切ったり?
そろそろオブジェクト指向という思想を理解できてきた。
言葉ではなく心でわかった。考えるんじゃない、感じるんだ。
今週はそんな感じだった。まぁ、Javaの頃から繰り返し言われてきた概念だから今さらわかったのか、の感はなきにしもあらず。
というわけで（どういうわけで？）今週はソースを公開してみる。気分転換に遊びで書いたやつ。意外にクラス（オブジェクト指向のキモ）を説明するには向いてるかもしれないと思い。半分そういうつもりで書いてみました。究極的には気まぐれです。
ちなみに一応ゲームになってます。プレイヤーは与えられた200の数値をHP、攻撃力、守備力にいい感じで割り振って「オブジェクト」同士を戦わせるのです。結構バランスとか破綻してますが。コードもさることながら。もしかしたらコピー&ペーストで使えるかもしれません。多分、変なところにスペースが入ってて駄目ですが。手打ちでかいたので誤字もあるかもしれませんが、それらを乗り越えれば動くかもしれません。その場合VC++6.0だとなお動きやすいかも。
詳しい説明->（！アロー演算子の使い方間違ってますね！）機会があればそのうち。スペース節約の関係でいろいろアレだけど簡単なコメント付(@_@;

11月　VBはじめました
C++が一段落したので、VBのプログラムに入った。
なんと言うか、VBはさほど難しくもなく勉強している感じではないのだが、すでに出回っている製品版の次版用に他人の書いたプログラムを改修する毎日。
････････････わかりづらいっす。
人の書いたコードは読みにくい、自分の書いたコードでも、半年経てば意味不明というのが常識のこの業界で、今さら話題にするまでもないことなのかもしれないが、それにしても中には相当厳しいものもある。そのご不満をこの場で吐露してみようと思う。

分かりづらいポイント�@　　　　コメントがない
どの処理がどの部分に書かれているのかぐらい、コメントを入れておいてほしかったっす。探せば分かることとは言え、もう少し何とかして欲しかった･･････。探すのが意外とめんどい。

分かりづらいポイント�A　　　　変数・関数名が分かりづらい
変数は特にフラグなんかで顕著だが、そういう目的に利用されているのかが分かりづらい。憶測で流用させて貰うとそれがとんでもない爆弾を抱えている場合もあり。
関数名は、中身を見れば大抵分かるが、多少長くても分かりやすい名前を付けていただけると探す手間が省けるというもの。

分かりづらいポイント�B　　　同じような処理を何箇所も書いてある
似たような処理は、一本の関数にまとめて、引数を工夫してうまくやってくれると保守の者が楽です。これは私自身も十分に出来ているとはいえない話なので、もっとレベルアップして、うまくできるようになりたいところですが。

分かりづらいポイント�C　　　数値項目のベタ打ち
ぶっちゃけた話し、今直してるところは帳票系のプログラムなんですが、主にラインを引く関数に引数（要するに開始位置・終了位置等の座標っす）を渡して、帳票に罫線が出るようにしてます。この引数、前の人は数字を直で書き込んでおられますが、確実に同じ数字が入る箇所は共通の変数なり何なりで書いてほしかった。仕様変更時などに変数の代入箇所だけ書き換えればあとは勝手に変わってくれましょう?

なんか、悪いコーディングの見本市のようだけど、多分今の私と同じようなレベルの人が悪戦苦闘しながら書いたのだろうなあ、と思う今日この頃。

11月（後編）　すばらしきいやし系コードの世界
上でこんなことを書いてたら、最近になってやはり総合整備計画が発動された。プログラムごとに異なる関数や変数のdefineが前線のプログラマに負担を強いているため、共通の処理はあらかじめ用意された関数を使い、各処理で必ず同じ数を使う場合も、共通のbasで定義された変数を使うことが決定された。現在は、これまで各プログラマがめいめいで作っていた関数（数値編集用）を新たに用意されたものに差し替えている最中。うまくいっても見た目に変化が無いので、地味な作業と言えば地味な作業だが、これを終えることによって以降の保守は格段に楽になり、作業効率もあがるはずである。
ところで、前回も書いたとおり人の書いたコードは読みにくい。特にフラグなんかを大量にたてられて、説明のコメントもようしいしてくれてなかった日にはたまったものではない。気分がくさくさしてくる。
とまあ、そんな殺伐とした日々を送っていたある日、非常にかわいらしいプログラムに出会う機会があった。先輩女子社員の書いたプログラムである。
ロジックがかわいいのではない。
コメントがかわいいのである。
コメントは、処理の流れとは全く関係ない部分だが、読みやすいプログラムを書く上で必要不可欠なものである。一まとまりの処理の内容を書いておいたり、重要な部分を目立つようにしておいたり、目的は色々である。
で、そのかわいらしいコメントとは、ズバリ☆である。プログラム上のあちこちにお星様がちりばめられていて非常に愛らしい。まさにいやし系コード。
また、関数の説明の部分にもかわいらしい部分が。関数の呼び出しとか、そんな言い方は無粋である。
お呼ばれ関数･･････なんてかわいい言い回しなんだ♪
これぞいやし系のコードの世界、いやし系コードの真骨頂。
コメントなんてものは要は、目立てばよかろう、なのだ。そういう意味ではこれはすばらしいコメントだと思う。私自身は、関数に渡す引数や戻り値の説明、処理に使う変数の説明を極力コメントしているが、そういう実際的な用法が全てではないことを知った。人生には遊びが必要だと言うことを知りました。
しかし、それを読む人の張り詰めた心を解きほぐすためには、一体どんなコメントを書けばいいのか。
そんなことを考えていた矢先、そのコードの作者からメールが届きました。そして署名部分にあったのは････････････アスキーアート！
その手があったか！確かに目立つわな、アスキーアート。
全く脱帽です。


特別企画　バキュラは壊せるか
バキュラとはナムコのシューティングゲーム、ゼビウスに出ていた『鉄板（敵）』である。いくら弾を打ち込んでも壊せないこのバキュラだったが、かつてある噂が流れた。
『バキュラは弾を256発打ち込めば壊せる』
というわけでこの噂の検証（と入ってももう答えは出ているのだけれど）。都市伝説との連動企画です。
私も一応プログラミングの仕事をしている関係で、この問題について少し考えてみた。もし私がゼビウスのプログラミングをするとしたら、問題のバキュラにザッパー（対空攻撃）が命中した時に走らせる最初の処理は、攻撃が有効かどうかだろう。ここで有効無効を判断すれば、これ以降の耐久力の減少を計算する必要がないからだ。こうすれば、256発という数字に意味はなくなるわけである。実際に256発の攻撃を打ち込むことが出来たとしても、ただ256回攻撃無効の判定が繰り返されるだけだ。あっさり結論の出る話ではないか。
と思っていたのだが、これはあくまで昨日今日のプログラマの発想であることを知ることになった。今よりもハードの性能が格段に劣っていた当時、プログラマはハードのスペックを常に意識しながらコーディングを進めなければならなかったのである。限りある資源を有効に使わなければ、満足な処理を実現することは出来ず、ゲームとして成立するものを作ることもまたできなかったというのである。
ゼビウスの頃のプログラマは、とにかく無駄の無いプログラムを心がけなければならなかったわけだが、ここに256発という数値の登場する余地がある。どうやら耐久力消耗計算の前に、攻撃の有効無効を判定するのは資源の無駄につながるらしく、そんなことをするくらいなら最初から極端に大きな耐久値を設定しておいたほうが無駄がない、というのが当時のセオリーだったようだ。
しかし、ここで再びハードの性能が問題になる。当時のハードのスペックではあまり巨大な数字を収める変数を用意することが出来なかったのである。ここで言うならば256以上の数字を収める変数を用意することが物理的に不可能だったのである。そのため、破壊不可能とほぼ同じ意味合いで設定されたこの255という数字でも、理論上は0までへらせるので、バキュラは破壊できると考えられたわけだ。
ところが、ゼビウスの敵にはそもそも耐久力という概念が存在しなかった。バキュラにだけ耐久力を設定するのはそれこそ資源の無駄になる。結局のところ資源の有効利用という発想から生まれ、、資源の有効利用によってとどめを刺された噂のようである。私自身には思いがけない勉強になったけれど。
21世紀になった今の感覚では、『極端に大きな数字』というのは、かつての高橋名人が数時間連射を続けても0に出来ないほどの大きさになっている。10年一昔とは言うが、隔世の感があるなあ。