Saboteur

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

В общем у вас вопрос слишком абстрактный

А причем тут алгоритм?
Ты имел ввиду типы данных?
Ну так граф. Но сейчас работать с битами - неудобно, ибо память не критична, а работа с битами занимает больше, чем с байтами, ибо усложнена адресация.

Дан файл с ip адресами. ip могут повторяться. Вес файла многократно превышает объём оперативной памяти.

Сколько оперативки?

Надо посчитать количество уникальных ip.
Простое решение, не учитывающее объём задачи - загнать все ip в хештаблицу и количество элементов в ней будет ответом.

Есть же алгоритмы сортировки, которым не нужно все грузить в память. Работать будет долго, но рано или поздно создаст файл, где все будет отсортировано. А количество уникальных IP в отсортироавнных данных уже школьный уровень.

Вообще не понимаю проблемы. Тут нкиаких условий к xyz не указано.
Просто вычисляем abc, либо идем к преподу и уточняем условия

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

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

Чтобы составить алгоритм как накачать мышцы, надо примерно разбираться в биологии, питании и спорте.

И так далее.
А Алгоритм отдельно от предметной области - абстракция.

"Стоит задача написать архиватор лог файлов"

"Алгоритмов сжатия данных немало и у каждого своя спецификация.
Как определить какой алгоритм сжатия данных нужно использовать для архивации файла, в котором много повторяющихся элементов?"

У вас в задаче я не вижу требований, написать идеальный архиватор лог файлов.
Вдобавок написать хотя бы простейший архиватор - уже нетривиальная задача для новичка, а судя по вопросу - вы новичок.

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

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

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

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

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

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

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

Номер договора не фиксированное число и может содержать все, что вам нужно (желательно конечно обойтись обычными символами).

Например, вам нужно передать структуру данных на удаленный сервер.
Структура данных выглядит примерно так
struct {
int age=17;
string name="Vasya";
date birthday="01/01/2001"
}

На удаленный сервер мы собираемся передавать обычным HTTP запросом, в который в принципе можно зааттачить XML, а можно передать просто одной строкой прямо в заголовке. Для этого мы можем нашу структуру данных серилизовать в строку, передать туда, там распаковать и получить сразу структуру.
Разница в том, что мы на той стороне будем не "парсить" неизвестные данные, а именно десерилизовать.

Почти все файлы хранят метаданные в самом начале. Поэтому шифруйте первый килобайт - более чем достаточно практически для любого типа файлов.

Плееры, которые проверяют валидность файлов, такой открывать не будут.