Я подозреваю, что C-подобный FOR -- это вообще единственный необходимый тип цикла. Например, в Эйфеле есть только конструкция FROM-UNTIL-LOOP (в простонародье -- просто LOOP).

BTW, в Эйфеле goto нет принципиально, и ничего, выкручиваются как-то...

Дейкстру и Кнута я изучал в 70-х, начале 80-х годов прошлого века. От CASE, FOR и т. п. отказываться нет смысла. Они не противоречат правилу "один вход, один выход". А GO TO противоречит. Если же хотите, чтобы Вам решили Вашу задачу, внятно ее сформулируйте. А то странно как-то звучит декартово произведение множеств A[i] = {j| 1 <= j <= N[i]}, где 1<=i<=n. А еще лучше приведите свое решение с GO TO, чтобы убедиться, что решается именно та задача, которая должна решаться. И не пытайтесь экзаменовать опонентов. Для этого надо доказать свое право это делать.

2anonymous (*) (2003-02-17 13:09:43.466):зачем в попугаев? В пакеты в секунду ламо :)

2eugine_kosenko: "Что там доказано" - ууу, как все запущено...:) Чтоб правильно задать вопрос надо знать большую часть ответа, однако...:) Слушай, ну почитай классиков, а уж потом спорь на програмисткие темы, а? ;)

** try{
** // some work
** }
** finally{
** // clean up
** } 

** Это именно то чего так нехватает C++

Да ну?

try {
   File f;
   char *p;
   f.open ("somefile.one");
   p = new char [10000000000]; // памяти не хватает, генерится эксепшн
// перед выходом из скопа вызывается деструктор
// от f, он сам себя чистит.
} catch (...) {
  ...
}

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

2 eugine_kosenko

>C-подобный FOR -- это вообще единственный необходимый тип цикла.

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

Так... А реальных цифр по скорости передачи данных между Windows-сервером и Windows-клиентом по 100-мегабитной сети я так и не дождусь, как я полагаю ? Что, никто прямо вот сейчас в Far-е каком-нибудь что-то качнуть не может и цифры показать ?

> ЛЮБУЮ программу можно написать при помощи 3- видов блоков:1) линейная последовательность; 2) цикл; 3) if.

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

Господа, я конечно понимаю, что спор про goto не будет закончен в этой дискуссии, и что он будет возникать снова и снова пока не вымрет последний программист, использующий этот аттавизм.Я, например, считаю, что этот оператор не настолько уж плох, чтобы от него полностью отказываться, но он так часто становился источником ошибок в программах, что в приличном обществе его РЕКОМЕНДУЮТ не употреблять. Кто-то считает, что goto это панацея от тормознутости программ или просто ленится и вместо того, чтобы пересмотреть и соптимизировать алгоритм, лепит goto направо и налево надеясь на качество компилятора. Но наличие goto в программе всегда настораживает. Доказательство - этот длинный флейм. Может проще перед тем как вставить этот дурацкий goto в программу подумать о том, как будет склонять ваше имя ваш коллега-эстет и чуть дольше поработать над алоритмом - глядишь и вместо экономии двух-трех машинных тактов - удастся сократить время выполнения программы вполовину ( что ж, и такое тоже бывает ). С другой стороны наличие goto в ядрах xBSD и Linux совсем не говорит о том, код в них плохой. Скорее это служит просто плохим примером для начинающих программистов.

ЗЫ: за время чтения этой увлекательной дискуссии совсем потерял нить обсуждения стеков TCP/IP, но само чтение доставило большоe удовольствие. Спасибо за представление!

2lb (*) (2003-02-17 14:28:11.499): "...цикл является частным случаем использования линейной последовательности и условного оператора...." Ну что же. Вот Вам условный оператор: if {...} else {...}; Вот линейная последовательность ...;...; Напишите при помощи них цикл.

2AS

Так... А реальных цифр по скорости передачи данных между Windows-сервером и Windows-клиентом по 100-мегабитной сети я так и не дождусь, как я полагаю ? Что, никто прямо вот сейчас в Far-е каком-нибудь что-то качнуть не может и цифры показать ?

