Wataru

Правильный ответ - ни так и не эдак. Никак. Сравнивать указатели не из одного и того же массива - undefined behavior. Это было недавно в статье на хабре. Там ссылаются на раздел 3.3.8, "Relational operators".

Более того, у вас там в программе еще UB: нельзя обращаться к данным в переменной long через указатель short - Это нарушение strict aliasing.

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

На практике - никаких лево и право там не существует, есть только младшие и старшие адреса, читайте про big/little endian порядки байт. Они там бывают и так и эдак в разных архитектурах. В x86, например, младший байт имеет меньший адрес.

Можно получить список всех потоков одного процесса через Thread32First/Thread32Next (пример).

Ищется в гугле буквально по "winapi list threads".

Скорее всего ошибка в файлах. Они наывазются не так, как вы передаете в параметрах, или находятся в другой директории, или пусты. А правильный текст вы видите в другом файле. Перепроверьте еще раз все названия. Или там первая строчка пустая.

TreeSet.

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

Нужно обратить все операции и делать их задом наперед.

Шифрование делает 34567890 итераций, вам надо сделать столько же. Внутри порядок операций надо развернуть, чтобы отмены выполнялись в обратном порядке. Если в строке 2 операции, например умножение и вычитание, то сначала надо выполнить обратное к вычитанию и только потом обратное к умножению.

Обратные к вычитанию и сложению - сложение и вычитание соответственно. Если шифрование прибавляет 12345, то вам надо 12345 вычитать в дешифраторе. Побитовое исключающее ИЛИ обратно само себе, ведь если его применить 2 раза, то получится исходное число.

С умножением все гораздо сложнее. Я предполагаю, что тип state - unsigned int. Если он знаковый, то умножение с переполнением - это undefined behavior вообще. В безнаковых целых умножение с переполнением есть просто умножение и взятие по модулую 2^32. Т.е вам нужно найти операцию, обратную умножению по модулю 2^32.

Это будет умножение на обратное по модулю.

Для его нахождения вам надо будет использовать расширенный алгоритм эвклида (в статье по ссылке выше оно расписано). Его можно или реализовать отдельно для нахождения обратных к 31663 (и другим множителям). Или можно его руками на бумажке прогнать.

Отдельно вам надо разобратсья с отрицательным множителем. Вам надо найти положительный множитель, который будет давать точно такой же результат шифрования. Подсказка.

Edit, только заметил в вопросе, что state - двубайтовый. Значит, все происходит по модулю 2^16.

Можно не рекурсивно.

Перебирите все битовые маски (числа) от 0 до 2^n -1 (mask = 0; mask < (1 << n); ++mask).

А внутри при подсчете суммы пройдитесь по всем позициям массива и, если i-ый бит установлен, прибавляйте текущее число. Проверить, что бит установлен можно сделав побитовое и (&) c 1 << i.

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

Картинка не видна, но по коментариям понятно, что вам хочется получать только выпуклые многоугольники?

Проверить, что что-то не так можно через векторное произведение последовательных сторон.

Для всех 3 подряд идущих вершин a, b и c, то надо проверить, что (b-a)*(c-b) всегда дает одинаковый знак (или всегда <=0 или всегда >=0). Это векторное произведение.
Формула в вашем случае будет (xb-xa)*(yc-yb)-(xc-xb)*(yb-ya).

Еще можно построить выпуклую оболочку (convex hull).
Вот расписан алгоритм, как ее построить по заданным точкам: https://e-maxx.ru/algo/convex_hull_graham

Edit: Еще можно, вместо сортировки точек в выпуклую оболочку, игнорировать клики от пользователя, которые делают текущий многоугольник невыпуклым. Опять же, проверку невыпуколсти можно делать только для новых сторон: В последней, новой и первой точках.

У вас правильная идея, что двух чисел в ответе всегда достаточно. Всегда можно выдать, например, n, n-1 и эти две операции покроют все позиции с 1 по n.

Но вот случай, когда достаточно одного числа вы неправильно разобрали. Почему вы ищите самое большое простое число? Какой вообще смысл смотреть, что в позиции ans-1 стоит c?

А еще ваш код выводит 0 неверно иногда.

Вы, может, задачу неправильно поняли? Надо сделать так, что бы все позиции, в которых символы отличные от c, не делились бы на хотя бы одно число в вашем ответе.

Ваша рекурсия восстонавливает ответ в динамическом программировании в матрице.

Построение матрицы менять не надо, оно просто считает оптимальную длину LCS. Вам надо отдавать приоритет переходам вверх (или влево) пока это возможно при восстановлении ответа.

Но можно сделать простой хак - усеките ваш текст как можно короче, пока LCS все еще оптимального размера.

Вам надо найти самое первое максимальное число в последней строке (или столбце, в зависимости от того в какой из входных строчек вы хотите как можно левее найти вхождение. Я не в курсе, что у вас за aCompareFunc).

От этой позиции и запускайте ваш DoDiff вместо левой нижней ячейки матрицы.

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

Вам еще придется в конце зарепортить необходимое количество l3diffDeleted или l3diffAdded, чтобы восстановить усеченную часть.

Это и есть нормальное преобразование float в int - с округлением вниз.

Edit: Видимо, проблема в том, что 0.9 нельзя идеально точно представить в float. На самом деле там хранится что-то вроде 0.8999999.... При домножении на 10 и округлении вниз вы получите 8, а не 9.

Надо использовать округление к ближайшему - round.

Используйте std::vector. Он автоматически расширяется и при этом работает быстро.