
/*
    KAB-studio.h
        　ＫＡＢ−ｓｔｕｄｉｏで先週更新した内容
        が格納されたヘッダーファイルです（笑）。

    (C)KAB-studio 1999 - 2000 ALL RIGHTS RESERVED.
        http://www.kab-studio.com/
        info@kab-studio.com

    送信日： 2000/03/20(Mon) No.049
    配信数： 3570（ Mag2 + Pubzine ）
＊    発行元： まぐまぐ( URL: http://www.mag2.com/  ID: 0000012198 )
＊    発行元： Pubzine( URL: http://www.pubzine.com/  ID: 590 )
*/


/*              ２０００年３月２０日（月）の更新                  */
http://www.kab-studio.com/Info/News/

・STL & iostream 入門購読登録開始！！
　４月からスタートする新しいメールマガジン「 STL & iostream 入門」の
購読登録を開始しました！！　とりあえず購読登録しておくんなまし！
　ちなみに「第０号」は３月２９日発行予定。それまではちょっと待ってね。

[ STL & iostream 入門]
http://www.kab-studio.com/Programing/STLiostream/


・「漫才マンガ三昧」リリース。
　「漫才マンガ三昧」……ＫＡＢ−ｓｔｕｄｉｏ開設当初から存在したかな
り変な日記。毎日アニメについてテキトーに語るという（今と変わらない）
内容だが、その特質すべき点は、鏑矢本人ではなく「キャラクター」が語る
という形式。火美ちゃん・金菜さん・水希の３人が生まれた場でもある。
　このおバカ日記が、チョー普通な日記読者の熱い（？）要望によってアー
カイブ化！　読んでみたいという人はフリーウェアインフォメーションルー
ムでダウンロードしよう！

[フリーウェアインフォメーションルーム]
http://www.kab-studio.com/Freeware/


/*                        チョー普通な日記                        */
http://www.kab-studio.com/nikki2/

２０００年３月１２日（日）：
　大相撲春場所スタート！　このあと、あのような修羅場が待っていようと
は……。あとテレビ色々。

２０００年３月１３日（月）：
　STL & iostream 入門、好調っぽい。そしてふたたび広告バナーの話。

２０００年３月１４日（火）：
　STL & iostream 入門、購読登録開始！　どんどん登録してねー。

２０００年３月１５日（水）：
　眠いし、お相撲録れ忘れちゃうし、ビデオデッキ壊れちゃうし、もしかし
て疲れてる？

２０００年３月１６日（木）：
　若乃花引退。あと kab-studio.com と、サブドメインなしで行けることが
判明。

２０００年３月１７日（金）：
　ビデオデッキ購入。画質はまーまー？　まーサブデッキとしては合格。あ
とやっぱ金曜はアニメの話。

２０００年３月１８日（土）：
　ゼミに行った俺を待ち受けていたのは花粉の嵐だった！！（泣）　そして
噂の日記「漫才マンガ三昧」。


/*                         鏑矢の憂鬱                             */
http://www.kab-studio.com/Programing/KabuU/

２０００年３月１２日（日）：
STL & iostream 入門書き
STL はイテレーターについて書いた
「自作イテレーターの例」があまりない
しようがないので std::istream_iterator を使う
STL の残りはコンテナ
お便り
Codian についての批判？
ってゆーか書き直す必要があるところ多すぎ
C++ については #pragma twice で

２０００年３月１３日（月）：
STL & iostream 入門書き
今日は少し
メンバ関数ポインタの使い道は？
お便り
参照を引数として受け取って値を返すのは？
しても大丈夫です
注意点
const 参照も使うこと
返す値はできるだけまとめて
トレードオフが必要

２０００年３月１４日（火）：
STL & iostream 入門購読登録開始
std::endl
サンプルコード
引数しか返せない
これってわざと？
お便り
メンバ関数ポインタはブロードキャストに使うといい
下準備が必要なく使えるのは強み

２０００年３月１５日（水）：
 STL & iostream 入門書き
