Разумеется, на практике следует пользоваться tolower(). Но вы хотели примеров - вот вам пример: паскаль не позволяет выполнять арифметические операции с символами. Да, для стандартных случаев, типа перевода регитра, еть функции, но случаи бывают и нестандартные.

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

Вы заблуждаетесь.
AVR:
../tn.c:242: warning: suggest parentheses around assignment used as truth value
MSVC:
c:\users\... .cpp(307) : warning C4706: assignment within conditional expression

а я и говорил, если повезет - компилятор скажет про неиспользуемый результат повторяю - я Си неплохо знаю. а что скажете про это: здесь тоже ворнинг будет?

никого не останавливает при этом использовать приведение типов (которое в Си сплошь и рядом применяется), а приведение типов и в паскале возможно хотя, вообще говоря, символ в паскале - это не число, и вполне логично, что просто так его просуммировать с числом нельзя. контроль типов, знаете ли...


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

блин, не заметил, как скатился на выискивание недостатков в Си, что изначально не входило в мои планы если можно - вернемся к выискиванию плохого в паскале

А если в паскале написать a := b = c что будет?
Я вообще не понимаю, что это за доводы - написать какой-то бредовый код и сказать - вот смтрите, на Си можно написать неправильную программу, значит это плохой язык!

Приведение типов в Си используется в сомнительных случаях - например, если вы попытаетесь указателю присвоить целое - операция странная, но в редких случаях необходимая. Но если вы складываете char и int - это рядовая операция и ничего приводить не требуется.

И тем не менее, на должность, которая предполагает непосредственный контакт с клиентами (типа продавец, менеджер, певец, ...) обычно подбирают человека "по лицу", а не по его уму, и отказывают умному человеку, но с безобразным лицом. Большая часть программистов так и поступают в отношении Паскаля, сливая его. Но в жизни всегда присутствуют исключения. Поэтому находится небольшая горстка людей, которые певцов выбирают по умению находить неберущиеся интегралы.


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

я изменил некоторые термины и вот что получилось:

Да, да. Это особенно так, если учесть, что программист не понимает для чего нужны комментарии.


Эт-точно! В Си ведь отсутствует аналогичная библиотечная функция? Поэтому Си-шникам приходится колдовать с битами, что очень сильно усложняет понимание текста программы. Бред какой-то!

будет ошибка компиляции, если а - число, а не логическая переменная. я не зря написал код на си с ЧИСЛАМИ. в паскале числа отдельно, символы - отдельно, логические отношения - отдельно, и только в Си мухи умножаются на котлеты и это считается нормальным.

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

а вот явно сужающие рамки возможности, о которых вы все время толкуете, так и остались виртуальными миражами - кроме жалкой попытки доказать, что символ и число на самом деле есть эквиваленты, ничего нету... почему не откликаетесь на предложение сравнить примитивнейший код, что я предложил выше? есть сомнения, что Си победит или что? давайте доказывать свою точку зрения фактами, а не словами. раз мы тут программисты - будем говорить на языках программирования, оставляя человеческие слова для комментариев идет?

Не знаю как Вам, но меня всегда тяготило принудительное членство во всяких принерско-комсомольских организациях. Анархия в разумных пределах намного лучше, чем клетка из законов. Ограничения нужны тем, кто боиться ошибиться; тем, кто боится ответственности; тому, кто не умеет правильно распорядится своими ресурсам.

Закон -- это прибежище, прикрытие и оправдание несостоятельности личности. С законам скучно, но безопасно. Умелое же использование анархии даст обществу (программе) большую пользу, чем безудержное законотворчество.

прямо по Фрейду! подсознательное определяет реальное вот она - истина! не за достоинства любим, а нелюбим за недостатки! главное - рожей не вышел, а то, что внутри - даже не интересует из любопытства...


глупость, коих свет не видывал, снова высказанная бездоказательно.

