Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, moudrick, Вы писали:
СГ>>
СГ> if(условие2);
СГ> return ЧтоТо2(......);
СГ>
M>>1. Будьте внимательны.
СГ>Если использовать язык с правильным синтаксисом, то таких "зевков" не будет. Их отловит копилятор.
C помощью warning.
M>>2. Соблюдайте Coding standards. Они рулез.
СГ>О чем я и говорил. А мне не верили. Фигурные скобки надо писать всегда в любом случае и без исключений и еще с новой строки, да и то, даже в этом случае некоторые "зевки" останутся не отлавливаемыми компилятором.
СГ>
СГ> if(условие2); /* <-- "зевок" остался не уловимым для компилятора */
СГ> {
СГ> return ЧтоТо2(......);
СГ> }
СГ>
Here is a form of control flow not supported in any language I've used:
loopa: while x:
do stuff
if something:
continue loopb
loopb: while y:
do other stuff
if something else:
continue loopa
To be sane, when loopa exits here control flow should naturally jump to after loopb instead of falling through to it, otherwise it's rather like duff's device.
I have to admit I've never really wanted this functionality in any code I've written, but it's a form of cleaning up the call stack and jumping not supported by break/continue/return/raise.
Yesterday I wrote code with the following structure, and corresponding comment, which I find hilarious but is probably a bit on the obscure side:
for p in q:
do stuff
for a in b:
if f(a):
break
else:
# Niklaus Wirth can bite me
continue
do more stuff
И объяснение для тех, кто не понял, что там происходит (а я не понял ):
darius: I suspect (having not looked that Forth in ages) you may still be missing the meaning of the code (and it is an almost-but-not-quite unique feature in python — I'm pretty sure Ada95 has it too — but it is rare, if expressive) in that else clause *isn't* on the inner "if"... it's actually on the for, that is, it is a for-break-else construct. It is perhaps best thought as a "find loop" -- look in these things until you find something, or ELSE do something else.
Основным постулатом при создании языков программирования должно стать следующее: Позволь программисту сделать все, что он захочет, наиболее эффективнфм и логическим способом. И еще оставь немного место для wow-эффекта
A>Понимаете, мне кажется, что здесь имеется противоречие между двумя подходами к пониманию структурности.
A>"Академический" ... A>"Прагматический" ... A>"Академический" ... A>"Прагматический" ... A>Почему я ставлю кавычки? Теория без практики мертва, а практика без теории слепа. Ни тот, ни другой подход не является оптимальным в чистом виде. Программист должен и создавать, и сопровождать код, значит, хороший программист со спокойной совестью напишет цикл, содержащий break, но обязательно осознавая, каков консеквент цикла он имеет в виду получить, а если цикл получится большой или достаточно сложный, — ещё и задокументирует свои намерения для целей сопровождения.
A>Каков итог? Ни Оберон, ни Фортран-II популярностью не пользуются, а Си++ — пользуется.
>> 22.06.2005 12:13:00 from ICQ wrote: >> еще боян: >> >> Табличка в отделе компьютерной поддержки: >> Теория – это когда вы знаете все, но ничего не работает. Практика – это когда все работает, но никто не знает, почему. В ЭТОМ МЕСТЕ мы совмещаем теорию и практику – ничего не работает и никто не знает почему.
Провокационный вопрос из зала: Это про сторонников Оберон и Фортран-II или про противников (Си++)?
Здравствуйте, moudrick, Вы писали:
К>>А вот нифига! Я встречал конвенцию игры в преферанс, где за недозаклад (скажем, при чистой восьмерной заказал шесть — и, естественно, огорчил вистующих) писали "без одной"
M>Блин. Против этого правила — преферанмная поговорка есть. *Недозаложился (вариант — перезаложился) — залез в совй карман.*
Естественно. Но рисунок игры с кривым раскладом (повезло: на чистом сталинграде срубил 9 взяток) и с однозначным недозакладом (на девятерной из осторожности или заподлизма заказал сталинград) будет разным.
В преф, в отличие от бриджа, играют ещё и для удовольствия. А какое нафиг удовольствие у вистующих при недозакладе?
M>А вистущим надо грамотно вистовать. И тогда и недозаклад, и перезаклад играются так, что поговорка справедлива. M>Преферанс — не для азарта, а для мышления.
Для мышления и азарта
А чтобы был повод лишний раз подумать — и ввели правило недозаклада. Подчёркиваю — это конвенция, причём редкая.
К>>В этом случае третья дама не считается за взятку, а марьяж или (король,дама)-валет-десять считается. (Разумеется, под прикрытием козырей). M>Считает взятки игра, а не расклад. Расклад лишь обусловливает некоторые моменты игры.
Не, разумеется, можно постараться и не взять своё. Однако есть однозначные взятки — например, старшие козыри.
То есть, если при разборе полётов (вистующих крепко посадили) выяснится, что сыграла третья дама — это значит повезло или вистующие прошляпили. А если там были все козыри и тузы — извините, канделябр берётся наизготовку.
К>>Аналогично этому, С++ный приём закрывания угловых скобок через пробел — хотя и является техникой — фактически, относится к правилам. M>Ничего страшного. Есть правила и у техники. Называются "правила техники безопасности".
СГ>>>n = ...
СГ>>>while(n --> 0)
СГ>>>{
СГ>>> ...
СГ>>>}
СГ>>>use(n); // теперь n на 1 меньше чем надо (а иногда нет)
СГ>>>
СГ>>>Мне стыдно за такую глупость, поддался "моде" на --> 0 оператор...
СГ>Ну вот. Я не одинок. Вы тоже совершили ту же самую ошибку что и я. Ведь здесь нет ошибки связанной с постфиксной или префиксной записью оператора --.
Вы, Сергей, как обычно ткнули пальцем в небо. Здесь есть именно ошибка, связанная с префиксной и постфиксной записью оператора --. И она здесь не одна. В сочетании с записью
n = неизвестно_чтоwhile(n-- > 0){...}
//смотрим n
вы получите -1 всегда, когда n>0 и n-1 когда n<=0
Вторую ошибку ищите самостоятельно. Из неё, кстати, следует описанный результат.
Как будет себя вести ваш код при префиксной записи, я думаю, вы математически докажете самостоятельно.
СГ>Придется объяснить. СГ>1) По условию задачи, цикл должен выполнятся только если n > 0. СГ>2) Запись n-- > 0 действительно сначала проверяет n > 0, а потом уменьшает n, тут ошибки нет. СГ>3) Ошибка в том, что уменьшение n производится в любом случае, даже тогда, когда n и так уже равно нулю.
СГ>
OAB>procedure TReferenceTree.UnlinkNode(current: PReferenceNode);
OAB>begin
OAB> // unlink left/right
OAB> if Assigned(current^.LeftInline) then
OAB> begin
OAB> if Assigned(current^.RightInline) then
OAB> begin
OAB> // glue left with right
OAB> current^.LeftInline^.RightInline := current^.RightInline;
OAB> current^.RightInline^.LeftInline := current^.LeftInline;
OAB> end
OAB> else
OAB> // unlink left
OAB> current^.LeftInline^.RightInline := nil;
OAB> end
OAB> else ; // nothink glue/unlink
OAB> // unlink next/previous
OAB> if Assigned(current^.PrevSibling) then
OAB> begin
OAB> if Assigned(current^.NextSibling) then
OAB> begin
OAB> // glue periouse with next
OAB> current^.PrevSibling^.NextSibling := current^.NextSibling;
OAB>
OAB>и т.д... и посмотрю на того кто осмелится такое писать в одну строку! понимаю что процедуры на 2-3 экрана это не нормально, но иногда без них не обойтись
Очень наглядный пример для демонстрации разницы между Delphi Language (бывший Object Pascal) и оберонами, точнее усовершенствованной версией Оберона 2 с коммерческим названием Component Pascal:
Разница:
0) Собственно, сам синтаксис.
1) В Component Pascal при объявлении метода явно указывается, что он новый NEW, а не перекрываемый старый метод из предка. Это необходимо для того чтобы если вдруг кто-нибудь потом из предка тот метод удалил или изменил, чтобы при компиляции этого кода компилятор сразу же сообщил, что метод не может быть перекрыт, так как в предке его нет. В Delphi все наоборот, если не написано ничего, значит метод новый, а если написано override — значит перекрытие старого. В Component Pascal противоположно — если написано NEW, то метод новый, а если не написано NEW, то метод перекрывает старый "виртуальный". И тот и этот подход, в принципе, эквивалентны. Да вот только слово NEW надо написать только в базовом классе, а во всех перевсех потомках уже писать ничего не надо. Так как потомков потенциально не ограниченное количество, то получается экономия (один раз написать NEW вместо того чтобы потом всегда писать override).
2) В Component Pascal нет ни какого зарезервированного слова навроде this или self. В указанном примере можно было обозвать переменную обозначающую сам объект как угодно
3) В Component Pascal символ разыменования указателя "^" в тех случаях когда он очевиден писать не обязательно.
4) В Component Pascal, как и во всех Modula/Oberon-ах есть полноценные процедурные переменные, так что специальная инструкция навроде assigned() не нужна. Процедурная переменная записанная как есть обозначает саму себя, в то время как записанная со скобками () означает активацию процедуры на которую она ссылается. Поэтому процедурную переменную в Modula/Oberon-ах можно сравнивать с NIL даже если она сама является процедурой-функцией.
Например,
TYPE Func: PROCEDURE(): Func;
VAR a: Func;
IF a # NIL THEN ... END
это одно (сравнивается значение процедурной переменной "a")
IF a() # NIL THEN ... END
а это совсем другое (сравнивается значение которое возвращается процедурой с которой связана процедурная переменная "a")
Комбинация первого и второго:
IF (a # NIL) & (a() # NIL) THEN ... END
M>>Блин. Против этого правила — преферанмная поговорка есть. *Недозаложился (вариант — перезаложился) — залез в совй карман.*
К>Естественно. Но рисунок игры с кривым раскладом (повезло: на чистом сталинграде срубил 9 взяток) и с однозначным недозакладом (на девятерной из осторожности или заподлизма заказал сталинград) будет разным.
За 9 на Сталинграде не наказывают. На то он и Сталинград.
К>Для мышления и азарта
A>В этом вашем примере assert(n <= -1) совершенно не имеет смысла, потому что значение n предсказуемо на 100% и всегда будет равно -1.
Позвольте раз в жизни согласиться с Сергеем Губановым (отпишусь-ка я на всякий случай от этой ветки, а то страшненько ).
Ассерт тут по смыслу очень даже правильный. Есть и такой чудесный паттерн рефакторинга — Введение утверждения (Introduce Assertion).
Суть которого в том, что не надо писать коммент, типа, тут ожидается такие и такие значения. надо указать это явно, при помощи программного кода. И без килотонн комментариев становится понятно, что при невыполнении ассершена правильность дальнейшей работы, вообще говоря, не гарантирована. Самодокументированность рулит. Да и при отладке ассершены помогают преизрядно, поверьте. Если экономишь такты — в опциях компилера ставь, чтоб не компилил ассершены или шото в этом роде, что спасет отца русской демократии.
Здравствуйте, Mamut, Вы писали:
M>Еще как возможен. M>
PROCEDURE a : BOOLEAN
{* пара десятков строчек кода *}
RETURN TRUE;
END a;
PROCEDURE b
VAR
a : BOOLEAN;
BEGIN
a := FALSE;
{* пара десятков строчек кода *}
IF a THEN
{* критически важный код *}
END
END;
Если в выражении IF a THEN, Вы хотели вызвать описанную ранее процедуру-функцию, то это надо было делать так:
IF a() THEN
{* критически важный код *}
END
"а" и "а()" — совершенно разные штукенции.
В принципе на "зевок" можно списать, но очень редкий, ведь тут двухсимвольная опечатка "()". А двухсимвольные опечатки менее вероятны чем односимвольные.
СГ>Если в выражении IF a THEN, Вы хотели вызвать описанную ранее процедуру-функцию, то это надо было делать так: СГ>
СГ> IF a() THEN
СГ> {* критически важный код *}
СГ> END
СГ>
СГ>"а" и "а()" — совершенно разные штукенции.
СГ>В принципе на "зевок" можно списать, но очень редкий, ведь тут двухсимвольная опечатка "()". А двухсимвольные опечатки менее вероятны чем односимвольные.
Что-то в примерах, которые вы приводили при подсчете лексем, вы почему-то не вызывали процедуры со скобками. Аяяяй, нехорошо
А в остальном — да, согласен, точку с запятой пропустить легче
Здравствуйте, Сергей Губанов, Вы писали:
СГ>0) Собственно, сам синтаксис.
Кстати ! Когда иссякнет эта тема, предлагаю начать следующую ! Как извесно в С/С++ индескы начинаются с 0, а в Обероне с 1 (т.е. я так предполагаю). "Спрашивается как долго ...". Ну и так далее. Убедительные примеры, доказательства и процентные соотношения выдумаете сами.
А ?
M>>>Блин. Против этого правила — преферанмная поговорка есть. *Недозаложился (вариант — перезаложился) — залез в совй карман.*
К>>Естественно. Но рисунок игры с кривым раскладом (повезло: на чистом сталинграде срубил 9 взяток) и с однозначным недозакладом (на девятерной из осторожности или заподлизма заказал сталинград) будет разным.
P>За 9 на Сталинграде не наказывают. На то он и Сталинград.
У нас — как договоришься Если просто посидеть, то договариваемся не подлить. А когда народ играет на то, кто за сигаретами сходит , то все средства хороши.
К>>Для мышления и азарта P>
Здравствуйте, CrystaX, Вы писали:
CX>Из Ваших слов выходит, что синтаксис должен быть масимально жестким. Вот в этом месте может быть только такая-то лексема и никакая другая, а вот в этом — такая-то и никакая другая, так?
Да примерно так. Должна быть возможность глядя на программу понять опечатка в ней или так и надо. По крайней мере синтаксис должен быть таким чтобы минимизировать количество возможных односимвольных опечаток (как в данном случае ";" — односимвольная опечатка)
CX> Жесткий каркас синтаксиса языка — хорошо компилятору, плохо пользователям. Гибкий синтаксис — плохо компилятору, хорошо разработчику.
Если в самом синтаксисе нет возможности для отслеживания опечаток, то как компилятор их найдет? В этом смысле синтаксис первичен, а пользователи вторичны. А вот уже из всех возможных правильных синтаксисов, надо выбрать тот, который будет еще и максимально удобен пользователю. Вот в какой последовательности нужно идти, а не в обратной.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Oleg A. Bachin, Вы писали:
OAB>>
OAB>>procedure TReferenceTree.UnlinkNode(current: PReferenceNode);
OAB>>begin
OAB>> // unlink left/right
OAB>> if Assigned(current^.LeftInline) then
OAB>> begin
OAB>> if Assigned(current^.RightInline) then
OAB>> begin
OAB>> // glue left with right
OAB>> current^.LeftInline^.RightInline := current^.RightInline;
OAB>> current^.RightInline^.LeftInline := current^.LeftInline;
OAB>> end
OAB>> else
OAB>> // unlink left
OAB>> current^.LeftInline^.RightInline := nil;
OAB>> end
OAB>> else ; // nothink glue/unlink
OAB>> // unlink next/previous
OAB>> if Assigned(current^.PrevSibling) then
OAB>> begin
OAB>> if Assigned(current^.NextSibling) then
OAB>> begin
OAB>> // glue periouse with next
OAB>> current^.PrevSibling^.NextSibling := current^.NextSibling;
OAB>>
OAB>>и т.д... и посмотрю на того кто осмелится такое писать в одну строку! понимаю что процедуры на 2-3 экрана это не нормально, но иногда без них не обойтись
СГ>Очень наглядный пример для демонстрации разницы между Delphi Language (бывший Object Pascal) и оберонами, точнее усовершенствованной версией Оберона 2 с коммерческим названием Component Pascal:
СГ>
СГ>Разница:
ну давайте посмотрим (и это не смотря на то, что вы абсолютно игнорируете мой пост утвеждающий что вы ничего не понимаете в програмировании судя по вашей конструкции "try try")
СГ>0) Собственно, сам синтаксис.
из синтаксиса убивают большие буквы. это ваша привычка или требование языка?
СГ>1) В Component Pascal при объявлении метода явно указывается, что он новый NEW, а не перекрываемый старый метод из предка. Это необходимо для того чтобы если вдруг кто-нибудь потом из предка тот метод удалил или изменил, чтобы при компиляции этого кода компилятор сразу же сообщил, что метод не может быть перекрыт, так как в предке его нет. В Delphi все наоборот, если не написано ничего, значит метод новый, а если написано override — значит перекрытие старого. В Component Pascal противоположно — если написано NEW, то метод новый, а если не написано NEW, то метод перекрывает старый "виртуальный". И тот и этот подход, в принципе, эквивалентны. Да вот только слово NEW надо написать только в базовом классе, а во всех перевсех потомках уже писать ничего не надо. Так как потомков потенциально не ограниченное количество, то получается экономия (один раз написать NEW вместо того чтобы потом всегда писать override).
давно подобного бреда не слышал! перекрытие методов куда более редкая вещь чем добаление новых! так что во всех наследниках новый метод прийдется описать как NEW.
кстати, а как у нас дело обстоит с абстрактными методами?
и еще одна мелочь, а что, абсолютно все методы можно перекрыть? т.е. я не могу жить без виртуальной таблицы? статика уже того, тоже устарела? хотелось бы с этим разобраться, а то такая универсальность далеко заведет...
СГ>2) В Component Pascal нет ни какого зарезервированного слова навроде this или self. В указанном примере можно было обозвать переменную обозначающую сам объект как угодно
СГ>PROCEDURE (t: ТипОбъекта) НазваниеМетода (аргументы...), NEW;
СГ>здесь я написал букву t — вместо this или self.
и? это экономия или куда? ну у меня всегда есть Self, в сях — this, а тутачки что в голову стукнет?
СГ>3) В Component Pascal символ разыменования указателя "^" в тех случаях когда он очевиден писать не обязательно.
ну и? в делфи тоже. и меня это убивает. я лично как писАл, так и буду писать то что есть, а не то что подразумевается.
СГ>4) В Component Pascal, как и во всех Modula/Oberon-ах есть полноценные процедурные переменные, так что специальная инструкция навроде assigned() не нужна. Процедурная переменная записанная как есть обозначает саму себя, в то время как записанная со скобками () означает активацию процедуры на которую она ссылается. Поэтому процедурную переменную в Modula/Oberon-ах можно сравнивать с NIL даже если она сама является процедурой-функцией.
бред полнейший!!!! какраз на NIL можно сравнивать что угодно! это в Assigned функцию передавать нельзя
вы хоть что-то в локальных переменных и результатах ф-ции понимаете?
а Assigned писал потому что мне так нравится.
СГ>Например,
СГ>TYPE Func: PROCEDURE(): Func;
СГ>VAR a: Func;
СГ>IF a # NIL THEN ... END СГ>это одно (сравнивается значение процедурной переменной "a")
СГ>IF a() # NIL THEN ... END СГ>а это совсем другое (сравнивается значение которое возвращается процедурой с которой связана процедурная переменная "a")
СГ>Комбинация первого и второго: СГ>IF (a # NIL) & (a() # NIL) THEN ... END
Здравствуйте, Privalov, Вы писали:
M>>>Блин. Против этого правила — преферанмная поговорка есть. *Недозаложился (вариант — перезаложился) — залез в совй карман.* К>>Естественно. Но рисунок игры с кривым раскладом (повезло: на чистом сталинграде срубил 9 взяток) и с однозначным недозакладом (на девятерной из осторожности или заподлизма заказал сталинград) будет разным. P>За 9 на Сталинграде не наказывают. На то он и Сталинград.
Если б вы знали, как прикольно мне, ни разу не игравшему это читать. Примерно как:
...
— Выстребаны обстряхнутся, — говорил он, — и дутой чернушенькой
объятно хлюпнут по маргазам. Это уже двадцать длинных хохарей. Марко было
бы тукнуть по пестрякам. Да хохари облыго ружуют. На том и покалим
сростень. Это наш примар...
Дон Рэба пощупал бритый подбородок.
— Студно туково, — задумчиво сказал он.
Вага пожал плечами.
— Таков наш примар. С нами габузиться для вашего оглода не сростно.
По габарям?
— По габарям, — решительно сказал министр охраны короны.
— И пей круг, — произнес Вага, поднимаясь.
...
Там не по теме. В этой ветке форума обсуждается си-образный синтаксис vs Modula/Oberon-образный. Если Вам охота какой-то другой синтаксис сравнить заводите другую ветку форума. Но такой популярности как эта ветка, она вряд ли добьется.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Например,
СГ>TYPE Func: PROCEDURE(): Func;
СГ>VAR a: Func;
СГ>IF a # NIL THEN ... END СГ>это одно (сравнивается значение процедурной переменной "a")
СГ>IF a() # NIL THEN ... END СГ>а это совсем другое (сравнивается значение которое возвращается процедурой с которой связана процедурная переменная "a")
То есть, забыл скобки — получил глюк.
-Оберон лучше чем С++!
-Чем Оберон лучше С++?
-Тебе же ясно сказано! Чем С++!
СГ>Если в самом синтаксисе нет возможности для отслеживания опечаток, то как компилятор их найдет? В этом смысле синтаксис первичен, а пользователи вторичны. А вот уже из всех возможных правильных синтаксисов, надо выбрать тот, который будет еще и максимально удобен пользователю. Вот в какой последовательности нужно идти, а не в обратной.
Синтаксис должен быть удобен пользователю. То, насколько это удобно компилятору — побоку. Компилятору удобно ассемблер яитать. Или напрямую машинные коды.
Средства анализа кода на сегодняшний день позволяют отлавливать такие ошибке в процессе написания и уж тем более на этапе компиляции. Современные компиляторы кидают в том месте warning. И правильно делают. Так как в общем случае это — не обязательно ошибка
):
Перекуём баги на фичи!
).
