Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, Erop, Вы писали:
E>>Предлагаю делать так:
E>>
E>>if (!_CreateDir(sFile)) {
E>> // возможно обработка ситуации
E>> return false;
E>>}
E>>if (!CopyFile(lpszTemp, sFile, FALSE)) {
E>> // опять возможна обработка ошибочной ситуации
E>> return false
E>>}
E>> return _tcsicmp(m_lpszFile, sFile);
E>>И понятно, и отлаживать удобно и поддерживать и доп. диагностику есть куда вставлять -- идеальный вариант однако
GN>Идеальный, если можно делать return;.
2 вопроса:
1. А почему может быть нельзя делать return?
2. (вытекающий из ответа на первый ) А мы про C или про C++ говорим?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
It's kind of fun to do the impossible (Walt Disney)
PD>>1. А если хоть одна функция в этой последовательности void ?
PD>Сорри, не совсем точно выразился. Я имею в виду, что внутри if ставится код в {}, и в нем вызываются void функции. Или что-то еще.
В данном случае operator , может быть заюзан (вместо ; )
Здравствуйте, Erop, Вы писали:
E>И понятно, и отлаживать удобно и поддерживать и доп. диагностику есть куда вставлять -- идеальный вариант однако E>(Всё ИМХО, ясень фуясень
Ну, имхо, это ещё страшнее, чем просто куча вложенных if-ов.
Потому что код растёт очень сильна как. Я так раньше писал, но разочаровался.
А если ещё требуется какая-то зачистка перед выходом, то это вообще почти неприемлемый вариант: либо юзай "goto finish" вместо return, либо Copy-Paste.
Здравствуйте, ssm, Вы писали:
ssm>Здравствуйте, gear nuke, Вы писали:
GN>>Идеальный, если можно делать return;.
ssm>если нельзя сделать return, всегда можно сделать break в фиктивном do{...}while(false);
Ж)
Уж тогда лучше "goto".
Здравствуйте, Chez, Вы писали:
R>>ИМХО данная записть основана на том что при разборе логических выражений выхдй из отношения "&&" происходит сразу же если текущий оператор равен 0 (тек поступают большинство компиляторов). Но никто не запрещает компилятору разбирато логические выражения полностью. сооьветсвенно он вызовет все функции. А вот отловить этот баг в данном случае будет проблематично. C>Выделенное курсивом — верно C>А вот выделенное жирным неверно — это запрещает Стандарт С++.
Только не в случае перегруженного оператора && для возвращаемых типов — тогда оба подвыражения будут вычислены полностью.
Здравствуйте, Alex Alexandrov, Вы писали:
GN>>Идеальный, если можно делать return;.
AA>2 вопроса:
AA>1. А почему может быть нельзя делать return?
Не всегда можно вынести часть кода в отдельную функцию.
Например — конечные автоматы (те, которые не table-driven, а забыл как называются )
AA>2. (вытекающий из ответа на первый ) А мы про C или про C++ говорим?
Исходя из ответа, в данном случае нет разницы.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, ssm, Вы писали:
GN>>Идеальный, если можно делать return;.
ssm>если нельзя сделать return, всегда можно сделать break в фиктивном do{...}while(false);
Не всегда. Цепочка if {} else {} может уже быть внутри цикла while(){}. Только не говорите что можно перейти на D .
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Erop, Вы писали:
GN>>Идеальный, если можно делать return;.
E>Ну я вообще ратую за короткие и простые функции с ясной семантикой
Я тоже, но иногда приходится делать длинные и сложные.
E>Ну а для такого сложного действия, как обсуждается тут (там помнится речь шла о десятке if'ов ) совершенно точно стоит заводить отдельную функцию
ИМХО, если у этой функции будет куча параметров ссылок — только читаемость усложнит.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re: Вместо if-ов
От:
Аноним
Дата:
27.09.05 15:02
Оценка:
Здравствуйте, Chez, Вы писали:
C>Придумалась тут одна шняга, выглядит очень симпатично! C>Вместо того, чтобы городить конструкции типа:
Здравствуйте, gear nuke, Вы писали:
GN>>>Идеальный, если можно делать return;.
E>>Ну я вообще ратую за короткие и простые функции с ясной семантикой
GN>Я тоже, но иногда приходится делать длинные и сложные.
E>>Ну а для такого сложного действия, как обсуждается тут (там помнится речь шла о десятке if'ов ) совершенно точно стоит заводить отдельную функцию
GN>ИМХО, если у этой функции будет куча параметров ссылок — только читаемость усложнит.
В случае, если приходится разбирать на запчасти функцию с большим количеством внутренних переменных, используется рефакторинг Replace Method with Method Object [Martin Fowler et al. Refactoring: Improving the Design of Existing Code, глава 6].
You have a long method that uses local variables in such a way that you cannot apply Extract Method.
Turn the method into its own object so that all the local variables become fields on that object.
You can then decompose the method into other methods on the same object.
Mechanics
Stolen shamelessly from Beck [Beck].
Create a new class, name it after the method.
Give the new class a final field for the object that hosted the original method (the source object) and a field for each temporary variable and each parameter in the method.
Give the new class a constructor that takes the source object and each parameter.
Give the new class a method named “compute”.
Copy the body of the original method into compute. Use the source object field for any invocations of methods on the original object.
Compile.
Replace the old method with one that creates the new object and calls compute.
Now comes the fun part. Because all the local variables are now fields, you can freely decompose the method without having to pass any parameters.
Здравствуйте, Centaur, Вы писали:
C>В случае, если приходится разбирать на запчасти функцию с большим количеством внутренних переменных, используется рефакторинг Replace Method with Method Object [Martin Fowler et al. Refactoring: Improving the Design of Existing Code, глава 6].
У Саттера авторство Фаулера/Бека не упоминалось, но предлагалось то же самое под С++-соусом — превратить функцию в function-object (т.е. вместо compute() — operator()).
Здравствуйте, Centaur, Вы писали:
C>В случае, если приходится разбирать на запчасти функцию с большим количеством внутренних переменных, используется рефакторинг Replace Method with Method Object [Martin Fowler et al. Refactoring: Improving the Design of Existing Code, глава 6].
Спасибо, но это решение для общего случая.
А частный случаи бывают разные. Например, лексер для JIT компилятора, для которого важнейшим фактором является скорость работы. Table-driven автоматы и прочие вкусности плохо подходят под это условие. Ну и читаемость кода там важна только на момент написания, потомучто — написал и забыл.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>Не всегда можно вынести часть кода в отдельную функцию. GN>Например — конечные автоматы (те, которые не table-driven, а забыл как называются )
Имеется в виду НКА? Не совсем понятно, почему нельзя его разбить на несколько функций. Рекурсия мешает? Впрочем, я не большой специалист в области конечных автоматов, поэтому просто заглянул в исходники PCRE — Perl Compatible Regular Expressions, как отличный пример НКА реализации на C. Безумных вложений условных конструкций не нашел.
AA>>2. (вытекающий из ответа на первый ) А мы про C или про C++ говорим?
GN>Исходя из ответа, в данном случае нет разницы.
Судя по всему, все-таки есть. Ибо как пример с невозможностью разбить код на несколько функций несколько надуман. В конце концов, inline функции еще никто не отменял. Это закон жанра: код должет быть либо удобочитаемым, либо автогенерируемым из чего-то удобочитаемого. Все остальное — от лукавого.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
It's kind of fun to do the impossible (Walt Disney)
Здравствуйте, Alex Alexandrov, Вы писали:
GN>>Не всегда можно вынести часть кода в отдельную функцию. GN>>Например — конечные автоматы (те, которые не table-driven, а забыл как называются )
AA>Имеется в виду НКА?
Детерминированные\недетерминированные — это классификация по другому принципу. Я имею ввиду, что обычно адреса переходов лежат в массиве-таблице, потом оттуда вытаскиваются и используются. Мне это не подходит — скорость критична, а на косвенной адресации она теряется. Поэтому приходится городить условные переходы.
AA>Не совсем понятно, почему нельзя его разбить на несколько функций. Рекурсия мешает? Впрочем, я не большой специалист в области конечных автоматов, поэтому просто заглянул в исходники PCRE — Perl Compatible Regular Expressions, как отличный пример НКА реализации на C. Безумных вложений условных конструкций не нашел.
PCRE и всё остальное — это хорошо, но это С. У меня же от С только язык написания, реально char'ы обрабатываются по 1, 2 или 4 за операцию. Другими словами, переписывается код с ассемблера . Безумных конструкций нет, просто длинные они.
AA>>>2. (вытекающий из ответа на первый ) А мы про C или про C++ говорим?
GN>>Исходя из ответа, в данном случае нет разницы.
AA>Судя по всему, все-таки есть. Ибо как пример с невозможностью разбить код на несколько функций несколько надуман. В конце концов, inline функции еще никто не отменял.
Проблема скорее в удобстве написания чернового варианта — так весь код перед глазами, и если правится в одном месте, то сразу видны зависимости. Функции же скрывают реализацию, поэтому несложно что-то пропустить.
AA>Это закон жанра: код должет быть либо удобочитаемым, либо автогенерируемым из чего-то удобочитаемого. Все остальное — от лукавого.
Не всегда это верно — ассемблер считается плохочитаемым, но его всё равно используют когда нужно. Так что, у меня тут по читаемости можно даже сказать прогресс .
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
[...]
GN>Проблема скорее в удобстве написания чернового варианта — так весь код перед глазами, и если правится в одном месте, то сразу видны зависимости. Функции же скрывают реализацию, поэтому несложно что-то пропустить.
AA>>Это закон жанра: код должет быть либо удобочитаемым, либо автогенерируемым из чего-то удобочитаемого. Все остальное — от лукавого.
GN>Не всегда это верно — ассемблер считается плохочитаемым, но его всё равно используют когда нужно. Так что, у меня тут по читаемости можно даже сказать прогресс .
Все-таки какая-то у тебя весьма специфическая область деятельности. Только никак не могу понять по постам точно — какая. С одной стороны, вроде как Rev. Eng. С другой, в оптимизации тоже шаришь. Похоже, что ты чьи-то оптимизированные бинарники в C/C++ перегоняешь.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
It's kind of fun to do the impossible (Walt Disney)
Здравствуйте, Alex Alexandrov, Вы писали:
AA>Все-таки какая-то у тебя весьма специфическая область деятельности. Только никак не могу понять по постам точно — какая. С одной стороны, вроде как Rev. Eng. С другой, в оптимизации тоже шаришь.
Оптимизацию необходимо понимать, поскольку не всё скомпилировано трансляторами от Борланд .
Да и не верю я, что компиляторы могут сделать конфетку из абы как написанного кода, поэтому стараюсь им помогать.
AA>Похоже, что ты чьи-то оптимизированные бинарники в C/C++ перегоняешь.
В данном случае — свои сорцы написанные на С-- (компилятор не справляется, при компиляции проявляются баги ). Но бывает и чужие нужно. Поэтому и пытаюсь создать компилятор, который будет понимать ассемблер, являющийся одновременно и валидным С.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
задаче — имхо приемлимо , но в Вашем случае — по рукам бы надавал . Хотя бы потому что обычно нужно анализировать, почему директория не создалась или файл не скопировался, и выполнять соответствующие действия, например сообщение пользователю выплюнуть.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)