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

GS>>Пользоваться надо уметь. Я ею ATL-ный проект в модель поднимал, и потом обратно в компилируемый код генерировал.

VD>От моего ATL-ого проекта она падает.

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

VD>И вообще я не против амтомтизации проеткирования. Но пусть эти средства тоже будут проффесионально спроектированными. А обуваться у сапожника без сопог.

Идеалист. А вот они в розе реалисты. Продается и хорошо.

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

Ну. Говоришь "фэ" и идешь к конкуренту. Продолжать?

VD>... Потом меня например совершенно не устраивает, что реальное моделирование идет только на уровне ОО-модели, а все остальные модели ни как с ней не связаны (физически).

Там еще на уровне физ. дизайна — раскладки классов по файлам есть.

VD>Этак я и на бумажке могу или в Визио.

Ну. Это и есть кодогенерация вручную.

VD>Помени мое слово Визио черз пару-иройку лет заткнет за пазушу эту Розу.

А что — она умеет код генерить? Не знал. Вообще-то у Рашионал и MS есть что-то вроде соглашения о неконкуренции. Было, по крайней мере.

GS>>Чтоб спинным мозгом программировалось.

VD>Ну, я лично предпочитаю обычным думать.

Не наш метод.

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

F>Мдя... Неужели ТАК еще кто то пишет...

Зато никакого скрытого кода! Пусть даже он компилятором весь и выбрасывается...

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

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

WH>И в обще для оценки качества кода есть 3 простых критерия:
WH>1)Наличие ошибок
WH>у вас покрайней мере одна
WH>2)Скорость работы
WH>эксепшены и вызовы процедур ее не увеличивают
WH>3)Затраты памяти
WH>у вас хоть не на много но больше

Есть и еще несколько но тебя они не волнуют. Ладно проверить твой код на скорость невозможно.

Предлагаю простой эксперемент напиши нам QuickSort в своем стиле. На твоей стороне будет ручной уход от рекусрсии и оптимизация путем хаотичного метания. А я тоже самое изображу в структурированном виде. Сравним что получивось (после компиляции этого дела VC7).

Вот мой вариант:

template <class SType> void __forceinline QuickSort(SType *item, int left, int right)
{
   SType x;
   int i = left;
   int j = right;   
   SType center = item[(left + right) / 2];
   while(i <= j)
   {
      while (item[i] < center && i < right)
         i++;
      while (item[j] > center && j > left)
         j--;
      
      if (i<=j)
      {
         x  = item[i];
         item[i] = item[j];
         item[j] = x;
         i++;
         j--;
      }
   } 
   if(left < j)
      QuickSort(item, left, j);
   if(right > i)
      QuickSort(item, i, right);
}

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

GS>Идеалист. А вот они в розе реалисты. Продается и хорошо.

Мне до их прдах дела нет. Думаю визио продается куда лучше, что же теперь мне продукты по рейтингу продаж выбирать? Тогда нужно проектировать на редакторе от Варкрафта.

GS>Ну. Говоришь "фэ" и идешь к конкуренту. Продолжать?

У них пока не лучше. Так что фэ я уже сказал... будем ждать конкурента.

VD>>... Потом меня например совершенно не устраивает, что реальное моделирование идет только на уровне ОО-модели, а все остальные модели ни как с ней не связаны (физически).

GS>Там еще на уровне физ. дизайна — раскладки классов по файлам есть.

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

VD>>Этак я и на бумажке могу или в Визио.

GS>Ну. Это и есть кодогенерация вручную.

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

VD>>Помени мое слово Визио черз пару-иройку лет заткнет за пазушу эту Розу.

GS>А что — она умеет код генерить? Не знал.

Умеет. Пока хреновенько, но потенциал большой. От того же ERWin-а мы похоже отказались в пользу Визио (хоть и уступает она кое в чем, но приимуществ больше, главное мньше глюков и удобнее).

