Вот ссылка

И что? Первое апреля растянулось до 25 мая...

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

Всё так и было.  

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

вот это точно компилируецца, и достаточно полезную вещь кстати делает.

как вы думаете что?
(не заглядывая сюда )

я думал квадратик нарисует   

возможно )) не копипастом единым жив программист ))

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


Это не скомпилируецца! И даже не потому что здесь не определено что такое P(),R и еще куча других переменных
а потому что оператор R- это ошибка по любому!
Похоже статью писал какой-то двоечник-паскалевец, 2-ой день изучающий С.
И писано это (судя по паскалю, и другим названиям) еще во времена МS-DOS'a. 
В те далекие времена, кое-кому казалось, что паскаль мог составить конкуренцию С.

Вы так говорите "казалось", как будто...  

Си сейчас "на коне". Но это эпоха уже заканчивается. Си, Лэди Гага и прочая низкопробная дрянь приходит и уходит. А Pascal ещё всех нас переживёт.  

kemiisto, паскаль сейчас используется только в качестве основы для Delphi и, возможно, для обучения программированию начинающих инженеров. На сколько я знаю, нынче популярны языки, производные от Си: C, C++, C#, Java/JavaScript, PHP... А вот производную паскаля на слуху я знаю только одну - Delphi. Не исключено, что Паскаль будет жить долго. Но только мне не верится, что он станет таким же популярным, как производные от C.

Я и не говорил, что он станет популярнее. Лишь переживёт. То есть С и прочие исчезнут как динозавры, а потомки Паскаля останутся. 

Прошу kemiisto.restart() 

Вы только определитесь, что считать "производными".   Например, Java унаследовала от C в основном вид синтаксиса, по идеологии этот язык ближе к Паскалю.

как может чисто ОО язык быть идеологически ближе к чисто процедурному? естественно, в предположении заимствований Java от C++ а не С.

обычно считается, что язык Java заимствовал у C++, SmallTalk, Scheme и повлиял на C#.
C++ - у С и Simula.
Pascal повлиял на Modula, Ada

и у них всех есть общий предок - Algol.

Добавлено через 3 минуты и 39 секунд
впрочем, есть и более ранний, повлиявший на всех (прямо или косвенно) - старый добрый фортран

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


Ещё раз - в Java заимствован из С только синтаксис. Никаким Смолтолком и Схемой там и не пахнет.


Это верно.


Pascal - прямой предок Modula, хоть и не единственный, поэтому, он очевидно на неё повлиял. А вот на Аду Паскаль повлиял крайне опосредованно.


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


А вот здесь - нет. Старый-"добрый" ФОРТРАН был как раз почти полной противоположностью АЛГОЛа. Собственно АЛГОЛ изначально создавался в противовсе ФОРТРАНу, который и алгоритмическим то языком назвать, простите за тавтологию, язык не поворачивался. Что собственно, в названии АЛГОЛа и отражено.

Так что нет. Только АЛГОЛ, только императив!  

Точно так же, как "Java потомок C".   Потомок, но не непосредственный. На самом деле Java - это Оберон (с некоторыми элементами Модулы-2, более раннего виртовского языка), снабженный C-образным синтаксисом. В принципе, во многом те же идеи использовались и при создании Delphi (точнее, тогда еще Object Pascal), так что и на него Java похож куда больше, чем на C++.



На Модулы - да, а вот на Аду - не очень. Внешнее сходство синтаксиса есть, а вот идеологически он ближе к PL/1.


Разве что в качестве образца "как делать не надо".   Фортран - великолепный язык, но для других целей.

P.S. М-да, похоже, что я почти дословно повторил то, что написал kemiisto.    

Это сообщение отредактировал(а) Фантом - 8.1.2013, 14:09

Фантом, kemiisto, я с вами согласен, пожалуй. мне лишь не нравится сентенция об идеологии pascal в java.


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

