Wataru

Из документации:

You cannot paste a DIB section from one application into another application.

Можно после изменения данных в DIB section сделать нормальный битмап через CreateDiBitmap.

А еще лучше, вместо CreateDIBSection, скопируйте данные из битмапа через GetDIBits, измените их и скопируйте назад в битмап через SetDIBits.

Это ассимптотическая сложность O(n log n). В ассимптотической сложности константа не имеет значения. И 2n, и 1000n - все одно O(n). При изменении основания логарифма у вас появится лишь константный множитель, который O() игнорирует, ведь log_а (n) = log_b(n) / log_b(a). Поэтому можно использовать вообще любой логарифм.

В компьютерной науке обычно используют логарифм по основанию 2. Потому что в алгоритмах вылезает именно деление на 2, а не на 10 и тем более не на e.

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

Читайте документацию: https://learn.microsoft.com/en-us/windows/win32/ap...

This function only affects the layout for the current process or thread.

Эта функция не может поменять раскладку в системе.

Попробуйте вот это: https://learn.microsoft.com/en-us/windows/win32/ap...

Вот как вы себе представляете: вызов одной и той же функции должен вернуть разные типы для разных индексов?

Нет, в C++ статическая типизация, одна функция может вернуть только один тип. Из List'а вы только Base вернуть и можете. А уже как-то опросив экземпляр класса с помощью виртуальных методов, вы сможете узнать, какого же он на самом деле типа и скастовать к нему.

В крайнем случае, можно сделать шаблонный метод, который будет возвращать тип, указанный в параметре шаблона. Но, опять же, вызывающий код должен будет сам решить, а какой же тип ему нужен.

Или хранте и возвращайте std::Variant, а не указатели на базовый класс.

Еще проще будет дизассемблировать исполняемый файл и заменить условный переход на безусловный в файле. Не во время исполнения, а на диске. Или вообще в начало функции вставить ret 1 куда-нибудь.

Вот так прям в памяти патчить, то это опасно. Вдруг функция исполняется в момент перезаписи?
Но если так хочется, то проще прям в памяти захардкодить return true. каким-то образом.

Вы там куда-то E9 вставили, и так поменяли код команды на jmp. Но адрес поменяли неправильно. Вставьте в первые несколько байт код ret 1 и все заработает.

Что у вас за опции сборки (Это же с++, не смотря на теги же?) Оптимизация-то включена? GCC 14 даже без оптимизаций выдает именно второй код в обоих случаях.

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

Если вы вставите более полный пример кода на godbolt.org, воспроизведете проблему, и поделитесь ссылкой, то, возможно, я смогу вам более детально ответить.

Edit:
Разобрались, что это clang c. Такой код он выдает с -O0. Если же оптимизации включены, то он его оптимизирует. Это не недочет или ошибка. Просто, вот такой у него стандартный код. Он вправе засовывать константы в секцию данных, а не вставлять прям в ассемблерный код.

А как вы адрес получали? Похоже, что с ним фигня.

Попробуйте запустить вашу программу в отладчике с брейкпоинтом по загрузке (видимо, нужно будет windbg использовать какой-нибудь. Не знаю, как это сделать в IDE). Пропустите загрузку всех модулей и потом ставьте брейкпойнт в вашем MainThread. Там пройдитесь до, собственно, вызова auth и посмотрите, по какому адресу оно сделает вызов. Потом, посмотрите в отладчике же, а какой же адрес у auth. Они точно совпадают?

Еще, а не рабатает ли, если auth в вашем взламываемом экзешнике объявить тоже _stdcall? Не помню, какое там соглашение по вызову по стандарту применяется, но надо чтобы они были одинаковы в коде экзешника и в вашей дллке.

DSU выполняет две операции: проверить, принадлежат ли 2 элемента одному множеству; объеденить множества двух данных элементов. Обе за O(log*n) ассимтотически. Это не логарифм, а суперлогарифм, или обратная функция Аккермана. Это - сколько нужно двоек сложить в степенную башню, чтобы набрать n. Она растет так медленно, что ее можно считать константой на практике (она достигнет 4 только при n=2^65536 - вы столько числел не сохраните во всех датацентрах мира).

Я бы в качестве альтернативной, "тривиальной" реализации рассматривал массив пометок + списки в массиве:
для каждого элемента храним номер его множества, а для каждого номера храним список всех его элементов в списках (так же, как и в DSU, в одном массиве ссылок на следующий элемент).