Вот вам факт. Если я напишу программу, аналогичную вашей, в ней либо будет уязвимость переполнения буфера, либо она будет безопасной и я буду знать сколько ресурсов требует моя программа и я буду решать на что делать упор, на быстродействие или на используемую память. А Вы тоже самое можете сказать про приведённую Вами программу?
Но всё таки было б неплохо не отклоняться от темы микроконтроллеров. Для них это ещё более актуально.

программа с уязвимостью - не будет полным аналогом моей - это главное. речь шла про полный аналог. вы попытались изменить условия задачи, пытаясь маневрировать между памятью и быстродействием, а на самом деле никакого выбора у вас нет. так вот, задание было конкретным - полный аналог. все прочее - не важно. как профессионал, вы должны просто сделать, не задумываясь о побудительных причинах такого условия. в этом случае тест будет корректным. ведь его цель - как раз и сравнить скорость и требуемую память (а заодно - объем усилий программиста) для решения простой задачи.

про свою программу я могу с гарантией сказать лишь то, что она будет работать всегда и везде одинаково. для МК - на сколько хватит его ОЗУ. уязвимостей, связанных с языком, в программе нет принципиально. к вводимым пользователем символам она не критична.

если желаете продолжить разговор в столь же конструктивном ключе - давайте ужесточим условия: пусть длина вводимой пользователем строки не более N символов. в моей программе это будет так:
вы сделайте программу на Си с теми же ограничениями и работающую точно так же - мы в равных условиях по уязвимости переполнения. но вот остальное - давайте продолжим сравнивать.

Оба-на! Проверка ошибок компиляции по гороскопу? Что-то новое...

А я могу Вас попросить прокомментировать слово "повезет". А то содается какое-то впечатление, что у Вы, действительно, свои программы пишите по принципу "повезет-не повезет".

А заодно кратенько нарисуйте портрет целевой группы (покупателей, потребителей) программы.

Мне кажется, что идея (целевое применение) этой гы-гы-программы настолько надумана, что ее лучше выкинуть, т.к. таких программ в жизни не бывает. Написать-то можно все что угодно. А вот продать написанное... Единственное назначение этой гы-гы-проги -- учебный момент. Больше она никуда не годится. А раз так, то какой смысл обсуждать то, чего на самом деле нет?

А вообще, readln -- это что, переменная или вызов функции? Судя по синтаксису -- должна переменная. Доступ к переменным происходит очень быстро. Но мы с вами знаем, что readln -- это есть функция, которая работает намного дольше долго. Паскаль вводит нас в заблуждение. Теперь ко всем проблемам добавилась еще одна -- теперь я должен помнить кто есть переменная, кто есть вызов функции. С первого взгляда на исходники хрен поймешь.

Скажите мне, как быстро отработает код, который, допустим, я получил от предыдущего программера:

Конечно, это не фатально! Что бы узнать что есть beta, нужно просто поискать это имя.


Все эти разборки примеров говорят не столько о преимуществах и недостатках того или иного языка, сколько об индивидуальных предпочтениях. Кому-то нравится спать на кафеле в переходах, а кто-то предпочетает спать на матраце в теплой квартире. Каждый вибирает себе инструмент согласно своим убеждениям и потребностям.

не по гороскопу, а если -Wall включено (или аналогичная опция). а что оно включено - не факт.
повезет - означает, смотря в какое место я добавлю лишний знак равенства. я привел далее пример. который 100% не ворнингуется, но принципиально меняет суть операторов.
смысл в том, чтобы разобраться в достоинствах и недостатках языка и, заодно, в степени беспристрастности спорщиков. вы говорите - у вас инструментарий круче? продемонстрируйте. пример чисто демонстрационный - не все же время хелловорд для этой цели использовать
к счастью, программист на паскале не должен думать над тонкостями реализации языка, он тратит свои силы именно на решение задачи. про хрен поймешь - отметаем, т.к. это можно сказать про любой язык тому, кто с ним не знаком. про время исполнения - согласен, для функции оно больше, а разве в Си не так? когда вы работаете со стандартным вводом-выводом, вы не особенно страдаете над быстродействием стандартных функций, не так ли?
логично. и в этом сравниваемые языки не имеют различий. тип переменной знать надо. деваться некуда.
а вот вы сначала решите эту примитивную задачу - а потом скажете. действительно ли она не заслуживает внимания уверен, что не все так просто, как вам показалось. а после вашего решения мы и сравним результаты - по скорости, размеру, памяти и т.п. - по объективным параметрам. и сделаем выводы. устраивает?

