Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Cyberax, Вы писали:

C>>Плевать мне на теорию про три цикла. На _ПРАКТИКЕ_ (подчеркиваю
C>>специально) нужен break для нормального кода.

СГ>Мне даже интересно стало. Может покажете пример?

Да пожалуйста — только не break а выброс исключения, как средство далёкого безусловного перехода. Поиск по дереву с очень глубокой рекурсией, сложным алгоритмом и нетривиальным усовием останова, которое может сработать в середине обхода и при этом необходимо прервать поиск полностью. Можно передавать булевский флаг, но когда у функции итак много параметров (алгоритм сложный) — это неудобно, да и сам алгоритм ещё больше запутывает. Самым оптимальным в этом случае с точки зрения понимания алгоритма, будет выброс исключения и отлов его в самом верху...
Структурные принципы нарушены? — Да. Но читабельность реализации алгоритма от этого только выиграла.

Здравствуйте, moudrick, Вы писали:

OAB>>>>и т.д... и посмотрю на того кто осмелится такое писать в одну строку!
OAB>>>> Понимаю что процедуры на 2-3 экрана это не нормально, но иногда без них не обойтись

M>>>Если надо — обойтись всегда можно. Надо привыкать делать из хорошего кода еще более лучший, если это себя оправдывает.
M>>>Рефакторинг рулит. Паттерн Выделение метода (Extract Method). Примерчик там, правда, галименький, но ничего лучшего я не нашел. Применяем его с одновременным применением паттерна добавление параметра (Add Parameter).

M>>>Сокращаем текст длинного метода на ~5 строк. Заодно если называем только что выделенный метод правильно, не нужно тратить лишние строки на поясняющие комментарии (самодокументированность).

OAB>>это все хорошо, но как я уже сказал ИНОГДА без этого не обойтись.
OAB>>1. я сам не приемлю работать с рекордами, но когда нужна скорость при выделении/освобождении памяти блоками, скорость доступа и т.д — я их использую, а так предпочитаю классы.
OAB>>(итак мне нужна была скорость)
OAB>>2. вы как минимум забыли в процедуру передать 1 параметр — this.
M>Нет. Выделенный метод и изначальный метод находится на одном уровне (в том же классе, либо оба глобальные). При вызове из того же класса this передается неявно. А если глобальные, какой тут тогда this. (В дельфях же есть вроде глобальные методы, если я не ошибаюсь)

1. т.е если у меня появляется новый тип линковки мне требуется изменить декларацию класса. я б поспорил здесь о выгоде...
2. какая разница, явно или неявно? при большой глубине рекурсии это иногда больно.
OAB>> да, он не попал в увиденом блоке, но он есть.
3. имелось ввиду не сам указатель на екземпляр конечно же, а доступ к данным екземпляра.

OAB>> один параметр конежно же мелочь, если... если у нас не будет глубоких вложенных рекурсий, а они тоже есть.
M>Если методы на одном уровне — это по барабану. В большинстве случаев. Рефакторинг — преобразование эквивалентности. То есть только что отрефакторенный код делает то же самое, что и неотрефакторенный, но выглядит иначе, удобнее для каких-то целей.
эээ... ну как мне вам объяснить что подобную вешь, только этак раз 8 проще я уже писал и знаю скользкие моменты

OAB>>так что если добавить к этому, что inline появилась только в D9... это то самое иногда.
M>Борьба эффективности и понятности.... старая история.
зинаю будет инлайн — смогу упростить часть, а так... просто ловил уже Stack Overflow на рабочем коде из-за красоты — на больших объемах залебывалась рекурсия

M>В борьбе бобра с ослом всегда побеждает бобро. (с) Сергей Бобро.

OAB>>PS код кстати приводился по сабджу
M>У нас не сабдж а флейм. Мы в хуморе.
так ты прикалываешься!

Здравствуйте, moudrick, Вы писали:

M> требования современных виртуальных оберон-машин.

