Здравствуйте m.a.g., Вы писали:

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

P>>ЗЗЫж Вот я и говорю, после ваших ответов у меня складывается впечатление, что все ето замечательное "граммотное структурное программирование" нужно людям дабы править баги после релиза. А не проще то время, которое нужно чтобы каждый чих обернуть в "объектную обертку" (sorry за тафтологию), пытаться вместо одного goto городить кучу if'ов\флагов\и т.д. потратить на то чтбы просто нормально написать\отладить.

...>А если произнести магические слова "изменение требований заказчиком"? Структурный (тем более ОО) код подстраивается под новые требования значительно быстрее монолитного.

С _этим_ никто не спорит. Как говориться, знал бы где упасть...

И нужно не забывать и то, что граммотно разработанный прект и "граммотное структурное программирование", рассчитываемые на эти самые "магические слова" требуют много больше времени\сил\средств.
И в случаях подобных этому (повторюсь, мы говорим о "девушке в железно ящичке") я предпочту пару goto, чем пытаться "структурировать" алгоритм, по методу Vlad'а.

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

W>Ау знатоки программирования :wow: может вы другие темы смотреть будете и помогать желающим, а
W>вы обсасываете старую избитую тему (вчем прикол — поговорить, для этого chat существует).
W>Я смотру если появляется хороший вопрос — ответов или 0 или <10 .

А можно хотя бы пару примеров "хороших" по твоему мнению вопросов?
Которые интересны не только самим спрашивающим?

W>Зато на такие темы вы кидаетсесь
W>как голодные ... (извеняюсь вырвалось). И необежайтесь если я неправ. Мне здесь тоже помогали.
W>Но активность — только из-за таких тем. :user:

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

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

W>>Ау знатоки программирования может вы другие темы смотреть будете и помогать желающим, а
W>>вы обсасываете старую избитую тему (вчем прикол — поговорить, для этого chat существует).
W>>Я смотру если появляется хороший вопрос — ответов или 0 или <10 .

DG>А можно хотя бы пару примеров "хороших" по твоему мнению вопросов?
DG>Которые интересны не только самим спрашивающим?

W>>Зато на такие темы вы кидаетсесь
W>>как голодные ... (извеняюсь вырвалось). И необежайтесь если я неправ. Мне здесь тоже помогали.
W>>Но активность — только из-за таких тем.

Каюсь я это все созлости написал. (уменя проблема с отображением курсора, а ответа в
Delphi & Builder — стоящего нет). Извените если кто обиделся.

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

P>Пардон, вмешаюсь...

Ничего... ничего...

P>Странные у тебя аргументы. То ты говоришь о некоем абстрактном горе-программисте, которому ни в коем случае нельзя давать в руки страшное оружие goto. И тут же приводишь в пример себя любимого, дескать "я никогда не перепутаю порядок освобождения ресурсов, если он важен" и далее по тексту. А что мешает этому абстрактному программисту перепутаь?

Ты бы почитал внимательнее о чём речь, что-ли

P>И еще, касательно 3-го пункта "аргументов": А ежели этот самый ресурс, который ты будешь открывать и закрывать в каждой итерации сильно долго открывается\закрывается?

А если сильно быстро?

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

GS>Автоматизация программирования для предметной области. Мне такое не интересно. Хотя коммерчески может быть весьма успешным: САПР Бухгалтерия! САПР Отчеты по бухгалтерии! САПР Отчеты в налоговую! САПР Левая бухгалтерия! САПР Кадры! САПР Крупный банк! САПР Мелкий банк! и т.д. и т.п., и за все бабки.

GS>И куда только вся эта тьма наглюканых бухгалтерий потом деваться будет?

Не... я под предметной областью понимаю: управление предпиятем, статистика. Видишь как сегодня разрабатываются игры? Обычно пишется энжин и редактор. Причем редактор является CASE-средством. Но не убогим вроде Розы, а способным выдовать конечные продукты. Вот хочется нечто подобное только для других областей. Конечно здорово было бы создать универсальный энжин и унивесальный редактор, но пока я реальных путей решения этой проблемы не вижу.

Здравствуйте m.a.g., Вы писали:

P>>ЗЫж Не флейма окаянного ради, может я и правда чего не знаю/понимаю?

...>Для детального анализа нужна мат. логика и обобщенная теория моделей вкупе с теорией категорий.

Новая струя в споре.