это игра по Вашим правилам. Не красиво поступаете.

А зачем "оно нам это надо?", да еще с такими условиями -- "с теми же ограничениями и работающую точно так же". Ой, Вы мастер на интриги и провакации!

Сравнивать нужно не по отдельным моментам кода, а общую картину. (Общая картина -- это и есть картина отношения Паскаль- и Си-разработок. Что может быть еще объективнее.) А то давайте начнем сравнивать длину лексем BEGIN-END с {}. Ну ведь глупость получается, правда? Так что давайте не будем лепить проблемы из двух строчек программы.

Да, к стати

Есть две огромные, но существенно отличающиеся по количеству группы людей...
Дак, кто из них идет не в ногу, первые или вторые?

блин! совсем заморочили!
вместо str := readln; надо же писать readln(str);

простите великодушно, зарапортовался, переключаясь с Си на Паскаль и обратно

Давайте меряться

Размер 15994 байт. Используемых пользовательских переменных - 1байт.

P.S. у любого микроконтроллера найдётся 1 байт для этой же программы, а не пока закончится ОЗУ

P.P.S. уж простите, поддался на провокацию.

да, по моим. что некрасивого? от вас не дождался предложений реально протестировать хоть что-то. предложил сам. правила вроде ясные. что не так?
в чем провокации? разве голословное утверждение. что Паскаль хуже - это не провокация? я не говорил ничего подобного, потому требую доказательств от тех, кто так говорил. я пошел на уступки - ограничил размер области памяти под строку, чтобы исходное "окружение" для обоих были одинаковы. под "работает точно так же" я имею ввиду не какие-то скрытые тонкости и микросекунды, а чисто по реакции на ввод-вывод. ОС для тестирования я так же конкретно назвал - Windows, консольное приложение. что снова не так?
гм... предлагаете протестировать упомянутый мной проект из 10000 строк, имеющий реальную ценность? ГЫ давайте хотя бы с этой мелочью решим... картина, как мозаика, сложится потом... может быть
будут продолжаться придирки в отношении "длинных лексем паскаля" и "экономии сил программиста" - будем и это сравнивать. будет разговор по существу - я на такие глупости не пойду

если провести исторические, общественные и т.п. аналогии - не раз бывало так, что только один шагал в ногу, а остальные топали не в ногу больше всего на земле насекомых, но люди как-то считают себя царями природы... так что не в количестве дело... во всяком случае, связь неоднозначна между количеством и качеством.

увы... пока не станем меряться. вы изменили условия задачи.
ваша программа работает не так, как моя. в моей пользователь вводит строку и жмет Enter - происходит перевод строки в консоли и выводится "эхо" строки. у вас будет посимвольное эхо.

да-а, тогда, действительно, у Вас по жизни большие проблемы... Сочувствую.


Отладку, всестороннее тестирование и многократные прогоны перед сдачей заказчику отменяем?
При желании можно и ... сломать. Было б желание!


Кому продемонстрировать? Кто будет судить? Здесь нет неангажированных судий.


Возьмите Васик -- там еще проще.


Нет, не устраивает. Как минимум мне не интересно это делать для Вас. Я банально не вижу особого смысла тратить на Вас свое время. Про судий я уже говорил. Да, и критерии оценки, условия и методы также должны быть заранее озвучены и удовлетворять обе спорящие стороны. Ничего этого нет. О чем говорить?

Обожемой, у меня дефектный компьютер

Но главное результат, а не способ, за что вы и ратуете. А в данном случае он один и тот же.

Внимание! Проблема Паскаля "намбер ту".

Переключение программиста с одного языка на другой приоводит к глупейшим ошибкам, кои отнимают время.

