Здравствуйте, мыщъх, Вы писали:

М> а вот пример кода, который читается только со второго повтора:

М>

М>for ( code = GetDebuggerEvent(WFNE_ANY|WFNE_CONT, -1); // resume
М>        code > 0;
М>        code = GetDebuggerEvent(WFNE_ANY, -1) )
М>  {
М>    r_eip = GetEventEa();
М>    if ( r_eip >= tea1 && r_eip < tea2 )
М>      break;
М>  }
М>

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

М>кстати, код взят отсюда:
М>http://www.hex-rays.com/products/ida/debugger/scriptable.shtml
М>и писал его выдающийся человек у которого есть чему поучиться. в том числе и тому, что в реальности приходится сталкиваться и с таким кодом, который шаблонным назвать трудно (хотя и к экзотике его не отнесешь).

Без вникания в суть кода можно сказать, что если GetDebuggerEvent(WFNE_ANY|WFNE_CONT, -1) вернёт неположительное нечто, то r_eip останется не изменённым и лови потом ошибку с не инициализированной переменной...

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

BFE>Здравствуйте, мыщъх, Вы писали:

М>> а вот пример кода, который читается только со второго повтора:
BFE> Я такой код читаю легко и сразу вижу потенциальную проблему. Но такой стиль я не люблю.
проблема там вообще-то в другом (код зависает в определенных ситуациях) и такой стиль я тоже не люблю. и чтобы исправить ошибку все нужно переписывать заново. но если вы такой код читаете легко, то x и y для вас уж точно не проблема, тем более что попытка конкретизации путем именования переменных "книга" и "цена" -- это в сто раз хуже, потому что в реальности сущности могут меняться (тот же амазон сначала только книгами торговал, а потом всем подряд).

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

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

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

BFE>Без вникания в суть кода можно сказать, что если GetDebuggerEvent(WFNE_ANY|WFNE_CONT, -1) вернёт неположительное нечто, то r_eip останется не изменённым и лови потом ошибку с не инициализированной переменной...
а как на счет -1 ? оно вообще никогда ничего не вернет. таймауты надо обрабатывать. вот повиснет оно и привет. причем, вечное ожидание это классика. понятно, что -1 это для простоты. но копипаста превращает эту простоту в тихий ужос.

Здравствуйте, мыщъх, Вы писали:

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


До сих пор, решая физические задачи, пишу нижние индексы для скоростей, сил, импульсов и масс, дабы не запутаться.
Конечная формула может получиться большой/длинной (если взаимодействующих объектов много).
Самое забавное здесь в том, что действия производятся именно со скоростями и импульсами, а не с абстрактными векторными величинами. До абсолютно абстрактного кода частенько пилить и пилить — иногда гораздо быстрее наколотить частный случай сейчас, чем сразу искать общее решение — выделить общее можно потом.