AB開発日記

ニュースを見てしったのですが、最新の地震警告システムは使いようによってはホントに画期的なものになりそうですね。

先日起きた宮城県沖の地震ですが、大きな揺れが始まる11秒前にそのシステムが警告を発していたようです。予想された時刻や震度はほぼ正確といってよいものだそうで、このシステムには是非とも、成長していただきたいものです。

たかが11秒前といってしまえばそれまでですが、ネットワークやヒューマンインターフェイスが化け物かという勢いで進化している今、その情報を活用する手段は色々ありそうです。

この地震システムと高速ネットワーク、地震警告インターフェイスを組み合わせれば、家にいながら確実に情報を取得できます。例えば、ガス検知機の横に、地震警報機なんかを設置しておけば、この地震システムから高速ネットワーク回線を介して送られる「10秒後に大地震が起きます」という情報を家庭にいるすべての人間が把握できるのです。

となれば、たかが10秒とはいってられませんよね。できることは沢山あります。まずは火を消し、自分の身に降りかかってくる不安要素を取り除く作業だってできます。家族が家のどの場所にいるか、非難通路となるドアは開いているか、などなど。最後は机の下へと潜ってしまえば完璧ですね。

で、問題となるのが、このシステムの信頼性です。間違いばかりを起こすと、「また警報機がなったけど、多分間違いでしょう」と流されてしまうかもしれません。普段からビービーなるような警報機であれば、スイッチを切られてしまうかもしれません。

的中率90パーセント台で、警告音がウルサイやつ。「何秒後に起きますよ〜」みたいな音声合成機能も付けておけば間違い無さそうです。

地震警報システムの信頼性向上さえ実現すれば、いずれは必ず、地震警報機は家庭に置かれることと思います。でも、何年後、何十年後の話になるのでしょうかね…。それまで東海大地震が起きないことを祈るばかりです。

本日は休日。相変わらず、この問題に取り組んでいるところです。どうも、おいらは開発に専念してしまうとWebコンテンツの製作が疎かになってしまうみたいですね。どなたか、同士を組んでDiscoversoftの運営を活発なものにしたいものです。

さてさて、キャストについてですが、Ver4.1β1をそろそろリリースできそうです。あとはヘルプを書くだけって感じですかね。

“#strict”ディレクティブが指定されたソースファイルで、曖昧な型変換が行われていると、下記のようなエラーがでるようになっています。

prompt.sbp(313) - [警告] "LoadIcon"の第2パラメータが、Longから*Byteに強制変換されています。
prompt.sbp(314) - [警告] "LoadIcon"の第2パラメータが、Longから*Byteに強制変換されています。
prompt.sbp(315) - [警告] "LoadCursor"の第2パラメータが、Longから*Byteに強制変換されています。
function.sbp(438) - [警告] "memcpy"の第2パラメータが、StringからVoidPtrに強制変換されています。
function.sbp(438) - [警告] "memcpy"の第1パラメータが、StringからVoidPtrに強制変換されています。
string.sbp(26) - [警告] "memcpy"の第1パラメータが、StringからVoidPtrに強制変換されています。

まだprompt.sbp、function.sbpのライブラリ書き換えが済んでいない証拠にもなっている上の出力サンプルですが、こいつは飽くまで「警告」なので、EXE生成とデバッグはできるようになっています。

8/15の話ですが、お盆のUターンラッシュの中、名古屋まで行ってきましたよ〜。東名が混んでいたため、静岡県内は今年春に無料解放されたバイパス道路を使いました。右の写真は、景色がめちゃくちゃキレイな浜名湖バイパス。サーファーが集ってました。〜イイな〜海入りたいよ〜。それにしても、果てしないほどの直線が続くこの道路。静岡県ではないような、変な錯覚を起こさせます。おいらがこの道路を昼間に走ったのは初めてなんで、レゲエに浸りながらちょっとした感動に出会うことができました☆

帰ってきて、「疲れたぁ〜」とホッとしたのもつかの間。夜はウイ店長の送別会があります。◯Ｏｏ。―ｙ（⌒O⌒)