GS>Вообще-то у Рашионал и MS есть что-то вроде соглашения о неконкуренции. Было, по крайней мере. Я думаю они Рашионалу акций на пару сотен мегобаксов отстегнули и Рашионал будет делать вид, что их вытесняет злой монстр-монополист.

GS>>>Чтоб спинным мозгом программировалось.

VD>>Ну, я лично предпочитаю обычным думать.

GS>Не наш метод.

Немогу не слгласится!

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

GS>>Идеалист. А вот они в розе реалисты. Продается и хорошо.

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

Да. Поглядывать. Соберут они денег на сделать следующую версию или нет. Вот Микрософь собрал денег на сделать NT, а IBM слил воду.

VD>Тогда нужно проектировать на редакторе от Варкрафта.

Продукт будет развиваться в расчете на текущих пользователей, а они — игруны, не проектировщики.

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

Диаграмма взаимодействий. Которая на самом деле SDT и диаграмма Хоара одновременно.

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

Ну. Так главное — проектировать, а генерировать можно и врукопашную.

VD>Это называется использование более удобного средства. Когда на розе (или конкурирующем продукте типа Визио) можно будет так же удобно и продуктивно работать, то я с удовольствием перелезу, а пока у меня на проектирование уходит 1% всего времени,

А вот сейчас тебе и скажут, что ты, значит, и не проектируешь.

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

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

WH>>И в обще для оценки качества кода есть 3 простых критерия:

IT>Главная оценка качества кода — maintenance, т.е. сопровождаемость и первое правило, которого нужно придерживаться — это то, что твой код будут читать и возможно править другие программисты. При этом некоторые из них менее опытные и будут тебя материть за непонятность и запутанность кода, а некоторые более опытные будут материть тебя за то же самое, но уже по другому.

Т.е. производство ради производства?

IT>Иногда встречаются такие программы, которые можно назвать монолитными. Не потому что они стройные и красивые, а потому что они неизменяемые и повторно неиспользуемые. Для того чтобы в них добавить хоть одну фичу их можно только полностью переписть, при этом перечисленным тобой ниже оценкам они вполне удовлетворяют, но ценность у них никакая для будущих поколений. Все твои goto как раз и делают программу монолитной и неизменяемой. Тому кто будет идти за тобой придётся твой код переделывать полностью. Понятное дело, что писать такие программы много ума не надо, а вот попробуй написать так, чтобы тот кто открыл твой текст сразу бы уведел место куда можно добавить свой кусочек и не тратил бы часы на выискивание меток и их вызовов.

А тебе не приходило в голову, что частенько пишутся программы, которые и должны быть монолитными? Которые и не нужно изменять? Ты всегда "офисный" софт пишешь? Тогда, конечно, узеру всегда приятно видеть пару лишних фенечек. А как насчет, что софт иногда пишется под конкртное железо (или ето уже не модно)?

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

WH>>1)Наличие ошибок
WH>>у вас покрайней мере одна
WH>>2)Скорость работы
WH>>эксепшены и вызовы процедур ее не увеличивают
WH>>3)Затраты памяти
WH>>у вас хоть не на много но больше

IT>Это всё важно, но вторично.

Еще раз повторюсь, есть вещи в которых _ЭТО_ первично. А вот модное слово maintenance вторично, либо совсем не нужно.

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

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



WH>И в обще для оценки качества кода есть 3 простых критерия:
WH>1)Наличие ошибок
WH>у вас покрайней мере одна
WH>2)Скорость работы
WH>эксепшены и вызовы процедур ее не увеличивают
WH>3)Затраты памяти
WH>у вас хоть не на много но больше

но и писалось это перед сном (после душа ) быстро и только потому, что пример Вашего кода
с использованием "гото" порсто вывел меня из себя

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


