No.3ベストアンサー
- 回答日時:
Visual C++ Ver6.0 SP5、WindowsMe、640MBの環境でWizardによってダイアログベースのアプリを作成して全てデフォルトのまま以下の変数を定義したところ...
static BYTE lpBuff[1000000000];
下のような警告が出ました。
warning LNK4084: トータル イメージ サイズ 1028317184 が最大値 (268435456) を越えています; イメージは動作しない可能性があります
また、
TRY
{
BYTE*lpBuff;
lpBuff = new BYTE[640000000];
delete lpBuff;
}
CATCH_ALL(e)
AfxMessageBox("error");
END_CATCH_ALL
ようにしたところコンパイルはできるものの例外がトラップできました。
ありがとうございます。
最大値 (268435456) というのは何かよく分からないけど、大きいですね。
俺は、http://www.mediawars.ne.jp/~freemage/progs/win01 … のスケルトンの、case WM_PAINT:を消して、switch(uMsg)の前に、char buf[250000];を書いて、エラーはありませんでした。
char buf[250000];エラー無し
char buf[260000];終了時にエラー
char buf[600000];起動時にエラー
でした。
1つの変数でなく、アプリケーション総合に限界があるみたいです。
char buf[120000];とchar buf2[130000];エラー無し
char buf[130000];とchar buf2[130000];終了時にエラー
でした。
終了時にエラーというのはとてもやっかいだと感じました。そんなことが起きると、case WM_DESTROY:のソースのデバッグを始めてしまいそうです。
char buf[250000];でエラーが起きることがあったり、
char buf[260000];でエラーにならなかったりしたらお知らせください。
No.5
- 回答日時:
自分に突っ込み!
> newによる動的領域確保は実装方法が不明確(処理系ごとに違う可能性がある)ので、APIでの動的猟奇確保<<誤字>>を利用するべきです。
おかしい事言ってますね。
newによる動的領域確保は実装方法が不明確(処理系ごとに違う可能性がある)ので、「『大容量の領域』または『長期間維持する領域』の場合は」APIでの動的領域確保を利用するべきです。
と書くべきでした。
じゃ、「大容量って何バイトから?」、「長期間ってどれくらい?」という話になるのですが…
時と場合と環境で決まります。
OSによっては「大容量領域確保用のAPI」や「メモリフラグメンテーションを回避するためのAPI」が用意されていることが多いので、言語処理系付属のプログラミングマニュアルやOSのアーキテクチャ解説書を参照して利用するAPIを決定します。
No.4
- 回答日時:
2の28乗バイトの静的データを必要とするEXEファイルは起動できません(Windowsの場合限定)。
これは明確な限界値が存在するので問題となることは少ないでしょう。
実行エラー(起動時、実行中、終了時)のエラーに関しては環境依存です。
・実装メモリ
・仮想記憶設定
・ページファイルを保持するディスクドライブの残り容量
・同時実行されているソフトウェアが占有するページ仮想記憶容量
などです。
通常、メモリ確保時のエラー報告を受け取りやすい動的領域の利用が推奨されます。
newによる動的領域確保は実装方法が不明確(処理系ごとに違う可能性がある)ので、APIでの動的猟奇確保を利用するべきです。
ありがとうございます。2の28乗という制限があるのは知りませんでした。
char buf[600000];の時の、600000*256=153600000で起動できなかったけど、
2の28乗の268435456までは100000000バイトあります。
この場合は2の28乗の制限よりも、環境依存の実行エラーの条件にあてはまったみたいですね。
No.2
- 回答日時:
ずっと昔し、スモールモデル、ラージモデル。
。。などの区別があって、ポインターのビット数やデータ領域の大きさなどの
話がありました。その頃はそれぞれのモデルでの限界値がはっきり決まっていました。
これについては、16ビットの頃のコンパイラのマニュアルを見れば良いと思います。
その後、ウインドウズのメモリーの扱いが変化してきて、
本当のメモリーの上に確保できないときは勝手にハードディスクの上の
移してしまうようになりました。
従って、外部変数として静的に確保するのはかなり大きなものでも大丈夫だとおもっています。確保の時の状態としては、ハードディスクが回転しっぱなしの状態になる。
内部変数は、話が別です。
あまり大きな領域を確保すると、ソフトウエアの性能が落ちると思います。
理由は、ハードディスクとのやりとりが始まると時間がかかりすぎるから。
メモリーは、必要なときに必要なだけ確保し、ポインターをチェックして
ほんとに確保できたか判定してから使い、いらなくなったらすぐに解放する。
このようにしないと、メモリーの少ない機械に移して稼働させるときに
使いものにならないプログラムになると思います。
最近、マイクロソフトのビジュアルスタジオのマニュアルを読んだのですが
詳しい話は書いてなかったです。
間違った内容の記述かもしれませんので、
他の専門家の方々の意見も聞かせていただければ幸いです。
ありがとうございます。
心配なぐらい大きいならnewして、newからのエラーを受けるのが確実だけど、どれぐらいからが心配なのかさえ分からない状態なんです。
No.1
- 回答日時:
コンパイルするときにラージにするとかスモールにするなどで変わるのではないでしょうか?
プログラムの動作時のメモリ確保はnewでも静的でも失敗することはあると思います。
お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!
このQ&Aを見た人はこんなQ&Aも見ています
関連するカテゴリからQ&Aを探す
おすすめ情報
このQ&Aを見た人がよく見るQ&A
デイリーランキングこのカテゴリの人気デイリーQ&Aランキング
-
GetCommandLineを使用しました。
-
ビットをローテートするプログ...
-
c言語のポインタへの文字列入力...
-
stringの最大サイズ
-
64ビットと32ビットの違い
-
ヒープメモリの解放について
-
newしないオブジェクトについて
-
仮想メモリでない環境でのmallo...
-
allocってなんですか?
-
配列の添え字の最大数とは?
-
win32APIのHeapAlloc()の使い方...
-
void*型のデータサイズ
-
callocの処理速度
-
malloc呼び出し時のセグメンテ...
-
メモリ不足になってしまう。
-
LoadLibraryでAccess Violation...
-
reallocの断片化対策について
-
メモリ解放について
-
C++で、メンバもヒープに確保さ...
-
reallocについて
マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング
-
allocってなんですか?
-
c言語のポインタへの文字列入力...
-
newしないオブジェクトについて
-
ヒープメモリの解放について
-
malloc呼び出し時のセグメンテ...
-
構造体でchar name[]と*nameの...
-
ビットをローテートするプログ...
-
配列の添え字の最大数とは?
-
Accessで、メモリを開放するタ...
-
スタック破壊の上手な見つけ方...
-
64ビットと32ビットの違い
-
大容量の静的な確保の限界値
-
C++のnewで確保したメモリーの...
-
stringの最大サイズ
-
GDI+におけるメモリの開放について
-
newでrealloc?
-
callocの処理速度
-
void*型のデータサイズ
-
プログラムが途中で強制終了し...
-
C++で、メンバもヒープに確保さ...
おすすめ情報