Code: for (byte b = 0; (std::cout << b++ << std::endl) && b; ); P.S.: не помню, как в VS, но в билдере по умолчанию typedef unsigned char byte; есть
не, конечно не спорю что JS разделяет переменные по типам, но насколько я помню в самом коде переменные не объявляются - т.к. JS работает с переменными взависимости от обращения, если я напишу: то сначала перем-ая s будет обрабатываться как число, затем как строка, а затем и вовсе как объект...
Algol, миниквест пора заканчивать. Говори правильный ответ. Мне кажется постпроверка с префиксным инкрементом в этом случае оптимальный вариант. По крайней мере по количеству используемой памяти )
SitraIT, ыыы, типа вот этого чтоли: Code: function MyClass(){ this.name="Some"; } var s=new MyClass(); хотя я с JS работаю весьма недолго - я знаю это, но я и не писал что там нельзя этого делать З.Ы. вообще имхо это не классы и объекты, а костыли)))
по-моему ответ где-то тут Code: .method private hidebysig static void Main() cil managed { .entrypoint // Code size 47 (0x2f) .maxstack 2 .locals init (uint8 V_0, bool V_1) IL_0000: nop IL_0001: ldc.i4.0 IL_0002: stloc.0 IL_0003: br.s IL_001b IL_0005: ldstr "{0}" IL_000a: ldloc.0 IL_000b: box [mscorlib]System.Byte IL_0010: call void [mscorlib]System.Console::WriteLine(string, object) IL_0015: nop IL_0016: ldloc.0 IL_0017: ldc.i4.1 IL_0018: add IL_0019: conv.u1 IL_001a: stloc.0 IL_001b: ldloca.s V_0 IL_001d: ldc.i4 0xff IL_0022: call instance int32 [mscorlib]System.Byte::CompareTo(uint8) IL_0027: ldc.i4.0 IL_0028: clt IL_002a: stloc.1 IL_002b: ldloc.1 IL_002c: brtrue.s IL_0005 IL_002e: ret } // end of method c::Main
Эээ... А разве здесь может быть правильный ответ Правильный - любой который работает Лично я бы писал так как предлагал slesh: Code: for(byte b=0;b<=255;b++) { Console.WriteLine(b); if(b==255) break; } Некрасиво конечно, но по другому не получится. Еще мне понравился вариант desTiny, что на C# выглядело бы типа такого Code: byte b = 0; do Console.WriteLine(b); b++; while(b!=0); Он конечно содержит минимум операторов, но у него есть недостаток - он в общем случае не работает, если границы перебора заранее не известны. Да и кстати, вообще-то я спрашивал почему же исходный код не работает, а все почему то начали приводить примеры работающих кодов Раз никто не ответил, отвечу сам: На самом деле, в си-подобных языках нет оператора for в чистом виде. Фактически for это цикл while, для которого указано условие продолжения (b<=255) и некторый оператор, изменяющий b (b++). Причем условние продолжения цикла проверяется на каждой итерации. Когда значение b достигает 255, цикл отрабатывает, и далее выполняется операция b++, результатом которой является снова 0! Далее проверяется условие b<=255 - оно очевидно выполняется, и цикл идет дальше, таким образом зацикливаясь в бесконечность. Для си в принципе это поведение нормальное, однако для C# лично мне это кажется не очень логичным поведением. Логичнее было бы на 255++ генерировать исключение (что то типа OverflowException) - ведь фктически происходит переполение. Но нет, он тихо сбрасывается в ноль и идет себе дальше Точно такая же ситуация возникает и для всех остальных целочисленных типов. Например цикл for(int i=0;i<=int.MaxInt;i++) - тоже зацикливается. Получается что стандартный код типа for(int i=1;i<=arr.Count;i++) является небезопасным, так как если arr.Count==int.MaxInt, то цикл будет бесконечным :[
Мне это напомнило такой код на с: Code: int a[10], i; for(i=0;i<=10;i++) a[i]=0; На старых компиляторах он уходил в бесконечный цикл. Вот и задачка. А ну-ка скажите, почему это происходит? Кстати, если чуть подправить код, программа и в новых компиляторах будет получаться вечная.
каким образом Algol вывел логическую цепочку от целеноправленного введения for в бесконечны цикл.... до отсутствия реализации for как цельной структуры а не цикла while не понятно (для программиста компилятора это узкоспециализированная задача и реализовывать он ее может в соответствии с быстродействием или оптимизацией памяти, никто же не заставляет его использовать реализацию while) ... по вашей логике все в этом мире сведется к циклу loop (ассемблера) а все остальное от лукавого?????? цикл for в примере algol-а не на миг не ушел от описния Керниган Ричи....(не делали же списиально списифического описания for для шарпа) дак что же задавать вопрос о том "..а почему он не разворачивает конфеты?" Вопросы переполнения переменных это азы Си 8))) Школьники многих школ .... где преподают Си вместо Паскаля ВАМ ПОДТВЕРДЯТ ЭТО для С# не придумывали новый синтаксис ни для 'for' ни для if ни для while или until, используется стандартные функции подходящие под описание языка Си и мне программировать совершенно без разницы на TurboC MSVC Net или шарпе без разницы что касается основных структур языка а если я хочу переполнять .... ПОЧЕМУ РАЗРАБОТЧИК КОМПИЛЯТОРА должен запретить мне в соответствии с синтаксисом переполнять переменную чтоб превратить ее в ноль? такой прием я видел дважды один раз в реализаци победителя конференции AES - блочном шифровании 2fish... каждый можете сделать аналог for и понять разницу между while(... ) {.....} и do {....} while(....); только тот кто использует for 8))) и сам знает как им пользоваться В СООТВЕТСВИИ С ОПИСАНИЕМ 8))!
Это конечно здорово, но в подавляющем числе случаев - checked не используется, а описанное поведение является неожиданным для программиста.
Из всего этого набора слов (отмечаешь наверное уже ) я так понял ты критикуешь мою фразу о том что "в си-подобных языках нет оператора for в чистом виде" ? Могу объяснить более подробно, что и имел ввиду: 1) Цикл for в Си действительно органозован через while. И даже не столько в синтаксическом плане, сколько в логическом. На каждой итерации - проверяется некое условие, и выполняется некое действие. По сути - это while, просто синтаксически оформленный иначе. Но, если мы посмотрим на теорию программирования (безотносително к какому-либо языку), то смысл for - совсем другой. Смысл for - повторить свое тело заданное число раз. Причем некоторые языки дают даже более жесткое определение - повторение своего тела определенное и заданное наперед число раз. Именно такое поведение реализуется в Паскале (Школьники многих школ .... где преподают Паскаль вместо Си ВАМ ПОДТВЕРДЯТ ЭТО ). И это правильно, ибо это ближе к изначальному определению for. В Си же (как и во многих других вещах) решили не париться и сделали for через while. А приведенный выше пример как раз и демонстрирует недостаток такого подхода. В Паскале же этот цикл работает без проблем. Он и не может не работать, ведь смысл конструкции for i:=0 to 255 do; в том, что i последовательно принимает значения от 0 до 255, и никаких i++ тут нет, поэтому и переполнения тут никакого быть не может в принципе. Конечно, где-то там внутри , в откомпилированном exe i++ где-то есть , но отсутсвие побочных эффектов, переполения нам гарантирует компилятор, и мы об этом не должны думать. Надеюсь понятно изложил? Да и к тому же фразу о том, что в Си по факту нет for - придумал не я. Слышал давно очень, уже и не вспомню откуда 2) Касаемо C#. Да, сишарп по синтаксису близок к Си, но семантика и идеология языка - гораздо ближе к Паскалю, чем к Си. Именно поэтому я и написал что си-подобное поведение шарпа в данном случае не очень ожидаемо.
память под а выделяется. тока она на стеке. а цикл идет <= 10, компиль видимо генерит так, что переменная i лежит за массивом(a[10] указывает на i). таким образом i при значении 10 затирается нулем, с помощью выхода за границы массива. видимо как то так а вот это бред. тогда уж скорее while - это for, у кторого не задан первый и последний параметр типа Code: for(; b < 255;){}
Ясно, ну здесь уже проблема с отсутствием контроля границ массива. В шарпе и паскале тут бы выпал эксепшен.
8)) ... ну еще раз повторюсь .... програмисты используют особенности работы for (в Си понимании) .... кароче ВСЕХ С НОВЫМ ГОДОМ !!
