Есть ли ограничение на количество вложенных циклов for?

Question

Поскольку все имеет предел, мне было интересно, существует ли ограничение на количество вложенных циклов for или пока у меня есть память, я могу их добавить, может ли компилятор Visual Studio создать такую ​​программу?

Конечно, 64-х или более вложенные петли for были бы непригодны для отладки, но возможно ли это?

private void TestForLoop() 
{ 
    for (int a = 0; a < 4; a++) 
    { 
    for (int b = 0; b < 56; b++) 
    { 
     for (int c = 0; c < 196; c++) 
     { 
     //etc.... 
     } 
    } 
    } 
} 

Answer 1

Я выхожу на конечности путем размещения, но я думаю, что ответ:

Между 550 и 575

^{с настройками по умолчанию в Visual Studio 2015}

Я создал небольшую программу, которая генерирует вложенные петли for ...

for (int i0=0; i0<10; i0++) 
{ 
    for (int i1=0; i1<10; i1++) 
    { 
     ... 
     ... 
     for (int i573=0; i573<10; i573++) 
     { 
      for (int i574=0; i574<10; i574++) 
      { 
       Console.WriteLine(i574); 
      } 
     } 
     ... 
     ... 
    } 
} 

Для 500 вложенных циклов программа все еще может быть скомпилирована. С 575 циклов, компилятор вываливается:

Предупреждение AD0001 Analyzer «Microsoft.CodeAnalysis.CSharp.Diagnostics.SimplifyTypeNames.CSharpSimplifyTypeNamesDiagnosticAnalyzer» бросил исключение типа «System.InsufficientExecutionStackException» с сообщением «Недостаточно стека продолжить выполнение безопасно. Это может произойти из-за слишком большого количества функций в стеке вызовов или функции в стеке, используя слишком много пространства стека. '.

с основным сообщением компилятора

ошибка CS8078: Выражение является слишком длинным или сложным для компиляции

Конечно, это чисто гипотетический результат. Если самый внутренний цикл содержит больше, чем Console.WriteLine, тогда может быть меньше вложенных циклов до превышения размера стека.Кроме того, это может быть не строго технический предел в том смысле, что могут быть скрытые настройки для увеличения максимального размера стека для «Анализатора», упомянутого в сообщении об ошибке, или (если необходимо) для результирующего исполняемого файла. Однако эта часть ответа остается для людей, которые знают C# по глубине.

---

Update

В ответ на question in the comments:

мне было бы интересно увидеть этот ответ расширен, чтобы «доказать» экспериментально, можно ли ставить 575 локальные переменные в стеке, если они 're не Используется в петлях и/или вы можете положить 575 не вложенные для петель в одной функции

В обоих случаях ответ: Да, это возможно. При заполнении метода 575 автоматически сгенерированных операторов

int i0=0; 
Console.WriteLine(i0); 
int i1=0; 
Console.WriteLine(i1); 
... 
int i574=0; 
Console.WriteLine(i574); 

он все еще может быть скомпилирован. Все остальное меня удивило бы. Размер стека, необходимый для переменных int, составляет всего 2,3 КБ. Но мне было любопытно, и для того, чтобы проверить дальнейшие ограничения, я увеличил это число. В конце концов, он сделал не компиляции, вызывая ошибку

ошибка CS0204: только 65534 местных жителей, в том числе, генерируемый компилятором, допускаются

который интересный момент, но уже наблюдали в других местах: Maximum number of variables in method

Аналогично, 575 невложенныхfor -loops, как и в

for (int i0=0; i0<10; i0++) 
{ 
    Console.WriteLine(i0); 
} 
for (int i1=0; i1<10; i1++) 
{ 
    Console.WriteLine(i1); 
} 
... 
for (int i574=0; i574<10; i574++) 
{ 
    Console.WriteLine(i574); 
} 

также может быть скомпилирован. Здесь я также попытался найти предел и создал больше этих циклов. В частности, я не был уверен, что переменные цикла в этом случае также считают als «locals», потому что они находятся в их собственном { block }. Но все же более 65534 невозможно. Наконец, я добавил тест, состоящий из 40000 петель узора

for (int i39999 = 0; i39999 < 10; i39999++) 
{ 
    int j = 0; 
    Console.WriteLine(j + i39999); 
} 

, который содержал дополнительную переменную в цикла, но они, кажется, считаются «местных», а также, и не было возможности собрать это.

---

Итак, подведем итог: Предел ~ 550 действительно вызвано вложенности петель.Это также было указано в сообщении об ошибке

ошибка CS8078: выражение слишком длинное или сложное для компиляции

documentation of error CS1647, к сожалению (но по понятным причинам) не определяет «измерение» сложности, но дает только прагматичный совет

В вашем компиляторе произошел переполнение стека. Чтобы устранить эту ошибку, упростите свой код.

Чтобы подчеркнуть это снова: Для конкретного случая глубоко вложенных for -loops, все это скорее академическое и гипотетический. Но поиск в Интернете сообщения об ошибке CS1647 показывает несколько случаев, когда эта ошибка появилась для кода, который, скорее всего, не был намеренно сложным, но создан в реалистичных сценариях.

Answer 2

В спецификации языка C# или в CLR нет жесткого ограничения. Ваш код будет итеративным, а не рекурсивным, что может привести к переполнению стека довольно быстро.

Есть несколько вещей, которые могли бы рассчитывать в качестве порогового значения, к примеру (в целом) int счетчика вы будете использовать, что бы выделить определенную int в памяти для каждого цикла (и, прежде чем вы выделили весь стек с Интс. ..). Обратите внимание, что использование этого int требуется, и вы можете повторно использовать одну и ту же переменную.

Как pointed out by Marco, текущий порог больше в компиляторе, чем в фактической спецификации языка или во время выполнения. Как только это будет перекодировано, у вас может возникнуть еще несколько итераций. If you for example use Ideone, который по умолчанию использует старый компилятор, вы можете легко получить более 1200 for.

Это много для петель, хотя индикатор плохой конструкции. Надеюсь, этот вопрос является чисто гипотетическим.

Answer 3

Существует лимит для всех C#, скомпилированных до MSIL. MSIL может поддерживать только 65535 локальных переменных. Если ваши петли for похожи на те, которые были показаны в примере, для каждого из них требуется переменная.

Возможно, ваш компилятор может выделять объекты в куче, чтобы действовать как хранилище для локальных переменных, обходя это ограничение. Однако я не уверен, какие из этих странных результатов будут получены. Могут возникнуть проблемы, возникающие с размышлениями, которые делают такой подход незаконным.

Answer 4

Между 800 и 900 для пустых for(;;) петель.

подхода Зеркального Marco13, за исключением пытавшихся for(;;) петель:

for (;;) // 0 
for (;;) // 1 
for (;;) // 2 
// ... 
for (;;) // n_max 
{ 
    // empty body 
} 

Он работал на 800 вложенных for(;;), но он дал ту же ошибку, что Marco13 столкнулся при попытке 900 петель.

Когда он компилируется, for(;;), по-видимому, блокирует поток без превышения ЦП; по-видимому, он действует как Thread.Sleep().