P>А тебе не приходило в голову, что частенько пишутся программы, которые и должны быть монолитными? Которые и не нужно изменять? Ты всегда "офисный" софт пишешь? Тогда, конечно, узеру всегда приятно видеть пару лишних фенечек. А как насчет, что софт иногда пишется под конкртное железо (или ето уже не модно)?

Не ради стёба спрашиваю, а ради интереса — на самом деле, какие такие программы, "которые и должны быть монолитными, Которые и не нужно изменять" ?

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

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

WH>>
WH>>Код НЕ ЭКВИВАЛЕНТЕН оригиналу!
WH>>Тк в оригинале при pRecord3 == NULL цикл закончится, а в вашем случяе начнется заново.

VD>Вообще-то моя задача была дать общую идею. Ну, да ладно, перепишим эквивалентно:


VD>

VD>for(SDirectoryRecord* pRecord3 = pRecord1->m_pFirstRecord; pRecord3;)
VD>{
VD>  for(;pRecord3 != NULL; pRecord3 = pRecord3->m_pNextDirectory) 
VD>  {
VD>    if(pRecord3 != pRecord2 && pRecord2->m_nLevel == pRecord3->m_nLevel) 
VD>    {
VD>       nRes = CompareRecord(pRecord2, pRecord3, nType) == 0 
VD>                ? CCB_ERR_EQUAL_ID : CCB_ERR_NOERROR;
VD>       if(nRes != CCB_ERR_NOERROR)
VD>       {
VD>            pCheckControl->m_data1 = reinterpret_cast<long>(pRecord2);
VD>            pCheckControl->m_data2 = reinterpret_cast<long>(pRecord3);
VD>            //Передается юзеру, который должен как-то отреагировать на ошибку
VD>            nCallBackRes = pCheckControl->DoControl(nRes); 
VD>            nErrorCount++;
VD>            
VD>            if(nCallBackRes == CCB_RES_MAKEAUTO || nCallBackRes == CCB_RES_IGNORE) 
VD>               continue; //OK, продолжаем дальше
VD>            else if(nCallBackRes == CCB_RES_ABORT) 
VD>               return nErrorCount; //Failed, отмена
VD>            else 
VD>               //Юзер попытался исправить ошибку, надо проверить заново
VD>               break;
VD>       }
VD>   }
VD>}
VD>

Код НЕ ЭКВИВАЛЕНТЕН оригиналу!
Тк в оригинале при "Юзер попытался исправить ошибку" цикл начнется заново, а в вашем случяе продолжиться.

WH>>Можно так: ...
WH>>Но это лишние извраты!

Можно и так, но так работать не будет.

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

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


P>>А тебе не приходило в голову, что частенько пишутся программы, которые и должны быть монолитными? Которые и не нужно изменять? Ты всегда "офисный" софт пишешь? Тогда, конечно, узеру всегда приятно видеть пару лишних фенечек. А как насчет, что софт иногда пишется под конкртное железо (или ето уже не модно)?

LG>Не ради стёба спрашиваю, а ради интереса — на самом деле, какие такие программы, "которые и должны быть монолитными, Которые и не нужно изменять" ?

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

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

P>Ну, представь себе такую ситуацию.
P>Есть некий прибор, управляется ета хрень какой-нибудь двушкой в железном ящичке под голым досом. Энтих приборчиков энное количество по всему миру (например в Нижнезадрюпенской области, городе Мухосраннске).
P>Maintenance с точки зрения новых красивых фенечек ненужен\невозможен по двум причинам — как ты представляешь обновление софта в этой ситуации? И, второе, железо (приборчик) рабоает на пределе, и новых фенечек из него не высосешь. Да и не нужны они, себестоимость тоже нужно учитывать.

В этой ситуации возможно ты и прав... я не могу объективно судить
Но, например, WolfHound привел пример программы на WinAPI, и следовательно он врят-ли
пишет для хрени с девушкой в железном ящичке...

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

[skip]

LG>В этой ситуации возможно ты и прав... я не могу объективно судить
LG>Но, например, WolfHound привел пример программы на WinAPI, и следовательно он врят-ли
LG>пишет для хрени с девушкой в железном ящичке...

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

ЗЫж А "девушкой в железном ящичке..." — рулез
Мсье оригинал

Ребята, давайте завершать беседы об отвлечённых материях. По теме в последнее время достаточно мало было сказано
Если кто не успел высказаться, вперёд! Заводите новую тему и публикуйте в соответствующем форуме.

P.S. Хорошо, что темы пока нельзя закрывать А то закрыл бы и не случилось бы такого бурного обсуждения в почти чистом форуме С++

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

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

Зато они говорят о том, к чему надо стремится.

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

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

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

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

DG>Зато они говорят о том, к чему надо стремится.

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

"девушку в железном ящичке" это как "сферическая операционная система в вакууме". Я говорил именно о том, что есть случаи, каторые общим мерилом не изменишь. Те же самые умные дяденьки етот момент обычно отмечают. Иначе они не были бы умными дяденьками.

ЗЫж Пора либо прекратить религиозные споры, либо перенести в прочее.

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

P>:no: :no: :no: :no: :no: :no:
P>Код НЕ ЭКВИВАЛЕНТЕН оригиналу!
P>Тк в оригинале при "Юзер попытался исправить ошибку" цикл начнется заново, а в вашем случяе продолжиться.

:) Самое интересное, что этот факт тоже можно истолковать двояко. goto сделало твой код настолько непонятным, что Влад со второго раза не может переписать его правильно. Вывод однозначен — goto несёт вред. Давить! ;)

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


