Вот попросили выложить... выкладываю....

Куда приводит GOTO

С детства нам говорили, что в программах использовать goto нельзя. Это было табу. Долгие годы я не мог его переступить. Некоторые особо рьяные ценители читаемости текста желали также запретить условные переходы, оставив только циклы, но к счастью их призывы до меня не дошли. Однако goto у меня непременно ассоциировался с плохо написаным кодом.
Поработав побольше, я пришел к выводу, что хороший текст должен быть таким:
1. Продолжать работать в любом случае, не падать при несрабатывании каких-либо функций.
2. Отслеживать все ошибки исполнения, по возможности их обходить и записывать толковый файл лога, по которому можно диагностировать проблему.
3. Быть компактным и легким для восприятия. Кроме того, хороший код содержит минимум неявно выполняемых операций.
4. Освобождать все занятые ресурсы и размещенную память в случае неудачи.
Соблюдению этих нехитрых условий зачастую помогает оператор перехода, что я попытаюсь проиллюстрировать ниже. Рассмотрим различные методы стили написания функции, которая заполняет указанный файл символом 'a'.
Итак:

Код

long fill_file( const char *psz ) {     HANDLE    hfile = ::CreateFile( psz, GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0 );     unsigned    size = ::GetFileSize( hfile, 0 );     HANDLE    hmap = ::CreateFileMapping( hfile, 0, PAGE_READWRITE, 0, 0, 0 );     void    *ptr = ::MapViewOfFile( hmap, FILE_MAP_WRITE, 0, 0, 0 );     memset( ptr, 'a', size );     ::UnmapViewOfFile( ptr );     ::CloseHandle( hmap );     ::CloseHandle( hfile );     return 0; }

(Внимание - я привожу не полноценный текст С++, а условный код, опуская неважные с точки зрения стиля программирования параметры функций).
Код прозрачен, однако крайне груб - ошибки не обрабатываются, лог ошибок не ведется.
Проверки и освобождение ресурсов "в лоб"

Код

long fill_file( const char *psz ) {     HANDLE    hfile = CreateFile( psz, GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0 );     if( hfile == INVALID_HANDLE_VALUE )return 1;     unsigned    size = ::GetFileSize( hfile, 0 );     HANDLE    hmap = ::CreateFileMapping( hfile, 0, PAGE_READWRITE, 0, 0, 0 );     if( hmap == 0 )     {         ::CloseHandle( hfile );             return 2;     }     void    *ptr = ::MapViewOfFile( hmap, FILE_MAP_WRITE, 0, 0, 0 );     if( !ptr )     {         ::CloseHandle( hmap );         ::CloseHandle( hfile );         return 3;     }     memset( ptr, 'a', size );     ::UnmapViewOfFile( ptr );     ::CloseHandle( hmap );     ::CloseHandle( hfile );     return 0; }

Страшно подумать, сколько раз будут дублироваться CloseHandle, как тяжело читать и модифицировать приведенный код, и в скольких местах нужно будет добавлять запись в лог о причине несрабатывания функции.
Что нам принесет C++.
В C++ все делается через классы. Соответственно, перед тем как разработать функцию нужно создать набор классов-оберток для объектов, которые в ней присутствуют:

Код

class handle_object { public:     handle_object()                     {h = 0;} public:         virtual ~handle_object()         {::CloseHandle( h );}          bool is_valid()                     {return h && h != INVALID_HANDLE_VALUE;} public:     HANDLE    h; }; class file : public handle_object {     bool create(); };      class file_mapping : public handle_object {     bool create( HANDLE hfile ); };

После такой "небольшой" подготовительной работы код придет к виду:

Код

long fill_file( const char *psz ) {     file    file;     _file.create( sz_path );     if( !file.is_valid() )return 1;     unsigned    size = file.get_size();     file_mapping    map;     map.create( file.h );     if( !map.is_valid() )return 2;     void    *ptr = map.map_view();              memset( ptr, 'a', size );     map.unmap_view( ptr );     return 0; }

