Wataru

Интерпретатор 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<>. Чтобы обратиться к методам/полям хранимого класса надо использовать ->.

А что вы вводите? Сдается мне, что ваш код ждет в цикле
while (getchar() != '\n') continue;

Это произойдет, если вы введете строку короче len-1 символов.

Чтобы это исправить, можно вставить в функцию проверку, если ch после первого цикла оказался '\n' - то второй цикл не нужен.

Или можно этот цикл вставить перед break в предыдущий цикл. Вы же должны пропустить символы до перевода строки только если строка слишком длинная.

В C++ можно через #include этого добиться.

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

Ну или можно использовать std::unordered_map<std::string, int> вместо trie.

Квадратичная сложность.

Решение со стеком будет линейным.

В find_in_nodes_by_name у вас return закомментирован. Это первая ошибка.

По второй ошибке: попробуйте написать LinearNavigation<T>::haveNext() там, где оно вызывается в isFullyConnectedQuad.

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

Не совсем поятно, что вы хотите сделать.

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

void f(const std::vector<int> &arg){
}
f({1,2,3});

И да, массив не в квадратных скобках задается, а в фигурных.
Передача по ссылке, чтобы не копировать эти все значения лишний раз. Для трех элементов погоды почти не делает, но если их 100, или тем более 1000 - это заметная оптимизация. const, чтобы можно было передавать временные объекты. Плюс так понятно, что это аргументы входные и вы их менять в функции не будете.

В .text Находится исполняемый код.

6kb там не зря. Там куча вспомогательного кода, чтобы взаимодействовать с операционной системой. Начиная от загрузки всяких внутренностей libc, до настройки консоли.