Я в свое время мерял.

Win_serv - Samba 2.2.7а :)

FreeBSD 4.7 on em0 (1000/intel 100 Mb full-duplex mode)

cross-кабель хост-хост

Win_client

Wi2k server (100/intel pro 100Mb full-duplex mode)

5 * ~600 Mb iso-image

На клиенте вып. команду

xcopy n:*.iso nul: (n: - шара на самбе)

В среднем 6.5 - 7.2 Mb/s

Зы самба была из портов, без тюнинга

После игр с socket options, read size read raw в smb.conf

Удалось достичь ~ 8.2 Mb/s

Саныч

>зачем в попугаев? В пакеты в секунду ламо :)

Ну ты весельчак.... А в пакетах то что? :))))))

2 anonymous (*) (2003-02-17 15:26:37.316)

Что? Попугаи! :)

Мне тут обещали про "честные 100 мегабит" поподробнее рассказать. И что там насчёт методик тестирования? Считали коров, а получились слоны. :))))

2lb (*) (2003-02-17 14:28:11.499): "...цикл является частным случаем использования линейной последовательности и условного оператора...." Ну что же. Вот Вам условный оператор: if {...} else {...}; Вот линейная последовательность ...;...; Напишите при помощи них цикл.

function chtoto{} { ...; ...; if (...) then { chtoto() } else {exit (0);} }

Вот так-то ...

2anonymous (*) (2003-02-17 17:06:07.398): Небольшой вопрос: function и exit - это разновидность if или линейной последовательности?

to all : извиняюсь за жуткий оффтопик

to anonymous (*) (2003-02-16 22:03:09.531)

>Во-первых: у MS с этим проблем вообще ни когда не было

Microsoft Windows 2000 [Version 5.00.2195]-GER,+SP2-GER
VS 5.0-EN
Через визард создал Win32 console application
----------------------------------------------------------
#include <stdlib.h>
#include <stdio.h>

int main(void)
{
void *var1 = NULL, *var2 = NULL, *var3 = NULL;

if( ((var1 = malloc(1024)) != NULL) &&
((var2 = malloc(1024)) != NULL) &&
((var3 = malloc(1024)) != NULL) )
{
printf("memory allocated\n");
}

free(var3);
printf("var3\n");
free(var2);
printf("var2\n");
free(var1);
printf("var1\n");

return 0;
}
----------------------------------------------------------
C/C++ -> Project options :
/nologo /ML /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /Fp"Release/test.pch" /YX /Fo"Release/"
----------------------------------------------------------
Linker -> Project options :
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console
----------------------------------------------------------

Сносит VS 5.0 крышу нафиг после запуска :)

Первый MessageBox -> Попытка записи по адресу 0x00000000
Второй MessageBox -> Попытка чтения по адресу 0x00000004

Это глюк VS 5.0, а не проги ;-) В консоле вроде корректно
отрабатывает...

Исходник с тем приколом нашел, но там уже "соратники"
постарались,все на new/delete переписали. Глюк точно был,
вполне возможно что VS где-то взгюканул, глюков у него
уйма... :-E

windows98->wondows98 2.14 M/c john

2eugine_kosenko
> "Задачи, неразрешимые без goto, решаются с помощью рекурсии"
Ага. А молоко является явным признаком коровы. :)

>еще не повод унижать оппонента. Кто Вам сказал, что я мальчик?
Изините. "Мальчик" просто к слову пришлось. Сосвсем не хотел обидить.

