・やっとこさ、かぶヘッダー来ました。ヘッダー見ると、やっぱ広告くっつけるサーバーで手間取ってますねー。もしかしたら、２月一杯は広告付けるのやめるかもしんない。こーゆーのは設定ひとつで簡単にできるんで。
　
・まだテストとか待ってるんで本格的なプログラミングはできないんだけど、少しずつ準備がてらしていこうと思ってます。来年に授業を受ける「信号処理」用に、 .wav ファイルの作成や FFT 、デジタルフィルタ関係のプログラムを組んでいこうと思ってます。んで最終的には Codian に載っけたいです。
　
・で、まず始めに .wav ファイルを読み込んで、ヘッダーの解析から。 .wav ファイルは、Ｃマガ１９９９年１１月号に情報が書いてあるし、ウィンドウズ向けフォーマットだから API でもサポートされてるんです。だからこの辺からまず手を付けていこうかなと。まー、ネット探せばたぶんサンプルコードもあるだろうし、そんなに大変じゃないかなーと思ったりも。
　
・こういうテストアプリを作るときにいつも思うのは、自作ライブラリをどうするか。たとえば今回みたいなヘッダーの読み込みには、自作の copy_n() っつーアルゴリズムがえらい役立ちます。 std::copy() の一定数だけ読み込むバージョン。 iostream で「ファイルの途中」を示すのはめんどいから。
　
・んでもこの関数を作っても、どうするかって結構面倒。ライブラリ化するともう書き直せないし、うっかりこの関数使ってるプログラムを配布しちゃったりすると「 copy_n() ってなんやねん」ってことになるし。っつーわけで当分は毎回コピー作ってるんだけどそれもねぇ。どーしよ。
　
・でわまたっ！

・今日は引き続き wav ファイル作成プログラムを作ってました。 wav フォーマットは、２バイトサイズと４バイトサイズがぐっちゃぐちゃに混ざってるんでえらい分かりにくいです（泣）。しかも、亜流フォーマットが多いんで完璧な解析はなかなか大変そう。
　
・なんか、何度となく同じポカをするんでここに書いときますです。まず、 istream::tellg() の戻り値 streampos はクラスなんだっちゅーこと。 int と勘違いして TRACE() で出力して０が出て？なこと数回（汗）。とゆーわけで位置は fpos::get_fpos_t() で取得できます。ってゆーかえーかげん printf() 系がヤになってきた……。
　
・ std::istream_iterator とかを使う時の注意。これをアルゴリズムに噛ませた場合、たいがいは「ひとつ先」まで行っちゃうんで、続けて使うときにはひとつ前に戻す必要アリ。本来アルゴリズムは、イテレーターが値渡しされることが前提で設計されてるんだけど、これはストリームの参照を持っていくんで操作の影響がストリームに残っちゃうわけですね。とゆーわけで、まず char の配列とかにコピーして、あとでまとめてストリームに書き込みましょう。
　
・あとバイナリーデータとしての書き込みがえらいめんどい。前述の通りデータごとにサイズは違うし、さらに文字列データもあるからねぇ。このへんの処理をうまーくできないかなーと画策中。できればテンプレート使って同じように処理できたらいいなと。文字列は整数値に置き換えちゃった方がいいかもしんない。あと移植用にエンディアンも考えないと。
　
・とりあえず、単純な sin 波を出力するとこまでは完成。ま、ホントは DFT や FFT すんのにこのファイル作る必要はないんだけどね。でも各ファイルの短時間 FFT を求めたりするときとか、デジタルフィルタ作ってそれに掛けるときには必要か。
　
・でわまたっ！

・今日のポカミス。 std::generate_n() と std::ostream_iterator と自作関数オブジェクトを使って波形をファイルに出力しようとしたら、なぜか double として出力したはずの値が char １文字として出力されてた。なぜに！？　なんで std::ostream_iterator::operator= はオーバーロードされてないの？　と思ったら、 std::ostream_iterator に渡す型をテンプレート引数で指定する仕様でした（汗）。テンプレート引数を double にしたら問題なく使えてひと安心。やっぱ STL と iostream はよくできてますね（爆）。
　
・鏑矢は叫んだ。「 protected は全然 protected じゃないんだー！　むしろ public なんだー！」と。さて今日のお便り。