Здравствуйте m.a.g., Вы писали:

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

VD>>Повторюь еще раз. goto не структурированный оператор. И его ипользование вност хаотичность в код.

...>Про схемы Янова слышал? Посмотри — потом будешь говорить насчет неструктурированности. Все зависит от контекста.

Нет. Не слыхал. А они помогут мне при чтении кода утыконого безсмысленными goto?

VD>>У нас в конторе написано ~ 300 000 рабочего кода (не считая кода к статьям) на C++ и goto не разу не применялся. Один программист как то раз начал отстаивать точку зрения "что в его случае лучше применить goto" и рьяно так... но когда мы переписали его код, он и сам согласился, что так элегантнее, понятее и безопаснее.

...>Единственное условие применения структурных конструкций — "правило отсутствия неожиданностей".

Именно. У программисто вообще должно быть правило "не удивляй!".

...>Если применение goto удовлетворяет этому принципу — оно и элегантно, и понятно, и безопасно.

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

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

Получается, что разумным использованиме этого оператора остается только выход из глубоко вложенного цикла. Да и то в 90% случаев можно найти более элегантный способ.

А теперь о тенденциях. goto вреден тем что он сидит в мозгах у программиста. Это как наркотик. Даже если ты не хочешь его использовать но зарылся в ситуацию которая кажется безвыходной (на замыленный взгляд), человека так и подмывает использовать этот оператор. И о твоем принципе он незадумывается. Он просто говорит: а... проподи все проподом и лепит горбатого. Ну, а потом, чтобы оправдаться начинает рассуждать о том, что и на goto можно создавать структурированную логику. Конечно можно, но зачем эмулировать имеющиеся конструукции на goto?

Замечательным примером неоправданного использования goto является открытого 80% кода MS используещего этот самый оператор. Ихним программистам или просто в лом подумать. Или вообще на все плевать с большой вышки. В ATL есть три места где использован этот оператор. Одно из них является явным переносом унаследованного кода. Второе ленью (сделать один раз обертку для ресурса, вместо того чтобы писать гору goto и вручную освобождать ресурсы). Ну, а третье — это собственно не совем и ATL. Это шаблоны OLEDB. Там такое ламерство и нарушений всех принципов безопастного и культурного программирования, что волосы дыбом встают. Процедуры на 500 строк кода все испещьренные goto. Вот именно этого и не хочется встречать. И если человек стремится избежать применения goto (но разумно, не перегибая палку), то это не сомненно плюс. А рассуждения о том, что и на goto можно... приводят к тому, что когда нужно делать выбор между читабельностью и более простым решением проблемы, эти рассуждения будт подмывать программиста сделать неверный выбор. Именно так и пояыляется весь writeonly-код.

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

P>Странные у тебя аргументы. То ты говоришь о некоем абстрактном горе-программисте, которому ни в коем случае нельзя давать в руки страшное оружие goto. И тут же приводишь в пример себя любимого, дескать "я никогда не перепутаю порядок освобождения ресурсов, если он важен" и далее по тексту. А что мешает этому абстрактному программисту перепутаь?

Перепутать одинаково легко как с if-ами, так и с goto. Для освобождения ресурсов в С++ есть замечательное решение: создавать классы-обертки. Используя их ничего не перепутаешь.

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

P>Похоже суть ты так и не понял. Ежели было все так просто, ни о каком goto в данном случае речи бы не было.

Заметь. Суть уже непоняли двое. Причем это ты заметил, что двое. На самом деле 80% не поняли. Или не поняли с первого раза. Вот именно в этом и состоит проблема goto.

P>А комментарий в ключевой строке гласит "Юзер попытался исправить ошибку, надо проверить заново". Дальше продолжать?

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

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

VD>>Ну, а как ошибочка в тоем замечательном монолите? А ты ркутой goto-шник на goto-зил и свалил в другую контору. Что делать тем беднягам которым приказано исправить ошибку и выложить в Inet патч?

P>Какой такой Inet в городе Мухосранске? Мсье не допонял исходную посылку. И какая такая ошибка, если монолдит замечательный?

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

P>Ежели в моем "замечательном монолите" будет критическая ошибка меня и так уволят

А толку, то? Исправить то твой монлит уже никто не сможет.

P>И не только меня. А если на этапе эксплуатации обнаружится не критическая ошибка, то баги перековываются в фичи