Каких еще виртуальных? Это у Java есть виртуальная машина, не путайте. Обероны с самого начала компилировались в родные машинные коды. Есть, конечно реализации компиляции в java байт код, или в промежуточный язык .NET. Но не забывайте, что первый оберон появился в 1987 году, второй в 1992 году. Тогда еще не было ни Java ни .NET. Опять же возьмем BlackBox Component Builder — там тоже идет компиляция в родные машинные коды. Нет ни какой виртуальной машины. Про операционные системы реального времени написанные на оберонах говорить думаю не надо — какая там-то еще виртуальная машина-то???

Здравствуйте, qwertyuiop, Вы писали:

Q>как научный работник умело подтасовывает данные.

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

OAB>>>2. вы как минимум забыли в процедуру передать 1 параметр — this.
M>>Нет. Выделенный метод и изначальный метод находится на одном уровне (в том же классе, либо оба глобальные). При вызове из того же класса this передается неявно. А если глобальные, какой тут тогда this. (В дельфях же есть вроде глобальные методы, если я не ошибаюсь)

OAB>1. т.е если у меня появляется новый тип линковки мне требуется изменить декларацию класса. я б поспорил здесь о выгоде...
Очень жаль, что детали линковки так глубоко въелись в язык Делфи... Правда, жаль, если это действительно так...

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

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

OAB>>> один параметр конежно же мелочь, если... если у нас не будет глубоких вложенных рекурсий, а они тоже есть.
M>>Если методы на одном уровне — это по барабану. В большинстве случаев. Рефакторинг — преобразование эквивалентности. То есть только что отрефакторенный код делает то же самое, что и неотрефакторенный, но выглядит иначе, удобнее для каких-то целей.
OAB>эээ... ну как мне вам объяснить что подобную вешь, только этак раз 8 проще я уже писал и знаю скользкие моменты

OAB>>>так что если добавить к этому, что inline появилась только в D9... это то самое иногда.
M>>Борьба эффективности и понятности.... старая история.
OAB>зинаю будет инлайн — смогу упростить часть, а так... просто ловил уже Stack Overflow на рабочем коде из-за красоты — на больших объемах залебывалась рекурсия

M>>В борьбе бобра с ослом всегда побеждает бобро. (с) Сергей Бобро.

OAB>>>PS код кстати приводился по сабджу
M>>У нас не сабдж а флейм. Мы в хуморе.
OAB>так ты прикалываешься!
Насчет пользы рефакторингва и возможности такового в Дельфях — ни капельки.

Здравствуйте, AVC, Вы писали:

AVC>а) Соответствие структурным принципам.

AVC>В отличие от синтаксиса Модулы/Оберона синтаксис Си/Си++ не соответствует принципам структурного программирования.
AVC>Рассмотрим хотя бы циклы.
AVC>Когда программист пишет (или, что важнее, читает) на Модуле/Обероне цикл
AVC>он абсолютно уверен, что перед следующим оператором после выхода из цикла выполняется условие ~p (NOT p).
AVC>на Си/Си++, он не может быть в этом уверен, т.к. внутри цикла может находиться как оператор break, так и знаменитый goto.
AVC>То же относится к циклам REPEAT UNTIL ~p и do {} whiie (p).

Смотри проще.
В С/С++ единственным консеквентом цикла является только тот факт, что цикл каким-то образом завершился и более не выполняется. Все. Более никаких утверждений об истинности или ложности условия этого цикла не делается.
Соответственно ни один программист С/С++ и в жизни даже не задумается на эту тему, он просто никогда не будет предполагать, что условие выхода из цикла обязано выполниться после цикла (а, соответственно, условие продолжения цикла обязано не выполниться). Точно так же, как он не предполагает, что выделенная им память сама собой освободится, а предпринимает какие-то действия в зависимости от конкретной ситуации и своих потребностей в ней.

Вот и все. Никаких проблем.
Если программист С++ хочет что-то гарантировать, он просто достигает этого другими методами, а этих методов уж точно больше, чем у Оберона (один RAII чего стоит).

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Пацак, Вы писали:

П>

П>while (queue.has_elements()) {
П>    Elem elem = queue.get_first();
П>    if (elem.get_state() == ST_FREE) {
П>        elem.start_processing(...);
П>        break;
П>    } else { 
П>        queue.make_last(elem);
П>    }
П>}
П>

А зачем ты после break ставишь else?

Здравствуйте, Кодт, Вы писали:

К>ZX Spectrum, БК-001, ещё какие-то модели микрош-ириш такой фичей обладали. Одна кнопка — одна лексема васика. У БК и Спектрум они даже подписаны были (соответственно, имели несколько шифт-клавиш ).

Угу, весьма раздражало, если надо было вбить PUT вместо PRINT.

К>МИР (Машина Инженерных Расчётов), насколько я слышал, тоже (свой собственный язык программирования).

Назывался Аналитик. Слышал от тех, кто на нем работал, что очень приятная вещь.

Здравствуйте, moudrick, Вы писали:
AVC>>Рассмотрим хотя бы циклы.
AVC>>Когда программист пишет (или, что важнее, читает) на Модуле/Обероне цикл
AVC>>

AVC>>WHILE p DO ... END
AVC>>

AVC>>он абсолютно уверен, что перед следующим оператором после выхода из цикла выполняется условие ~p (NOT p).
AVC>>Если программист читает аналогичный цикл
AVC>>

AVC>>while (p) { ... }
AVC>>

AVC>>на Си/Си++, он не может быть в этом уверен, т.к. внутри цикла может находиться как оператор break, так и знаменитый goto.
M>Ах, вот о чем речь? А что мешает Вам их не использовать?

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Mamut, Вы писали:

M>> недокостыле

СГ>Вы спорите против прописных истин.
СГ>Циклы с проверкой условия выполнения и циклы с проверкой условия завершения для того и придуманы, чтобы гарантировать выполнение пост условий. Вообще же достаточно было бы иметь лишь один тип цикла LOOP ... END и больше ни чего не надо, ни WHILE ни REPEAT. Но, опять же таки, вспоминаем: Сделать так просто как только можно, но не проще!

А что здесь есть прописная истина?
Еще раз, универсальным типом цикла является WHILE (цикл с предусловием). Почитайте Вирта.

Здравствуйте, Socrat, Вы писали:


S>А зачем ты после break ставишь else?

Стормозил конечно.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Mamut, Вы писали:

M>> недокостыле

СГ>Вы спорите против прописных истин.
СГ>Циклы с проверкой условия выполнения и циклы с проверкой условия завершения для того и придуманы, чтобы гарантировать выполнение пост условий.

А-а-а, так вот они зачем придуманы! А я-то....

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Пацак, Вы писали:

П>Угу, ясно. Допустим (совершенно условно):
П>

П>while (queue.has_elements()) {
П>    Elem elem = queue.get_first();
П>    if (elem.get_state() == ST_FREE) {
П>        elem.start_processing(...);
П>        break;
П>    } else { 
П>        queue.make_last(elem);
П>    }
П>}
П>

П>И чо делать?

Ну, как что делать, обращайтесь ко мне, я Вам помогу, научу как надо грамотно программировать.

В данном случае надо использовать цикл с проверкой остановки выполнения итерации внутри самой итерации, то есть надо использовать цикл LOOP:

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Примеры типичных ошибок как так может быть:

СГ>Было:
СГ>

СГ>n = ...
СГ>while(n > 0)
СГ>{
СГ>  ...
СГ>  n--;
СГ>}
СГ>use(n);
СГ>

СГ>После глупого с моей стороны так сказать усовершенствования стало:
СГ>

СГ>n = ...
СГ>while(n --> 0)
СГ>{
СГ>  ...
СГ>}
СГ>use(n); // теперь n на 1 меньше чем надо (а иногда нет)
СГ>