>Да и стек не резиновый...
Эт точно. Но не кто и не собирался в лоб алгоритм реализовывать. Всегда можно промежуточные точки выхода из рекурсии предусмотреть. Варианов море, и доводы Ваши неубедительны. Да и задача сама нерешаемая на компьютере (в общем виде). В общем виде на компьютере ни чего не решается. Есть физический предел у любого оборудования. Это опьть же из кибернетики. Там очень забавные, на первый взгляд, теоремы и аксиомы. Зачастую противоречащие здравому смыслу. Напрмер: "Код любой программы можно сократить, как минимум, на одну команду", "Любая программа содержит, как минимум, одну ошибку" и т.д. :))) Рекомендую почитать. Очень интересная наука. Может на мир подругому смотреть будете. А на счет систем доказательства правильности программ, так их туча. Ссылку не дам, так-как в инете копаться лень. Но они есть. И этой технологии лет 25-30. Точно знаю что у IBM была. Видил еще на системе 370 (наш аналог ЕС ЭВМ). Помоему. под кобол заточенная. Не помню.

2anonymous (*) (2003-02-17 17:06:07.398): Небольшой вопрос: function и exit - это разновидность if или линейной последовательности?

Exit ожешь убрать вообще (это для красоты)

1 - 2 - 3 - 4 - 5 -

или 2 - 3 - 1 - 4 - 5 -

И то и другое линейные последовательности

2anonymous (*) (2003-02-17 18:30:48.36):А function? Да и txit скорее не для красоты, а для ошибки.

2anonymous (*) (2003-02-17 15:26:37.316): молоко бля! :) Блин, ну почему меня не удивляет тот факт, что красноглазые онанимусы не в курсе, что предельное кол-во пакетов, которое может пропустить через себя сетевой девайс (роутер, коммутатор, сервер и т.д.), весьма слабо зависит от размера пакета...:)

Irsi

> предельное кол-во пакетов, которое может пропустить > через себя сетевой девайс (роутер, коммутатор, > сервер и т.д.), весьма слабо зависит от размера > пакета...:)

1. подумай, что сказал. Подсказка: есть еще такая вещь, как пропускная способность интерфейса.

2. подумай, о чем говорил тот анонимус. А имел ввиду он именно то, что имел - сколько пакетов в секунду способен обработать стек. О скорости речь вовсе не шла. Попробуй пофлудить систему с Win и поводить в это время мышкой по десктопу. Потом попробуй сделать то же с Linux / BSD / OS/2 /etc

Версию Win не называю - не знаю, как поведут себя NT 2000 и XP.

3. Будь спокойнее, и люди к тебе потянутсяю :-)

to anonymous (*) (2003-02-17 13:58:16.667) :

> Да ну?

Ага. Я про замену goto для отчистки говорил

>Итак, в С++ вместо костыля finally (он рассматривался, кстати),
>решение гораздо проще и лучше.

В java стоящий в finally код будет вызываться ВСЕГДА, даже если
стоит return в try блоке. В C++ при catch(....) этого не происходит.

#include <iostream>
#include <fstream>

using namespace std;

int main (void) {

ifstream f;

try {

f.open ("somefile.one");

cout << "try{}\n";

if (!f.is_open())
{
cerr << "ERROR\n";
return 1;
}
}
catch(...)
{
cout<<"catch{}\n";
}

return 0;
}

>break и continue не совсем аналоги goto (можешь так и написать
>Экелю ;) так как их область действия ограничина :)
Ок, при случае передам. :)

>Если говорить о жабе то для этих целей правильно
>использовать блок

>Если одни и теже ресурсы то завернуть в функции захвата
>и распределения ресурса и засунуть в отдельный модуль,
>вызывать по надобности.Ненадо забывать что на C так же можно
>писать в OO стиле ;)
Ага, я и не говорил, что goto необходим. Я говорил, что он иногда удобнее. Можно завернуть все в С в функции захвата, но это будет неоптимально по производительности.
А вот еще при реализации конечных автоматов можно воспользоваться хрестоматийным case, но goto добавит производительности.
Одним словом, goto можно использовать в экстримальных случаях, когда что-то хочется оттюнинговать до последнего. :)
И иногда он читабельнее. :)

2MrBool:

> Microsoft Windows 2000 [Version 5.00.2195]-GER,+SP2-GER VS 5.0-EN Через визард создал Win32 console application