впрочем, я не настаиваю) часто авторы сами не знают, какие влияния имели место)

Добавлено через 11 минут и 43 секунды
  а может мне просто лениво спорить   

Увы, это факт.   Кстати, поскольку C# - это очередной "наш ответ Чемберлену" от MS, то и он является потомком C в основном в маркетинговом смысле.

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

Сколько раз видел споры о том что лучше чистый С или С++ ? 
А между тем сам Страуструп очень тесно взаимодействовал с Денисом Ричи и при обсуждении. В книге "Б.Страуструп. Дизайн и эволюция C++ (2006).djvu" очень ясно на стр. 70 Страуструп пояснил в какой атмосфере рождался С++ , а на стр. 37 пояснил роль и стремления языка и почему нету Framework-ов!

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

К чему нужны хУливары? Какая конкретно от них польза?

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

Ну я и тролль...  

Начнем, например, с самой идеи платформы, к которой привязан язык.   

Наверное стоит пожалеть фанатов паскаля, раз уж им приходицца упавать на java, в качестве приемника..
Дескать это только внешне сын похож на соседа, но глубоко в душе весь в отца...
Мда уж....

baldina, как Вам уже написали, идея некоторого промежуточного представления кода, которое переносимо, так как исполняется некой виртуальной машиной, была реализована Виртом уже для языка Pascal. Промежуточный язык именовался p-code, а виртуальная машина (внезапно!) p-code machine. 

А на самом деле эта идея была реализована примерно на 10 лет раньше для языков Euler (кстати, Виртом с коллегами) и BCPL. Последнее крайне занятно, так как язык B, который позже выльется в язык С, был всего-навсего урезанной версией BCPL. Урезали BCPL только по той причине, что в распоряжении у Томпсона и Ричи были крайне слабые машинки DEC PDP-7 и (позже) PDP-11 с очень маленьким объёмом памяти. Среди прочего отказались и от идеи промежуточного представления кода и исполнения его виртуальной машиной. Именно таким образом, B а вслед за ним и C оказались жёстко привязанными к железу. Показательный, кстати, момент. Язык C не проектировался как переносимый. Он вообще не проектировался. Он рождался в муках по выпиливанию из одного языка всего невмешяющегося в пямать совершенно определённого компьютера. И если Вы думаете, что таким образом можно было создать что-то хорошее... Я тебя слепила из того, что было... Ну, да ладно.

Добавлено через 5 минут и 20 секунд

Никто Java приемником Pascal не называл. Речь о том, что Java значительно ближе к потомкам Pascal, чем к C. У неё только синтаксис С-шный, а он (в определённым смысле) вторичен. И потом, где Вы уведили упавание?

Вам самому никак фанатизм мешает увидеть, что до Вас пытаются донести.

Я беру камень и отсекаю всё лишнее. (В ответ на вопрос: «Как вы делаете свои скульптуры?») - http://ru.wikiquote.org/wiki/%D0%9C%D0%B8%...%BE%D1%82%D0%B8

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

Начнём с того, почему же эта цитата не к месту. Дело в том, что у слова "лишний" есть несколько значений.


Очевидно, что скульптор, создавая некий художественный образ из камня, отсекает всё избыточное. Микеланджело выступил в роли Капитана Очевидность, ответив таким образом на совершенно идиотский вопрос. Эх, журналисты...  

А в контексте нашей беседы о проектировании языков программирования "лишний" столь же очевидно означает "ненужный". Бритва Оккама шлёт нам пламенный привет. Так вот, есть две большие разницы между ситуацией, когда с целью упрощения языка ведёться многолетняя целенаправленная работа по идентификации и уничтожению лишних (сиречь ненужных) сущностей и когда этот процесс происходит абсолютно неконтролируемо под давлением внешних обстоятельств (малый объём ОЗУ). В первом случае имеем дело с проектированием, во втором - ни о каком проектировании и речи быть не может.

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

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

