什么限制在C嵌套循环的数量? [英] What limits the number of nested loops in c?

查看:111
本文介绍了什么限制在C嵌套循环的数量?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

编辑:对于那些寻找一个问题的答案是规定标准在编译时限制嵌套循环的数量。在运行时,这是一个不同的问题,因为唯一的限制是,程序段的大小。

For those of you looking for an answer to the question as stated the standard limits the number of nested loops at compile time. At runtime this is a different issue as the only limit would be the size of the program segment.

解决:我一直在寻找太早在构建过程。 C文件获取适用于它进一步preprocessing。断到随后的步骤。

Solved: I was looking too early on in the build process. The c file gets further preprocessing applied to it. Off to the subsequent steps.

我已经通过的Perl从产生的发音适用规则的语言生成的C code的一个问题。在本质论的投入是发音的规则异常巨大的字典。在code为百病之GOTOS和它的工作,直到例外词典之一达到23K规则。

I have a problem with c code generated via perl from a language that applies rules for generating pronunciation. In essense the input is a huge dictionary of exceptions for pronounciation rules. The code is riddled with gotos and it worked up until one of the exception dictionaries reached 23K rules.

在code基本上是不可读的,但我已经设法使去除这似乎是第六千二百嵌套循环后的C code编译:

The code is basically unreadable but I have managed to make the c code compile after removing what appears to be the 6200th nested loop:

for (dictionionary1=seed1;dicitonary1<limit1;dictionary1++)
{
    for (dictionionary2=seed2;dicitonary2<limit2;dictionary2++)
    {
           /* .... */
        for (dictionionary6199=seed6199;dicitonary6199<limit6199;dictionary6199++)
        {
               /* two hundred more removed adding one makes it not compile */

        }

    }
}

GCC和在了xlC能够处理这些,但ACC 3.73(上H11.23 PA RISC)的呕吐。

Both gcc and xlC are able to handle these but aCC 3.73 (on H11.23 PA RISC) is puking.

Compiling /home/ojblass/exception_dictionary_a.c...
Loading the kernel...
Pid 18324 killed due to text modification or page I/O error
/bin/ksh: 28004 Bus error(coredump)
*** Error exit code 138

我发现这个链接和尝试了很多没有成功的建议的修复。

I have found this link and tried many of the suggested fixes without success.

有关遗留的原因,我不得不编译32位(它使用32位的库,我有没有为64位对应)。

For legacy reasons I have to compile for 32 bit (it uses a 32 bit library that I have no 64 bit counterpart for).

maxdsiz = 256 MB (x10000000) tried up to 4 GB
maxssiz = 16 MB (x1000000) tried up to 100MB
maxtsiz = 256 MB (x10000000) tried up to 1 GB

在编译器设置或任何建议,一个很好的链接documetation为ACC 3.73?我淹没在搜索结果中。

Any suggestions at compiler settings or a good link for documetation for aCC 3.73? I am drowning in search results.

我有codeD一种变通方法打破字典成两部分导致dictionary_an.c和dictionary_az.c。我不得不触及一些核心逻辑,我觉得不舒服感人,以退出这个功能,我希望能回落到原来的配置。

I have coded a workaround breaking the dictionary into two parts resulting in dictionary_an.c and dictionary_az.c. I have had to touch some core logic I don't feel comfortable touching in order to pull this off and I was hoping to back down to the original configuration.

推荐答案

哇 - 我知道这对你没有帮助,但嵌套6199级深远远超过什么C或C ++需要(15 C90,127 C99和256 C ++)。

Wow - I know it's no help to you, but nesting 6199 levels deep is well in excess of what C or C++ require (15 for C90, 127 for C99 and 256 for C++).

我很好奇的是如何好那件事运行 - 如果你的词典是任何大小,循环迭代次数一定是天价。说每一个字典大小为10(10 ^ 6199)是一个相当大的数字。即使只有2个项目每字典,(2 ^ 6199)是IM pressive为好。

What I'm curious about is how well that thing runs - if your dictionaries are of any size, the number of loop iterations must be astronomical. Say each dictionary size is 10: (10 ^ 6199) is quite a large number. Even if there are only 2 items per dictionary, (2 ^ 6199) is impressive as well.

这篇关于什么限制在C嵌套循环的数量?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