Итак.

Во-первых, мне не совсем понятно, почему для противники goto постоянно щеголяют приёмами из арсенала C++. Если goto противоречит принципам структурного программирования, давайте оперировать средствами языка C. То есть никаких исключений, объектных обёрток и пр.

Во-вторых, по поводу стиля. Для меня стиль — это не набор конкретных правил. Это скорее возведённый во главу угла принцип писать програмы, понятные другим. Всё остальное — лишь средства для достижения цели, которые, однако, могут быть использованы и во вред. Мы все широко и с удовольствием используем break для выхода из цикла. Чем отличается goto для выхода из вложенного цикла? Практически ничем. Кстати, в Java goto убрали, но расширили синтаксис break для выхода из вложенных циклов. Похоже, ребята рассуждали похожим образом.

В-третьих, по поводу других предложенных методов.
1. Вспомогательная функция+выход по return. Поскольку функции по правилам C могут находиться в любом месте программы (в т. ч. в другом модуле), читателю совершенно непонятно, куда приведёт return. Эту ситуацию можно немного поправить, структурируя код и добавляя комментарии, но это не меняет сути — такой подход не способствует читабельности.
2. Вспомогательные переменные и проверки. Конечно, это субъективно, но на мой взгляд они более непонятны для читателя. И чем глубже вложенность, тем ситуация хуже. Логически выход осуществляется в том месте, где мы измегняем условие выхода, но фактически выход осуществляется где-то в другом месте (возможно, несколькими страницами выше/ниже). Читабельности это не способствует.

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

В-четвёртых, по поводу квалификации программиста и зависимости количества goto от неё. Смеха ради я открыл папку VC6 и сделал по ней глобальный поиск. Что же я вижу? MFC. goto используются во многих местах. Ну, я всегда подозревал, что MFC писали ламеры. Смотрим дальше. CRT. Что это? И здесь goto? Список кандидатов на увольнение из Микрософт разрастается... Но ведь есть же ATL. Её писали настоящие ООП-пацаны, они не могут нас подвести. Как, и здесь goto? :???: Поистине, мы живём в обществе потребления, без веры, без идеалов... ;) Список можно продолжать. Загляните в исходники ядра Linux. Там вы тоже найдёте goto. Почему Linux-комьюнити до сих пор не переписала этот позорный код? Ы? Вот и я о том же.