Вот именно так (судя по коду) думают многие программеры из MS. И именно из-за такого отношения в ворде вот уже 4 версии подряд сидят один и теже глюки.

Приятно только одно... Так хамить могут только очень богатые контры. Маленьким это грозит разорением. Вот Гупта не смогла вовремя переписать энжин своего SQLBase и нету боьше гупты.

P>ЗЫж Что будут делать те "бедняги" меня нисколько не волнует, ибо в человеколюбии замечен не был. Да и самому не раз приходилось оказываться в такой ситуации. Хотя все зависит от ситуации.

Ну, кичись, кичись. По крайней мере когда в следующий раз попадешь в эту шкуру, будешь вспоминать.

P>ЗЗЫж Вот я и говорю, после ваших ответов у меня складывается впечатление, что все ето замечательное "граммотное структурное программирование" нужно людям дабы править баги после релиза.

Да. И для этого тоже. Потому, что ни твои, ни мои, не MS-ные, ни чьи другие коды без ошибок не бывают (если это не ХаляваВолд). И порой пролежают и критичные, или не критичные, но сильно действующие на нервы.

Я вот все время пользовался ERWin-ом, но теперь видимо больше не буду. Количесвто глюков в 4-й версии меня в этом убедила.

P>А не проще то время, которое нужно чтобы каждый чих обернуть в "объектную обертку" (sorry за тафтологию), пытаться вместо одного goto городить кучу if'ов\флагов\и т.д. потратить на то чтбы просто нормально написать\отладить.

Если было проще, то IT и я сдесь не матерились бы. Он тебе уже сказал, что именно такой подход как ты описываешь тормозит развитие этого сайта. Да и вранье это, что создание оберток замедляет процесс разработки. В программе 10-15 типов ресурсов которые нужно контролировать. Для 70% обертки уже есть. Так что из года ты убьешь на это занятие две недели. Зато потом, тебе не придется убивать кучу времени на встраивания такого же кода после меток от goto и отлаживать каждое такое место. Не придется так же и следить за последовотельностю освобождения этих ресурсов.

Насколько я в курсе (давно это было, отошёл от теории), есть положение, согласно которому любую программу можно написать без goto.

Я приведу аналогию этому положению из Тории Логики: точно так же как любое сложности логическое выражение можно записать с помощью двух операций — И и НЕ (или ИЛИ и НЕ), не применяя любых других. Невзирая на то, что получившаяся сложность выражения может увеличиться или может уменьшиться. Это, наверное, известный факт.

Так же и с goto. Переходы могут быть заменены на if (переход вниз) или cycle (переход вверх). Я не знаю точно для чего такая замена была обоснована, но то что она вызвала фурор на ровном месте — очевидно. Но, в точности с предыдущей аналогией, сложность программы может увеличиться или уменьшиться.

Однако, мало кто, защищая goto, защищает логические манипуляции — каждый пишет логические выражения согласно пониманию и по возможности короче, а не отстаивая принцип 2 операций.

Лично для меня проблема goto такова: goto — это оператор языка. Не больше и не меньше.

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

Но для программ-модулей в долгосрочном использовании у меня отношение иное, наверное, действительно как отголосок из Фортрановского прошлого. Если мне нужно вставить этот оператор в действующий код, исходя из обстоятельств (например, нужно сделать сегодня), я вставляю его, НО это звоночек в сторону того, что этот кусок программы пришёл в несоответствие с требованиями (перерос их), которые накладывались на него изначально при проектировании его, и, следовательно, должен быть пересмотрен в самое ближайшее время. И не в коем случае нем может быть рассмотрен как идеальный вариант, как "так и должно быть". Невзирая на то, как смотрится этот код — идеально или нет. Потому что в нем что-то "не так", следующие изменения могут быть не такими простыми и т.д. и т.п. Однако при перепроектировании этого места goto могут быть и оставлены (или добавлены). Вот такое сложное отношение к нему.

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

VD>Не... я под предметной областью понимаю: управление предпиятем, статистика. Видишь как сегодня разрабатываются игры? Обычно пишется энжин и редактор. Причем редактор является CASE-средством.

Не является. Поскольку не поддерживает методик SE. Кодогенератором — да является.

VD>Но не убогим вроде Розы, а способным выдовать конечные продукты.

"Но не убогим вроде редактора уровней, а способным поддерживать методики проектирования".