идея некоторого промежуточного представления кода и язык вещи сильно разные. сравните например Java, C#, F#, Scala.
идея язык+унифицированная платформа как единого целого интересна, не спорю, хотя (см. выше) на одной платформе может быть несколько языков. 
заметьте, любой интерпретируемый язык имеет плаформу (часто индивидуальную), однако и такие языки сравнивают. языки, а не платформы.

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

язык это идеология, подход. с такой точки зрения java и oberon, не говоря уж о pascal, весьма далеки. а java и C++ близки. имхо, конечно, так что с удовольствием выслушаю нечто конструктивное.

Добавлено через 2 минуты и 13 секунд

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

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

А в случае с С не было такой цели. Там была чисто практическая цель портирования BCPL на слабые машины. В итоге это всё вылилось в создание языка B, а затем и C. Я вообще не уверен можно ли тут говорить об отборе...

Нет, нет. Мы сразу абсолютно однозначно (и я это подчёркивал) обсуждаем алголопожобные языки. То есть императивные. Поэтому не надо нам ни (никому ненужной  ) функциАнальщины, ни монструозных гибридов. Вот и сравни Java и какой-нибудь другой императивный язык под JVM. Разница тут будет чисто синтасическая. Синтаксис в данном случае как раз будет вторичен.

Конечно, если включить в рассмотрении какой-нибудь функциАнальный язык, то синтаксис уже вторичен не будет. При таком сравнении уже нужно понимать, что синтаксис будет определять уже сам способ мышления программиста. Поэтому, повторюсь, мы ограничимся императивными языками, когда синтаксис (до какой-то степени) будет вторичен. Благо, мы можем наложить такое ограничение на дискуссию с чистой совестью и почти без последствий, ибо о(б)суждаемые ЯП (C, C++, Pascal, Oberon, Java) императивны.


Безусловно. Но мы говорим только за Java. Это один язык. То, что впоследствии (благодаря популярности Java) появилось множество языков под JVM не меняет дело. Изначально JVM писалась чисто и только под Java. И, кстати, многие идеосинкрозии JVM отсюда и растут. Поэтому, кстати  , при разработке своей JVM с пасьянсом и куртизанками MS так сильно концентрировалась на том, чтобы платформа была максимально независима от (пускай и основного) языка, что отразилось даже в названии CLR.

Но, повторюсь, с JVM была совсем иная история.
 

Опять же, не думаю, что это имеет какое-то отношение к нашему разговору. Интерепретатор он на то и интерпретатор, что там не нужно ни промежуточное представление кода, ни виртуальная машина для его исполнения.


Дык о том и речь, что не имеет. Это же ключевое различие, а Вы его сразу отметаете. И как Вы собираетесь сравнивать Java в отрыве от платформы? Это бессмысленно. Там останется только синтаксис. А он мало того, что вторичен, он банально (почти) одинаков. И сравнивать то особо нечего.


Нет, нет, нет и ещё раз нет. С точностью до наоборот. Java существенно ближе к Оберону, чем к С++ с точки зрения идеалогия, чтобы Вы под ней не понимали.

Вот, смотрите. Первой будет идти характеристика общая для Java и Oberon, затем характеристика C++.

• Промежуточное представление кода и исполняющая его виртуальная машина против компиляции в машинный код на каждой платформе.
• Раздельная компиляция (separate compilation) против независимой компиляции (independent compilation). Разница существенная, между прочим. Вот тут можете посмотреть, о чём речь. Впрочем, я именно Вам уже это пытался объяснить, как мне кажется.
• Динамическое связывание против статического связывания.
• Только процедурное и ОО программирование против всего, что пожелаете. Да, в Java есть процедурное программирование. Из-за того, что класс выполняет функции модуля оно просто скрыто. Каждый раз, когда Вы пишете статическую функции и, не зная куда её деть, создаёте какой-то недокласс - это и есть процедурное программирование на Java.  
• Только полностью автоматическое управление памятью (сборка мусора) против ручного и (всё-таки) полуавтоматического (умные указатели).