Так уже значительно легче, но крайне напрягает необходимость писать класс на каждый используемый объект. Тут проблем масса - начиная со сложностью передачи экземпляра класса-оболочки в другие функции, и до неочевидности последовательности вызова деструкторов при выходе из функции.
Неочевидный код предполагает ошибки:
1. Первым вызовется деструктор file, а потом map (если экземпляр map создан раньше), что может в некоторых случаях привести к потере ресурсов. (типичный пример - удалить сначала HPEN, выбранный в HDC, а потом сам HDC).
2. Невиртуальность деструктора в handle_object не вызовет ошибки компиляции, однако деструктор не будет вызван при удалении объектов.
Напомню также, что к ведению лога ошибок мы так и не приступили.
Для справедливости замечу, что C++ вместо return в случае несрабатывания функции позволяет использовать оператор throw, однако прозрачность кода при этом становится настолько мала, а код настолько откровенно опасней, что я пожалуй не буду рассматриавть этот вариант.
Хорошее решение:
Вспомним про наш опальный оператор:

Код

long fill_file( const char *psz ) {     long    error_code = 1;     void    *ptr = 0;     HANDLE    hfile = 0, hmap = 0;     unsigned size;     hfile = CreateFile( psz, GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0 );     if( !hfile )goto _end;          size = ::GetFileSize( hfile, 0 );     hmap = ::CreateFileMapping( hfile, 0, PAGE_READWRITE, 0, 0, 0 );     if( !hmap )goto _end;          ptr = ::MapViewOfFile( hmap, FILE_MAP_WRITE, 0, 0, 0 );     if( !ptr )goto _end;          memset( ptr, 'a', size );     error_code = 0; _end:     ::UnmapViewOfFile( ptr );     ::CloseHandle( hmap );     ::CloseHandle( hfile );     return error; }

Жить стало легче. С одной стороны инициализация и освобождение ресурсов прописаны явно (чем достигается прозрачность текста), с другой стороны объем дополнительного кода минимален.
Запись журнала
И наконец, одним росчерком добавим запись в лог всех непредвиденных ситуаций:

Код

long fill_file( const char *psz ) {     long    error_code = 0;     void    *ptr = 0;     HANDLE    hfile = 0, hmap = 0;     unsigned size;     error_code = 1;     hfile = CreateFile( psz, GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0 );     if( !hfile )goto _end;     error_code = 2;         size = ::GetFileSize( hfile, 0 );     hmap = ::CreateFileMapping( hfile, 0, PAGE_READWRITE, 0, 0, 0 );     if( !hmap )goto _end;          error_code = 3;     ptr = ::MapViewOfFile( hmap, FILE_MAP_WRITE, 0, 0, 0 );     if( !ptr )goto _end;          memset( ptr, 'a', size );     error_code = 0; _end:     if( error_code )_trace_file( 0, "error %d/%08x", error_code, ::GetLastError() );     ::UnmapViewOfFile( ptr );     ::CloseHandle( hmap );     ::CloseHandle( hfile );          return error_code != 0; }

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

Код

HANDLE    hfile = INVALID_HANDLE_VALUE; while( hfile == INVALID_HANDLE_VALUE ) {     hfile = ::CreateFile( psz, GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0 );     if( hfile != INVALID_HANDLE_VALUE )break;     DWORD dw = ::GetLastError();     if( ERROR_DEVICE_NOT_READY  == dw )     {         if( MessageBox( "insert disk", MB_RETRYCANCEL ) != IDRETRY )             break;     } }

Цикл на мой взгляд совершенно лишний, тем более что в ветке, когда все в порядке, код в цикле исполняется один раз. На мой взгляд совершенно неверно такие конструкции применять с использованием цикла.
Далее - вариант с goto:

Код

_repeat_open:     HANDLE    hfile = ::CreateFile( psz, GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0 );     if( hfile == INVALID_HANDLE_VALUE )     {         DWORD    dw = GetLastError();         _trace_file( 0, "file error %08x/%s", GetLastError(), sz_file);         if( ERROR_DEVICE_NOT_READY  == dw )         {             if( MessageBox( "insert disk", MB_RETRYCANCEL ) == IDRETRY )                 goto _repeat_open;         }     }