開催場所は富士駅付近にある笑笑（←飲み屋チェーン店！？）。おいらが服屋のバイトを始めて、数え切れないほどの飲み会を楽しんできたわけですが、この日のようにスタッフ全員+OBスタッフが集合するという前代未聞の出席率には驚くばかり。欠席ゼロですよ、ゼロ！！！やはりそこには、店長の人間性が絡んでくるのか、はたまたおいら達が自ら作り出したアットホームな結束力がそうさせたのか！？？？ちょっとわからない点ではありますが、総勢22人で、楽しい一年間を提供してくれた店長を送り出すことができました。

で、問題だったのは、ジョニー先輩とMICが繰り出す飲め飲めコール。飲めない女スタッフに順番がくると、「身代わり♪ ヽ(^。^)ノ」「でぇーすけ♪ z(-_-z)」という身代わりコールに変わるんです。やむなく、飲めない焼酎を限界値を超して飲んで、数年間は味わうことがなかった地獄へと行ってしまったというわけです。

ウイ店長とは一体、何回ファミレスで話込んだことでしょう…。一年間、ホントに色々ありました。9月から、新しい店長、新しい店に生まれ変わります。おいらはこの新しい環境を目にしてから、引退を考えようと思っているところです。もうそろそろ服屋も引退かぁ…シンミリ(／_；。)

今日は、とあるABユーザーの方と話をするために名古屋へと出向いたんです。

内容を色々と書きたいところなのですが、今夜はお世話になった店長の送別会があるんで、今からはそっちへ行ってきます〜。

短くてごめんですm(__)m

キャストの問題を処理していて、フッと思ったことなのですが、Win32APIが用意してくれる型って、ちょっと悪趣味だと思いません？だって、よく考えてみてくださいよ。

typedef int INT;
typedef long LONG;

とかしてるんですよ。APIの上では、型を大文字で統一しましょうみたいな流れがあったと風の噂で聞いたことはありますが、それが徹底されていない現状を見ると、どうしても気持ち悪いんです。

ABはWin32APIの影響をモロに受けるような言語仕様、ライブラリ構成になってるんですが、これらVCで不徹底されている型環境というお荷物まで背負い込むことはしたくないんですよね。

ABはVer4.1から厳しい型チェックを行える”#strict”ディレクティブを導入するので、LongとDWordを曖昧に使い分けたりはできないんです。気持ち悪い型の例をもう一つくらい示しておきましょうか。

typedef long LONG;
typedef unsigned int UINT;
typedef UINT WPARAM;
typedef LONG LPARAM;

LRESULT CALLBACK WindowProc(
HWND hwnd,// ウィンドウのハンドル
UINT uMsg,// メッセージ
WPARAM wParam,// メッセージの追加情報1
LPARAM lParam// メッセージの追加情報2
);

WPARAMとLPARAMって、正直新しい型を導入してまで定義する必要、あるんでしょうか。wParamもlParamも所詮はメッセージの追加情報。どうあがいても32ビット整数値なんです。しかも、符号あり/なしに分別されている意味がわかりません。2つともDWORD（もしくはUINT）に統一させればいいじゃないですか。

初心者向けにWin32APIを解説しているページを見かけると、WPARAMとLPARAMについてのコラム的な解説が目立ちます。結局はlongとかunsigned intとかなんですぅ〜、という具合にまとめられているのですが、だったら最初からlongとかunsigned intとかで定義してくれよぅ。WPARAMとLPARAMという新たな型を作り出す必要、符号あり/なしを分ける必要がどこにあるんだよーぅ。

と、まるでタダをこねるような本日の思想ですが、、、ABライブラリではどうしようか悩んでしまいます。Win32APIとの互換性を重要視するんであれば、またはネット上にある様々な情報を取り入れやすいようにするんであれば、WPARAMやLPARAMを始めとする奇妙な型を導入すべきなんだと思います。でもでも、おいら的に納得がいかないんですよね〜。