СГ>Мне стыдно за такую глупость, поддался "моде" на --> 0 оператор...

Нет оператора "-->". Тут два оператора, написанных без пробела. А вообще, for рулит.

СГ>Еще пример (авторство не моё)
СГ>

СГ>  if(условие1) 
СГ>    return ЧтоТо1(......);

СГ>  if(условие2);
СГ>    return ЧтоТо2(......);

СГ>  if(условие3) 
СГ>    return ЧтоТо3(......);
СГ>

СГ>лишняя точка с запятой поставленная по невнимательности у if(условие2).

А еще типичная ошибка — вместо "==" в условии поставить "="... Издержки нестрогих языков.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Cyberax, Вы писали:

C>>Плевать мне на теорию про три цикла. На _ПРАКТИКЕ_ (подчеркиваю
C>>специально) нужен break для нормального кода.

СГ>Мне даже интересно стало. Может покажете пример?

здесь

Автор: Mamut
Дата: 21.06.05

Здравствуйте, Socrat, Вы писали:

S>А при чем тут деструктор?

Не знаю при чем. Какой еще деструктор?

M>> недокостыле

СГ>Вы спорите против прописных истин.
СГ>Циклы с проверкой условия выполнения и циклы с проверкой условия завершения для того и придуманы, чтобы гарантировать выполнение пост условий. Вообще же достаточно было бы иметь лишь один тип цикла LOOP ... END и больше ни чего не надо, ни WHILE ни REPEAT. Но, опять же таки, вспоминаем: Сделать так просто как только можно, но не проще!

Потягаемся в цитатах

"Не плоди сущностей без необходимости" LOOP — такая вот ненужная сущность.

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

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

Вы опять игнорируете здесь

Автор: Mamut
Дата: 22.06.05

. (Если есть проблемы с языком, я могу перевести, хоть и лень )

Здравствуйте, moudrick, Вы писали:

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

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

Почитай D&E.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, moudrick, Вы писали:

OAB>>>>2. вы как минимум забыли в процедуру передать 1 параметр — this.
M>>>Нет. Выделенный метод и изначальный метод находится на одном уровне (в том же классе, либо оба глобальные). При вызове из того же класса this передается неявно. А если глобальные, какой тут тогда this. (В дельфях же есть вроде глобальные методы, если я не ошибаюсь)

OAB>>1. т.е если у меня появляется новый тип линковки мне требуется изменить декларацию класса. я б поспорил здесь о выгоде...
M>Очень жаль, что детали линковки так глубоко въелись в язык Делфи... Правда, жаль, если это действительно так...
эээ... не та линковка вы мне просто предлагали разбить на блоки разъединения нод... разлинковки или линковки (сам забыл какой код приводил).
в случае реализации функцией класса (в делфях принято метод называть) при появлении нового "типа линковки" мне понадобится еще одна процедура класса, т.е. прийдется остальным пересобираться ... честно коворя на нынешней стадии разработки это мелочь

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

OAB>>>> да, он не попал в увиденом блоке, но он есть.
OAB>>3. имелось ввиду не сам указатель на екземпляр конечно же, а доступ к данным екземпляра.
M>Точно чего-то недопонял...
я тож...

OAB>>>>PS код кстати приводился по сабджу
M>>>У нас не сабдж а флейм. Мы в хуморе.
OAB>>так ты прикалываешься!
M>Насчет пользы рефакторингва и возможности такового в Дельфях — ни капельки.
так я не против рефакторинга! и вообще это не класс для красоты — может на асме перепишу

Здравствуйте, Сергей Губанов, Вы писали:


P>>И от них не слышно о языке, позволяющем создавать правильные "по определению" программы. Это третье.

СГ>На Си их и невозможно создавать. А любителей языка Limbo я еще не встречал. Кто знает, может и появятся в будущем.

А на Обероне возможно? Если Вы определите константу, скажем, _MAX_PATH = 250 вместо 260, компилятор Вас поправит?
А синтаксис Limbo каков?