Хватит для начала?

ну собственно все расхождение в этом.

я когда-то пытался (безуспешно) приобрести книгу по C#, где был бы описан в первую очередь язык, а CRL во вторую (или вообще не описан).
я понимаю, почему не нашел. понимаю, насколько сильна связь подобных языков с платформой. понимаю исторические причины вида java (как и C++).
но когда я пишу на языке, неважно каким образом исполняемым, я думаю на этом языке. а встроенные структуры/алгоритмы воспринимаю как прилагаемые библиотеки (что вполне естественно, т.к. часть структур и алгоритмов мы таки пишем сами).

что касается раздельной/независимой компиляции, я все безусловно понимаю. это, пожалуй, действительно серьезный аргумент, и я его пропустил. но опять же, на определенном уровне по большому счету неважно, что писать - import, #include или uses, точнее, что при этом думать.

Добавлено через 2 минуты и 54 секунды
  

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

солидарен, платформы надо сравнивать вне сравнений языков ))

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

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

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

У всякого тьюринг-полного языка (а все обсуждаемые к этой категории относятся) выразительность максимально возможная. Так что критерием это служить не может.

Фантом, может и служит )

Не уверен, но вроде как наличие миксинов в языке никак не влияет на полноту по Тьюрингу (ну если только в compile-time), однако в некоторых ситуациях позволяет элегантно решить задачу. Т.е. позволяет программисту выразить свою мысль просто и доступно, ближе к терминам прикладной задачи, а не языка. Т.к. программы пишутся для людей в первую очередь, это позволяет код сделать читабельным, а значит легким для сопровождения, а значит более эффективным. Ассемблер-то тоже тьюринг полный. Чем больше язык позволяет оперировать ближе к терминам прикладной задачи, тем он эффективнее - вот в этом я уверен на 100%. А тут тьюринг-полноты не достаточно.

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

Это совершенно правильно. Но это не "выразительность" в терминологии  mes, она определяется совсем не тем, описываются операторные скобки как begin..end или {..}.   

  позвольте уточнить, "выразительность" в терминологии mes, это описание операторных скобок через {...} ?  а то я русский подзабыл..

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

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

С точностью до наоборот. 

кажется все тут выразительность понимают по разному. если выразительность синоним возможности реализовать вычислимую функцию, то и brainfuck выразителен.
однако традиционно под выразительностью ЯП понимают его синтаксические возможности, т.е. удобство для человека.

В том и проблема, что удобство для человека может быть разным. Можно сделать так, чтобы удобно было писать код, а можно так, чтобы его удобно было читать и поддерживать.

можно пример, когда удобно писать, но неудобно читать и наоборот?

По-моему это одно и то же. Как можно удобно писать код, который неудобно читать и поддерживать?

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

Два классических примера: Perl и Ada.

позиция ясна, но согласиться трудно. 

поясню:

удобно как писать, так и читать. последнее с оговоркой: для тех, кто в теме. ну а если кто не в теме, ему писать/читать рано.


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

Добавлено через 3 минуты и 40 секунд
Думаю г....код можно выдавать и на Ада, и вообще любом языке

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

Добавлено через 20 секунд
  

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




  

Фантом, Читаемость кода - вещь очень субъективная...
Возможно кто-то скажет что ему удобно читать пёрл, и кстати, будет прав.
Ну удобно ему читать пёрл и что? Вам Аду удобно? да ради бога!
Не нужно лишь это выдавать за непреложную истину, в последней инстанции.  

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


Вот именно.