В-пятых, по поводу принципов. Лично я не видел ни одного бесспорного принципа в программировании. Да и вообще по жизни. Структурное программирование, ООП, обобщённое программирование — замечательные вещи, но их принципы работают не всегда. Помнится, Влад сам развлекался, описывая всеохватную припверженность создателей Java принципам ООП. Так о чём теперь спор? Что из правила не может быть исключений? Помилуйте, это история не из реального мира.

В-шестых, по поводу важности характеристик программ. Тут назвали уже корректность, эффективность по скорости и по памяти, понятность для других, поддерживаемость, расширяемость, переиспользуемость и т. д. В этом вопросе, как мне кажется, каждый смотрит со своей колокольни. Понятно, что корректность как главное качество программы под сомнение не ставится. Но те, кто разрабатывает приложения для enterprise, упирают на поддерживаемость/расширяемость. А те, кто занимается реальным временем, встроенными системами и т. п., будет упирать на эффективность. Мне удалось поработать и там, и там, и я полностью согласен со всеми аргументами. Я видел очень важные, полезные программы, которые были абсолютно нечитабельными (в частности, из-за массы #ifdef/#endif для подержки различных аппаратных платформ). Расскажите фирме, что они дураки, когда они уже заработали на этой программе мегабаксы. Словом, важность отдельных параметров зависит от конкретного проекта. Так было, и так будет.

Ну и последнее. По поводу надуманности примеров, где goto реально помогает. На мой взгляд, даже в Windows-программировании такие случаи бывают. Вот самый что ни есть типичный сценарий (напоминаю, пока мы остаёмся в рамках C):

void foo()
{
   HANDLE hFile = NULL; // Файл
   HANDLE hFileMapping = NULL; // Отображение
   LPVOID pMappedBuffer = NULL; // Буфер для работы с отображением
   char *pBuf = NULL; // Целевой буфер
   BOOL bResult = TRUE;

   // Открываем файл
   // Создаём отображение
   // Мапим
   // Копируем содержимое файла в буфер
   // Работаем с данными

failure:
   bResult = FALSE;

cleanup:

   if(pBuf != NULL)
      delete [] pBuf;
   if(pMappedBuffer != NULL)
      UnmapViewOfFile(pMappedBuffer);
   if(hMapping != NULL)
      CloseHandle(hMapping);
   if(hFile != NULL)
      CloseHandle(hFile);

   return bResult;
}

Да, в C++ это решается с помощью исключений. Но исключения — палка о двух концах. Во-первых, не все пишут на C++ (некоторые на C). Во-вторых, бывают разные платформы. Я сейчас пишу для Windows CE, так вот здесь исключения C++ вместе с RTTI не поддерживаются. Не поддерживаются, и всё тут. В-третьих, любители жить без CRT тоже не очень-то жалуют исключения (и ATL/WTL вполне поддерживают такой стиль жизни).

Можно приводить и другие примеры. Про встроенные/низкоуровневые системы, которые с основном пишутся на C, тут уже сказали, и я с этим согласен. Другой характерный пример — портирование. Когда портируешь, скажем, сложную вычислительную программу с Фортрана (а они испещрены goto), лучше всего не ломаться и перенести все goto без изменений (проверено практикой). Иначе вероятность внести ошибку огромна, а проверить возможности нет никакой (большинство goto — это какие-то вырожденные случаи алгоритма, и если он сложен, нужный набор исходных данных фиг подберёшь). Впрочем, последний пример — это и иллюстрация недостатков goto при их повсеместном применении (как это было в фортране).

Резюме. Я призиваю участников этого флейма не быть такими категоричными. Эту ветку могут читать начинающие. Не надо прессовать им мозги "незыблемыми правилами". Лучше поучите их думать головой.

PS. "Правила игры", принятые в некоторой фирме (всяческие styleguide'ы и пр.), следует уважать. Большие программы создаются большими коллективами. Хотя умение работать в команде не имеет прямого отношения к квалификации программиста, это важнейшая вещь. Этому нужно учиться. Чего себе и вам желаю.

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

AS>Влад говорил, что первая двадцатка топа его поддержит. Ну, я уже давно из неё выбыл, так что мне можно.
Ща мы тебя в нее опять задвинем. Сколько тебе там надо? 65 очков?

Для чистоты эксперимента сам пока ставить не буду. Но оч. круто написал. Предлагаю поставить точку на этом.

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

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

P>>
P>>Код НЕ ЭКВИВАЛЕНТЕН оригиналу!
P>>Тк в оригинале при "Юзер попытался исправить ошибку" цикл начнется заново, а в вашем случяе продолжиться.

AS> Самое интересное, что этот факт тоже можно истолковать двояко. goto сделало твой код настолько непонятным, что Влад со второго раза не может переписать его правильно. Вывод однозначен — goto несёт вред. Давить!

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

Складывается впечатление, что все противники goto работают в коллективе не менее чем человек 200 (причем удаленно), разрабатывают просто грандиозные проЭкты, в основном заботясь о том, чтобы оставить себе хорошую возможность позднее править кучу багов, ибо времени на хорошее кодирование не остается, поскольку оно ушло на проекирование и реализацию "граммотного структурного кода". Упаси боже сомневаться в огромной его пользе, Это многое, но не все.
А то что "граммотный структурный код" может работать неправильно или не работать совсем, я думаю все понимают

Все тобой нижесказанное и мной поскипанное целиком поддреживаю, распечатаю и повешу на стенку. Ибо как говорится, "Никогда не говори никогда".

[skip]

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

AS>Во-первых, мне не совсем понятно, почему для противники goto постоянно щеголяют приёмами из арсенала C++. Если goto противоречит принципам структурного программирования, давайте оперировать средствами языка C. То есть никаких исключений, объектных обёрток и пр.

Не, это не честно. Неиспользование goto в C — это уже совсем другой вопрос. Я думаю, экстремистов, утверждающих, что goto не нужен в С куда меньше, чем протестующих против его использования в C++.

AS>Кстати, в Java goto убрали, но расширили синтаксис break для выхода из вложенных циклов. Похоже, ребята рассуждали похожим образом.

И правильно сделали. А комитет по стандартизации C++ правильно делает, что goto не убирает. Хотя break усовершенствовать не помешало бы — глядишь, goto только в legacy коде и остался бы.

AS>В-третьих, по поводу других предложенных методов.
AS>1. Вспомогательная функция+выход по return. Поскольку функции по правилам C могут находиться в любом месте программы (в т. ч. в другом модуле), читателю совершенно непонятно, куда приведёт return. Эту ситуацию можно немного поправить, структурируя код и добавляя комментарии, но это не меняет сути — такой подход не способствует читабельности.

Вот именно! Функция должна выполнять логически завершенное действие, а не служить заменой циклу. Уж лучше goto.

AS>2. Вспомогательные переменные и проверки. Конечно, это субъективно, но на мой взгляд они более непонятны для читателя. И чем глубже вложенность, тем ситуация хуже. Логически выход осуществляется в том месте, где мы измегняем условие выхода, но фактически выход осуществляется где-то в другом месте (возможно, несколькими страницами выше/ниже). Читабельности это не способствует.

AS>Проблема в том, чтоь вложенные циклы со сложной логикой выхода — конструкция сама по себе не очень очевидная. Я согласен, что если программу можно перепроектировать и избавиться от них, то это нужно сделать. Но это возможно не всегда.

Угу. Но break в стиле java был бы красивше. В общем-то, есть большая между return/break и goto — goto умеет прыгать назад.

AS>В-четвёртых, по поводу квалификации программиста и зависимости количества goto от неё. Смеха ради я открыл папку VC6 и сделал по ней глобальный поиск. Что же я вижу? MFC. goto используются во многих местах. Ну, я всегда подозревал, что MFC писали ламеры. Смотрим дальше. CRT. Что это? И здесь goto? Список кандидатов на увольнение из Микрософт разрастается... Но ведь есть же ATL. Её писали настоящие ООП-пацаны, они не могут нас подвести. Как, и здесь goto? :???: Поистине, мы живём в обществе потребления, без веры, без идеалов... ;) Список можно продолжать. Загляните в исходники ядра Linux. Там вы тоже найдёте goto. Почему Linux-комьюнити до сих пор не переписала этот позорный код? Ы? Вот и я о том же.

Не, это не слишком удачные примеры. Linux вроде как на C писана, там goto нужнее. CRT — тоже. Что касается ATL, то в atlbase.h можно было легко обойтись без goto, не потеряв читабельности. atlcom.h — CSecurityDescriptor::GetTokenSids и CSecurityDescriptor::Attach, по-моему, написаны не слишком тщательно, там при некоторых ошибках лики вроде могут быть (да и код этот явно унаследованный). atldb.h — одно большое глюкало, явно писалось на скорую руку (когда пришлось однажды его использовать, нашел кучу разнообразных утечек). statreg.h — в CRegObject::RegisterFromResource (написанной в сишном стиле, кстати) от goto без труда можно было бы избавиться (вроде даже без объектных оберток); в CRegParser::RegisterSubkeys вообще хрен чего поймешь, что с goto, что без него — код явно write-only :), напрашивается на полное переписывание при необходимости малейшей модификации. Так что насчет "настоящих ООП-пацанов" я сильно не уверен :))