といいながら、Ver4.1でWPARAMとLPARAMを導入してしまいそうな、意思の弱さときたら…（トホホ）。まぁ、64ビット環境のライブラリなどの環境変化を考慮すると、型指定にワンクッション余裕を持たせるのは必要ではあるんですけどね…。ABユーザーの皆さん、AB環境に影響を及ぼしかねないWin32APIの型について、どう思います？？？

おいらが気になるくらいなので、頻繁にプロジェクトエディタを利用するABユーザーさんも気にはしていたことと思います。

それはパラメータヒントを表示してからカーソルを移動するなどして、そのヒントが消えたとき。一瞬だけプロジェクトエディタのウィンドウがチラツクんです。こいつに意外と集中力を削られます。

ウィンドウの再描画のトラブルってのは、Windowsプログラマーなら誰しも通る道ですよね。描画工程ってどうしても、わかり辛いんですよ。それについて詳細にかかれている文献が見つからないというか、そのトラブルにおいて正確な状況を把握しきれないというか…。歯がゆい状況に対面すると、試行錯誤を繰り返すしかないです(-w-

なにはともあれ、InvalidateRectとUpdateWindowを適確なタイミングで呼び出すことで今回のチラツキ問題は解消されました。皆様には、次回のバージョンアップでお披露目（そんな大袈裟じゃないか…）できるかと思います☆

CheckDifferentType関数を新たに設けました。この関数、コンパイラ内部で、以下のようなタイミングで呼ばれる便利な関数です。

・変数にデータを格納するとき

・関数にパラメータを引き渡すとき

呼び出されると、双方（右辺、左辺）の型の整合性を判断します。型が異なると判断された場合は、「強制変換されますよ〜、キャストしてください」みたいな警告を発します。更に、Char型変数にLong型データを代入したときなど、自身の型が持ち合わせるデータ領域よりも大きな領域を持ち合わせる型の代入に遭遇すると、「データが失われちゃいますよ〜」という親切な警告も発するようになっています。

我ながら、迅速行動でした。最初は久々に触るコンパイラの中枢部にタジタジだったのですが、プログラミングのカンを取り戻せたような一日でした。こういう、プログラミングに関するちょっとした壁を乗り越えたときの満足感は何者にも変えがたいものですね。

中枢部を改良したということで、色々と不具合がでるかもしれません。まとまり次第、Ver4.1β1としてリリースしようと思います。そうだっ、ヘルプを書かねばっっっ（式の中で “As 〜” が使えるのよ〜ん♪）

もうすぐお盆になりそうな今日この頃…ジョニー先輩とのどうでもいい会話です。

ジョニー先輩「山ちゃん、大学４年の夏ってのは、過ぎるのがめちゃくちゃ早いよ。ホントにあっという間だよ。”あっ” て言ってみろよ」

おいら「あっ」

ジョニー先輩「クリスマスになったら、”という間だったろ！” って言ってやるよ」

もう暑いのだけはマジ勘弁なのですが、こんな時期もすぐに過ぎてしまうものだと思うと、ちょっとシンミリとしてしまいます。ウチの店にも秋物が本格的に投入され、そのスピードは加速されたようにも感じます。

レゲエを思いっきり楽しめるのもあと一ヶ月ちょっとといったとこでしょうか。音楽のほうも秋物を仕入れにゃなませんね。2005年秋は大人っぽく、ジャズでせめたいところ。ジャズといっても、クラシックジャズ、サックスジャズ、ジャズボーカルなどがあるのですが、最近のポップスに近い、入り易そうなSMOOTH JAZZの領域に踏み込んでいきたいと思っています。

今から従兄弟とCDショップ行ってくるんで、今のウチにゲトります(^^

今日は夕方から家業の配達の手伝いがあるので、それまでは開発を進めます。

まずは、問題にあがっているキャストの問題。すぐにキャスト可能な仕様に改良することはできないので、ことはじめとしてコンパイラの演算コード生成部をすべての型に対応させるところから始めます。今まではコード軽量のため、一定の型（Double/Single/Int64/QWord/DWord/Long）のみに制御を絞っていたのですが、今後はInteger/Word/Char/Byte及びその他ポインタ型の識別も可能にしていかなければなりません。

中核部分をいじるのは数ヶ月ぶりなので、ちょっと不安なんですよ(–;;;。コンパイラを製作したことがある方ならわかると思うのですが、コンパイラを記述しているプログラムコードっていうのは、対象となる言語仕様が複雑になればなるほど難解になっていくんです。ABは、仕様を追加しまくる方向できているので、例外事例にムリヤリ対処するためのコードが目立つんですよね（汗）。

まぁ、そういうこともありまして、マイペースに作業を進めているところです。お昼の段階で、演算コード抽出ルーチンで対応できる型を基本型すべてに拡張したところです。今後は型識別コードでは表現しきれない付加識別コードに対応させていきます。

型識別コードとは？

・Char/Byte/Integer/Word/Long/DWord/Int64/QWord/Single/Double

・文字列型

・オブジェクト型

・列挙型

・基本型のポインタ型

・オブジェクトポインタ型

・関数ポインタ型

これらの型を識別すめためのID番号。コンパイラ内部で使用されるため、一般のプログラマーは意識する必要はないっす。

付加識別コード

オブジェクト型、列挙型、オブジェクトポインタ型、関数ポインタ型など、1つの型識別コードだけでは表現できない識別情報を持ち合わせます。

例えば、オブジェクト型、オブジェクトポインタ型の付加識別コードには、クラスを指し示すID番号が振り分けられます。

この文章、読み返してみたら、暗号のようなものになっていますね。コンパイラを作る過程での悩みが相談できる人（かなり特殊なケース！？）ってのは幸せです。おいらはいつも一人ぼっちですから…。

キャストの問題が出てきてから色々と考えているのですが、ABの演算部分がかなり簡略化された構造になっとることを再確認させられました。こいつはおいらが1人でABを開発することから、コードの軽量化とその内容のわかりやすさを重視した上でのことであり、言語仕様としては劣る部分でもあります。そこらへんの甘さが、キャストの甘さに繋がっているんですね。

コンパイラの内部構造の話になってしまいますが、ABコンパイラを製作する上で、与えられたBasicの式コードをもとにアセンブラの演算コードを抽出するルーチンがあります。このルーチン、字句解析はもちろんのこと、すべての演算子とすべての型を熟知したものでなければなりません。構造自体はスタックを活用したシンプルなものではあるのですが、扱う演算及び型の種類は日々、多くなっています。この演算と型、掛け算方式で肥大化していくのです。

いわれてもれば、一つの演算をアセンブラコードに変換するためには、右辺、左辺がどのような型なのか、双方の型が違う場合は、どちらの型を優先して演算を行うべきか。足し算だけを見ても、実数演算と整数演算で使用する機械語コードは違うんですね。実数演算ではDouble型とSingle型があるので、2通りに対応するものを作る必要がありますし、整数演算では符号有り無しの考慮、Integer、Word、Char、Byteなど、ビット数が少ないものも考慮しなければなりません。

まだ基本型ならばいいのですが、ポインタ型になるとまたちょっとややこしくなります。ややこしくなる原因はオブジェクトポインタを扱ったときです。AB内部で型を識別するための型コードだけでは、オブジェクトポインタの種類を見分けることはできないからです（オブジェクトポインタはクラスの数だけ存在することになりますから…）。となると、「オブジェクトポインタ」という一つの型コードと、別途クラスコードを管理する必要がでてくるというわけです。

この演算抽出のルーチン、コンパイラ内部のあちらこちらから呼び出されるので、オブジェクトポインタを考慮したものに書き換えるというと大きな作業になってしまうんですね。

こういう問題を抱えつつですが、近日中にキャストの問題をクリアしてより繊細な演算ができるような仕様に拡張していきたいと思います。ウーン、「次回のバージョンアップで…」というのはちと難しいかもしれません。少なくとも、Ver4.1あたりで対応させたいところです(><)