Wataru

for file in filename: переберет в file все символы строки filename.

Вам надо просто передавать ваш filename в open.

Заведите массив из нулей. Для каждого отрезка сделайте +1 в координату его левого конца и -1 в координату, следующую за правым концом.

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

Это если вам надо весь массив, как в примере, выводить. Не знаю специфику вашей задачи, может эффективнее будет класть в массив пары {координата, +-1} и сортировать. Потом точно также обойти слева направо поддерживая счетчик.

Генерируются они так:

Есть у вас список уже сгенеренных чисел, изначально содержит только 1.

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

Поддерживайте 3 указателя (изначально на первое число), которые указывают на первые неиспользованные числа для домножения на 2, 3 и 5.

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

Пример:
шаг 1.
указатели: 1, 1, 1
список: {1}
варианты:1*2, 1*3, 1*5. Лучший - 2.

шаг 2.
указатели: 2, 1, 1
список: {1, 2}
варианты:2*2, 1*3, 1*5. Лучший - 3.

шаг 3.
указатели: 2, 2, 1
список: {1, 2, 3}
варианты:2*2, 2*3, 1*5. Лучший - 4.

шаг 4.
указатели: 3, 2, 1
список: {1, 2, 3, 4}
варианты: 3*2, 2*3, 1*5. Лучший - 5.

Есть неалгоритмический способ ускорить ваше решение - храните в каждой ячейке массива не одну цифру - а несколько. Фактически, проводите вычисления в системе счисления 10000, вместо 10. Или даже 1000000000 - но тогда надо временные вычисления (умножение) делать в int64_t, чтобы переполнения не было.

Еше, при выводе такого числа надо выводить ведущие нули для всех ячеек, кроме самой старшей.

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

Но в таком виде алгоритм будет даже медленнее на больших числах. Ему потребуется O(log K) умножений большого на большое (которое делается за O(L^2), где L - длина числа, которая будет O(K)). Итоговая сложность этого алгорима будет O(K^2 log K).

Когда как ваше текущее решение делает K коротких умножений (Каждое - O(K)) - всего O(k^2) операций. Но если применять быстрое умножение длинных чисел через быстрое преобразование Фурье то итоговая сложность будет O(K log^2 K log log K). Для power=100 особо вы разницы не почуствуете, даже медленнее будет, но вот при каких-нибудь 10000 уже будет заметно быстрее.

Советую попробовать обычные оптимизации, прежде чем браться за преобразование фурье.

Еще, вместо хранения конца числа в виде особого значения 10 - вам стоит отдельно хранить длину числа в какой-то переменной с говорящим названием (хотя бы len). Тогда код будет сильно читабельнее.

Это задача о многомерном рюкзаке (multi-dimensional knapsack). Каких-то простых трюков, как с обычным одномерным рюкзаком тут нет. Только перебор с отсечениями.

Еще можно свести задачу к целочисленному линейному программированию. Вводите переменные - сколько штук каждого пункта съели, составляете линейные уравнения. Потом можно это все скормить какому-нибудь решателю. Сейчас много библиотек и они довольно быстро такие задачи щелкают. Гуглите "integer linear programming solver".

У вас в примере вообще классы без данных, поэтому разницы никакой нет между первым и вторым вариантом. Третий выделят память под объект не на стеке, а в куче - поэтому и выделение и работа с объектом, обычно, будет дольше.

Если бы в объекте были данные, то первый вариант был бы быстрее всего, потому что он ничего бы не инициализировал, в отличии от остальных.

Если бы в объекте был еще и конструктор, то первый и второй варинт были бы идентичными.

Третий вариант всегда инициализирует объект и выделяет память, поэтому он будет медленнее.

Введите 2 переменные t и q - это "время" на первом и втором луче, составьте 2 уравнения. Решите их - найдете время пересечения на каждом луче. Убедитесь, что пересечения при t>=0, q>=0:

x1+t*vx1=x2+q*vx2
y1+t*vy1=y2+q*vy2

надо проверить, что оно имеет решение. Преобразуйте его к стандартному виду:

t*vx1-q*vx2=x2-x1
t*vy1-q*vy2=y2-y1

Решите систему методом Краммера. Если определитель системы != 0 - то найдте 2 переменные q и t. Проверьте, что они обе неотрицательные.

Если определитель равен нулю, то прямые или не пересекаются вообще, или совпадают. Они совпадают, если оба вспомогательные определители системы равны 0.

В этом случае надо проверить, что лучи пересекаются по отрезку или лучу. Для этого надо проверить, а не лежит ли начало второго луча на первом и наоборот. Для этой проверки можно воспользоватся векторным произведением векторов. Считаете вектор {x2-x1, y2-y1} и умножаете на вектор {vx1, vy1}. Эти 2 вектора или смотрят в одну сторону (и пересечение есть), или в разные. В первом случае векторное произведение будет положительно, во втором - отрицательно. Нулевое произведение считайте как положительное - это значит что или точки совпадают или вектор направления нулевой.

Т.е. весь алгоритм
1) Считайте 3 определителя по методу краммера
2) Если главный определитель не 0, считайте q и t. Пересечение есть, если q>=0 и t>=0.
3) Если главный определитель 0, но хотя бы один из вспомогательных не 0 - пересечения нет.
4) Считайте векторное произведение {x2-x1, y2-y1} на {vx1, vy1}. Если оно неотрицательно - пересечение есть.
5) Считайте векторное произведение {x1-x2, y1-y2} на {vx2, vy2}. Если оно неотрицательно - пересечение есть.

Никак. Заставьте вашу функцию принимать указатель:

template <typename type>
  static void readMemory(uintptr_t offset, unsigned int length, type* var) {
    ReadProcessMemory(targetHandle, (LPVOID)offset, var, length * sizeof(type), 0);
  }

uint8_t arr[100500];
readMemory<uint8_t>(0x00, 10, arr);

По поводу вызова неконстантных методов - а с чего вы взяли, что они не дожны быть возможны? Временные объекты не имеют const квалификаторов. Иначе нельзя было бы делать вещи типа SomethingBuilder().WithA().WithB().Finalize().

//! f6() = X(1);

Оператор присвоения требует Lvalue слева. Временный объект же - Rvalue. Eго можно ставить только справа от =. А не потому что у него const квалификатор.

Это сделано скорее всего потому, что, ну, нет же смысла перезаписывать временный объект. Он временный, к нему потом никак не обратиться.

//! f6().modify();

Вот тут попытка вызова неконстантного метода у константного (и временного - но это не важно) объекта.

//! f7(f5());

Видимо, это чтобы исключить некоторый класс ошибок. Если вы передаете в качестве неконстантной ссылки что либо, значит оно должно внутри менятся и снаружи эти изменения должны быть видны. Иначе можно было бы передавать по константной ссылке или по значению. Но вы передаете туда временный объект - его никак снаружи видно не будет. Он существует только в этой строчке. Поэтому в C++ нельзя инициализировать неконстантные lvalue ссылки через rvalue (временные объекты).

Вам придется переписать функцию readMemory, чтобы она принималаlength и читала length*sizeof(type). Или вызывайте прямо ReadProcessMemory в вашей функции.

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

Нет. Распишите формулы, они будут разные. В прогрессии каждый раз добавляется степень коэффициента q. В проценте происходит домножение на (1+q):

A+Aq+Aq^2+Aq^3+...
A+Aq+(Aq+Aq^2)+(Aq+2*Aq^2+Aq^3)+...

машина состояний?