iostream 編完成！
ボリュームいっぱい
STL も #17 まで完成
C++ 遅れまくり
C++ は Effective C++ を推薦図書に

２０００年３月１６日（木）：
STL & iostream 入門書き
STL があと１回
std::set などの連想コンテナ関係
便利すぎるから最後に
連想コンテナもイテレーターを返す
アルゴリズムとの連携が大事
STL はドキュメントが豊富だけど
エントリーレベルのものがない、から書いた

２０００年３月１７日（金）：
STL & iostream 入門書き
STL 完成！
お便り
ローカルフックがうまくセットされない
DLL に置かれていないか
引数を渡す必要があるかもしれない

２０００年３月１８日（土）：
亜流ハンガリアン記法
変数名のプレフィックスに型名を付ける
クラスに比べて組込型は非常に危険
テンプレートの存在が大きい
本当は組込型は使いたくない
でも使わざるを得ない
だから型名が分かる変数名にする


/*                       今週の追加単語                           */
http://www.kab-studio.com/Programing/Dictionary/

・追加単語：
イベントログ 仮想キー

・今週のごめんなさい
InputLib イベント イベントビューアへの書込み dll strconv ポインタ

　うわっ、少な！　追加がたった２単語とは。
　どうやら「引っ越し先ページからのみ送信可能」ってのがえらい効いてる
ようです。まー楽でいーや（爆）。


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[KCM]
『ねー、 STL ってなに？』
「火美ちゃんはまだ知らなくていいよ」
『えー？　知りたい知りたい知りたいぃ』
　知りたいあなたは購読登録。
http://www.kab-studio.com/Programing/STLiostream/
_______________________________________________________________[KCM]


/*                       #pragma twice                            */
http://www.kab-studio.com/Programing/PragmaTwice/

　Version 3.24
デバッグビルドとリリースビルド


「というわけで、〈計算機アプリケーション〉は完成ってことにします」
『……なんだかなー』
「でもね、こういうプログラムって手を加えていくとキリがないし、手を加
えすぎてもね」
『シンプルイズベスト！　どの辺がいちばんいいか、とかも考えるの大事だ
よね』
「そうそう」
『ってことはこれくらいシンプルな計算機が実はウケたり？』
「それはない。さて、おさらいも兼ねて、これまで手を加えてきたところを
見ていきましょう。まず、 Calc.cpp に GetTheApp() って関数を作りまし
た」
『 theApp そのものを返す関数だよね』
「次に CCalcApp::InitInstance() 。これもかなりお世話になったね」
『なったねーここは』

    CCalcDlg dlg;
    m_pMainWnd = &dlg;
    // のあとに追加しました。
    CString cCompanyStr;
    cCompanyStr.LoadString( IDS_REG_COMPANY );
    SetRegistryKey( cCompanyStr );

『そういえばこれだけなんだね、ほとんど CCalcDlg に移しちゃったから』
「プログラムはできる限り小さい方がいいからね。あ、あとこのあとに」

    int nResponse = dlg.DoModal();
    if (nResponse == IDOK)
    {
    }
    else if (nResponse == IDCANCEL)
    {
    }

『これは最初からあるのそのままだね』
「でも【OK】ボタンを押したとき、とかは CCalcDlg に移したから」
『あ、いらないんだ、この if とか』
「だから」

    dlg.DoModal();

『うわー、かなり小さくなっちゃったね』
「プログラムの〈なんで〉を知っていれば、最初からあるものを削ることも
できるってことだね」
『削る？』
「そ。ブラッシュアップって言うんだけど、無駄なプログラムが少なければ、
ビルドしたあとの実行ファイルが小さくなるし、少し速くなるから」
『ぜい肉みたいなもんね』
「でも増やすのは楽だけど減らすのは結構大変。そのために」
『おやつ抜き』
「じゃなくてー、プログラムのちゃんとした知識が必要ってこと。それにお
やつはあった方がやせられるって説もあるよ」
『なんでそんなこと知っとんねん……』
「さて CalcDlg.cpp 」
『こっちにほとんどのプログラムがあるんだよね』
「そういう風にしたからね。まずは CCalcDlg::OnInitDialog() 」
『えーっと、前々回の時は、書き加えた部分全体を載せてなかったから、今
回載せます』