нет, нет и нет. Ветка начиналась перечислениями плюсов платформы, которыми Ява красовалась перед С++.. На что был ответ, что не плюсы платформы, а именно выразительные свойства языка красят его. Что, как я позже понял, было воспринято, что сила выразительности определяется возможностью оперирования скобками.. 
Нет, нет и еще раз нет.. конечно наличие загромождающих конструкций, могут отвлекать внимание.. но в данном вопросе это действительно дело вкуса.. 
А вот к примеру С и С++ обладают обсолютно одинаковой "синтаксической выразительностью" однако выразительность языков совершенно разная..
Чтоб эффективно реализовать/выразить мысль на этих двух с виду похожих языках, нужно перестроить ход мыслей.... 
И речь была именно об этом ))

Ой ли? В C++ несколько больше языковых конструкций. И, как хорошо известно, действительно можно писать на C++ как на "C с классами", а можно - как на C++. Во втором случае код даже визуально будет сильно отличаться от кода на C.

больше, но речь шла о скобках, кои как я понял, определяют по  Вашему ту самую "синтаксическую выразительность".. 


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


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

Это сообщение отредактировал(а) mes - 20.1.2013, 19:05

Именно. Только вот не Вы ли ранее писали вот это:

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


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


именно выразительная способность, а не синтаксис. Не представляю, как синтаксис может быть нe приемлим для какой то платформы 


Это сообщение отредактировал(а) mes - 20.1.2013, 22:41

Так, собственно, и так уже понятно, что сошлись.    Итог такой:
1) Различие и сходство языков определяется не синтаксисом (это к вопросу о родственности Java и C);
2) удобство пользования языком от синтаксиса существенно зависит (но не только от него), однако этот фактор в основном субъективен (это к вопросу о преимуществе синтаксически-С-подобных языков над остальными).

Добавлено через 1 минуту и 51 секунду


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

зачастую к синтаксису приписывают морфологию,  так как морфология имеет сильное влияние на синтаксис, и сопутствуют друг другу.. 
вот например конструкции :

синтаксически разные , но морфологически схожи, а

отличаются не только синтаксически, но и морфологически.. но видно что синтаксис конструкции 2. немного избыточен для реализации морфологии 1.
так если в конструкцию 1. добавить To, Step, Begin, End, но при этом сохранить морфологию, то конструкции останется родственной, в отличие синтаксически похожей констукции 2..

Добавлено @ 13:46

тут опять же, смысл не в том что удобнее && или AND, это действительно дело вкуса , a о том, каким синтаксисом удобнее отразить логику языка.. 
Так например опять те же Begin с End добавить в С не сложно.. но зачем они там нужны ?

Это сообщение отредактировал(а) mes - 26.1.2013, 19:40

сама конструкция 1 избыточна, ибо цикл ни разу не выполницца.
mes, Щас фанаты паскаля набегут и скажут что в паскале это запишецца как



Это сообщение отредактировал(а) volatile - 26.1.2013, 19:29

Разбудите в 3 часа ночи, в дупель пьяного программера С/С++ и спросите что это такое. Он ответит что это инкремент, и будет прав!



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

(Это по поводу легкого прочтения ады, паскакаля и прочих)
И кстати личные предпочтения здесь не причем.
Код объективно неудобно ни писать, ни тем более читать !

не выполнится из ошибки... бывает.. концентрировался на мысли, а нe коде.. исправил как оно хотелось.. 
volatile,  спасибо за внимательность 


под конструкцией в моем посте подразумевается не приведенная законченная конструкция с циклом до 10, а конструкция языка for  

Добавлено через 5 минут и 59 секунд

ну так, наверняка вместо

пишут Inc(somenumericvalue); или ?

Это сообщение отредактировал(а) mes - 26.1.2013, 19:46

mes, я то вас понял. Просто фанатам п., им палец в рот не клади, откусят  


Inc - это уже  позднее наслоение, неуклюжая попытка подражать С.
и вообще это функция, а не языковая конструкция.

И вы же понимаете , что я говорю не только об инкременте :
somenumericvalue  *= n;
somenumericvalue  += n;
somenumericvalue  -= n;
somenumericvalue  /= n;
somenumericvalue  %= n;