编译 C++代码使系统挂起
当我尝试通过发出命令“g++ qr.cpp -o qr”来编译此文件时,系统挂起。我在其他地方没有看到过这种错误。
#include<iostream>
using namespace std;
bool win[1000000001];
bool know[1000000001];
int sixes[] = {6, 36, 216, 1296, 7776, 46656, 279936, 1679616, 10077696, 60466176, 362797056};
bool check(int n){
cout << n << endl;
if(!know[n]){
bool b = check(n-1);
for(int i=0; i<11; i++){
if(n > sixes[i]){
b = b & check(n-sixes[i]);
}
}
win[n] = !b;
}
return win[n];
}
int main(){
win[1] = know[1] = true;
for(int j=0; j<11; j++){
win[sixes[j]] = know[sixes[j]] = true;
}
int n = 1;
cin >> n;
int i = 0;
while(n != 0){
i++;
win[n] = check(n);
cout << i << (win[n]?"-Heckle":"-Jeckle");
cin >> n;
if(n!=0) cout << endl;
}
return 0;
}
我的编译器版本信息如下。
yasith@vostro:~/Dropbox/Shared$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
When I try to compile this file by issuing the command, "g++ qr.cpp -o qr" The system hangs. I haven't seen this kind of an error anywhere else.
#include<iostream>
using namespace std;
bool win[1000000001];
bool know[1000000001];
int sixes[] = {6, 36, 216, 1296, 7776, 46656, 279936, 1679616, 10077696, 60466176, 362797056};
bool check(int n){
cout << n << endl;
if(!know[n]){
bool b = check(n-1);
for(int i=0; i<11; i++){
if(n > sixes[i]){
b = b & check(n-sixes[i]);
}
}
win[n] = !b;
}
return win[n];
}
int main(){
win[1] = know[1] = true;
for(int j=0; j<11; j++){
win[sixes[j]] = know[sixes[j]] = true;
}
int n = 1;
cin >> n;
int i = 0;
while(n != 0){
i++;
win[n] = check(n);
cout << i << (win[n]?"-Heckle":"-Jeckle");
cin >> n;
if(n!=0) cout << endl;
}
return 0;
}
My compiler version information is given below.
yasith@vostro:~/Dropbox/Shared$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
你知道这些有多大吗?
每个至少 1GB!你会想要动态分配它们......
Do you realize how big these are?
Those are at least 1GB each!!! You're gonna want to allocate them dynamically...
它在我的 Debian 系统上用 g++ 4.6.1 编译得很好,该系统只有 1GB 内存。
我尝试查看在更改数组大小时编译器和链接器的各个遍使用的内存,并且内存使用量没有太大变化,这表明编译器没有尝试分配任何与数组大小。
但是,我安装了新的 GNU 链接器“gold”。
然后我再次尝试,使用较旧的(“基于 BFD”)GNU 链接器(它仍然是许多系统上的默认链接器)进行链接步骤,然后我的系统开始疯狂地颠簸(我必须杀死链接器进程)!
因此,新的黄金链接器似乎比旧的链接器更聪明地处理大数组。
在 Debian 上,只需安装“binutils-gold”软件包即可将 gold 安装为系统链接器。 [我不知道Ubuntu是否有相同的软件包,但由于Ubuntu是基于Debian的,所以看起来很有可能。]
It compiles fine with g++ 4.6.1 on my Debian system, which only has 1GB of memory.
I tried looking at the memory used by the various passes of the compiler and the linker when changing the size of the arrays, and the memory use didn't change much, indicating the compiler wasn't trying to allocate any data-structures proportional to the array size.
However, I have the new GNU linker "gold" installed.
I then tried it again, using the older ("BFD-based") GNU linker, which is still the default on many systems, for the link step—and then my system started thrashing like crazy (I had to kill the linker process)!
So it seems that the new gold linker is smarter about big arrays than the older linker.
On Debian, gold can be installed as the system linker by just installing the "binutils-gold" package. [I don't know if Ubuntu has the same package, but as Ubuntu is based on Debian, it seems likely.]
您正在分配 2GB 的静态空间。尝试更改大小并重新编译?
You're allocating 2GB of static space. Try changing the size and recompiling?
该代码虽然有点疯狂,但不应该挂起编译器。如果这是真正的挂起(即超过几分钟),请将其报告为 GCC bug。
The code, while a bit insane, should not hang the compiler. If it's a true hang (i.e. more than a few minutes), report it as a GCC bug.