VD>Вот хочется нечто подобное только для других областей. Конечно здорово было бы создать универсальный энжин и унивесальный редактор, но пока я реальных путей решения этой проблемы не вижу.

Самое универсальное, что есть — операционные системы, компонентые модели и ЯВУ. Во что-то другое типа универсального движка/редактора я не верю, даже для управления предприятием и/или игр. Для полноты хотелось бы добавить, что не верю и в неуниверсальные энжины/редакторы, но это будет уже перебор.

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

VD>>

S>   код поскипан.
VD>>

S>Ну про такой код что говорить — типичный пример сишного стиля в С++ коде. Либо писал человек, которого Страус так и не убедил, что С++ — савсэм другой язык, нежели С, либо это легаси и переписывать некогда/незачем было.

Это реальный код поставляемый MS. У них есть круче на порядки. Я тут тоже приводил... Вот он ДИКО глчит и по сравнению с ним этот просто идеален.

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

S>А у нас в конторе оптимизатор запрещен, как у некоторых goto . А без нагромождения циклов иногда не обойдешся.

Ну, это это уже явно тяжелое детство вашего начальства. А нагромаждение циклов... Мы как то обходится.

S>А исключения

Мы пишим на ATL. С ATL_MINCRT, так что исключения для нас исключены.

S>(для того же STL нужны, кстати)?

Для некоторых реализаций не нужны. К тому же привязка исключений к CRT — это проблемы конкретной версии компилятора. Ну, и есть разные минимальные сабсеты CRT. У нас на сайте есть статья о том как жить без CRT. Там и про ток как STL использовать без исключений сказано.

S>А конструкция/деструкция глобальных объектов (я слышал, в семерке для это рантайм не нужен, но у меня )?

В VC7 эта проблема решена. К тому же можно жить как жили до недавнего времени мы. Есть один объект без деструктора и конструктора. Все что должно быть глобально кладем в него... Создаем его в хипе и вручную вызваем коструктор и деструтора.

S>Строки/локали STLные тоже за собой рантайм тянут. А плавающая точка? К четырем прибавть два, конечно, и без CRT можно, но вот чтоб юзеру результат показать — уже хотя бы printf нужен.

Без строк придется пережить. printf в GUI-приложениях не нужен (да и есть реализации MinCRT котрые дают его реализации). Ну, а sprintf реализован в Win32 API.

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

S>>Ну про такой код что говорить — типичный пример сишного стиля в С++ коде. Либо писал человек, которого Страус так и не убедил, что С++ — савсэм другой язык, нежели С, либо это легаси и переписывать некогда/незачем было.

VD>Это реальный код поставляемый MS. У них есть круче на порядки. Я тут тоже приводил... Вот он ДИКО глчит и по сравнению с ним этот просто идеален.

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

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

S>>А у нас в конторе оптимизатор запрещен, как у некоторых goto :). А без нагромождения циклов иногда не обойдешся.

VD>Ну, это это уже явно тяжелое детство вашего начальства. :) А нагромаждение циклов... Мы как то обходится. :shuffle:

Задачи разные, я думаю.

S>>А исключения

VD>Мы пишим на ATL. С ATL_MINCRT, так что исключения для нас исключены. :)

S>>(для того же STL нужны, кстати)?

VD>Для некоторых реализаций не нужны. К тому же привязка исключений к CRT — это проблемы конкретной версии компилятора. Ну, и есть разные минимальные сабсеты CRT. У нас на сайте есть статья о том как жить без CRT. Там и про ток как STL использовать без исключений сказано.

Значит, по пунктам:

1) STL без исключений — не STL. Просто потому, что vector<T>::at обязан кидать out_of_range при выходе за границы.
2) Привязка исключений к CRT действительно зависит конкретной версии компилятора. У меня версия вполне конкретная :) Да и ценность реализации исключений С++ (не SEH) вне CRT довольна сомнительна — примерно как CRT статически линковать. (возможно, тут я ошибаюсь).
3) Статью читал. Только вот про самое интересное там не написано (детально про fp, например). Очевидно, потому что нафиг это никому не надо — трахаться с плавающей точкой без CRT.
4) Ну, про STL без исключений я уже высказался.
Вообще-то, я пару программок без CRT писал, но только там, где это реально было надо. Но это все был равно не С++ :)

S>>А конструкция/деструкция глобальных объектов (я слышал, в семерке для это рантайм не нужен, но у меня )?