・はじめまして〜。さて質問の方ですが、これは CMenu::TrackPopupMenu() の第１引数に TPM_RIGHTBUTTON を加えると直りました。つまり右クリックも効くようにするとうまくいくみたいです。エクスプローラーもそうなってましたし。ただなんか釈然としない感じも（汗）。なんか他に方法ありそうだけど、とりあえずこれが一番手っ取り早いってことで。
　
・でわまたっ！

・んー、今日も信号処理関係のプログラミングをしてました。今日はこのまえ教えてもらったページから FFT プログラムを拾ってきて、矩形波や sin 波を FFT に掛けてみました。んでも思ったのとちょっと違うなー。ホントは先に DFT をやりたかったんだけど、 DFT のプログラムって少ないから、まず FFT を使って解析してからってことで。
　
・出力は std::ofstream を使ってファイルに出力して、 gnuplot で表示しています。 gnuplot 用に出しておけば他の環境でも使い回しできるし、わざわざ表示用のアプリ作るのもめんどいしね。それに、この辺もぜーんぶ STL と iostream 使って処理できるから。あとは、 FFT アルゴリズムの解析だなー。ってそんなことより勉強しなきゃ（汗）。
　
・でわまた。

・今日もちょっとだけプログラミング。方形波や sin 波を FFT に掛けるの、うまくいきました。いやー、やっぱサンプリング周波数合わせないとダメなんすね。そりゃ、そうしないと「周波数１の sin 波」が一致しないんだもんねぇ。方形波の方も前の実験のと結果が一致したし、とりあえずひと安心。
　
・んで、これからは逆に DFT を作ります（爆）。 DFT や FFT の仕組みを理解するのが目的だから。っつーてもテスト勉強せにゃならんからすこし自重しよっと。
　
・でわまたっ！

・今日はプログラミングしてないからお便りの紹介だけ。では今日のお便り。

・そうそう、 WM_DRAWITEM での描画ってメニューの各項目ごとだから、その外はダメなんだよね。えっとまず、 WM_DRAWITEM のデバイスコンテキストを WindowFromDC() に渡すことでメニューのウィンドウハンドルが拾えると思います。それからさらに GetWindowDC() を使えば、メニュー全体のデバイスコンテキストを取得できるはず（試してないけど（汗））。
　
・んでも縁が塗れるかどうかは微妙。あ、もしかしたらウィンドウスタイルを変えれば「縁なしウィンドウ」にできるかも。その上で一度全部塗りつぶして縁を描けば……。まぁ、基本的にはこんな感じかな。実際にできるかどうかは不明。メニューのウィンドウが「アプリのプロセス内のオブジェクト」じゃなかったら、 SetWindowLong() とかは失敗しちゃうし。
　
・そういうときは、システムフックを掛けてすべてのウィンドウを拾って、そのうち目的のメニューだけを見つけるようにする必要があるかな。システムフックを使うと「他プロセスに侵入できる」から、これなら SetWindowLong() も成功するはず。サブクラス化と同じ要領やね。ちなみにメニューのウィンドウクラスは #32768 だから、これでメニューは見つかるはず。あとは目的のアプリのメニューかどうかを判別できるか、かな。
　
・まー、正直言えば、めんどいよきっと……。もしかしたら、メニューに似せたウィンドウを作るようにしちゃった方が楽かもしんない。スタートメニューとかはこれなのよん。要は「らしく見える」んならえーわけやね。もしかしたらそういうメニューを提供してくれるライブラリやコンポーネントがあったりするのかも？　……ないような気がする（汗）。
　
・でわまたっ！

・今日は疲れたからお休み＜って疲れただけでお休みにできるんすか？

・今日は信号処理関連の続き。はて、なんで rExp(s) x Exp(wt) の s を「位相のずれ」って言うんだろうか、と思い考えること数分。……もしかして、 sin と cos を足し合わせると、 sin と cos の中間の波ができるのかも？　と思いついてプログラム作成。試してみたら、 r =１ を維持しつつ sin と cos の割合を変えて足したら、 sin 波をずらしたものに。なるほど、だから「位相」なんだ！＜これでも理系大学生デス。
　
・ずーっと、なんで sin と cos 両方使うんやろ、 sin ずらせば cos になるやんとか思うとったんですが、逆なんすね。 sin と cos を割合を変えて足し合わせると、それだけで位相のずれを表せる、つまり角度部分に手を加えずに sin 波をずらせるんすね。そのために sin と cos の両方を使っていると。うむ、一歩前進（爆）。
　
・こーゆーのの確認のためのプログラムを組めるようになったって事が、ちょっとうれしいかなーとか。わてはこーゆーの苦手だからねぇ。これからもどんどん使っていって、アレルギー取り除きたいです。
　
・でわまたっ！

