2

今日、私のプログラムをコンパイルしているときに、GCC のメモリ消費パターン (コンパイル ステップ) に非常に奇妙な点があることに気付きました (これは何らかの形で説明できるはずです)。「cc1plus」と呼ばれるプロセスは、コード行が 10000 行未満のプログラムに約 10 GB の RAM を使用していました。コード行にコメントを付けてコメントを外した後、最終的に「犯人」を見つけました。

std::bitset<UINT_MAX>

自分自身をテストしたい場合は、次の非常に短いプログラムを試してください。

#include <iostream>
#include <bitset>
#include <climits>

std::bitset<UINT_MAX> justAVar;

int main()
{
   std::cout << UINT_MAX << std::endl;
   return 0;
}

-std=c++11または-std=c++0xを使用してコンパイルします。この小さな例でも、コンパイル時に 大量の RAM を使用することに注意してください(私の場合、gcc のボックスと clang の 2.6 ボックスの両方で 7 GB) ) したがって、リセット ボタンを押さなければならない場合は、警告を受けていないかのように泣き言を言ったり神々を呪ったりしないでください。

私のテストマシン:

セットアップ 1: Debian 7.0 64、gcc 4.8.1

セットアップ 2: Ubuntu 12.04 64、gcc 4.7.3、gcc 4.8.1、clang 3.0.6 (最後に-std=c++0xを使用)

私の親切な同僚の1人が私に示したように、ビットセットコンストラクターの実装に関する1つのヒント(明らかにC++ 11およびC ++ 0xのif defによって保護されています):constexprを使用して宣言されています

そして今、質問: 誰かが私 (私たち) に、この場合、これらすべてのコンパイラーで何が起こっているのか説明してもらえますか?

ありがとうございました

4

3 に答える 3

0

UINT_MAX最新のマシンでは約 40 億です。std::bitset<N>はビットを格納するためN、このような に必要なメモリは 0.5 ギガバイト (40 億 / 8) になりstd::bitsetます。表示されるオーバーヘッドは、おそらく内部コンパイラの最適化によるものです。

http://coliru.stacked-crooked.com/でのいくつかの小さな実験:

したがって、少なくとも Clang の場合、constexprC++98 に がないため、適切なリソースで問題なくこのプログラムをコンパイルできます (Coliru がクライアントに許可するメモリの量はわかりません)。

于 2013-10-04T08:28:21.017 に答える