не совсем так. приложите исполняемый файл - что-то хочется проверить на моем компьютере
если вы мне объясните, как так в вашей программе получается, что ввод с немедленным выводом символа не приводит к следующему: я тут же приму вашу точку зрения, что Си круче во всем всего, что было, есть и будет во веки веков

getchar() вводит символ из консоли (при этом символ в самой консоли отображается), putchar() выводит символ в консоль. значит, по вашей программе при вводе 'a' в консоли появится первый раз символ 'a', а затем он тут же выведется обратно и появится рядом с первым. после нажатия Enter в консоли перевеедтся строка, символ введется и тут же выведется, т.е. строка переведется еще раз - после чего программа завершится. что не так в моих рассуждениях? как получается две строки из одинаковых последовательностей символов?

Вот это то, о чем я талдычу!

Вы предлагаете свои условия. Они не устравиают. Люди свои условия. Теперь Вас не устраивает. Что будем делать?


ключевая фраза выделена.
Мозайка не сложится, слишком много пазлов придется перебрать. Реально нам это не осуществить. Значит, мы не в праве по звосту, хоботу и ноге говорить о слоне. Еще раз повторяю критерий оценки -- если при свободном выборе большинство людей препочетают один продукт другому, значит он лучше.

Еще раз. Ваше утверждение "Паскаль не хуже Си" эквивалентно утверждению "Паскаль лучше или такой же как Си". Но мы с вами знаем, что эти языки не равнозначны и имеют разную популярность. Значит об их равенстве не может быть и речи. А это значит, что один из них лучше, другой хуже. В каких-то отдельных, выхваченных из контекста, моментах один язык будет уделывать другой. В других, также выхваченных моментах, картина будет обратная. Т.е. тут можно долго и бесполезно тратить время на споры. Но если подводить общий знаменатель, а мы все, тут присутствующие, это хотим сделать, нам нужно подняться сразу над всеми отдельно взятыми проблемами того и другого языка и оценит ситуацию в мире Си-Паскаль в целом.

Предположем, что Паскаль лучше Си. Предположим, мы имеем свободный рынок компиляторов и программистов, как потребителей этих компиляторв. Предположим так же, что мы умеем писать компиляторы. Мы видим, что Паскаль более востребован, чем Си.

Что мы делаем? Мы садимся и через какое-то время создаем Паскаль-компилятор. Этот компайлер на рынке востребован, и мы его продаем с тем или иным успехом, а полученные доходы пускаем на его клонирование и дальнейшее развитие. Рынок Си-компайлеров сокращается.

Скажите мне, что здесь не так? Почему наблюдается обратная картина? Почему масса людей делает свой свободный выбор не в пользу Паскаля? Неужели они все на столько глупы, что не замечают очевидных преимуществ Паскаля? Особенно после обуения Паскалю в школе и институте.

zhevak, ваш словесный понос утомляет. без комментариев. хотите что-то доказать - доказывайте кодом, а не словами. как попытался gotty. с ним я продолжу разговор (если он пожелает), с вами - нет.

по правилам спортивных созтязаний противнику, ранее принявшему вызов и по любым причинам затем отказавшемуся (уклонившемуся) от поединка, засчитывается поражение. и даже если он призовет всех философов мира, которые на коммерческих, религиозных, физико-математических, литературно-филологических примерах "докажут", что спортсмен гораздо сильнее - в расчет такие аргументы не принимаются.

будем по-спортивному действовать?

ок. можем переиграть условия. вот код, 1 в 1 аналогичный предложенному "другими" людьми:
размер exe-шника из-под Delphi7 15360 байт. скажите, не говорит ли это о том, что результат из-под Паскаля как минимум не хуже Сишного ни по размеру итогового файла. ни по скорости его исполнения?

P.S. самое странное, что действительно, при этом коде вывродится 2 строки, как у gotty! если поначалу я подозревал, что тут какой-то подвох с его стороны, то теперь я сам не понимаю. как это возможно... судя по всему, дело в буфферизации ввода-вывода ОС... однако, это по-моему, странно