Ну немецкого виндовса у меня нет, но на англиском с vs5.0 что в отладчике, что в консоле ни каких проблем. Что опять MrBool прогнал? Или не думал, что еще у кого-то VS5.0 сохранился?

Да кстати, та ошибка что ты написал, даже если и возникает, то это проблема в IDE связанная с чем-то другим, а не освобождением памяти, потому как 3кб я думаю тебе там все-таки выделили. Так что утверждение, что у VS с free(NULL) у MS ни когда не было, так и остается в силе.

2AS:
1. ну разумеется общий поток данных меньше пропускной способности интерфейса... Эээх, лень графики рисовать и куданибуть выкладывать - проще бы было объяснить...:)
2. Блин, а я что имел ввиду по-твоему? :) Еще раз вернись к той статье на iXBT и переделай графики с мегабайтов на пакеты...:)
Не знаю как себя ведут 9х - NT based ведут себя ничем не хуже фрюниксов.

>В java стоящий в finally код будет вызываться ВСЕГДА, даже если
>стоит return в try блоке. В C++ при catch(....) этого не происходит.

:- [ ]
Т.е. как это? No comments.
Деструкторы, оказывается, не вызываются при выходе из scope :-)))))))
Просто офигительно. Не знал, что есть стандарт С++ от Mr. Bool :-)))

Повторяю для танкистов:

В С++ очистка возложена на сам объект (деструктор) вместо кода, который этот объект использует.
И это правильно.

Поправка:

" на сам объект (деструктор)" следует читать "на сам объект (через деструктор) "

Раз уж пошла мода постить исходники:

#include <stdio.h>
#include <iostream>
using namespace std;

class A {
  char *n;
  FILE *fp;
public:
   A (char *name) : n(name), fp(0) { 
       cout << n << " ctor" << endl;
   	   fp = fopen (n, "rb"); if (!fp) throw "No file"; 
   }
   ~A () { cout << n << " dtor" << endl; fclose(fp); }
};

int main ()
{
   try {
       A a ("test.cpp"), b("test.o");
   } catch (const char *e) {
      cout << "catched exception: " << e <<endl;
   }
}

Рассказать, что будет, если, например, 'test.o' не существует?

>Еще раз вернись к той статье на iXBT и переделай графики с
>мегабайтов на пакеты...:)

2Irsi: Упрямость, тебя когда-нибудь погубит... Ты вдумайся в свои
слова несколько раз подряд, может допрешь своими тупыми
мозгишками, что считать пакеты со скорости просто мудацкое
занятие, ты уверен в том, что небыло потерь пакетов или ты
все идиализируешь без учета трансфера в драйверах, возможности
самой железки, потерь пакетов, хуевости сетевого оборудования и линий? Бля, и после этого ты говоришь, что ты работал в провайдерской конторе? Да тебя сети строить на пушечный выстрел подпускать нельзя,
просто даже незнаю, кто за тобой потом твои расчеты расхлебывал....

> Чтоб правильно задать вопрос надо знать большую часть ответа,
> однако...:)

Верно! И я эту половину знаю. А вот многие не знают, и пойдет гулять по сети очередной миф о "правильности" ядра QNX.

> Слушай, ну почитай классиков, а уж потом спорь на програмисткие темы,
> а? ;)

Дык, читал я, читал! Может, не все? Ну так поделитесь тайным знанием: что у Дийкстры есть такого, что стоит почитать, и при этом сразу откроется истина?

BTW, мы с Вами на брудершафт не пили.

> "Любая программа содержит, как минимум, одну ошибку" и т.д. :))) > Рекомендую почитать.

Угу. Уже прочел. Лет 10 назад. Там, кстати, было интересное следствие -- "Все программы бесконечны" ;-)

А еще можно вспомнить принцип Донды: "Маленькая программа на большом компьютере эквивалентна большой программе на маленьком компьютере. Следствие 1: бесконечно большая программа может работать вообще без компьютера. Следствие 2: информация имеет массу" (C) С. Лем

;-))

> Может на мир подругому смотреть будете