AS>Ну и последнее. По поводу надуманности примеров, где goto реально помогает. На мой взгляд, даже в Windows-программировании такие случаи бывают. Вот самый что ни есть типичный сценарий (напоминаю, пока мы остаёмся в рамках C):

AS>

AS>void foo()
AS>{
AS>   HANDLE hFile = NULL; // Файл
AS>   HANDLE hFileMapping = NULL; // Отображение
AS>   LPVOID pMappedBuffer = NULL; // Буфер для работы с отображением
AS>   char *pBuf = NULL; // Целевой буфер
AS>   BOOL bResult = TRUE;

AS>   // Открываем файл
AS>   // Создаём отображение
AS>   // Мапим
AS>   // Копируем содержимое файла в буфер
AS>   // Работаем с данными

AS>failure:
AS>   bResult = FALSE;

AS>cleanup:

AS>   if(pBuf != NULL)
AS>      delete [] pBuf;
AS>   if(pMappedBuffer != NULL)
AS>      UnmapViewOfFile(pMappedBuffer);
AS>   if(hMapping != NULL)
AS>      CloseHandle(hMapping);
AS>   if(hFile != NULL)
AS>      CloseHandle(hFile);

AS>   return bResult;
AS>}
AS>

AS>Да, в C++ это решается с помощью исключений. Но исключения — палка о двух концах. Во-первых, не все пишут на C++ (некоторые на C). Во-вторых, бывают разные платформы. Я сейчас пишу для Windows CE, так вот здесь исключения C++ вместе с RTTI не поддерживаются. Не поддерживаются, и всё тут. В-третьих, любители жить без CRT тоже не очень-то жалуют исключения (и ATL/WTL вполне поддерживают такой стиль жизни).

