Ｍｕｓｅ掲示板

●Elekenさん
> なぜ「32」byte かは、もし仮にマクロ展開時に作る構造体が 25-32 byte なら
> 説明がつきそうですが・・・。
Elekenさんって、まるでシャーロックホームズみたいですね！

私が掲示板[8493]で書き込んだ、
> また、機能を削り取ることで不要となった構造体のメンバをコメントアウトしたら、症状が出なくなったこともありました。
を具体的にお示しします。何か考察のヒントになるかもしれません。

既に純正培養Museでは３つの構造体しか使用しておらず、
利用しないメンバーもどんどん剥ぎ取っていますので、
以下の様な簡素な内容になっています。

// ノート構造体 --------------------------------
typedef struct t_note {
	struct t_note* mpz_next;	/* 次ポインタ */
	char* mpc_txt;		/* コマンド文字列 */
	DWORD mh_tim;		/* イベント時刻(ミリ秒) */
	char mc_mid;		/* MIDIデータ */
} T_note;

// データ展開ワーク ----------------------------
typedef struct t_work {
	struct t_work* mpz_next;	/* 次ポインタ */
	char* mpc_data;		/* データ文字列 */
	int mi_num;		/* ★行番号 */
} T_work;

// 定義マクロリスト ----------------------------
typedef struct t_macr {
	struct t_macr* mpz_next;	/* 次ポインタ */
	char* mpc_name;		/* マクロ名(無名マクロの場合はNULL) */
	T_work* mpz_p0;		/* ★開始アドレス( { の次) */
	T_work* mpz_p1;		/* ★終了アドレス( } の前) */
	char mc_ext;		/* ★展開中フラグ */
} T_macr;

この中の★印の付いたメンバーは、現時点の純正培養Museでは使用していません。
そこでこれらの★付きメンバーを剥ぎ取ろうとしたのですが、
１つでも取り払うと、症状が出なくなってしまいました。

●himajin925さん
> しつこいなぁと思われたでしょうが(^_^;)
いえいえ、むしろ“真実を追究する”真摯な姿に感動さえしています。
少々大袈裟かもしれませんが、
この姿勢は、科学者や検事や医師などの職業を問わず、
人のあらゆる活動で尊重されるべきものだと思います。

> で、やはり +1 とするのですか？
はい。可変長文字列のmalloc()だけ１バイト余分に確保するようにしようと思います。
ほとんどは、コンパイル時の一時的な確保ですから、永続的にメモリ効率を落とす訳ではないし、
演奏時にも確保し続けるのは、テキストの表示文字列と譜面モニタの属性表示文字列、
履歴データのパス、楽譜出力用のタイトル群とスルーコマンド位です。
そもそもたった１バイトですので、大勢に影響は無いでしょう。

※その対応箇所のコメント文には、今回の趣旨が分かるように書いておこうと思います。
　さもないと１０年後の自分が見直した時、無駄なメモリを確保している！
　と、戻してしまいそうです(笑)。

> これで、「Muse にバグはなかった！」で良いでしょうね。よかったよかった
とても安堵しています。＼(^o^)／
でもこの“戦いの踊り”が終わり、お二人とエキサイティングなやりとりもできなくなると思うと、
ちょっち淋しい感じもしたりして(苦笑)。

記念といってはなんですが、現時点の純正培養Museをアップデートしておきました。
リロード操作は［↑］に限らず、何のキーボードを押下しても起こるようになっています。
http://www1.c3-net.ne.jp/kato/data/muse.zip