Wataru

Формализуйте метрику корелляции. Там если расписать - то в итоге все придет к свертке (если одну последовательность развернуть сначала). Ее можно за 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. Как-то разбираться, что эта ошибка не критичская и весь кусок кода можно тупо выкинуть - это компилятору сложно, да и опасно это. Поэтому нужен именно какой-то предварительный этап, который не может использовать тот же самый синтаксис.

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

По идее надо оформить код в файле в функцию и вызывать ее там где вам надо.

В хедере вы декларируете функцию и включаете этот хедер в начало вашего С++ файла, приведенного в вопросе.
Другой С++ файл будет реализовывать функцию (и тоже включать хедер). Потом какая-то система сборки или IDE скомпилирует оба файла и соберет из получившихся объектных файлов одну dll-ку. Или вы руками скомпилируете каждый из двух C++ файлов и потом отдельным вызовом слинкуете все.

Вы, видимо, предполагаете просто тупо написать код функции в файле и включить его в тело функции через #include. Вообще говоря, это даже скомпилируется, но это такой лютый говнокод получается, что так делать никогда и ни при каких обстоятельствах нельзя. Сообщения об ошибках будут со съехавшими номерами строк, сам файл с кодом будет некорректным С++ кодом, поэтому любой редактор не сможет вам ни подстветить его, ни понять какие там есть штуки, чтобы показывать их вам в подсказках. Такой подход не обобщается на более чем пару файлов - вы потом сами запутаетесь что где и куда включено.

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

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

Как вариант - смотрите соревнования организованные большими компаниями. Например google code jam, facebook hackercup. Тут не надо будет объяснять университету, что это такое и всем сразу все понятно.

Первая ошибка: проблема в том, что вызывается конструктор копирования unique_ptr, но он авторами unique_ptr удален (потому что unique_ptr нельзя копировать по дизайну).

Похоже get_parent возвращает ссылку на unique_ptr. По-моему тут лучше возвращать сырой указатель или ссылку на объект. зачем вам тут unique_ptr вообще?

Но, игнорируя дизайн, ссылка на unique_ptr в принципе будет работать. Проблема в том, что auto не выводит ссылочность. Поэтому переменная parent становится просто unique_ptr, который конструируется из ссылки копированием. Поэтому если вы напишите auto& parent = то все должно заработать.

Вторая ошибка - .обращается к методам и полям класса unique_ptr, ведь переменная parent имеет тип unique_ptr<>. Чтобы обратиться к методам/полям хранимого класса надо использовать ->.