N> do { // pseudo-cycle to destruct tempRasters BEFORE doc-switching & CloseDocument()
N> KompasIteratorHolder tempApprox(CreateIterator(ALL_OBJ, 0)); // GetViewReference(0)));
N> if(!tempApprox) break;
N> elem = MoveIterator(tempApprox, 'F');
N> } while (0);
N>
N>вот это что за цикл на одно действие?
Стандартная императивная конструкция, предоставляет блок (scope), из которого можно выйти по break. Также широко используется в препроцессорных дефайнах, если нужен блок, но { ... } использовать нежелательно.
Здравствуйте, GhostCoders, Вы писали:
GC>Данный код был написан моим сотрудником. Мне этот код не нравится, но он мне отвечает что я субъективен и его код неплох.
GC>
Здравствуйте, Qbit86, Вы писали: Q>Стандартная императивная конструкция, предоставляет блок (scope), из которого можно выйти по break. Также широко используется в препроцессорных дефайнах, если нужен блок, но { ... } использовать нежелательно.
Ну конкретно тут в чем плюс его использования?
Понимаю если бы там макросы были, а так...
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, -n1l-, Вы писали:
N>>
N>> do { // pseudo-cycle to destruct tempRasters BEFORE doc-switching & CloseDocument()
N>> KompasIteratorHolder tempApprox(CreateIterator(ALL_OBJ, 0)); // GetViewReference(0)));
N>> if(!tempApprox) break;
N>> elem = MoveIterator(tempApprox, 'F');
N>> } while (0);
N>>
N>>вот это что за цикл на одно действие?
Q>Стандартная императивная конструкция, предоставляет блок (scope), из которого можно выйти по break. Также широко используется в препроцессорных дефайнах, если нужен блок, но { ... } использовать нежелательно.
И насчет стандартности я бы поспорил, да трюк do {} while (false) для макросов
это стандартная идиома,
но вот блок для которого можно выйти по "break",
редко встречающаяся.
Здравствуйте, Zhendos, Вы писали:
Z>Разве не намного проще?
Возможно, перед нами артефакт незавершённого упрощения — изначально блок был сложнее и содержал больше выходов по break.
Z>но вот блок для которого можно выйти по "break", Z>редко встречающаяся.
Иногда встречается в длинных многошаговых инициализациях, где по break осуществляется фоллбэк, аналог goto-перехода к метке error.
Здравствуйте, -n1l-, Вы писали:
К>>Это прикольнейшая идиома. Это не цикл, а goto end. В роли goto используется break. N>И типа if тут никак? Чем это хуже?
Здравствуйте, -n1l-, Вы писали:
N>Ну конкретно тут в чем плюс его использования?
Вообще по правильному ( в теории, но не на практике ) вместо такого while(1) {;;; break;} или do {}while(0); надо делать функцию в которой уже выходить на end просто по return.
Но на практике особенно там где код не оптимизируют ( ядро например ) но производительность требуется используют такой вот метод.
while (1){
HANDLE h = open();
if ( !h )
break;
while (1){
s=write(h,"{");
if ( !s )
break;
write(h,"abc,def,uuu");
write(h,"}");
break;
}
close(h);
break;
}
то есть это по уму, по идеализму надо заменять на функцию даже если она один раз вывывается, но еще не понятно что яснее — функция которая написана только для того чтобы брековаться по return вместо goto.
То есть есть такие операции которые требуют "операций скобок" — открыл -> надо закрыть, записал начало "{" надо записть и конец "}". И так делее.
В этом случае в конце кода действий возникает логика — а открыли мы или нет, и если открыли надо закрыть. И так далее.
Но если применять логику иную — типа создавать объект у которого есть свойсто "открыть" и есть констуктор и есть деструктор то тогда такая логика с проверкой а мы открыли или нет в том же деструкторе выглядит логично. Но если это просто небольшой код, и нет нужды городить обьекты и классы, ну как я уже сказал в ядре например. Где эфективность важнее красоты, а оптимизации от компилятора нет, то пишут вот так — ну не очень красиво, но по привыкнешь — нормально.
Здравствуйте, uzhas, Вы писали:
U>эта "идиома" в плюсовом коде не нужна. в старом добром Си — на здоровье
Предложи наглядное решение на С++. Мне вот интересно.
Здравствуйте, Кодт, Вы писали:
К>>>Это прикольнейшая идиома. Это не цикл, а goto end. В роли goto используется break. N>>И типа if тут никак? Чем это хуже?
По-моему этой идиоме место только в коде на C и только для идеологических противников goto cleanup
Здравствуйте, GhostCoders, Вы писали:
GC>Данный код был написан моим сотрудником. Мне этот код не нравится, но он мне отвечает что я субъективен и его код неплох.
Вы еще попробуйте код показать на http://codereview.stackexchange.com/
Я думаю, там будет устроен разнос.
На мой взгляд, код ужасен.
Чтобы не быть субъективным, нужно принять стандарт оформления кода и встроить линтер на прекоммит.
Тогда никто не сможет писать в одном месте "m_", "_" или просто "someMemberName".
Принять решение о написании тестов. Тогда никто не будет писать таких огромных классов.
Использовать VCS, их куча на выбор, тогда не будет никаких закомментированных участков кода.
Организовать код-ревью если не каждого коммита в master, то хотя бы важных фич.
Тогда Вы сможете аргументировать.
Я понимаю, что это может показаться сложным и довольно дорогим в смысле времени и денег.
Но представьте, сколько Вы готовы потратить на содержание сотрудников, которые пишут ужасный код, но разбираются в нем, и поэтому их не уволить?
На отладке, потому что нет тестов и все проверяется вручную?
На поддержке, потому что нужно по пеплу орла и кофейной гуще гадать что сломалось у клиента?
Перекуём баги на фичи!