Не, исключения тут ни к чему — не для того их придумывали. Только объектные обертки — если подходящих классов нет, описываем прямо внутри foo(). Все шустро делается инлайновыми деструкторами, никакого проигрыша по сравнению с goto — одни плюсы. А без CRT — это уже не С++, а "С с классами", да и то урезанный.

AS>Можно приводить и другие примеры. Про встроенные/низкоуровневые системы, которые с основном пишутся на C, тут уже сказали, и я с этим согласен. Другой характерный пример — портирование. Когда портируешь, скажем, сложную вычислительную программу с Фортрана (а они испещрены goto), лучше всего не ломаться и перенести все goto без изменений (проверено практикой). Иначе вероятность внести ошибку огромна, а проверить возможности нет никакой (большинство goto — это какие-то вырожденные случаи алгоритма, и если он сложен, нужный набор исходных данных фиг подберёшь). Впрочем, последний пример — это и иллюстрация недостатков goto при их повсеместном применении (как это было в фортране).

Я вот только два примера оправданного использования goto в C++ знаю — выход из вложенных циклов и впихивание к себе в программу чужого/унаследованного кода. Больше ничего не попадалось.

AS>Резюме. Я призиваю участников этого флейма не быть такими категоричными. Эту ветку могут читать начинающие. Не надо прессовать им мозги "незыблемыми правилами". Лучше поучите их думать головой.

