質問には逆から答えよう。楽な順というか長さの逆順だな。
>>(その三)
>>
>>日曜日に練プ連副会長から電話があり「春会やらないの?」との質問あり。
>>会長殿は三月ぐらいのご予定はどうでしょうか?
いまのところ3月には何の予定も入っていない。
ヨキニハカラエ。
>>(その二)
>>
>>上記と関連するんですけれど、文字列で何かを初期化する場合
>>
>> char Msg[] = {"ErrorMessage!!"};
>>
>>こうやると"ErrorMessage!!"文字列分の領域が確保されると思います。
>>
>> char pMsg * = "ErrorMessage!!";
>>
>>こうやった場合"ErrorMessage!!"文字列分の領域が確保されたあと pMsg のメモリが獲得
>>され、アドレスが格納されるんでしょうか?。 上下の意味合いの違いがよく分かりません。
>>(雑誌のサンプルコードに下の記述方法をよく見かけるんですけど・・・)
>>
上記2つの違いをノベルはNetWare。便宜的に上をア、下をイとする。ア
は文字列の領域のみを確保する方法。イは文字列の領域はモチロンだが、その
ポインタが実体として存在する方法。イの方法はアの方法に比べ(32bit機なら)
1文字列毎に4Byte余計にメモリを食う。
余計にメモリを食うのになんで下の方法を良く見るのかというと、アの方法
ではメッセージを配列にはできないけど、イの方法は配列にできるなど、取り
扱いが楽になるからだ。これは問いの(その一)にも関係する。
externでの参照も違う。
アは
extern char Msg[];
と書かなくてはいけない。
イはもちろん
extern char *pMsg;
となる。
使うときの記述が同じだから、同じように扱えると思ったら大間違い。ポイ
ンタの実体があることとと配列の先頭のアドレスが参照できるってのは全然意
味が違うのであった。イのpMsgには代入できるがアのMsgには代入できないっ
てのが大きな違い。
ポインタとアドレスの違いはCプログラマの優劣の分かれ目なんできちんと
理解しようね。「同じように扱える」は「本当は同じではない」ということだ
から。
>>
>>(その一)
>>
>>ロジック構築段階においての僕の疑問について師匠の意見を伺いたいのですが
>>よろしいでしょうか?。
>>
>>概要:何らかの処理を行っている時にエラーが発生した場合、特定の領域に
>> エラーコードを設定して、上位にエラーが発生している旨を通知する。
>> 上位層は通知を受けた後で、そのエラーコードを参照してメッセージ表示
>> を行う。エラーコードは順列値ではない。エラー原因によってエラーレベルを
>> 判断し、エラー表示方式を切り換えたい。(GetLaseError()のイメージ)
>>
>>僕の設計:エラー情報テーブルを以下の用に持つ
>>
>> struct ErrorInfo {
>> DWORD ErrorCode:
>> DWORD ErrorLevel:
>> char ErrorMsg[256];
>> }
>>
>> この構造体をエラーの数だけ構築し、それぞれの内容を
>> 各エラー項目に合わせた情報で初期化しておく。エラー発生時に上位層から
>> 渡されたエラーコードでテーブルを検索し、エラーレベル、エラーメッセージを獲得、
>> エラーメッセージを表示する。
>>
>>心配点:これって標準的な方法何でしょうか? エラーの数分テーブルを
>> 持てば改造は楽かもしれませんが、数が増えた場合問題無いんでしょうか?
>> 今まではエラーメッセージ等は#defineで定義していたので、メモリ領域とか
>> はあまり問題視していませんでした。今回はエラーコードに対応してメッセージ
>> を検索しなければならないので#defineが使用できません(ですよね???)
>> なので上記のような方法を考えたのですが、どうでしょうか?
>>
>>結構マジで悩んでいます。動けばいいというのであれば上記のもので問題ないんですが
>>どうも府に落ちません。エラーメッセージ表示処理の一般的な方法というものが
>>存在するのであればご享受できないでしょうか?
>>
もう答えはわかっているね。
A
struct ErrorInfo {
DWORD ErrorCode;
DWORD ErrorLevel;
char ErrorMsg[256];
}
ではなく
B
struct ErrorInfo {
DWORD ErrorCode;
DWORD ErrorLevel;
char *ErrorMsg;
}
とすべきだろう。
MFCが使えるなら
C
struct ErrorInfo {
DWORD ErrorCode;
DWORD ErrorLevel;
CString ErrorMsg;
}
でもよい。
Aはメッセージひとつごとに必ず256バイトのエリアが必要となるが、エラー
メッセージなんて40バイト程度が相場。とてつもない無駄になる。配列にする
ときの制限としてサイズが固定されるのは(その二)を理解すればわかると思
う(不定長の配列はCの仕様にはない)。
Bは不定長の配列が作れないという限界をポインタを使うことで解決したも
のだ。メッセージファイルから読むならmallocで結び付けてもよかろうし、ソー
スに書くなら普通に代入すれば良い。
エラー表示関数を工夫して、エラーメッセージがNULLだったらコードとレベ
ルから簡単なメッセージを作って表示するようにすれば、ユーザレベルが見な
いはずのメッセージを省略できるし、そもそも、メッセージが完成していなく
てもプログラムとして確実にエラー表示できる。
CStringはchar *に比べれば多少多くのメモリを消費するが、char[256]みた
いに馬鹿食いはしない。
こんなもんかな。
Takeshi Yoneki
PM8500への環境移行も済んで、次はHUNDOSHI-EDITのリリース向け仕上げだ。かなり久しぶりのアップだがさほどの変更があったわけではない。改行と漢字の自動コンバートをするようになった程度だ。
かなり久しぶりにアバウトダイアログのレイアウトを変更し、プログラムでバージョンとリリース年月を表示するようにした。アバウトを見て68K版かPPC版かの判断をしたかったからだ。
引用符プラグインの後藤さんに連絡を入れなくちゃいけないなぁ。
褌満点音頭のデータをQuickTime2.5に合わせて調整した。ドラムスを中心に音色の大幅改定がなされているため、従来のデータではかなりバランスが崩れて再生される。シンバルの音がやたらとでかいのだ。これはQuickTime2.5の方のバランスが悪いんだと思うんだが、また改定するんだろうか。他環境向けのファイルを演奏させるとどうなんだろうね。ウチにはいわゆるGMデータ再生環境がない(あるのはGM以前の器材ばかり)んで聴き比べはできないのが残念。
音そのものは以前に比べ格段に良くなった。根本的にショボいのはしかたないとしても、前のはあまりにあんまりだった。PM8500にAT互換機を買ったときに付いてきたスピーカを接続し、QuickTime2.5環境で演奏させるとかなりイケる。Master Tracks Pro 6は直接内蔵音源で演奏できるのでデータ調整も非常に楽だ。MoviePlayerを使って標準MIDIファイルをコンバートすると、オプションでQT2.0互換が設定できる。これでMIDIデータのプログラムナンバー(音色番号)をいちいちズラして保存する必要がなくなった。
IIcxではそもそもまともに音がでなかった(処理が重過ぎて)。やはり速いマシンは良い。
前回アップ時のアーカイブを参考にしようとMacLHaを使うとExtract指定で必ずコケる。_CalcMaskとかいう関数だ。よくよく調べると、アーカイブに含まれるフォルダ名と同じ名前のファイルがあった。これが原因となっていたようだ。あんまりチェックはしてないんだね。
困ったことに、キャラベルのAV-1000HGをPM8500に接続すると、ディスクが回転しない。PM8500の電源を入れる以前に外付けのディスクが回転しないのだ。キャラベルに電話するが(非常につながりにくかった)こういった症例はないそうで、解決にはほど遠い。
キャラベルでないディスクはちゃんと動作しているし、キャラベルのディスクも他のマックでは動作している。他のPM8500が存在すれば試験もできるんだがなぁ。お姉ちゃんに頼もうかな。
ひとつ懸念材料がある。PM8500の内蔵ディスクは本来の製品構成ではない増設したものであろうということだ。旧型PM8500のディスクが2GBだったとは思えない。このSeagateディスクがキャラベルのディスクと喧嘩しているのではないかという可能性がある。そもそも内蔵用かどうかも怪しい。
今アップル(株)のサイトを見たら、旧型PM8500のディスクは1.2GBまたは2GBとある。純正の可能性もあるってことか。ともかく内蔵ディスクを外しての実験が必要だな。
私はSCSIでトラブらないマック買ったことないぞぉ。
1997.02.27
PM8500の内蔵ディスクはアップルマーク付きの純正品であった。昨日はモニタ画面に変な点線が入ったし、どうも不良っぽいなぁ。
1997.02.28
「ホーム」へ戻る
「読まなくてもいいよ16(前編)」
OSTRACISM CO.
OSTRA / Takeshi Yoneki