//    SetIcon(m_hIcon, FALSE);        // 小さいアイコンを設定
    SetIcon( AfxGetApp()->LoadIcon( IDI_DLGICON ), FALSE);

    // TODO: 特別な初期化を行う時はこの場所に追加してください。
    CString cDialogStr;
    cDialogStr.LoadString( IDS_REG_DIALOG );
    CString cAnsStr;
    cAnsStr.LoadString( IDS_REG_ANS );

    m_iAns = GetTheApp().GetProfileInt( cDialogStr, cAnsStr, 0 );
    UpdateData( FALSE );

『あれ、アイコンのって』
「大きいアイコンと小さいアイコンの話の時のだね。 Ver 3.6 （ No.031 ）
を参照してください」
『そうそう、小さいアイコンは別にしとくんだよね』
「ちなみにここにある AfxGetApp()-> と、この前作った GetTheApp().は同
じだったりします」
『どゆこと？』
「つまり」

    SetIcon( GetTheApp().LoadIcon( IDI_DLGICON ), FALSE);

「ってできるってこと」
『はて、分かるような分からないような……』
「ホントは、わざわざ GetTheApp() を作る必要はなかったってことだね。
元々 AfxGetApp() っていうのが MFC に用意されてるから」
『ってことは無駄なことさせられたってことぉ？』
「でもさ、 -> 演算子って」
『知らん』
「でも . は」
『知ってる。 dlg.Modal() みたいに、メンバ関数やメンバ変数使う時の』
「だからわざわざ作ったってことね」
『でも -> と . の違いって？』
「それはもちょっと先でね。あと、CCalcDlg::OnInitDialog() の最初の所
で CDialog::OnInitDialog() が呼ばれてるのも確認しといて」
『あ、ホントだ。これってこの前の、オーバーライドとかのと同じ？』
「そゆこと。あと、【＝】ボタンを押したときと、【OK】ボタンを押したと
きのイベントハンドラ。これはまとめて」

void CCalcDlg::OnBEqual() 
{
    UpdateData( TRUE );
    m_iAns = m_iLh + m_iRh;
    UpdateData( FALSE );
}

void CCalcDlg::OnOK() 
{
    CDialog::OnOK();
    CString cDialogStr;
    cDialogStr.LoadString( IDS_REG_DIALOG );
    CString cAnsStr;
    cAnsStr.LoadString( IDS_REG_ANS );

    GetTheApp().WriteProfileInt( cDialogStr, cAnsStr, m_iAns );
}