"Не учите меня жить! Лучше помогите материально...". Слушайте, Вы миссионером не пробовали подрабатывать? ;-)

> И этой технологии лет 25-30

И Вы будете смеяться, но я именно в этой области и специализируюсь! Чтобы не быть голословным:

> А на счет систем доказательства правильности программ, так их туча

Ближе всего к программам подошел Spin, но и тот имеет характеристику "деградация решения". Могу еще упомянуть PVS и HOL, но это абстрактно-облачные системы. Остальные так или иначе заточены под языки моделирования аппаратуры -- SMV, COSPAN, С@S, Step...

> Точно знаю что у IBM была

Угу. И именно поэтому они только сейчас начали толкать Sugar? Который вообще-то, тоже под аппаратуру заточен. Да и о том, что OS/2 или AIX (про OS/360 молчу, потому как, в отличие от Вас надеюсь, что Вы классиков читали) были верифицированы супер-пупер-точной ситемы доказательства правильности (чего?). Видно, далеко не все так хорошо в королевстве датском.

Ну что, хватит пиписьками меряться?

Прежде, чем я продолжу, предлагаю договориться:

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

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

Я, например, уже трижды поменял свои взгляды на goto, и не исключено, что я поменяю их в четвертый раз. Пока что меня отсылают к литературе моей далекой юности, когда я только освоил структурное программирование, перескочив с Бейсика на Паскаль. Тогда я был полон восторженного оптимизма и считал, что любую программу можно написать без goto, а факториал непременно нужно реализовывать как рекурсивную функцию. Пример, который я предложил, взят из моего конспекта, который я вел во время сборов юных программистов. Тогда меня поразило, что не все в жизни так здорово, как пишется в учебниках, но я по-прежнему считал, что такого рода примеры -- скорее экзотика, досадное исключение. Статья Калинина заставила меня немного по другому взглянуть на goto, особенно, в свете низкоуровневости языка C.

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

Вот пример реализации алгоритма декартового произведения множеств:

for i in 1..n
	j[i] := 1
end for

print_tuple:

print(j)
k := n
repeat
	j[k] := j[k] + 1
	if j[k] <= N[k]
		goto print_tuple
	end if
	j[k] := 1
	k := k - 1
until k = 0

Обратите внимание, что из трех возможных вариантов реализации алгоритма (рекурсия пока не в счет) я выбрал именно этот. Контрольный вопрос: почему был именно этот вариант?

Подсказка: кроме "чистого" структурного программирования существует еще "псевдоструктурное", в котором goto таки разрешено, но на него наложены очень жесткие ограничения.

Рекурсивное решение, на первый взгляд, кажется простым, но у меня нет времени довести его до ума. Кто возьмется?

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

А идея с рекурсией оказалась очень плодотворной!

Доказано, что всякая простая (хвостовая) рекурсия эквивалентна итеративному решению. На этом основаны отдельные виды оптимизации кода.

Однако, кроме простой существует еще сложная рекурсия, которая принципиально не сводится к итеративным решениям, чем она и живет. Но!.. Можно выдвинуть следующую гипотезу:

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

Кто возьмется это доказать? Или это уже доказано?

Если эта гипотеза справедлива, то из нее следует один интересный момент. Пожалуй, самым весомым аргументом против goto является то, что он создает множество точек выхода из конструкции, и тем самым становится невозможным вычисление слабейших предусловий (по Дийкстре). Однако, в таком случае можно говорить о том, что сложная рекурсия также неверифицируема по Дийкстре! Значит ли это, что сложную рекурсию нужно предать анафеме и запретить ее использование в программировании?

Кстати, тот, кто пробовал отлаживать рекурсию (даже простую!) обычными отладчиками, сразу скажет, что рекурсия не более удобоварима, чем goto. Хотя бы потому, что поставить нормальные точки прерываний просто невозможно.

А теперь вернемся к основной теме. Мы имеем задачу, которую можно решить двумя способами:

1) циклами с goto; 2) рекурсией

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