・今日はちょっとだけ。なんで CD とか wave とかのサンプリングレートって 44100Hz が標準なんだろーか。いやね、人が聞けるのはせいぜい 20kHz だから「そのくらい」になるのは分かるんだけど、でもだから帯域幅が 22050Hz ってその余分な 2050 はなんですか？　ちょっと謎。 こーゆーとこにきっと数々のロマンが！＜あるのか？
　
・でわまたっ！

・今日はプログラミングしてないのよ。そーいえば、４月完了を目標に引っ越しを少しずつしていきます。とりあえずこちらでも言っておかないと。詳しくは日記の方を見て欲しいです。
　
・でわまたっ！

・今日は CGI 関係の話。えーっと、日記の方を読んでない読者の方々に解説しますとですねー、わてが使ってるプロバイダジャストネットで「独自ドメインサービス」を開始したんで、さっそく www.kab-studio.com っつーのを作って現在引越準備中なのです。しかーし！！　新しいサーバーにはアクセスカウンターが用意されていない！　つまり自分で用意しなきゃいけないわけですね。
　
・ CGI の使用は Perl のものに限り許可されてます。 C では CGI 作ったけど、 Perl はまったくダメ、しかーしアクセスカウンターの設置は急務、っつーわけでCマガジン１９９９年５月号の「 C & Perl で学ぶ CGI レッスン」に載ってたアクセスカウンターを設置することに。だがしかーし、設置したはいいが意味不明のサーバーエラーが！　調べてみると、 CGI に関わらず cgi-bin 以下のどんなファイルも見れないことが判明。
　
・あ、ここで新サーバーの CGI について解説。あらかじめ新サーバーには cgi-bin っつーディレクトリがあって、そんなかののみ CGI を実行することができます。で、ここにはすでにサンプル用 CGI が置いてあったり。その CGI は環境変数やパラメーターを表示するもので、これからの CGI 作成に役立ちそうななかなかよさげなサンプルでした。……って、これは実行できるやん(汗)。
　
・さらにテストを重ねた結果、なぜかそのサンプル CGI に似たファイル名だとうまくいくことが判明(爆)。どーゆー仕組みになっとるんや……。まーファイル名なんかどーでもいい、ってことでさっきのアクセスカウンターをそのファイル名で設置、そして問題なく使用できました！　現在かぶスタのメニューバーからも実行して、ファイルロックとかがちゃんとうまくいってるかテスト中。いまんとこ大丈夫っぽいです。
　
・ちなみにここは telnet 不可（入れるけどパスワード変更専用）。 chmod は FTP で実行せにゃならんのです。コマンドはよく分かんないし、いつも使ってる FTP Explorer はこの機能がないんで、このためだけにわざわざ WS_FTP をダウンロード。でも右クリックメニューから chmod で簡単に変えられるんで良かったです。
　
・で、今はテスト段階。実用バージョンでは、インクリメントをメニューバーで、表示は表紙でっていう今のアクセスカウンターと同じシステムにしたいんで、パラメーターで増加数を変えられるようにしようと思ってます。さらに、マーケティングリサーチのためにアクセスログとリンクログも作成予定。そんためにも Perl のお勉強が必須。本買うかな。

・あ、パラメーターでってのはパス。表示とインクリメント、別々の CGI を作ることにしました。まだパラメーターの解析はできないんで(汗)。別々のとして作るのなら、ファイルへの書き込み部分とかを削除するだけでいいんでこれならわてにも分かるってことで。現在のはこのバージョンです。
　
・でわまたっ！

・表紙見てもらえば分かるとおり、以前のカウンターを新しいカウンター CGI に置き換えてテストしています。今のところちゃんと動いてるっぽいです。ちなみにこのミョーな数字はわてが作ったもの(汗)。急造にしちゃ結構いい感じじゃないかなーと。

・今度作るのは、リンクログ。アクセスログよりは簡単だから。 Java スクリプトから「直前のページ」を取得して、それをファイルに書き込みます。 C では一度作ったけど、今回はちょっと変える予定。今回は、追記モードでどんどん後ろに書き込んでいくようにしようと思ってます。その方が楽そうだから(汗)。 Perl の細かい文字列操作をマスターすんには時間なくて。