『これは完璧？』
「完璧ってことは……」
『えーそーなの？』
「例えば、 cDialogStr 作ったりするのって CCalcDlg::OnInitDialog() で
もしてるでしょ」
『あ、そういえば』
「こういうふうに、同じのをいろんなとこに書くとミスが出やすいから、本
当は CCalcDlg のメンバ変数とかにして使い回す方がいいかな」
『なるほど』
「で、プログラム関係はこれくらい」
『ホント、基本的にシンプルだよね』
「ただ、量的にはそれなりにあるよ。イベントハンドラごとに分かれてるか
ら、少なく感じるだけで」
『全部まとめたら大きいってことなんだ。でも〈小さいプログラムの組み合
わせ〉が大事なんでしょ？』
「そういうこと。こんなふうにイベントハンドラ関数ごとにプログラムを分
ければ分かりやすいってことだね」
『はーい』
「あとはリソース」
『アイコンとかバージョン情報とか、バージョン情報ダイアログとかだね。
うん、これはちゃんとしたよ』
「フリーウェアとして公開するんならこういうのもちゃんとしなきゃね。
で、今回最後は」
『デバッグビルドとリリースビルド！　ってなに？』
「んーとまず、プログラムの間違いを〈バグ〉って言います」
『あ、ゲームとかでよく言うよねそれ。画面ぐちゃぐちゃになって〈あ、バ
グった！〉とか』
「そのバグを取り除くことを〈デバッグ〉っていいます」
『で、デバッグビルド？』
「そう。実は、今までしてきたビルドはこの〈デバッグビルド〉。デバッグ
ビルドはデバッグ用のいろんな機能がついてます」
『いろんな機能って？』
「例えばブレークポイントとか」
『え、あれってどんなアプリでもできるんじゃないの？』
「デバッグビルドしなきゃ、ブレークポイントは使えないの。あと TRACE()
も実はデバッグビルド専用」
『えっ、てことはフツーのアプリはアウトプットウィンドウに文字表示した
りできないの？』
「一応ね。で、こういったことができないようなビルドを〈リリースビルド〉
っていいます」
『えー、なんかそれって不安』
「でもデバッグビルドだと余分なものがいっぱい憑いてるから、実行ファイ
ルが大きくなるし、少し遅くなるし」
『つまりブラッシュアップってこと？』
「手軽なブラッシュアップ、かもね。だから、デバッグビルドで作ったプロ
グラムで入念にテストしたあと、リリースビルドでアプリを作って、公開」
『それがパターンってことなんだ』
「そういうこと。じゃ、さっそくしてみましょう。メニューの【ビルド】
−【アクティブな構成の設定】を選んで」
『はーい』
　【プロジェクトの標準構成】というダイアログが表示される。中に
Calc - Win32 Release と Calc - Win32 Debug があり、後者が選択され
ている。
『 Debug がデバッグ、 Release がリリースだよね。じゃ、 Release の方
を選んで OK っと』
「そしたらビルド」
『ビルド。あ、時間かかってる』
「全部別のファイルとして新しく作り直すからね」
『あ、終わった』
「そしたら、できた Calc.exe を見比べてみようか。 Calc.cpp とかがある
フォルダを開いて」
『メニューの【ファイルを開く】っと。あ、 Debug と Release のフォルダ
がある！』
「デバッグビルドしたのとリリースビルドしたのが別々に置いてあるってこ
と。両方とも開いて、 Calc.exe のサイズを比べてみて」
『えっとねー、 Debug が 108KB 、 Release が…… 24KB って４分の１以
下！？』
「こんだけ違うわけ。リリースビルドした方がいいってことが分かったで
しょ」
『ホントねー、これだけ違うとねー』
「当たり前だけど、もちろん普通のアプリとして機能するから」
『あ、そっか。ダブルクリック……ちゃんと計算機してる！』
「足し算だけだけどね」
『うっさいなー』
「じゃ、最後にちょっと難しい話」
『えー？』
「ま、軽く聞き流すくらいでいいから。メニューの【プロジェクト】−【設
定】を選んで」
『はーい』
　【プロジェクトの設定】ダイアログが表示される。
『あ、上の【設定の対象】が Win32 Release ってのになってるけど、もし
かして？』
「その通り。えっと右側の【C++】ページの、カテゴリ【一般】に【デバッ
グ情報】ってあるでしょ」
『うん、【しない】になってる』
「ここで【設定の対象】を Win32 Debug にすると……」
『あ、【エディットコンティニュー用のプログラムデータベース】とかゆー
のになった！』
「つまり、リリースだとデバッグ情報を作らなくて、デバッグだとなんか作
ってくれるってこと」
『ほー』
「今は簡単にデバッグとビルドって言ってるけど、ホントはこういう細かい
設定の話なんだってこと、ちょっとだけ憶えといて」
『ってことは、いつかこれもわかんなくちゃいけないってことなのね……』

/*
    Preview Next Story!
*/
『来週で最終回！』
「最終回じゃありません、まだまだ続きます」
『まだまだ先は長いのね』
「というわけで次回」
＜ Version 3.25 フリーウェア、公開！ ＞
『につづく！！』
「ま、今の予定じゃ全１５０回、３年ってとこだね」
『ってことはきっと５０年は掛かるのね！！』
「おい」