P.P.S. в общем, ковыряния в отладчике подтвердили мою догадку: read у меня и getchar у gotty фактически считывают не символ, а строку, совпадающую по размеру с внутренним размером буффера ввода, выделенному библиотекой стандартного ввода-вывода. к тому же похоже консоль windows свой буфер имеет...
как выяснилось, данный пример некорректный - слишком системнозависимый предлагаю вернуться к исходному - ввода целой строки "по-правилам". можно с ограничением размера. можно без

либо так

Мы ж меряемся программами а не отладочной информацией

P.S. предлагаю остановиться. Результаты никого не переубедят при любом из исходов. Все останутся при своём мнении.

Ничего странного, это называется канонический режим, в котором консоль находится по умолчанию. Подробности здесь
http://www.gnu.org/software/libtool/manual...cal-or-Not.html

Спасибо за ссылку.

ок. будем считать 1:0 в вашу пользу по соревнованию в размерах

с неправильным тестом все ясно - там, в сущности, все буферы системные используются. давайте вернемся к первоначальному варианту теста. и посмотрим, сколько сухого остатка будет там. чтобы как-то избавиться от влияния системных буферов, предлагаю такой вариант: задача: считать строку любой (заранее неизвестной) длины из файла в переменную и вывести ее. я вбил сначала в свой файл 1.txt 9000 символов без символов \n\r. результат работы правильный - без переполнений и т.п. затем сделал файл 11 мегабайт (простым копированием) - результат аналогичный. размер 16384 байта

ваш ход!

Да Вы меня тоже утомили уже прилично. Вы внимательно читаете мои постинги? Я там где-то уже говорил, что мы не в состянии перебрать кучу пазлов, что бы сложить картину. Поэтому выхваченный в истерике (придуманный на пустом месте) код рассматривать не имеет смысла. Где-то победит Паскаль, где-то Си. Мы даже процентное отношение побед и проигрышей не сможем правильно оценить. А Вы тут со своими примерами для 8-го класса пытаетесь народ заставить расматривать листики-иголочки на веточках. А Вы поднимитесь на самолете и оцените, чей лес гуще и больше.



Ну блин, даже не знаю как уйти от нелестных комментариев, того как Вы понимаите ситуацию...
Я Вам уже в который раз говорю -- у нас нет ни судий, ни озвученных условий тестирования, которые устраивали бы обе стороны. У нас ничего нет! А Вы, наивный, пытаетесь еще угрожать мне поражением!
О чем Вы? Очнитесь!



Да. Мне тоже странно. Тут кто-то говорил, что неплохо знает Си. Не в курсе?



В топку Ваши правила! В топку все Ваши условия! Они выгодны только для Вас. В топку кодописание оторванное от жизни!


Хотите, Я Вам скажу, чем выгоднее Вам биться с gotty?

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

Боюсь Вас огорчить, но я даже не буду пытаться. Языки слишком разные, паскаль для программиста дружелюбнее, а си для - целевого железа. Если хотите меряться строками динамической длинны - вам к С++.

zhevak, вы накорябали такое сообщение, что даже SQL не хочет его цитировать ошибку выдает.

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

Я дико извиняюсь, но правильнее было бы написать until eof(F);
Не помню кто там говорил тысячу постов назад, но согласен, что трудновато переключаться с ЦЭ на паскаль и наоборот: лезут ошибки.
И мое мнение: чтобы правильно померяться п%ськами надо очень друг на друга разозлиться и по хорошему ТЗ наваять нечто посложнее двух операторов. А это суть убитое время. Так что не обольщайтесь - кроме ругани скорей всего ничего не будет.
В споре рождается истина... братцы, нас нае обманули!

нет. вы меня не огорчили. ваш "ход" понятен. языки разные - это было ясно с самого начала. и назначение разное - это так же очевидно. и сравнение так же не корректное абсолютно - простой Си и Delphi, который все-таки из категории С++. все верно.

С++ по размеру исходника, скорее всего, проиграет Delphi, по итоговому экзешнику - бог знает... может, и выиграет... не важно в конце концов.

