Забавные новости 0й-Ti :)

Тема в разделе "WASM.HEAP", создана пользователем UbIvItS, 18 июн 2018.

  1. E.D.

    E.D. New Member

    Публикаций:
    0
    Регистрация:
    8 окт 2017
    Сообщения:
    1
    даа, это не Ассемблер, чёрт ногу сломит :crazy:
     
  2. f13nd

    f13nd Well-Known Member

    Публикаций:
    0
    Регистрация:
    22 июн 2009
    Сообщения:
    1.967
    Юзал. Это по-моему теперь самый популярный кряк на винду. И он лежит на гитхабе.
    Разрабы в общих чертах описали используемые методы https://massgrave.dev/kms38
     
    Marylin нравится это.
  3. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.124

    охЪЪЪ, уж этих исследователей этих развелось - аж жуть :) уязвимостью можно называть лишь тогда, когда прописаны чёткие шаги элевации прав хотя бы до уровня обычного юзвера без сознательного участия жертвы, а нет - йййййдите Лесом-де Садом, клоуны :)
    --- Сообщение объединено, 7 май 2024 ---
    для выч задач ничего лучше сихи и фортрана ничего не было да быть не может.. хотя сам фортран тоже вполне можно выкинуть на свалку, пч всё мб реализовано сихой - и код шустрей получается, и интеграция в среду удобней + для кучи расчётов нужна длинная арифа. Лучше, чем сихой, её реализовать невозможно - компиль тамо самый лучший :)
     
    alex_dz нравится это.
  4. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.270
  5. q2e74

    q2e74 Active Member

    Публикаций:
    0
    Регистрация:
    18 окт 2018
    Сообщения:
    994
    Rel, может он не особо понимает клинкод? как бы если есть интерфейсы, то откуда наследование, оно зачем? Если стоит задача добавить что-то в существующий код, то лучше что бы там всё было на полиморфизмах, чем на жестких свичах, которые еще размазаны по разным местам. А перформанс тоже лучше поднимать не во всей проге сразу, а расширяя бутылочное горлышко. Просто нет ничего хуже преждевременной оптимизации, потому перформщики и просрали всё на свете.
    --- Сообщение объединено, 10 май 2024 ---
    короче всю утиную типизацию и интерпретаторы на мыло отправил ради перформанса.
    --- Сообщение объединено, 10 май 2024 ---
    а лисп тем временем продолжает жить
     
    Последнее редактирование: 10 май 2024
  6. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.270
    Да, он не понимает клинкод. Проблема в том, что обе стороны конфликта (и адепты клинкода и адепты на 2 процента более быстрых циклов) не понимают одной важной вещи: если код будет идеально чистым, то он будет гораздо медленнее, чем он мог бы быть; если код будет идеально быстрым, то его будет слишком сложно поддерживать. В реальном мире нет идеального ни одного, ни другого, но почему-то одни продолжают навязывать одно, а другие - другое.
     
    q2e74 нравится это.
  7. q2e74

    q2e74 Active Member

    Публикаций:
    0
    Регистрация:
    18 окт 2018
    Сообщения:
    994
    Идеальный код не надо поддерживать, и мир вокруг него не меняется. Вот тогда он может позволить себе топовый перформанс. Есть ситуации, где улучшение на процент приводит к увеличению прибыли, но это редко. Клинкод это про то, как "х%к х%я и в прод" с костылями, которые меньше навредят в дальнейшем. Именно что с костылями, а не совсем без них. Просто садиться за код надо в последнюю очередь, и нормально качестсвенно отрабатывать аналитикам и архитектору. Но это не очевидно с позиции кодера, вот и вечные зарубы у спецов. Как бы так соломку подложить, прежде чем выяснится что эффективно бежали не в ту сторону, и теперь надо разворачиваться.
     
  8. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.124
    вот возьмём, к примеру, dry (don't repeat yourself) - очень плохая идея..
    допустим, у нас 10 фунок пользуют одну базовую и нам нужно написать 11ую, коя тоже должна пользовать ту базовую, но нам необходимо внести изменения в базовую для удовлетворения нужд новой функи. что делать??? можно зафигачить изменения в базовую и сношаться с отладчиком по всему древу зависимостей. А можно скопировать базовую и сделать серию минорных изменений под новую функу.. то бишь мы проводим Атомизацию Кода и лишаем себе туЕвой Хучи печалей + АК помогает спид-апу проги и улучшает её портабельность + улучшаем читабельность кода, лишая себя мути доп условных ветвлений. Короче, правила спид-апа кода гораздо ближе к Чистому Коду, чем тот замшелый клинкод. потом - чем Тебе те свичи не нравятся - пользуй инлайн функи ==>> вот Тебе читабельность да спид-ап в одном флаконе :grin:
     
  9. q2e74

    q2e74 Active Member

    Публикаций:
    0
    Регистрация:
    18 окт 2018
    Сообщения:
    994
    UbIvItS, если про атомарность - так я только за. Чем не нарвятся свичи. Если я хз какой потом новый тип придумает заказчик, то это однозначный повод залепить диспатчер по типу, внутри которого по требованиям интерфейса должен быть метод. И когда надо будет добавить, то нужно будет именно добавить, а не читать и вникать, что куда можно, а что куда нельзя. Итератор по списку имхо легче читать, чем держать в голове разные ифы на все случаи жизни.
     
  10. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.124
    а нельзя быть за АК и бегать с интерфейсами клинкода :) клинявый код подразумевает работу сугубо с интерфейсами - у Тебя задача и Ты смотришь аким дикобразом её решить чрез набор доступных. но что происходит, когда не хватает функционала базовых модулей??? dry требует впихнуть новые функи, не нарушая кол-во модулей - ведь, повторяться нельзя :) клинявый код приводит к длинным абстракциям, что ввергает всю идею к полному Абсурду. абстракция не должна становиться источником проблемы, а размер длинной абстракции легко превышает весь базовый код в разы и в итоге погружаешься в кромешный идиотизм ==>> тестирование и отладка абстракций:laugh1::laugh2::laugh3:
     
  11. Aoizora

    Aoizora Active Member

    Публикаций:
    0
    Регистрация:
    29 янв 2017
    Сообщения:
    355
    А как относитесь к паттернам проектирования в промышленной разработке? Они нужны или нет?
     
  12. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.124
    там, где прога начинает рулить реальные объекты с высоким индексом цены/риска, вступают в действие доп ограничения и они, конечно, нужны в силу сугубо практического опыта. но, вообще, софтина очень педальная хрень в плане реальной безопасности: например, в электрической цепи элементарная пробка тупо на порядки более надёжное решение, нежель самый надёжный софтинный вариант. :)
     
  13. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.270
    Особенно, когда пишешь софтину на Цэ...
     
  14. aa_dav

    aa_dav Active Member

    Публикаций:
    0
    Регистрация:
    24 дек 2008
    Сообщения:
    448
    Ну если площадь треугольника через полиморфизм решать, то действительно можно добиться ускорения выкидыванием этого лишнего и подгонкой данных в кеш.
    Я давно и планомерно пропагандирую мысль, что за термином ООП в глобальных масштабах закрепилось очень неправильное и кишмишное понимание, которое смешало коней и блекджеков в плохо перевариваемую кашу из мантр.
    На самом деле всё просто - ООП это принцип Лисков и точка. Вот так просто - ООП-нутый код это код в котором используется подстановка ссылок на производные классы через ссылку на базовый в расчёте использования виртуальных функций. Всё. Ничего более. Если даже в коде пестрит ключевое слово class, но этот приём не используется - его всегда можно трансформировать в код из функций и структур как писали fopen и matrix3x3_multiply деды и в ус не дули до всякого ООП. Потому что это не ООП.
    Так вот главная суть ООП - это как видно полиморфизм, когда мы пишем код который будет работать с заранее неизвестно каким объектом удовлетворяющим некоторой спецификации состоящей из виртуальных его функций. И эта штука реально нужна в сложных программах когда мы чаще всего сталкиваемся с коллекциями однотипно ведущих себя, но разных объектов - как то монстры в игре или визуальные компоненты на окне GUI или разные типы XML сообщений Сервиса Электронного Документооборота Социального Фонда России - разные типы объектов монотонно перемалываются в разнообразных циклах item.Draw, item.ProcessXML, item.TakeDamage и т.п. Вот тут ООП на коне. И тут городить switch-и себе дороже. И оно не cache-friendly уже просто потому что разные объекты разного размера не поместишь в один массив. Это по природе вещей штука не cache-friendly. Абстракция такая прикольная тут действительно бьёт по перфомансу.
    В то же время огромное количество кода этого просто не требует. И не является ООП-нутым. И может быть сведена к локальности данных в массивах и тому подобное.
    Поэтому прежде чем считать площади треугольников через полиморфные объекты надо сперва спросить себя - а тебе действительно нужны полиморфные объекты или тут можно обойтись без ООП?
    Если можно обойтись без ООП, то и clean code будет без ООП, а если нельзя - ну хоть тресни ты, но надо нарушать cache-frendliness в пользу чистого кода. Или задумываться об Entity Component System.
    Предположу, что истинная ошибка этого автора книг про чистый код - это как раз неправильное понимание ООП и завет решать все проблемы этим микроскопом, включая забивание гвоздей. Но я книг его не читал и просто предполагаю.
     
    Последнее редактирование: 13 май 2024
  15. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.124

    ета керь ии-шечкой сгенерина :)
    разные объекты не могут себя вести однотипно ==>> лишь для юзверя создаётся ИЛЛЮЗИЯ однотипности, а при разработке кода для каждого объекта прописываются серии коррекций в зависимости от размера/структуры данных и железа, на коем оное безобразие должно пахать. куча ооп-еров по своей сути тоже юзвери, они никогда не видели базовых фунок ооп-ского кода, а просто фигачили расширения чрез интерфейсы :)
    конечно, сиха богомерзкая и нам всем надо полностью забить на её самый лучший компиль, самые удобные средства отладки и самую обширную базу СТАБИЛЬНОГО КОДА :laugh1::laugh2::laugh3: глянь crates.io ==>> тамошняя публика так бодро пишет ржачные коды, что даже мой ноу нейм пет проект часто мелькает на первой странице:blush2::crazy::drinks:
     
  16. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.270
    Какой компиль? Clang? Это тот же Clang, бекенд которого использует Ржавый и тонна других языков? Или, может, GCC? Это тот же GCC, который имеет фронтэнды Ады, Дэ и Фортрана и один общий для всех бекенд?
     
  17. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.124
    кхммм.. :) даже на одном компиле у сихи будет самый быстрый код, пч нет по дефолту той туевой Хучи ограничений, что задаёт тот же ржака иль ада ==>> базовый компиль делается именно под сиху, остальное с боку-припёку :grin:
     
  18. Rel

    Rel Well-Known Member

    Публикаций:
    2
    Регистрация:
    11 дек 2008
    Сообщения:
    5.270
    А ну да, ну да, как же я забыл, что качество компилятора определяется отсутствием в языке абстракций, там же циклы на 2 процента быстрее...
     
    Mikl___ нравится это.
  19. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.124
    экий же Ты терпила - сидишь на осях, написанных богомерзкой сихой :laugh1::laugh2::laugh3: харе терпеть такое безобразие ==>> выключи сю мерзость из розетки иль сразу топором по системнику.. УБЕЙ СИХУ ВЕЗДЕ И ГЛАВНОЕ В СЕБЕ :popcorm2::grin:
     
  20. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.124
    самое опасное, что глюки ии-шки могут перекидываться на людей, эдакий ментальный/соц вирус получается.