VD>В VC7 эта проблема решена. К тому же можно жить как жили до недавнего времени мы. Есть один объект без деструктора и конструктора. Все что должно быть глобально кладем в него... Создаем его в хипе и вручную вызваем коструктор и деструтора.

Вот я и говорю — это не С++. Хотя подобным образом извращаться, конечно, иногда приходится.

S>>Строки/локали STLные тоже за собой рантайм тянут. А плавающая точка? К четырем прибавть два, конечно, и без CRT можно, но вот чтоб юзеру результат показать — уже хотя бы printf нужен.

VD>Без строк придется пережить. printf в GUI-приложениях не нужен (да и есть реализации MinCRT котрые дают его реализации). Ну, а sprintf реализован в Win32 API.

Я sprintf и имел в виду. А реализация wsprintf, wvsprintf и вообще любого форматирующего вывода в WinAPI не поддерживает плавающую точку (что, впрочем, не удивительно).

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

P>Я — за :super:

Создавай голосование, посмотрим результаты.

IT>>Ты говоришь как типичный одиночка...

P>Может быть. Скорее даже так и есть...

Всё понятно, дальше можно не объяснять. Частенько у одиночек вырабатывается комплекс "Первый парень на деревне". Симптомы просматриваются. Просто один маленький совет, когда будешь менять работу помни, что кое-кто может не захотеть подстраиваться под твои взгляды.

P>ЗЗЫж У нас был один менеджер, который пытался уволить одного как ты выразился одиночку (не меня), дело закончилось тем что выгнали менеджера. И, имхо, это правильно.

Раз выгнали, значит был плохой менеджер, вот и всё. Никакой связи с использованием goto я тут не вижу ;)

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

VD>>Не... я под предметной областью понимаю: управление предпиятем, статистика. Видишь как сегодня разрабатываются игры? Обычно пишется энжин и редактор. Причем редактор является CASE-средством.

GS>Не является. Поскольку не поддерживает методик SE.

Вот тебе цитата из Лингво:

CASE  
сокр. от computer-aided software engineering  
автоматизированное проектирование и создание программ

Так как игра это программа, а редактор позволяет ее создавать, то значит является.

GS>Кодогенератором — да является.

А вот кодогенератором не обязательно. Хотя что называть кодом...

GS>"Но не убогим вроде редактора уровней, а способным поддерживать методики проектирования".

А мне проектирование ради проектирования не нужно. Мне результат нужен.

Вот редактор уровней со своей задачей справляется. Может не на пятерку, но все же. Без него игры были бы приметинее и убогее (как 10 лет назад). А проектирование и сегодня вручную делатся с той же эффективностью, что на Розе. Только меньше геммороя.


VD>>Вот хочется нечто подобное только для других областей. Конечно здорово было бы создать универсальный энжин и унивесальный редактор, но пока я реальных путей решения этой проблемы не вижу.

GS>Самое универсальное, что есть — операционные системы, компонентые модели и ЯВУ. Во что-то другое типа универсального движка/редактора я не верю, даже для управления предприятием и/или игр. Для полноты хотелось бы добавить, что не верю и в неуниверсальные энжины/редакторы, но это будет уже перебор.

Что в них верить, то? Поставь себе Кваку или Старкрафт и убедись. Они универсальны для своей области.

А в Яву я не верю. Это всего лишь еще один язык программирования. Переносимость мне не нужна...

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

S>Не, не надо путать причину со следствием. Тут не готу у человека отбирать надо, а конкретно дать ему по башке, чтоб выучил новый язык.

Если бы это было возможно... А вот если отнять гоуту, то он сам будет вынужден выучить язык.

S>Задачи разные, я думаю.

Это же в какой задаче увеличение скорости программы на порядок и более может быть не нужна?


S>1) STL без исключений — не STL. Просто потому, что vector<T>::at обязан кидать out_of_range при выходе за границы.
S>2) Привязка исключений к CRT действительно зависит конкретной версии компилятора. У меня версия вполне конкретная Да и ценность реализации исключений С++ (не SEH) вне CRT довольна сомнительна — примерно как CRT статически линковать. (возможно, тут я ошибаюсь).
S>3) Статью читал. Только вот про самое интересное там не написано (детально про fp, например). Очевидно, потому что нафиг это никому не надо — трахаться с плавающей точкой без CRT.