・パラメータの渡し方と受け取り方はだいたい分かるから、あとは追加書き込みの方法を調べることかな。リンクログがうまくいったら今度はアクセスログ。って言っても基本的には同じもの。これもただただ追記していくつもり。将来的には、時刻も書き込めるようにしたいかな。そうすれば、いつアクセスが多いのか分かるし。

・アクセスログを取ったあとの、ログ解析は別のプログラムでするつもり。この辺も勉強かも。楽して C++ で書いちゃうかもしんない(汗)。できればアクセスログまでとっとと完成させて、引越のときに各ページに書き込んでおきたいです。この書き込みが結構面倒なんだよねー。だからホントは、アクセスログはサーバー側で取ってもらって、それを見せてもらうのが一番なんだけど……。あとは、全ページ CGI を使って出力するとか(汗)。

・でわまたっ！

・今日はお休みです。はひぃ。

・まずはごめんなさいから。今日発行の KAB-studio.h の #pragma twice でレジストリを取り上げました。その中で、レジストリファイルの user.dat の置き場所を Windows フォルダと書きましたが、マルチユーザー環境の場合にはこれに加えて「 Windows\Profiles\ログオン名」にも置かれます、が正しいです。ってゆーか知りませんでした(汗)。「マルチユーザーのためにレジストリを使うんだよ」とか言っといて知らなかったってのが……ごめんです。
　
・あと、 NT4 の場合には NTUser.dat っていうファイルも作成されるそうです。いやー、シングルユーザーで Win9x しか触れてないってのがやっぱまずいですか(汗)。確か「ログオン名」フォルダにはスタートメニューとかも置かれるはずなんで、そういうのをまとめて管理してるんですね。 NT だとたぶんセキュリティで保護される仕組みになってるんだと思いますです。むー、やっぱ家で Win9x 、会社かガッコで WinNT ってのが理想なんだが……。
　
・今日は図書館で Perl の本を借りてきました。 C++ と全然違う感じでえらい新鮮。文字列リテラルんなかにそのまんま変数を置けるのとか、ファイルハンドルから直接データを取り込めたりとか、なんかすごい。ところで、いいコンソールってないですかねー。 DOS 窓は見づらい、 Comwin 使ってみたら落ちちゃったし、今のところ gcc に付いてた cygwish が一番使いやすいとゆー(汗)。
　
・おひさ、今日のお便り。まずひとつめ。

・まず CKeyboardHook::KeyboardProc() が static メンバ関数になってるかどうかチェックしてみてください。普通のメンバ関数はフックプロシージャにはできないんで、 static メンバ関数として作って渡すことになります。エラーの原因はこれでしょう。'long (__stdcall *)(int,unsigned int,long)'ってフックプロシージャのことだし。このことについてはローカルフックに書いてあるんで読んでみてねー。
　
・もうひとつ可能性があるとすれば、 GetThisHInst() って関数がちゃんと作ってあるかどうかかな。このコードはシステムフックのページを参考にしたんだと思うけど、この中にあるとおり GetThisHInst() は自分で作る必要があります。これを作ってないか、作っても呼び出せないか、とかがあり得るかな。
　
・まー、 static メンバ関数にしてないってゆーのは、 MFC から触れて API へと挑戦するときに誰もがやっちゃうことだと思うんで気にしなくていいでしょう。もちろんわてもやった(爆)。では次のお便り。

・これは２月９日のことですね、情報ありがとうです。そっか、本当の意味で「サンプリング」するときの問題が絡んでくるわけですね。考えてみたらサンプリングレートとかの考え方とかはずっと前からあるわけだから、そういった頃の試行錯誤とかが今に残ったりしてるってことなのかも。
　
・で、今は性能に物言わせてるってわけですね(爆)。 MP3 とかのフォーマットが一般的になったのも、処理速度とかが上がって FFT とかがかなり速くなったからなんだよね、確か。そんな時代でも 44100Hz が残ってる。やっぱなんかロマンだ(爆)。
　
・でわまたっ！

・今日は盛りだくさんですよ、うふふ。
　
・テストが終了したんで、早速リンクログを作成しました。現在稼働中。どっちかってゆーとアクセスログのためのテスト用だけど、でももちろんちゃんとリンクログとしても働くんでかぶスタへどっから来るのかばっちりデータが取れますです。数ヶ月ぶりのデータはどんなんなってるかな？
　
・ぐはっ、 Cygwish は２バイト文字を表示できなかった！　ショック。
　
・さて今日もお便りが２通。まずひとつめ。

