Здравствуйте, Александр!

> Понравилась реализация необязательного параметра n в макросе

Спасибо.  Но этот прием не я придумал.  Видел где-то.

А вот полным решением проблемы с избыточностью имен в struct в Си
я горжусь :)
И в учебниках по программированию на Си, и в реальных программах —
тонны этой избыточности, но решение показывает, что она не нужна.

> Мой пример выглядел бы так:
>
> int row, col;  // используются после цикла, нельзя объявлять внутри.
> loop (
>   row = 0; col = 0
> , row < MAXROW && elem_at(row, col) == 0
> , ++col;
>   if (col == MAXCOL) {
>     col = 0;
>     ++row;
>   }
> )
>   // тело пустое, как я и предполагал
> fin();

Возможно, вы смотрели определение loop в статье?
То, что в файле m.cpp, является более поздним и с ним данный фрагмент
не сработает.   Ваш вариант поиска я записал бы так:

loop (row = 0; col = 0 , row < MAXROW)
exitif (elem_at(row, col) != 0)
upd (if (++col == MAXCOL) { col = 0; ++row;})
fin();

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

> Фишка этого примера в том, что он записывается целиком в рамках структурного 
> программирования: без goto, break и return.

Это если принять, что в структурном программировании их нет.
Но данная точка зрения не единственная.

> Плата за структурное программирование. В варианте Сергея Абрамова (в 
> следующем письме) вводится дополнительная булевская переменная и тоже 
> требуется дополнительная проверка

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

Плата за структурное программирование?  Скорее, по-моему, это
плата за определенное, очень конкретное понимание структурного
программирования.  Но единого определения этого понятия, с которым
все были бы согласны, нет.  Зачем подгонять решения задач под
какое-то представление о структурности, которое даже не является
общепризнанным?  Что получаем за «плату»?  Ведь решения становятся
в той или иной мере искусственными (признаком чего является
избыточность имен и действий), а что получаем навстречу и так ли
оно ценно?  Не лучше ли пересмотреть наше понимание о структурности?

Допустим, кто-то постановил, что программировать структурно — это
только через while и простую последовательность.  Даже if не нужен, он
выражается через while.  Но такое понимание структурности не берет
во внимание ни локальность связываний имен, ни количество тех же
имен и вообще элементов программ, ни обоснованность введения всех
этих элементов с точки зрения решаемой задачи (а не соблюдения
заранее придуманных правил «структурности»).

Признано, что придерживаться какого-нибудь множества структурных схем
нужно, но по-моему так же нужно выбор этого множества время от времени
пересматривать.  Иначе в императивном программировании мы бы остались
с Фортраном или Алголом-60, у каждого из которых имеется единственный
оператор цикла.  А в функциональном программировании так и не пришли
бы к лексическому связыванию, частичному применению, одноаргументности
и композиции функций и сопоставлению с образцом — остались бы с Лиспом,
у которого их и сегодня нет, за исключением лексического связывания.

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

Ответить