Как видим, все стало очевидней, обработка ошибки легко отделяется от основного текста, а также практически бесплатно получаем полную информацию в логе ошибок.

Андрей Ямов
28.04.2004

Пример на Си++ откровенно неудачен.

Бредовая статья и такие же аргументы.
Оригинал здесь.
Даже в таком простом примере использование RAII понятнее, более сопровождаемо, и оправдывает усилия на написание оберток. Если автор не умеет читать C++ - это его проблемы. "Легкость" логирования в неструктурном коде вообще убила.

Цитата(Void @ 25.10.2005, 18:50)

Бредовая статья и такие же аргументы.

угу.

Albinos_x,

Цитата(Void @ 25.10.2005, 18:50)

RAII

-"захват ресурса-есть инициализация"?

Цитата(Void @ 25.10.2005, 18:50)

Бредовая статья и такие же аргументы. ... "Легкость" логирования в неструктурном коде вообще убила.

Воистину так.
Что восхищает, так это апломб г-на Ямова.
Можно было бы согласится с автором, если бы речь шла о чистом С без классаов и исключений...

Но "обертки" потрясают до слез, особенно заявление

Цитата

Невиртуальность деструктора в handle_object не вызовет ошибки компиляции, однако деструктор не будет вызван при удалении объектов.

учитывая способ объявления

Код

file_mapping map;

а также

Цитата

...C++ вместо return в случае несрабатывания функции позволяет использовать оператор throw, однако прозрачность кода при этом становится настолько мала, а код настолько откровенно опасней, что я пожалуй не буду рассматриавть этот вариант.

Это сообщение отредактировал(а) Earnest - 25.10.2005, 19:28

Цитата(DeadSoul @ 25.10.2005, 18:52)

"захват ресурса-есть инициализация"?

я не автор статьи:

Цитата(Albinos_x @ 25.10.2005, 17:10)

...информацию в логе ошибок. Андрей Ямов 28.04.2004

попросили выложить почитать, вот я и выложил....поэтому пинать меня не надо, к тому же, если Вы обратили внимание, что моих сообщений в разделе С# только несколько штук, а остальные в Делфи, поэтому код я не разбирал и ещё:

Цитата