・どうも初めましてー。テンプレート使い始めたら今度は STL に挑戦してみましょう、面白いですよー。さて、 KTL の関数 b2B() 、これは bool to BOOL の略で、 C++ の bool 型をこれまで慣例的に使われてきた BOOL 型に変換するための関数です。こんなんわざわざ作らなきゃいかんっつーのがなぁ……。
　
・さて throw 。これは例外処理の throw と同じキーワードですが、関数宣言の後ろに付いているのは違う意味になります。正式名称は「例外指定（ exception-specification ）」と言います。これについて書いてある本はかなり少ないし、 VC でも実は「書ける」ってだけで機能してなかったりします。で、その機能。まずこのコードを見てください。
　

void Test()
{
	throw 0;
}
	

　
・この関数は 0 を投げています。ということは「 int 型の例外がこの関数から投げられる」ということです。投げられたときのことを考えて、呼び出す側は catch する必要があります。もしこの関数が DLL に封じ込まれたりして、宣言部だけしかない場合、どうやって「 int が投げられる」ということを知ればいいのでしょうか。そこで、 C++ では次のような関数宣言を書けるようになっています。
　

//	宣言。
void Test() throw( int );

//	定義。
void Test() throw( int )
{
	throw 0;
}
	

　
・これが例外指定。これは「 この関数は int 型の例外を投げるから catch( int ) すれば受け取れるよ」って意味です。こう書けば、ソースコードを見なくてもどの型を catch すればいいか一目瞭然ってわけですね。また、 throw() と型が指定されてない場合には「何も投げませんよ」という意味で、また、 throw が書かれていなければ「何が投げられるか不明」ってことでもあります。
　
・例外は catch されなければ関数を呼ばれた順にどんどんさかのぼっていきます。っつーことはですね、末端の関数の「投げるかもしんない例外」は、呼び出し元にさかのぼるに従って増えていくってことです。食物連鎖みたいなもんですね。たとえば、さっきの Test() を呼び出す関数は、かならず throw( int ) を明記しなきゃいけないってことです。こんなふうに。
　

void Test2() throw( double, int )	//ふたつとも指定。
{
	Test();	//こっから int が投げられる。
	throw 1.0;	//ここで double が投げられる。
}
	

　
・あら、すごいことになりそうな予感ですね。受け取る側もすごいことになります。今のVC は throw( int ) を書かなくても問題なく通ります。つまり機能してないってことね。でも将来はコンパイルエラー（もしくはランタイムエラー）になるでしょう。中途半端に使うと大変。例外処理、誰も使わなくなるかも(爆)。
　
・実際の所、ポリモーフィズムやテンプレートでは呼び出される関数を特定できないんで、必然的に例外指定ができないことになります。すべての関数呼び出しでできるわけではないんですね。でも逆に、投げる例外は std::exception 派生クラスにするのが基本なんで、それを守っていれば劇的に例外指定が増えることはない……はず。うまく適切に使えるか（ってゆーか使ってあるライブラリがあるか）どうかってとこかも。
　
・この構文を完全に使いこなすのはなかなか大変でしょう。今のところは「こういうのがある」って憶えておくくらいがいいかも。これサポートしてるライブラリって少ないと思うし（余談だが MFC は使ってる(爆)。 CFile::CFile() を見てみよう）。ま、少なくとも「簡単な質問」じゃないと思うんで安心しましょう。
　
・おおう、なんか C++ の話になるととまんなくてやばいですね。もうひとつのお便り。

・どうもー。えっと、標準ライブラリには入ってないんで、基本的には他の人が作ったものを借用することになると思うです。たとえばここのとか。あとは Shift-JIS の文字テーブルを見て、その変換をべたべたに書くって言う方法とか。規則性ないから基本的にこういうべたな方法しかないんだよね……。
　
・ただ、実際にはもっと細かい処理が必要だと思うです。本当にそれが半角文字なのか、とか。全角から半角はさらに面倒っぽいです。ま、面倒なだけでこつこつすればなんとかなるかも。そういえば、皆さんは文字コードのテーブルとかってどうやって調べてるんでしょう。わては ATOK13 の「文字パレット」を使ってます。これは結構便利よん。他の文字コード（ Unicode とか）も見られるし。
　
・でわまたっ！