К чему это я? А к тому, что, похоже, стек TCP/IP -- это, в каком-то роде, реальный аналог нашей простенькой задачи. В таком случае можно предположить, что реализация BSD построена на циклах с goto, а Linux-реализация -- на рекурсии.

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

С другой стороны, я подозреваю, что в названии этой задачи недаром упомянуто слово "стек" -- основной признак рекурсии. Поэтому, скорее всего, в BSD-реализации стек все-равно присутствует, только реализован явно. Конечно, это не так красиво, как в Linux-реализации, и дефектов, мобыть, поболее (чиста субж!), но зато наверняка намного эффективнее. А при достаточной глубине (а какова типичная глубина этого стека?) -- решающим образом.

Замечу сразу же, что изложенное в двух предыдущих абзацах -- всего лишь ПРЕДПОЛОЖЕНИЕ. Я НЕЗНАКОМ ни с одной из этих реализаций. А теперь кто попробует мне ответить, НЕ ХАМЯ -- я угадал?

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

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

Достаточно сказать, что система построения трансляторов Lex/Yacc использует итеративную реализацию, а PCCTS -- рекурсивную. Я думаю, не стоит рассказывать, какая из них более популярна и почему?

Да, а вот то, что Lex/Yacc прячет goto за специализированным кодогенератором -- это хорошая идея. В принципе, можно было бы создать язык высокого уровня ждя описания протоколов, а затем генерить эффективный, но нечитабельный код. Более того, такой язык уже есть, и не один. Могу вспомнить, как минимум, PROMELA. Кстати, там, по-моему, тоже нет goto. Но... Это решение выгодно, если бы нам было необходимо клепать сотни и тысячи реализаций TCP/IP. Вопрос в том, нужно ли нам это?

Следствие 3 /* offtopic */

2 eugine_kosenko:

Следствие 3: бесконечно большой компьютер может работать вообще без программ.

to anonymous (*) (2003-02-17 21:16:28.157) :

>Ну немецкого виндовса у меня нет, но на англиском с
>vs5.0 что в отладчике, что в консоле ни каких проблем.

Поздравляю :)

>Что опять MrBool прогнал?

Да нет, есть подозрение что VS в тот раз прогнал.

>Или не думал, что еще у кого-то VS5.0 сохранился?

Ты гонишь :)

>Да кстати, та ошибка что ты написал, даже если и возникает,
>то это проблема в IDE связанная с чем-то другим, а не
>освобождением памяти,

Хз, все рушится после return, VS дебагить желания нет :)

>потому как 3кб я думаю тебе там все-таки выделили.

Ты читать умеешь ? Я же ясно сказал что в консоле отрабатывает.

>Так что утверждение, что у VS с free(NULL) у MS ни когда
>не было, так и остается в силе.

Будешь утверждать что VS 5.0 всегда прямой код генерит ? :)))

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

    // print_tuple:
    do {
        // print(j)
        printf("%d\n", j);
        // k := n
        k = n;
        // repeat
        do {
        // j[k] := j[k] + 1
        j[k] += 1;
        // if j[k] <= N[k]
        if (j[k] <= N[k]) {
            // goto __PRINT_TUPLE
            break;
        // end if
        }
        // j[k] := 1
        j[k] = 1;
        // k := k - 1
        k--;
        // until k = 0
        } while ( k == 0 );
        // __PRINT_TUPLE:
        // goto print_tuple
    } while ( k == 0 );

to anonymous (*) (2003-02-17 21:54:57.188) :

>:- [ ]
>Т.е. как это? No comments.

А так это, самым натуральным образом :) Челюсть подбери.

>Деструкторы, оказывается, не вызываются при выходе из scope
>:-)))))))

Ты есче скажи что деструкторы всегда вызываются "при выходе из scope" :)))

>Просто офигительно. Не знал, что есть стандарт С++ от
>Mr. Bool :-)))

По моему мы говорим о разных вещах.

"Повторяю для танкистов:"

