Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Sergey J. A., Вы писали:
SJA>>Давайте, вы когда говорите ерунду, будете ставить смайлики ? А то неокрепшие умы могут и поверить....
СГ>Вы определили i внутри for, а надо было определить ее снаружи так как в Delphi, иначе смысл сравнения отсутствует. Почему сишный for медленнее дельфийского я уже объяснил: 1) в Delphi значение переменной цикла for не определено после его завершения, 2) значение переменной цикла запрещено самому менять. И вообще, по данному вопросу есть громадные обсуждения в других форумах. Ссылки, к сожалению, дать не могу, не сохранил. Кажется на delphikingdom...
Я же просил — смайлики ставить !
#include <stdio.h>
int f()
{
int i;
for(i=0;i<10;i++)
{
printf("%d\n", i);
}
return 0;
}
_f PROC NEAR ; COMDAT
; 3 : {
push esi
; 4 : int i;
; 5 : for(i=0;i<10;i++)
xor esi, esi
$L863:
; 6 : {
; 7 : printf("%d\n", i);
push esi
push OFFSET FLAT:??_C@_03PMGGPEJJ@?$CFd?6?$AA@
call _printf
add esp, 8
inc esi
cmp esi, 10 ; 0000000aH
jl SHORT $L863
; 8 : }
; 9 : return 0;
xor eax, eax
pop esi
; 10 : }
ret 0
_f ENDP
Какие ещё будут предположения ?
Теперь я объясню.
Если в Дельфи нужно значение счётчика после цикла, то нужно ввести доп переменную. А это замедлит цикл, + даст 100% оверхед по переменным !
Итого: дельфи медленнее работает с циклами, да ещё и даёт 100% оверхед.
З.Ы. Производительность и оверхед упомянутые в последнем абзаце были расчитан исходя из запатентованной методики Сергея Губанова.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Вобщем, на основании этой ветки и доп. источников я вывел:
Еще раз!!!
REPEAT искать UNTIL нашел
REPEAT понимать UNTIL понял
REPEAT слушать UNTIL услышал
REPEAT принимать UNTIL принял
REPEAT делать UNTIL сделал
По определению цикл REPEAT может завершиться только тогда когда будет выполнено условие завершения. Если цикл не удовлетворяет этому определению, то он не может называться циклом REPEAT
WHILE можно DO делать всё что можно END
WHILE нельзя DO ждать END
WHILE молодой DO танцевать END
WHILE есть патроны и есть враги DO стрелять END
WHILE спишь DO видеть сны END
По определению цикл WHILE может завершиться только тогда когда будет нарушено условие выполнения. Если цикл не удовлетворяет этому определению, то он не может называться циклом WHILE.
В Си-образных языках, циклы while/do не удовлетворяют этим определениям так как могут быть завершены еще и по break и goto.
Цикл LOOP ... END либо исполняется вечно, либо завершается выполнением инструкции EXIT. Ни каких других ограничений на него не накладывается.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Sergey J. A., Вы писали:
SJA>>Вобщем, на основании этой ветки и доп. источников я вывел:
СГ>Еще раз!!!
СГ>REPEAT искать UNTIL нашел СГ>REPEAT понимать UNTIL понял СГ>REPEAT слушать UNTIL услышал СГ>REPEAT принимать UNTIL принял СГ>REPEAT делать UNTIL сделал
СГ>По определению цикл REPEAT может завершиться только тогда когда будет выполнено условие завершения. Если цикл не удовлетворяет этому определению, то он не может называться циклом REPEAT
Ну, конкчно кроме случаев, когда из REPEAT ... UNTIL можно выйти по EXIT.
На этом месте прошу выполнить выделенный цикл.
СГ>WHILE можно DO делать всё что можно END СГ>WHILE нельзя DO ждать END СГ>WHILE молодой DO танцевать END СГ>WHILE есть патроны и есть враги DO стрелять END СГ>WHILE спишь DO видеть сны END
СГ>По определению цикл WHILE может завершиться только тогда когда будет нарушено условие выполнения. Если цикл не удовлетворяет этому определению, то он не может называться циклом WHILE.
Ну, разумеется, если WHILE вложен в LOOP и из него можн выйти до того, как условие будет выполнено, то это не может называтся WHILE. Пожалуй по аналогии с процедурами-функциями я назову его LOOP-n-WHILE (ЛУП-Н-ВАВЙЛ).
СГ>В Си-образных языках, циклы while/do не удовлетворяют этим определениям так как могут быть завершены еще и по break и goto.
Да. Согласен.
СГ>Цикл LOOP ... END либо исполняется вечно, либо завершается выполнением инструкции EXIT. Ни каких других ограничений на него не накладывается.
Итого. В Обероне есть 7 видов циклов:
WHILE — строго один вход/один выход
REPEAT — строго один вход/один выход
FOR — строго один вход/один выход
LOOP — строго один вход. Может быть больше одного выхода.
LOOP-n-WHILE — строго один вход. Может быть больше одного выхода.
LOOP-n-REPEAT — строго один вход. Может быть больше одного выхода.
LOOP-n-FOR — строго один вход. Может быть больше одного выхода.
Не слишком ли многовато для идеального языка ? Это ж какой оверхед !
Толи дело С:
for — строго один вход. Может быть больше одного выхода.
while — строго один вход. Может быть больше одного выхода.
do-while — строго один вход. Может быть больше одного выхода.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Sergey J. A., Вы писали:
SJA>>Какие ещё будут предположения ?
СГ>Предлагаю Вам найти тот форум и всех там разбомбить.
Какая глупость, считать, что я смогу их разбомбить. Даж если в каждом их них половина вашей брутальности, не один хумор можно будет загадить !
Вы по существу то отвечать будете ? Или просто выдали на гора то что читали, не удосужившись проверить ?
Здравствуйте, Sinclair, Вы писали:
S>Иначе мы дойдем до маразма.
К компиляторам-то это как относится?
Откуда компилятору знать какая ветвь в IF наиболее вероятна главная или побочная? Он компилирует так как написано. Откуда процессору знать какая ветвь более вероятна? Ни откуда ему это знать нельзя. А раз ни откуда это заранее узнать нельзя, то логично всегда начинать заранее подгружать данные из главной ветви. А раз так, то и программист должен главную ветвь делать наиболее вероятной.
S> частоиспользуемые переменные до редкоиспользуемых?
В Дельфи это между прочим официально рекомендуют на полном серьезе (Тейксейра, Пачеко). А откуда компилятору-то знать?
A loop is a sequence of statements which is specified once but which may be carried out several times in succession. The code "inside" the loop (the body of the loop, shown below as xxx) is obeyed a specified number of times, or once for each of a collection of items, or until some condition is met.
In some languages, such as Scheme, loops are often expressed using tail recursion rather than explicit looping constructs.
...
Condition-controlled loops
Again, most programming languages have constructions for repeating a loop until some condition changes. Note that some variations place the test at the start of the loop, while others have the test at the end of the loop. In the former case the body may be skipped completely, while in the latter case the body is always obeyed at least once.
...
Early exit from loops
When using a count-controlled loop to search through a table, you may wish to stop searching as soon as you have found the required item. Some programming languages provide a statement such as break or exit, whose effect is to terminate the current loop immediately and transfer control to the statement immediately following that loop.
Все. Единственное ограничение, накладываемое на while и for — это необходимость изменения исловия для выхода из цикла. Более того, отсутствие break — это ограничение, накладываемое не на циклы, а на программирование вообще. И называется оно — структурное программирование Дейкстры. Более того:
By the end of the 20th century, the majority of programmers endorsed structured procedural programming. Some claim that colleagues can understand a structured program more easily, leading to improved reliability and easier maintenance. Attempts to actually measure this have been rare, and there is a suspicion in some circles that the benefits are real but small.
Towards the end of the 20th century, designers have created new paradigms loosely based on procedural programming that accept the lessons of structured programming but attempt to go beyond this in providing structure for data as well as for program flow.
И еще более того, помимо структурного программирования есть еще и другие прадигмы — aspect programming, subject programming, post-object programming.
СГ>Цикл LOOP ... END либо исполняется вечно, либо завершается выполнением инструкции EXIT. Ни каких других ограничений на него не накладывается.
Зато зачем-то накладывается на другие циклы. А зачем — неизвестно никому, кроме Вирта
Здравствуйте, Mamut, Вы писали:
M> Просто надор было эту идею сразу нести в массы, а не подсчитывать лексемы Что-то в стиле M>
M>Как мне кажется, написание программ могло бы быть облегчено и, возможно, ускорено, если бы создатели придерживались простого правила — одно пользовательское выражение + одна лексема.
M>-- И дальше — звездочки, примеры программ и так далее — а то устроили этакое кровавое побоище ---
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, faulx, Вы писали:
F>> Это, конечно, цикл for.
СГ>Дело в том, что в Обероне (1987) цикла FOR нет вообще (вспомните: циклы бывают всего трех типов... и FOR-а среди них нет).
In his 1974 article, Donald Knuth identified two situations which were not covered by the control structures listed above, and gave examples of control structures which could handle these situations. Despite their utility, these constructions have not yet found their way into main-stream programming languages.
Loop with test in the middle
Multiple early exit/exit from nested loops
Да-да! Даже в "правильном во всех отношениях Обероне" (с) их нет
Здравствуйте, qwertyuiop, Вы писали:
SJA>>>Какие ещё будут предположения ?
СГ>>Предлагаю Вам найти тот форум и всех там разбомбить.
Q>Кажется это конец...
Сергей Губанов wrote:
> S>Иначе мы дойдем до маразма. > К компиляторам-то это как относится? > Откуда компилятору знать какая ветвь в IF наиболее вероятна главная > или побочная? Он компилирует так как написано. Откуда процессору знать > какая ветвь более вероятна? Ни откуда ему это знать нельзя. А раз ни > откуда это заранее узнать нельзя, то логично всегда начинать заранее > подгружать данные из главной ветви. А раз так, то и программист должен > главную ветвь делать наиболее вероятной.
1. Компилятор может оценить сложность ветки, и соптимизировать учитывая
эту сложность.
2. Существет PGO — Profile Guided Optimization. То есть сначала
программа запускается под профайлером, в котором собирается статистика
по путям исполнения (и много чему еще), а потом на основании этой
статистики программа перекомпилируется с оптимизациями.
> S> частоиспользуемые переменные до редкоиспользуемых? > В Дельфи это между прочим официально рекомендуют на полном серьезе > (Тейксейра, Пачеко). А откуда компилятору-то знать?
Вот ЭТО уже клиника... Нормальные современные компиляторы должны
оптимизировать часто используемые переменные без всяких подсказок.
СГ>Не вижу смысла, но ладно. Например, что-то вроде такого: СГ>
СГ>n = N;
СГ>IF n > 0 THEN
СГ> LOOP
СГ> ...
СГ> (* здесь может вызываться DEC(n), но не более N раз, поэтому n >= 0 *)
СГ> ...
СГ> END;
СГ> ASSERT(n >= 0);
СГ> использование "n"
СГ>END
СГ>
И за какое время выполнится код, выделенный жирным? Не может быть, что за 8 сек! (Или сколько там его выполняет супер быстрая машина?)
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Курилка, Вы писали:
К>>А пример аналогичный на Обероне так и останется заигноренным?
СГ>Не вижу смысла, но ладно. Например, что-то вроде такого: СГ>
СГ>
СГ>я уже подзабыл с чего началось...
Я напомню !
Переписывать ничего не надо.
Вопрос такой: Вы допустили ошибку и посетовали, что Оберон бы такого не допустил. Я взял да и написал аналог на обероне тут
Здравствуйте, Пацак, Вы писали:
П>Это не ответ на вопрос. Повторю его, если непонятно: чем использование BEGIN END в подпрограммах и модулях с синтаксической точки зрения отличается от использования его же в управляющих инструкциях? ИМХО — ничем.
В одном случае есть выбор использовать блок BEGIN END или не использовать, а в другом случае этого блока просто нет. Разница в более строгом синтаксисе — меньше вероятность совершить опечаточную глупую ошибку.
П>А в таком случае говорить, что эта связка в обероне не используется — явное лукавство.
Сам по себе блок BEGIN END отсутсвуют напрочь.
П>Итого имеем: строгое чередование лексема — звездочка наблюдается только в синтетических простейших случаях, имеющих мало общего с тем, что может встретиться в реальной программе. Ну и стоило ради этого огород городить?
Стоило. В си-образном синтаксисе это невозможно даже на синтетических тестах.
Кстати, а возможно ли, добиться того чтобы звездочное чередование всегда было бы правильным? Наверное нет, ведь тогда, как мне кажется, пришлось бы вводить очень много разных служебных лексем. Например правильность в сложный IF была внесена ценой добавочной лексемы ELSIF, но на все случаи жизни ведь новых лексем не напасешся... Можно было бы отменить ";" после "END", ведь END сам является разделителем. Действуя в этом направлении, избыточность уменьшилась бы, но, видимо, ценой введения исключений из общих правил. А это плохо. Лучше иметь правила не имеющие исключений.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Я приведу компиляющийся код, иначе Серегй объяснит где у вас ошибка в листинге, и уйдёт с гордо поднятой головой, проигнорировав остальное. SJA>Дааа... какая неожиданность. После WHILE i не равно 0 !
Супер.
Теория, мой друг, сера, но древо жизни вечно зеленеет. (с)
Вообще-то у меня тот способ построения управляющих конструкций языка, который вы пропагандируете, ассоциируется с языком Ку-Бейсик или с ФоксБейз (диБэйз, ФоксПро и т. п.). Но это не суть важно.
Я действительно нахожу, что синтаксис, основанный на отсустствии понятия "составная инструкция", удобнее и практичнее, а именно: он более устойчив к ошибкам, исключает проблему "чей else?" и прочая, и прочая.
Однако не считаю, что это такой уж важный вопрос. Ценность языка программирования составляется из многих источников, и удобный синтаксис — лишь один из них, и далеко не самый важный. В конце концов, Си-образный синтаксис (Си, Си++, Си-шарп, Ява и другие) хоть и не идеален, но он достаточно удобен для практического применения. В итоге вопросы совместимости по коду — они важнее, чем вопросы совершенствования синтаксиса.
Просто надор было эту идею сразу нести в массы, а не подсчитывать лексемы 
Что-то в стиле
