Wataru

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

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

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

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

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

Похоже там тупо где-то стоит округление вниз, ведь разница после преобразований по всем каналам - ровно 1. Может, это значение RGB в HSL на самом деле что-то вроде (15.01, 30.5, 49.9). Но в пиксели HSL в итоге запишутся целые числа (0-255). Из-за этого округления при обратном преобразовании получается не 0x91 а 0x90.6, что, опять же, округляется вниз.

Если так важна полная обратимость преобразований, попробуйте использовать 10-битные или 16-битные форматы пикселей (расширяя исходный 8-битный RGB нулями справа). Тогда эти округления не испортят важные вам 8 старших бит.

Потому что оно есть n! / (n-k)! Вот n-k и в числителе и в знаменателе сокращается. А вот n-k+1 в числителе остается, потому что сокращатся ему не с чем.

Формализуйте метрику корелляции. Там если расписать - то в итоге все придет к свертке (если одну последовательность развернуть сначала). Ее можно за n log n подсчитать быстрым преобразованием фурье.

Тут уже надо дизассемблировать игру и там находить уже код, отвечающий за торможение, и там же в ассемблерном коде надо посмотреть, а по какому адресу он пишет/читает.

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

Это реально 3 строки кода, если вам непонятно, снова почитайте учебник про циклы.

Первая ошибка:
char *marka_ = new char;

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

Вторая ошибка:
char* m = "Renault"

Тут используется значение аргумента по умолчанию, где у вас строковая константа. Тут не происходит копирование строки, просто в переменную m сохраняется адрес вот этой вот константы, которую компилятор куда-то в памяти проложения засунет. Вы не выделяли эту память, поэтому попытка сделать delete на ней - неопределенное поведение, что в данном удачном случае приводет к крэшу.

У вас вообще проблема тут - marka может указывать на выделенную вами в Input() память, а может указывать на переданную из вне память. Кто ее удалять должен-то? Так же в Input() вы можете переписать переданный в конструкторе указатель. А надо ли было его удалять классу?

Я бы сделал в конструкторе всегда копирование переданной строки. Тогда можно будет передавать туда и строковые константы и использовать вот такое вот значение по умолчанию.

Интерпретатор Python не осуществляет проверку типов:

The Python runtime does not enforce function and variable type annotations. They can be used by third party tools such as type checkers, IDEs, linters, etc.

Надо использовать mypy или еще какой-то другой инструмент.

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

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

Второй вариант - выходные дни недели подсчитать ручками: если дата начала и дата коца в одной неделе, то выходных нет. Иначе, если начало не понедельник - то сдвинуть ее до следующего понедельника и прибавить следующие субботу и воскресение к счетчику. Потом, если дата конца не пятница - сдвинуть ее на предудущий понедельник. Теперь разность между датами кратна 7 и покрывает сколько-то недель целиком. Делите разность на 7 и умножайте на 2, чтобы подсчитать, сколько там суббот и воскресений (разность может быть и 0 и это нормально).

Потом надо ручками же подсчитать все праздники. Для этого составьте в массиве даты всех календарных праздников в затронутых годах отсортированные. Потом для каждой задачи в этом массиве бинпоиском найдите первый и последний праздник в отрезке. Вот вы уже знаете их количество (разность индексов +1). Так же можно еще вести список всех рабочих суббот и воскресений. Этот список дат можно, наверно, где-то из интернета автоматически скачивать, а можно и тупо ручками в январе вбивать в базу.

В С++ рефлексии нет. Только ручками. Где-то придется писать список всех классов и по всем им пробегаться и сравнивать строку. Ну или map какой-то создать. В качестве ключа вставлять команду, в качестве значения - функцию создающую объект конкретного класса.

Как вариант, можно как-то упростить себе работу с помощью шаблонной магии. Шаблон будет принимать список всех классов, сравнивать первый с заданной командой и или рекурсивно вызваться дальше или создавать объект текущего класса.

Пример можно посмотреть вот тут. Там CreateEncoderInternal делает практически то, что вам надо. Только там не константное поле command проверяется, а проверяется, что заданный формат есть в статическом списке в текущем классе.

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

Не зачем, а почему. Так получилось. В те времена, когда C созадавался, технологии были не настолько развиты. Первый компилятор даже, по-моему, и код-то оптимизировать особо не мог. Предложенная вами compile-time директива слишком сложна. Даже в C++ что-то подобное завезли только совсем недавно.

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

Еще одна причина - это кросс-платформенный код. Ну вот вызов какой-то функции winapi просто не скомпилируется под linux, потому что ее там тупо нет. Значит надо сказать компилятору вот тот кусок вообще игнорировать. Если это делается на том же этапе, что и сама компиляция, да и с тем же синтакисом, то возникает проблема - в синтаксисе-то ошибка под linux. Как-то разбираться, что эта ошибка не критичская и весь кусок кода можно тупо выкинуть - это компилятору сложно, да и опасно это. Поэтому нужен именно какой-то предварительный этап, который не может использовать тот же самый синтаксис.

Вы точно этот код запустили? Пока очень похоже, что просто одна вершина не рисуется в коде.