Это правильно.

AS>PS. "Правила игры", принятые в некоторой фирме (всяческие styleguide'ы и пр.), следует уважать. Большие программы создаются большими коллективами. Хотя умение работать в команде не имеет прямого отношения к квалификации программиста, это важнейшая вещь. Этому нужно учиться. Чего себе и вам желаю.

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

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

AS>>Во-первых, мне не совсем понятно, почему для противники goto постоянно щеголяют приёмами из арсенала C++. Если goto противоречит принципам структурного программирования, давайте оперировать средствами языка C. То есть никаких исключений, объектных обёрток и пр.

S>Не, это не честно. Неиспользование goto в C — это уже совсем другой вопрос. Я думаю, экстремистов, утверждающих, что goto не нужен в С куда меньше, чем протестующих против его использования в C++.

Если бы мы спорили о том, какие средства C++ лучше применять, то ты был бы прав: C ни при чём. Но в этом треде утверждалось, что goto противоречит принципам структурного программирования, нарушает их и из-за этого плох. Ну, раз уж мы заговорили о структурном программировании, то давайте продемонстрируем несостоятельность goto в рамках чисто структурного языка. Кстати, вряд ли те же исключения можно причислить к структурному программированию.


S>Угу. Но break в стиле java был бы красивше. В общем-то, есть большая между return/break и goto — goto умеет прыгать назад.

Ох, а ведь есть ещё setjmp/longjmp...


AS>>В-четвёртых, по поводу квалификации программиста и зависимости количества goto от неё. Смеха ради я открыл папку VC6 и сделал по ней глобальный поиск. Что же я вижу? MFC. goto используются во многих местах. Ну, я всегда подозревал, что MFC писали ламеры. Смотрим дальше. CRT. Что это? И здесь goto? Список кандидатов на увольнение из Микрософт разрастается... Но ведь есть же ATL. Её писали настоящие ООП-пацаны, они не могут нас подвести. Как, и здесь goto? Поистине, мы живём в обществе потребления, без веры, без идеалов... Список можно продолжать. Загляните в исходники ядра Linux. Там вы тоже найдёте goto. Почему Linux-комьюнити до сих пор не переписала этот позорный код? Ы? Вот и я о том же.

S>Не, это не слишком удачные примеры. Linux вроде как на C писана, там goto нужнее. CRT — тоже. Что касается ATL, то в atlbase.h можно было легко обойтись без goto, не потеряв читабельности.
[skip]

Здесь речь не о том. Дело в том, что создатели Linux и библиотек Microsoft таки используют goto. По логике Влада это даёт нам право зачислить их в ламеры. Сделать это несложно, но таким образом можно ненароком прописать в ламеры и самого себя.


S>Не, исключения тут ни к чему — не для того их придумывали. Только объектные обертки — если подходящих классов нет, описываем прямо внутри foo(). Все шустро делается инлайновыми деструкторами, никакого проигрыша по сравнению с goto — одни плюсы.

Да, здесь согласен. C++ — богатый язык.