Перейти к контенту

Malandrinus

 Глобальные модераторы
  • Число публикаций

    1 915
  • Регистрация

  • Последнее посещение

10 подписчиков

О Malandrinus

Недавние посетители профиля

3 065 просмотров профиля
  1. Курилка программистов

    Ну это вообще классика. Конструкции вида: if (<условие>) return true; else return false; Вместо простого return <условие> всегда вызывали у меня ступор. Начинаешь гадать, а не имел ли в виду автор что-то премудрое, например последующее расширение кода типа такого: if (<условие>) { // сделать что-то перед возвратом значения return true; } else return false; Но потом всегда оказывается, что это стиль такой. Немного позанудствую, но это не оператор. Это два последовательных оператора логического отрицания. И поскольку в С/С++ значения и так автоматом интерпретируются как логические, то в использовании этой конструкции чаще всего нет нужды. О, да! Особенно использование неинициализированной переменной x1. Понятно, что это Паскаль, и там есть значения по умолчанию, но всё же это подрастрельная статья. Однако, этот код напомнил мне ещё об одном вполне легитимном использовании goto. Если надо организовать цикл из кода, который не влезает в один экран, то использование goto может оказаться предпочтительным перед встроенным циклом. Дело в том, что к структурным операторам прилагается соответствующее форматирование, в частности отступ. А если отступ идёт на огромный блок кода, то он не улучшает читаемость, а только ухудшает (структуру всё равно не показывает, поскольку не видно обеих границ, а только увеличивает пустое пространство слева). goto же отступа не требует. Типичный случай - главный цикл программы. Это обычно бесконечный цикл, и внутри него может быть до чёрта напихано. Это помимо уже упоминавшегося выхода из вложенных циклов. Ещё весьма важный случай - для нужд отладки и эксперимента. Хоть это и не должно попасть в готовую программу, но наличие такого инструмента может сильно упростить процесс разработки. Ещё вспомнил случай из своей практики. Был у меня код вида такого: lab1: // фрагмент сложного цикла 1 lab2: // фрагмент сложного цикла 2 if () goto lab1; // фрагмент сложного цикла 3 if () goto lab2; Т.е. цикл состоит из трёх фрагментов, где постоянной частью является фрагмент 2, а зависимости от условий перед ним или после него выполняется ещё какой-то код. Я пытался заменить это на использование структурных операторов, но всё выходило существенно хуже: более громоздко и намного менее очевидно.
  2. Курилка программистов

    Desertir, возможно кого-то это покоробит, но лично мне глубоко безразлично, что будут думать о моём коде другие люди. Я исхожу из того, что первым человеком, который будет сопровождать мой код, буду я сам. Поэтому я себе упрощаю жизнь. Если есть смысл использовать goto, и код от этого станет лаконичнее и понятнее, то я буду использовать goto. Нет смысла - не буду. Чаще всего он и не нужен. Но если таки нужен, то все теоретики идут лесом. Я признаться не понял, ты споришь со мной или соглашаешься. Судя по этой фразе, обсуждать вообще нечего. Если проблема не в инструменте, а в том, кто его использует, то и с goto нет проблем. Это ведь всего лишь инструмент. Как и любой инструмент, его надо использовать с умом, и будет тогда щастье. Поскольку без головы можно любую программу превратить в нечитаемое, непостижимое и неотлаживаемое УГ. И причём безо всяких там goto.
  3. Курилка программистов

    =) Злостное трюкачество. Да и вообще-то речь о другом. Я только хотел сказать, что сам по себе оператор switch - это в сущности не что иное, как goto на метку case xxx: У case даже синтаксис почти как у метки - заканчивается двоеточием - и логика работы в точности как у метки для перехода, т.е. туда тупо передаётся управление и продолжается выполнение далее по ходу (если нет break конечно). Сам break - это не что иное, как goto на метку, расположенную сразу за оператором for или switch. Оператор continue - просто замаскированный goto на метку, расположенную в конце тела цикла. Оператор return для внутренней реализации часто требует или дублирования кода завершения функции либо опять же представляет собой просто аналог перехода на метку в конце тела функции. Т.е. сам язык по-сути набит фиговыми листиками, едва-едва прикрывающими этот самый goto. Посему не вижу большого смысла быть святее Папы Римского и разводить большие разговоры насчёт неприемлемости использования этого оператора.
  4. Курилка программистов

    Не надо преувеличивать проблему. В точно такой же ад может превратить дебаг, исправление, понимание и т.д. не использование этого оператора там, где это уместно. Как, к примеру, в вышеприведённом совете паковать вложенный цикл в функцию. В С++, кстати, полно замаскированных операторов goto: switch, break, continue, множественные return - это всё по сути операторы goto.
  5. Курилка программистов

    Ты же сам и ответил на вопрос. Потому что реальное быстродействие зависит от приложения и от компилятора. К числу факторов могу ещё добавить скорость работы оперативной памяти. Память - это вообще узкое место современного компьютера, поскольку работает в несколько раз медленнее процессора. Как-то это компенсируется кешами, но есть куча приложений, где кеш не помогает, и скорость вычислений сводится к скорости чтения/записи. Собственно, это как раз и делает, среди прочего, реальную скорость вычислений так сильно зависимой от приложения, поскольку в разных задачах сильно разнится соотношение и порядок чтения/записи/вычислений.
  6. X-Ray extensions

    @7.9 К сожалению, это вряд ли осуществимо в виде ассемблерной правки (не считая того, что проект уже по-сути заморожен). В исходниках наверное можно сделать, но это уже другая история. Вообще же, не очень понятно, зачем вообще эта фича нужна. При текущем подходе для каждой пропорции надо всё равно делать набор конфигов руками. От этой работы никто не избавит (в рамках именно такого подхода). Получается, что движок должен только переключать наборы конфигов в зависимости от пропорций. Но это как раз совершенно спокойно можно сделать и вне движка: например в специальном ланчере. Я бы так и делал, а из движка это переключение вообще бы убрал (всё равно оно там сделано до невозможности криво и попросту убого).
  7. Курилка программистов

    Предложенные тобой варианты избыточны в плохом смысле. Дело в том, что размер элемента массива вообще хранить не нужно, поскольку в С/С++ эта информация связана с типом и меняться не может. Размер элемента "вкомпилирован" в код, а ты предлагаешь хранить его в ячейке памяти, что существенно медленнее работает. А в стандартном векторе С++, если мне не изменяет память, хранится не указатель на конец массива, а указатель на конец зарезервированной под массив памяти. Есть там даже специальный метод reserve() для резервирования этой памяти, а сам язык при наращивании размера массива добавляет резерв с запасом, который рассчитывает по определённому алгоритму. Т.е. там ничего избыточного нет.
  8. X-Ray extensions

    @НаноБот, вношу поправку в предыдущий пост. bsdiff использовался не столько для удобства публики, а скорее потому, что не хотелось вносить в состав публичного проекта правленый файл dll. Ну т.е. в сущности всё равно для удобства публики, поскольку иначе пришлось бы заставлять всех учиться добавлять секцию с помощью PE Tools =) Если вышеозначенное соображение насчёт присутствия правленного коммерческого бинарника не важно, то можно просто создать этот файл с пустой секцией один раз и затем его и использовать. Просто создавать батником копию перед переносом правок, а оригинал не трогать. В любом случае мучения с PE Tools - это ровно один раз на один проект. ЗЫ: Только не подумай, что я тебя отговариваю от написания своих утилит. Я просто уточняю как было. А так чем больше утилит, тем лучше. Если бы меня не стукнуло переписать вариант Колмогора, то мучились бы сейчас с его утилитой (там было больше ручной настройки).
  9. X-Ray extensions

    @НаноБот, Ну в целом bspatch использовался только для удобства публики. Исходно новая секция добавлялась с помощью PE Tools, а bsdiff/bspatch только создавал файл разницы и позволял его позже применять уже без PE Tools. Если знаете, как пользоваться PE Tools или чем-то подобным, то ничего другого не нужно.
  10. X-Ray extensions

    @НаноБот, автором bspatch.exe/bsdiff.exe является Colin Percival.Там есть исходники, но под Unix/Linux. Порт утилиты под винду сделал Andreas John. Его сайта уже нет, как и ссылки на скачивание. Однако, у себя нашёл. Авторами patcher.exe являются [member=Колмогор] и ваш покорный слуга. Колмогор изначально разработал методику бинарных патчей с дополнительной секцией и создал утилиту для этого дела. Я утилиту переработал для более удобного и автоматизированного использования. Вот исходники. Утилита ужасна внутри и наверняка имеет косяки, но доводить её до ума времени, да и желания, так и не появилось.
  11. Курилка программистов

    @Kondr48, Там есть ссылка на хорошее разъяснение сути. Там правда на английском. Полностью согласен с @abramcumner. Всякие тонкости, которые там обсуждаются, совершенно не важны для проектов на основе x-ray по той простой причине, что они по сути своей нелегальны. Так что беспокоиться не о чем - удалить могут так и так в любой момент.
  12. Курилка программистов

    Ну вот, можно было бы развести сочный пафосный холивар на тему "как единственно верно инициализировать глобальные таблицы". Но это, выходит, только "для посвящённых". Скучно.
  13. Курилка программистов

    @Dennis_Chikin, прошу прощения, но я либо что-то пропустил, либо совсем в танке. Ничего не понял, о каких именно файлах с таблицами речь?
  14. Курилка программистов

    @Дизель, так а какая мораль? Выходит, x-ray не так уж плох, если тянул это без проблем да ещё и на весьма древнем железе.
  15. Курилка программистов

    Эта функция сама аттач не выполняет, а только вызывает метод attach_Actor у холдера. Это именно то, о чём я и говорил. Без наличия основного функционала ничего бы вернуть не удалось. Опять же с точки зрения исходников (а бинарные правки я вообще не вижу смысла обсуждать) и вовсе ничего не вырезано, поскольку разрабы даже не потрудились удалить фрагмент кода. Вернуть обратно - стереть четыре символа.
×