new とかで作る分には全然問題なし。
ローカルに取るとちょっと不安。

PAIさん　お返事ありがとうございます。

>ローカルに取るとちょっと不安。

そうなんですか。（涙）
ローカルとはメンバ変数で持っている場合も含まれるのですか？
「ちょっと不安」というのは経験からでしょうか？

変数の持ち方を考え直さないといけないでしょうか？
よろしくお願いします。

あ、念のため。

>int型を4バイトchar型を1バイトで計算しました。
>これは問題ないでしょうか？

構造体の中でパディングが生じてない限りＯＫ。

>皆様はもっと大きなサイズで扱われたことがありますでしょうか？

今vectorで16バイトの構造体を5万件ぐらい一気にメモリにとって処理してる。

>また、どのあたりのサイズで「危なそう」という判定をすればよいのでしょうか？

環境による、ふつうのＰＣでスタック上でなら１Ｍぐらいまで、
ヒープ上は最近のＯＳは仮想メモリが働くので１００ＭぐらいまではだいたいＯＫ、
// 組み込みだったら動的にメモリなんか取れない。

とか。

>ローカルとはメンバ変数で持っている場合も含まれるのですか？

メンバに持ってても、そのオブジェクト全体をNewした場合はヒープにできます。

>「ちょっと不安」というのは経験からでしょうか？

確か、VCのスタックサイズはデフォルトで１Ｍだったような気が・・・

PAIさん　お早いお返事、ありがとうございます。m(..)m

>メンバに持ってても、そのオブジェクト全体をNewした場合はヒープにできます。
あ、なるほどですぅ。

CABCApp::InitInstance()で

CMultiDocTemplate* pDocTemplate;
pDocTemplate = new CMultiDocTemplate(
IDR_WU3TERTYPE,
RUNTIME_CLASS(CABCDoc), // このドキュメントのメンバ変数が
// 大きい配列を持っています
RUNTIME_CLASS(CChildFrame),
RUNTIME_CLASS(CABCView1));
AddDocTemplate(pDocTemplate);

このように ドキュメントテンプレートが new されていまして、ドキュメントクラスの
メンバ変数に大きなサイズの配列が２Ｍバイトくらいあります。

この場合ですと、ドキュメントクラスも new されていると判断して良いでしょうか？
この場合でしたら「問題なし」と判定して良いでしょうか？
よろしくお願いしますぅ。m(..)mペコリ

どうもです。計算についてですが、
char型は最後に＋１バイトするのでは？
例えば、
char hoge[10];
だったら、１１バイトでは？
たしか、ＶＣのコンパイラではそうなると聞いたのですが・・・

間違いだったら、ゴミレスです。

>int型を4バイトchar型を1バイトで計算しました。これは問題ないでしょうか？
問題ありません。

>この場合ですと、ドキュメントクラスも new されていると判断して良いでしょうか？
良いです。

>この場合でしたら「問題なし」と判定して良いでしょうか？
良いです。但し正しく動かすだけならという事です。
理由はMFCの構造に助けられた為です。

最良なのは、既出の2[Mbyte]配列は 自前でヒープへ配置する 事です。

>// 組み込みだったら動的にメモリなんか取れない。
ターゲットが少ヒープならそうですね。
但し 組み込みでも動的確保が常 というターゲットはたくさんあります。

>char型は最後に＋１バイトするのでは？
しません。

＞char型は最後に＋１バイトするのでは？
＞例えば、
＞char hoge[10];
＞だったら、１１バイトでは？

そうではなくて、C言語やC++言語では、文字列の最後をNUL文字で認識するので
10文字の文字列を扱いたい時は、終端文字(NUL)の分まで余計に確保しなくては
ならないというのが正解です。
従って、宣言上で10個の配列で宣言していれば10バイトと考えて問題ありません。
但し、既に話が出ているように構造体のようにワンセットで扱う場合は、バウンダリの
問題があり、コンパイル時にパックをしないとメンバー上にない余分な領域が出来て
しまいます。この場合は、バウンダリ合わせも考慮に入れて計算しなくてはなりません。

>>この場合でしたら「問題なし」と判定して良いでしょうか？
>良いです。但し正しく動かすだけならという事です。
>理由はMFCの構造に助けられた為です。

くたくたさん　お返事ありがとうございました。