Эта структура компактна по памяти и более быстра, чем ваши хеш таблицы. Тут можно за O(1) проверить, что два числа в одном множестве и за O(log n) объеденить два множества (амортизированно, если перекрашиваем меньшее множество).

Итак, имеем O(Log*n) vs O(1) за проверку и O(log*n) vs O(log n) за объединения.

Т.е. вроде бы имеет смысл использовать пометки+списки, если у вас заметно больше проверок, чем объединений.

Но на практике там выигрыша нет, ибо редко когда у вас сильно больше проверок. Да и, если у вас много проверок, то оценка O(log*n) - завышена, ведь если вы одну и ту же проверку повторяете, то там пути сжимаются и проверки работают уже за O(1).

Таким образом, DSU от Тарьяна - лучше всех других структур на практике.

Формула включения-исключения. Берете все графы, где хотя бы одна вершина соединена со всеми (их n*2^(n-2)*(n-1)), вычитаете все графы, где хотя бы две вершины соеденины со всеми (2 раза, ведь они 2 раза подсчитались), прибавляете графы, где хотя бы 3 вершины соеденины со всеми (3 раза)... И т.д.

Графов, где хотя бы k вершин имеют степень n-1 - C(n, k)*2^{(n-k-1)(n-k)/2}: тут можно выбрать k вершин и для каждого ребра из оставшихся n-k вершин есть 2 варианта - оно или есть, или нет.

Это будет за O(n log n) решение, если пердподсчитать все факториалы и обратные к им по модулю в задаче. Ну, или O(n^2), если считать сочетания через треугольник паскаля.

Ражеванное объяснение:

Сложно подсчитать количество графов где ровно 1 вершина такая полная. Но легко подсчитать те, где k или более таких. Мы их такие зафиксируем и нарисуем от них все ребра. А все оставшиеся ребра в графе могут быть любыми. Во-первых, можно выбрать эти k вершин - поэтому у нас есть множитель C[n,k]. Оставшиеся, незафиксированные ребра идут между любыми двумя оставшимся n-k вершин. Их (n-k)(n-k-1)/2. И каждое может быть или проведено или нет.

Поэтому всего таких графов, с не менее k вершин: F(k)=C[n,k]*2^{(n-k)(n-k-1)/2}.

Теперь, как подсчитать графы ровно с 1 вершиной? Можно взять F(1). Но мы насчитали много лишнего, Графы с 2мя такими вершинами мы в F(1) подсчитали 2 раза. Поэтому вычтем 2F(2). Теперь графы ровно с 3 вершинами мы подсчитали 3 раза в F(1) и 3 раза в каждом F(2). Поэтому пока мы их насчитали 3-2*3 = -3 раза. Поэтому прибавим 3F(3). И далее, получится, что графы ровно с 4-мя вершинами мы подсчитали 4 раза (4-2*6+3*4). И т.д.

Достаточно списка. При принудительном обновлении берите первый элемент из списка. При любом обновлении перемещайте объект(ы) в конец. Можно перед началом из списка элемент удалить, а после конца в конце вернуть.

Тут вам еще понадобится какая-то структура, чтобы по объекту получить итератор на него в списке. Если у вас объекты каким-то id определяются, то это может быть

std::unordered_map<int, std::list<Object>::iterator>

.

Вам нужен какой-то потокобезопасный список, да. Доставать из списка первые 4 элемента можно и циклом, по одному. Операция быстрая. Или пусть каждый поток сам достает из списка первый элемент, лоча для этого список.

А вообще, есть и Lock-free списки. Если у вас обновления сами по себе очень быстрые операции, то такая структура может быть в итоге работать быстрее.

Edit: простите за C++-ый код. Не заметил, что вопрос с java тегом. В общем, тут нужны какой-то список и hashmap из id в итераторы в этом листе.

Да, нижние индексы - это обозначение системы счисления. Так, 110 в двочиной - это 6 в десятичной, или вот то разложение по степеням двойки.

Это один и тот же тип. Просто для обратной совместимости, при запихивании его в стандарт, в std::int32_t протащили сишные типы. Вот код.

Edit: я сначала перепутал, что куда протащили.

Проверка числа на простоту не так.
Во-первых, начинайте c n=2, ибо 1 у вас иначе простым числом будет.

Во-вторых, в вашем случае надо проверять, что n не делится на все предыдущие простые числа. Вложенным циклом. Ну, или решето эратосфена реализуйте.