Значит плохо читал. А про флоат без CRT... Не просто можно но и очень даже ничего получаетя. Это я тебе говорю, так как мы с БД без CRT работаем, а там флоаты частенько поадаются. Тащить за собой лишний мегобайт нам не охота (именно столько набегает если CRT использовать). К тому же есть еще один плюс. Наш код лучше использует настройки нет.

S>Вообще-то, я пару программок без CRT писал, но только там, где это реально было надо. Но это все был равно не С++

Мы пишим COM-библиотеки и нужно распространять их по сети.

S>Вот я и говорю — это не С++. Хотя подобным образом извращаться, конечно, иногда приходится.

Изваращаться все равно по какому-нибудь поводу придется. Мы на вычистку CRT один раз потратили две недели и не жалеем.

S>Я sprintf и имел в виду. А реализация wsprintf, wvsprintf и вообще любого форматирующего вывода в WinAPI не поддерживает плавающую точку (что, впрочем, не удивительно).

Плавающую точку поддерживает automation API. Причем на порядок лучше чем CRT. Многие программы вообще флоат не используют. Но я стабой согласен, что на отказ от CRT должна быть причина. На VC6 это трах. На семерке уже по проще.

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

WH>Можно и так, но как писать это ЛИЧНОЕ дело программиста и пытаться изменить стиль того чьи программы РАБОТАЮТ это ВРЕДНАЯ трата времени.

Этот код легко прочесть и легко понять (в отличии от исходного). А "ЛИЧНОЕ дело" у программиста может быть только когда он пишит код который нужен только одному ему.

Вообще это примен замечательно показывает что лучше жить без goto.

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

VD>Вот тебе цитата из Лингво:
VD>

VD>CASE  
VD>сокр. от computer-aided software engineering  
VD>автоматизированное проектирование и создание программ
VD>

VD>Так как игра это программа, а редактор позволяет ее создавать, то значит является.

А что Лингво говорит по поводу goto? Тоже, небось, какую-нибудь ересь...

VD>А мне проектирование ради проектирования не нужно. Мне результат нужен.

А мне кодирование ради кодирования не нужно. Сколько ты "проектируешь"? 1% времени? Никому больше это не говори. Правильные пацаны проектируют от 10 до 50 % времени.

GS>>Самое универсальное, что есть — операционные системы, компонентые модели и ЯВУ. Во что-то другое типа универсального движка/редактора я не верю, даже для управления предприятием и/или игр. Для полноты хотелось бы добавить, что не верю и в неуниверсальные энжины/редакторы, но это будет уже перебор.

VD>Что в них верить, то? Поставь себе Кваку или Старкрафт и убедись. Они универсальны для своей области.

"Они летают, но низэнько-низэнько..."

VD>А в Яву я не верю. Это всего лишь еще один язык программирования. Переносимость мне не нужна...

А я не верю в веру и неверие.

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

DG>Здравствуйте Alexander Shargin, Вы писали:

DG>В таких задачах часто можно сделать двухмерный "итератор" (в паре задач я так делал, когда надо было часто бегать по двухмерной областе).

DG>

DG>for (Pos i(0, 0); i < Pos(1000, 1000); ++i)
DG>{
DG>  if (i.x == 666 && i.y == 123)
DG>    break;
DG>}
DG>

IT>>>1. Флаг в первом цикле
IT>>>2. Проверка счётчика второго цикла на завершённость
IT>>>3. return
IT>>>4. inline процедура (очень специфический вариант, но возможный)

DG>Я бы еще добавил:
DG>5. использовать goto, но спрятать за макросами (одиннаковыми для всей команды)
DG>6. вышеприведенный двухмерный "итератор"

Вариант 7 (или это разновидность варианта 6 ?)
Я, обычно вместо "двумерных итераторов" использую два итератора в for:

for(int i=0,j=0; j<1000 ; i<1000 ? i++ : (i=0, j++) )
{
    if(i==666 && j==123)
        break;
};

А сам for прячу за максросами ...

#define for2(Start_1,Cond_1,Next_1,Start_2,Cond_2,Next_2)        for((Start_1),(Start_2) ; (Cond_2) ; (Cond_1) ? (Next_1) : ((Start_1), (Next_2)) )

Но эта техника применима только сли обходимая облась имеет несложную структу (прямоугольник или треугольник ...).
Кроме того, вложенные циклы, даже в выч.-математике, это , как правило, не просто обход многомерных массивов.