finally в JAVA вызывается всегда по завершении.
В стандартном C++ аналога нет, поэтому некоторые особо
хитрые через goto умудряются. Кстати, C++ это не всегда
классы и OOP - это на случай если ты не знал :)

>В С++ очистка возложена на сам объект (деструктор) вместо
>кода, который этот объект использует.
>И это правильно.

Да ради бога. Только это работает до тех пор пока объект не
был создан динамически.

> А так это, самым натуральным образом :) Ну-ка нука, поподробнее. > Ты есче скажи что деструкторы всегда вызываются "при выходе из scope" :))) Ну-ну. Продолжаем бредить, да? > По моему мы говорим о разных вещах. Я говорю о том, что finally нах не нужен и является костылем. О чем говорите вы, это вам виднее. По-моему вы бредите. > Кстати, C++ это не всегда классы и OOP - это на случай если ты не знал :) Ну дык может просветите? А то пиздить-то не мешки ворочать. >>И это правильно. >Да ради бога. Только это работает до тех пор пока объект не был создан динамически. Ваши знания С++ на динамических объектах заканчиваются? Про smart-pointerы таки слышали?

> А так это, самым натуральным образом :)

Ну-ка нука, поподробнее.

> Ты есче скажи что деструкторы всегда вызываются "при выходе из scope" :)))

Ну-ну. Продолжаем бредить, да?

> По моему мы говорим о разных вещах.

Я говорю о том, что finally нах не нужен и является костылем.
О чем говорите вы, это вам виднее. По-моему вы бредите.

> Кстати, C++ это не всегда классы и OOP - это на случай если ты не знал :)

Ну дык может просветите? А то пиздить-то не мешки ворочать.

>>И это правильно.
>Да ради бога. Только это работает до тех пор пока объект не был создан динамически.

Ваши знания С++ на динамических объектах заканчиваются?
Про smart-pointerы таки слышали?

2nst ай молодца ;)

2eugine_kosenko
Прочитали прогу-с?
А вы еще на Дейкстру ругались, мол устарел он. А сами кодите в стиле до-дейкстровской эпохи. Так на фортране 4, фортране 77, бейсике писали.
Так и скажите, я просто привык/приучен думать и писать в фортрановском стиле и через goto.

2 eugine_kosenko (*) (2003-02-17 23:44:34.18)
2 nst (*) (2003-02-18 01:01:15.643)

Еще одна вариация алгоритма без goto:

main()
{
   int i, k;

   for(i = 1; i < n; i++) j[i] = 1;

   print(j);
   k = n;
   while(1) {
       j[k]++;
       if(j[k] > N[k]) {
           j[k] = 1;
           k--;
           if(k == 0) break;
       }
       else {
           print(j);
           k = n;
       }
   }
}

Предвижу нарекания:
У nst лишняя проверка, у меня дублирование. Но, за то без goto. :)
Да, согласен - с goto эффективней.

Мне бы тоже хотелось бы услышать мнение знатоков, по поводу
общего метода доказательства программы на правильность.
Ну, скажем:
int *a = malloc(10*sizeof(int)); a[5] = 1;
доказуемо, что правильно? Если да, то как надо объяснить
автоматическому доказывателю, что делает функция malloc?
Думаю анализ исходников данной функции (в рамках доказательства)
может только усугубить ситуацию.
(Если я что-то не так понимаю, то хотелось бы услышать, как понимаете
вы, что тоже будет интересно)

GOTO

Интересно, а интерпретатор языка, в котором предусмотрено GOTO может обойтись без GOTO ?

IMHO доказать правильность алгоритма можно только приведя его к виду конечного автомата. Например для qnx'а эта задача мне представляется скучноватой.

2Бул:

Скажем, не при завершении, а когда-нибудь. И, по-моему, в яве можно заблокировать вызов finalyze... Хотя не уверен

2 eugine_kosenko

>Оно у меня в блок-схемах, его еще закодировать нужно...
Вот оно! Вот от куда goto появляется! из блок-схем. Порочная система проектирования.