/*                       金菜さんの憂鬱                           */
http://www.kab-studio.com/Programing/KanaU/

アプリのツボ
#12 画像処理 その２

　画像処理アプリには、主に３つの種類があります。ペイント系、ベジエ曲
線系、3D 系のみっつ。

　ペイント系は Photoshop や PaintShopPro なんかのこと。これらは、画
像データをビットマップとして持っています。ある意味、一番普通のタイプ
ってことね。各ピクセルをそのまま画面に表示すればいいんだから。
　ま、実際に売り物にするには相当の付加価値を付けないとダメだろうけど
ね。さまざまな描画方法のサポート、レイヤやアルファチャンネル、そして
前回見た各種フィルタ。こういったアプリを作るには、画像の知識と同時に
それをどう実装するのかっていう知識も必要だから、かなり大変かも。

　ベジエ曲線系は、「ベジエ曲線」っていう方法を使って絵をデザインする
タイプのアプリです。 Illustrator や CorelDRAW なんかがそう。デザイ
ナーがよく使います。
　この手のアプリは、まずベジエ曲線を扱うことが大変かも。でも、フリー
のライブラリに、ベジエ曲線を扱っているものがあるみたい。こういうのを
使ってみるのがまず近道かな
　いまいちベジエ曲線系は人気ないけど、 Photoshop に「パス」として備
わっていたりしてるし、「フォント作成アプリ」に使われてたりして、意外
と需要はあるのよ。

　3D 系はその名の通り 3DCG を作成するアプリケーション。 Shade や
LightWave なんかがそう。
　これはもうずはり、 3D 処理をするライブラリを使えるようになることか
ら始める必要があるよね。いろんな OS で動かすなら OpenGL 、ウィンドウ
ズだけでいいんなら Direct3D 、結局このふたつが安価で手軽に使える 3D
ライブラリね。
　これができるようになったら、今度はモデリングの方法。 Shade みたいに
ベジエ曲線で表現するのか、 LightWave みたいにポリゴンで表現するのか。
これも結構大変よね。

　というわけで、はっきり言ってどれも大変。でもね、別にパッケージアプ
リ並のものを作る必要はないと思うの。パッケージアプリでも「この機能は
使いづらい」とかあるでしょ、そういう部分だけを持つアプリを作るとかす
れば、結構当たると思うよ。データのコンバートさえできればね。
　画像と来れば、ってことで来週は音声処理。じゃね。


/*            ２０００年３月２７日（月）の更新予定                */
http://www.kab-studio.com/Info/News/

・……予定なし。
　今のところ予定なし。
　ただ、３月末から４月始めに掛けて「 STL & iostream 入門開始」「４月
表紙」「 KAB-studio.h １周年！」などなんか予定が詰まってるんで、表紙
だけでも先に掲載しちゃうかもしんない。


/*                          ご注意！！                            */

・このメールを返信しないでください。
・ご意見・ご希望・ご感想は[チョー普通な日記]よりお送りください。
http://www.kab-studio.com/nikki2/
・プログラミングに関する質問は[鏑矢の憂鬱]にお送りください。
http://www.kab-studio.com/Programing/KabuU/
・購読登録を解除したいときにはこのページで行なってください。
＊http://www.mag2.com/m/0000012198.htm
＊http://www.pubzine.com/detail.asp?id=000590
・解除は自分で行なってください。
・バックナンバーはこれらのページにあります。
http://bigbeat.tegami.com/~mgsearch/frame.cgi?id=0000012198
http://www.kab-studio.com/Freeware/

/*
    KAB-studio.h
    Weekly Mail Magazine.
    Written by Kaburaya Seiden.

    (C)KAB-studio 1999 - 2000 ALL RIGHTS RESERVED.
        http://www.kab-studio.com/
        info@kab-studio.com
*/


/*                      See you next week!!                      */