хоть я от вас и не слышал утверждения, что Паскаль хуже Си (или С++), прошу вас высказаться: вы так же считаете, что ХУЖЕ? или все-таки согласны, что ПАСКАЛЬ не хуже, не лучше, а такой же, просто иной язык. Не ограниченный какими-то глупыми рамками, дающий свободу программисту и т.п. - короче, ПО БОЛЬШОМУ СЧЕТУ ТАКОЙ ЖЕ, КАК С(С++) со скидкой на особенности синтаксиса.
все-таки вы наиболее адекватный оппонент в данном топике (были и другие, но они ограничились минимумом слов).

Ладно, чего уж там! Тем не менее, спасибо Вам за "игру".
(Правда, не понятно на основании чего Вы сделали свои выводы относительно меня, как специалиста. Впрочем, меня это (т.е. ход Ваших рассуждений) мало интересует.)

Удачи!

принимается спешка не способствует правильнописанию

что касается меня, я не сомневался ни секунды, что истина не родится в этом споре для поиска истины как минимум надо воспринимать слова оппонента, а не ограничиваться только своим мнением.

и вам не болеть!

+1

Уже было собрался нафлудить, но потом одумался... нет, к черту это все...



Несчастен, кто ищет истин в холиварах...

Моё мнение не поменялось и вряд ли это произойдёт

а как забавно в них принимать участие! как это бодрит! неожиданно наталкиваешься на давно забытые штуки типа режима консольного ввода крррасота!

самое смешное, наверное, что я и Си и Delphi применяю постоянно, и очень обоим рад и доволен потому как гармония, баланс. а односторонне неуравновешенные специалисты нервно холиварят про паскаль

Народ, давайте серьезную задачу сформулируем.
Например, "8 ферзей".
Найти все возможные варианты расстановки 8 ферзей на шахматной доске, при которой ни один из них не бьет других. Никакой графики, варианты выдавать в виде строк типа "а3 b7 e8 ..."
Это чистая алгоритмика, интересно будет сравнить

Что значит забытые??? ( А теперь понаблюдаем за холиваром GUI vs CLI)



Ага... Сурьезная задача

Ну всяко интереснее, чем ввод-вывод строк мусолить

Эту задачу люди на МК-61 (микрокалькулятор такой, кто помнит) решали. Вариантов программ было множество, включая вариант, учитывающий "зеркальность" некоторых расстановок... А память команд МК-61 была шагов на 102, если склероз не изменяет...

105. У 54-го 98 (это если склероз не изменяет мне).

Ну и здорово. Я же не предлагаю написать шахматную программу уровня Deep Blue
Для сравнительного теста в самый раз будет

По двум критериям? размер исходника/размер ехешника ?
Вот нагуглил

Рекурсия.

задача о ферзях для доски N*N, критерий - максимальное N для времени счета не более 1 мин. Или 10 мин.

Казалось бы, причём тут микроконтроллеры Atmel AVR....

+1! Вот и я удивляюсь...
Мало того, что спорщики уже давно спорят "ради спора", признавая, что переубедить их нереально в любом случае...
Мало того, что скатились, как обычно, до взаимных обвинений...
Мало того, что аргументов на всём 20-страничном сражении так и не встретилось...
Кажется, и сам предмет спора вот-вот будет забыт...
Господа! Вспомните хоть название темы!

Вот зануды... Если бы все посты во всех темах были по делу, Электроникс ужался бы раз в 10
Сейчас проверим, как Пашин вариант в Дельфях фунциклирует

Твёрдое окончательное Тьфу.

Шумный, бурлящий слифф засчитан. Расчёт окончен.

Вольно, Вечный Облом

Exe-шник получился 374 Кб в Дельфи 7. Найдены все 92 варианта, ура!

Гы! Автор спросил, какие есть паскалевские компиляторы, и все началось - что мол нафиг оно надо, итд.


А чего вспоминать? Ну нет нормальных паскалей для АВР! Уже ж все выяснили...


Не согласен. А как избавиться от оси? Она ж тормозить станет... результаты случайные получатся

Кстати, о ферзях и различиях между С и Паскалем