(Внимание - я привожу не полноценный текст С++, а условный код,

поэтому не стоит принимать всё так близко к сердцу...

PS: а вообще интересно узнать мнения, т.к. собираюсь углублять свои знания по С#. В Паскале, особенно Делфи про то, что пишет автор, сильно можно не заморачиваться, и он будет всё равно читабельным. А вот про С#, ничего сказать не могу, т.к. знаю его поверхостно

Цитата(Albinos_x @ 25.10.2005, 20:48)

Цитата (DeadSoul @ 25.10.2005, 18:52) "захват ресурса-есть инициализация"? я не автор статьи:

Это был вопрос Voidу. Но сути это оно, вопрос был правильно ли я понял перевод.

Цитата(DeadSoul @ 25.10.2005, 23:10)

вопрос был правильно ли я понял перевод.

Да.

Ну вот набросились... Приведите пример как правильно, сравним, а goto - сакс каждый кричать сможет, будучи уверенным на 100% в своей правоте.

ИМХО виной всему сишный WinAPI, а обертки писать задолбаешься, лучше уж MFC тогда.

Цитата(Perchilla @ 25.10.2005, 21:31)

ИМХО виной всему сишный WinAPI,

Он не только Сишный, мне казалось WinApi универсальная вещь.
Именно это и накладывает свои ограничения

Цитата(DeadSoul @ 25.10.2005, 21:10)

Это был вопрос Voidу. Но сути это оно, вопрос был правильно ли я понял перевод.

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

ОФФТОП:
Автор статьи, кстати, зарегистрирован на винграде: AndyY. Правда он здесь не появлялся ещё с лета, а так можно было бы поспорить

Это сообщение отредактировал(а) Дрон - 26.10.2005, 23:21

Пара-тройка строк о таинствах структурного программирования.

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

Следование - операторы выполняются в порядке очереди, один за другим. Графическое представление:

Код

+-----------+ | оператор1 | +-----------+       | +-----------+ | оператор2 | +-----------+       | +-----------+ | оператор3 | +-----------+

Ветвление - в зависимости от выполнения условия происходит выполнение операторов по альтернативному пути. Графическое представление:

Код

+-----------+         | оператор1 |         +-----------+              / \             /   \            /     \           /       \          /         \ +-----------+    +-----------+  | оператор2 |    | оператор3 | +-----------+    +-----------+

Цикл - операторы выполняются циклически постоянно или до выполнения определённого условия. Графическое представление:

Код

+-----------+ | оператор1 |----+ +-----------+    |       |          | +-----------+    | | оператор2 |    | +-----------+    |       |          | +-----------+    | | оператор3 |    | +-----------+    |       |          |       +----------+

Обратите внимание, внезапная передача управления "по метке" структурным программированием не предусмотрена в принципе, как излишняя.

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

Цитата(Neitron @ 27.10.2005, 13:17)

как излишняя.

особенная понимаешь её "излишество", когда приходится выходить break'ом из вложенных циклов.
Особенно когда ты забываешь про то, что находишься во вложенном цикле. Здравствуй, дебагер.


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


Это сообщение отредактировал(а) Mayk - 27.10.2005, 17:15

использовать или нет goto - это одно
но приводить аргумент "излишество" в пользу отказа от него - другое
тогда лучше прийти к машине Тьюринга - там нет ничего лишнего
кроме того, сами циклы могут быть реализованы с помощью goto
так что "излишество" - никак не довод...

Это сообщение отредактировал(а) maxim1000 - 27.10.2005, 17:21

Кстати- Адрей Ямов наш бывший форумчанин
Мой учитель в МФС
Добавлено @ 17:46
http://forum.vingrad.ru/index.php?showuser...&nickname=AndyY

Добавлено @ 17:48
Можно непосредственно обратится к нему и посмотреть, что он скажет

Цитата(Mayk @ 27.10.2005, 17:15)

Цитата(Neitron @ 27.10.2005, 13:17) как излишняя. особенная понимаешь её "излишество", когда приходится выходить break'ом из вложенных циклов. Особенно когда ты забываешь про то, что находишься во вложенном цикле. Здравствуй, дебагер. ЗЫ. Сейчас набегут жависты, которые из вложенных циклов выходят за раз плюнуть и закидают помидорами.

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

Цитата(Mayk @ 27.10.2005, 17:15)

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

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

Цитата(Void @ 25.10.2005, 18:50)

Если автор не умеет читать C++ - это его проблемы

Умеет и даже очень. Человек пытается разрушить правила, которые мы подчеркивали из книжек. Но никто не разу не усомнился в книжныхх правилах.
Я иной раз использую goto. Когда мне удобно. Я использую for, чаще чем while в три-четыре раза. Но это дело удобства, хотя и при невнимательности, можно с ними вылететь в дебаг..

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

Это сообщение отредактировал(а) Neitron - 27.10.2005, 18:02

Цитата(Neitron @ 27.10.2005, 18:02)

является первым признаком, плохо спроектированного кода

Аргументы? Что такое плохо спроектированный код. Назови мне разницу между циклами goto,for, while( не синтаксическую..)
А как быть с обьектами, которые разрушаются, при выходе из цикла?

Цитата(Neitron @ 27.10.2005, 21:56)

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

Цитата(Neitron @ 27.10.2005, 21:56)

В ассемблере, счетчиком цикла является регистр CX

При чём тут ассемблер? Сишные компиляторы вовсе не обязаны использовать CX. И они его не всегда используют.
Хорошо если они вообще испоьзуют регистр и loop. Что не всегда так.
Кстати, при break'е cx'ы тоже не обязаны занулится.
(хотя бы потому что в стандарте сей существование RCX/ECX/CX не оговаривается)

Это сообщение отредактировал(а) Mayk - 27.10.2005, 18:08

Coocky
Вот именно, ты сам только что ответил на вопрос.
Объекты не разрушаются, регистры не сбрасываются...

Цитата(Neitron @ 27.10.2005, 22:08)

Объекты не разрушаются,

У моего компилятора иное мнение на этот счёт

Код

class DestructMe {         public:                 ~DestructMe(){                         cout << "ff" << endl;                 } }; int main(int argc, char* argv[]) {     char c;     while(true){             DestructMe d;             goto ss;     } ss:; }

Цитата(Neitron @ 27.10.2005, 18:08)

Объекты не разрушаются, регистры не сбрасываются...

Дык я и говорю за то, что можно контролировать разрушение обьекта...
Разве это плохо?
И я еще не увидел ни одного НОРМАЛЬНОГО аргумента против goto, кроме привычки "неудобно"...

Цитата(Coocky @ 27.10.2005, 19:59)

Я иной раз использую goto. Когда мне удобно.

Не спорю. Фанатизму не место в программировании, и структурное программирование не догма. Но, ИМХО, в приведенных примерах goto не к месту. Совсем.

Цитата(Mayk @ 27.10.2005, 18:06)

Цитата(Neitron @ 27.10.2005, 21:56) соответсвенно выход производится после того как регистр уйдет в нуль. Цитата(Neitron @ 27.10.2005, 21:56) В ассемблере, счетчиком цикла является регистр CX При чём тут ассемблер? Сишные компиляторы вовсе не обязаны использовать CX. И они его не всегда используют. Хорошо если они вообще испоьзуют регистр и loop. Что не всегда так. Кстати, при break'е cx'ы тоже не обязаны занулится. (хотя бы потому что в стандарте сей существование RCX/ECX/CX не оговаривается)

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

Mayk

Ну хитрец!
А че в цикл засунул?
Ты цикл из goto сделай и выложи!

Цитата(Coocky @ 27.10.2005, 18:10)

Цитата(Neitron @ 27.10.2005, ) Объекты не разрушаются, регистры не сбрасываются... Дык я и говорю за то, что можно контролировать разрушение обьекта... Разве это плохо? И я еще не увидел ни одного НОРМАЛЬНОГО аргумента против goto, кроме привычки "неудобно"...

Для контролирования времени жизни обекта в Си++, придумали методы new и delete.

Это сообщение отредактировал(а) Neitron - 27.10.2005, 18:15

Цитата(Coocky @ 27.10.2005, 22:12)

Ну хитрец! А че в цикл засунул? Ты цикл из goto сделай и выложи!

да без проблем.

Код

int t=0; class DestructMe {         public:                 ~DestructMe(){                         cout << "ff" << t << endl;                 } }; int main(int argc, char* argv[]) {     char c;     t=5; ss:{            DestructMe d;            if(t != 0){                    --t;           goto ss;            }     } }

Я подвожу итоги!
три оператора могут(должны ) делать цикл
for, while, goto.
два первых-одно и тоже. Только вот goto работает без разрушения обьектов внутри него.
Ну и. Теперь слово за ненавидящими goto в пользу while и for

Цитата(Neitron @ 27.10.2005, 20:12)

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

Если имеется в виду x86 инструкции loop, то это уже давно не так. Цикл закодированный с помощью обычных команд перехода получается быстрее.

Mayk
И че-рушится?
А если фигурные скобки убрать?

Цитата(Coocky @ 27.10.2005, 18:12)

Ну хитрец! А че в цикл засунул? Ты цикл из goto сделай и выложи!

имелось в виду, что при выходе из блока с помощью goto объекты нормально удаляются...

А если вспомнить про немаловажную вещь как Стиль программирования С++?
Правильный и неправильный?
goto - неправильный.

Цитата(Neitron @ 27.10.2005, 22:12)

Не думаю, что реализации упускают такую возможность.

Я повторюсь, но у компиляторов иное мнение на этот счёт
(посмотри листинги борлы, вязанки, гнуса. Они далеко не все forы и whileы в луп пихают.

Код

for(int i = 0; i != 123; ++i)             t += i;

вот отрывок из асма(компилил как g++ -O3 a.cpp)

Код

LCFI4:         subl    $8, %esp .LCFI5:         movl    $5, %eax         andl    $-16, %esp         movl    %edx, t         xorl    %edx, %edx         .p2align 4,,15 .L9:         addl    %edx, %eax         incl    %edx         cmpl    $123, %edx         movl    %eax, t         jne     .L9         leave         xorl    %eax, %eax         ret

Добавлено @ 18:19

Цитата(Coocky @ 27.10.2005, 22:17)

А если фигурные скобки убрать?

Код

while(i < 5){   s+= i;   ++i }

А если фигурные скобки убрать? ©

Это сообщение отредактировал(а) Mayk - 27.10.2005, 18:22

Mayk

Цитата(Neitron @ 27.10.2005, 18:17)

А если вспомнить про немаловажную вещь как Стиль программирования С++? Правильный и неправильный? goto - неправильный.

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

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

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

Это сообщение отредактировал(а) Neitron - 27.10.2005, 18:27

Ладно и я домой.
Пока в goto ничего плохого с точки зрения работы не увидел..

Любопытно. Автор весьма пристрастен или лукавит. Небольшое изменение в его же коде( is_valid() - лишняя , а create при неудаче выбрасывает исключение) и все становиться весьма прозрачно и лаконично. В том числе и вывод лога. Можно кстати повозиться с темплайтаим и все встанет на свои места

Код

long fill_file( const char *psz ) {    try {          file    file;          file.create( sz_path );          unsigned    size = file.get_size();          file_mapping    map;          map.create( file.h );              void    *ptr = map.map_view();                   memset( ptr, 'a', size );          map.unmap_view( ptr );    } catch (myexception& err ) {           cout << err.what()           return err.code();     }     return 0; }

Сравниваем с этим

Код

long fill_file( const char *psz ) {     long    error_code = 0;     void    *ptr = 0;     HANDLE    hfile = 0, hmap = 0;     unsigned size;     error_code = 1;     hfile = CreateFile( psz, GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0 );     if( !hfile )goto _end;     error_code = 2;         size = ::GetFileSize( hfile, 0 );     hmap = ::CreateFileMapping( hfile, 0, PAGE_READWRITE, 0, 0, 0 );     if( !hmap )goto _end;          error_code = 3;     ptr = ::MapViewOfFile( hmap, FILE_MAP_WRITE, 0, 0, 0 );     if( !ptr )goto _end;          memset( ptr, 'a', size );     error_code = 0; _end:     if( error_code )_trace_file( 0, "error %d/%08x", error_code, ::GetLastError() );     ::UnmapViewOfFile( ptr );     ::CloseHandle( hmap );     ::CloseHandle( hfile );          return error_code != 0; }

Выводы делайте сами.

Цитата

Теперь слово за ненавидящими goto в пользу while и for

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

деление последовательности операторов на блоки {} лично мне очень помогает, оно позволяет структурировать код, даже необязательно, чтобы был какой-то цикл или условный оператор, создавать маленькие объекты в стеке на очень маленькое время, просто попользоваться и удалить

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

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

и, пожалуйста, не надо говорить "так не надо использовать goto для прыжком между блоками", потому что по той же логике не стоит делать в класах protected и private

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

Это сообщение отредактировал(а) maxim1000 - 27.10.2005, 18:33

Цитата(Vyacheslav @ 28.10.2005, 02:27)

Любопытно. Автор весьма пристрастен или лукавит. Небольшое изменение в его же коде( is_valid() - лишняя , а create при неудаче выбрасывает исключение) и все становиться весьма прозрачно и лаконично. В том числе и вывод лога. Можно кстати повозиться с темплайтаим и все встанет на свои места

В соответствии с упоминавшейся выше RAII функция-член create() тут тоже лишняя. А если её выбросить, то пропадёт неоднозначность в порядке вызовов деструкторов, что было одним из аргументов автора.

Цитата(maxim1000 @ 27.10.2005, 18:28)

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

а вот тут, уважаемый maxim1000, я бы возразил
попробовал сделать, то что описал, оказывается, что запрещено пропускать инициализацию объектов с помощью goto...
Добавлено @ 18:44
а для выходов из циклов, пожалуй, подходит...

Цитата(Coocky @ 27.10.2005, 18:04)

Цитата(Neitron @ 27.10.2005, ) является первым признаком, плохо спроектированного кода Аргументы? Что такое плохо спроектированный код. Назови мне разницу между циклами goto,for, while( не синтаксическую..) А как быть с обьектами, которые разрушаются, при выходе из цикла?

А Вы не создавайте в цикле , тогда и разрушаться не будут

Код

struct B  {     B() { s_number++;}     ~B() { m_number = 0; }      static int s_number;      int m_number; }; int B::s_number = 0; int main(int argc, char* argv[]) {   Label:   B b ;   cout <<  b.m_number  << endl;   b.m_number =    B::s_number ;   if  (B::s_number < 5 ) goto Label;   cout << b.m_number << endl;   return 0; }

И вот после этого начинаем думать в каких случаях когда удаляется и когда создается


А теперь делаем финт ушами

Код

struct B  {     int func(){ return m_number; }     int m_number; }; int main(int argc, char* argv[]) {        if ( true ) goto Label;   B b ;   b.m_number = 5;   Label: int result = b.func();   return 0;

Цитата

Кто сказал такое- твой преподаватель, друг , книжники буржуазные?

Лично у меня возникает вопрос почему все книжники так говорят?B ведь не С один в других языках анологично.Все пишут одно и тоже:
-это противоречит принципам структурного програмирования
-злоупотребление goto может привести к нестабильной работе приложения.
Никаких аргументов в доказательство этоих правил не приводится.Это как аксеома програмирования,но это таким не является.
Единственной мысолью которая у меня приходит в голову-это то что когда-то давным давно действительно goto(или подобный оператор) по каким то причинам использовать было опасно(к примеру компелятор плохо с ними спровлялся).В результате этого наложили на него табу.Прошло время и из покаления в покаление это табу передавалось,но никто не проверял правдивость этого правила.


ЗЫ А с чего все начиналось:c детской игрушки .

Цитата(nikitao @ 27.10.2005, 22:01)

-это противоречит принципам структурного програмирования

Как ни странно, нет Структурное программирование и программирование без goto часто путают. Это взаимосвязанные, но не идентичные понятия. Структурное программирование не исключает goto, более того, оно не требует языковой поддержки. Это просто подход к проектированию программ. В высокоуровневых языках при применении структурного программирования необходимость goto просто сводится на нет.
Ссылки в тему:
Дейкстра, Go To Statement Considered Harmful
Дональд Кнут, Structured Programming with Go To

Цитата(nikitao @ 27.10.2005, 22:01)

-злоупотребление goto может привести к нестабильной работе приложения.

Лишь косвенно, из-за потенциально низкого качества кода с использованием goto. Прямой связи нет.

Ну не нужен goto в высокоуровневых языках Единственное более-менее оправданное ему применение в C++ - выход из глубоко вложенных циклов, о чем уже неоднократно говорилось (и то, такие нагромождение циклов проситься на рефакторинг в отдельные функции). В остальных случаях goto банально неудобен.

Кстати, вот почему я прекратил спор.

Цитата

Существует очень мало примеров использования goto при программировании на высоком уровне, но эта инструкция можеты быть крайне полезна, когда С++ генерируется программой, а не человеком. Например goto могут быть использованы в анализаторе, сгенерированном по описанию грамматики. Инструкция goto может также оказаться полезной в редких случаях, когда требуется максимальная производительность, например во внутреннем цикле приложения, работающего в реальном вмерени. Одним из немногих разумных способов использования goto в обычном коде является выход из вложенного цикла или switch инструкции.

Надеюсь чья это цитата объяснять не нужно

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