nirvimel

Не надо создавать отдельный поток для каждого файла. Создайте два пула потоков.

Пул №1 (вычислительный): количество потоков равно количеству ядер CPU. Во входную очередь сыплются блоки данных, для которых потоки пула рассчитывают хеши.

Пул №2 (синхронное чтение с диска): количество потоков равно количеству ядер, помноженному на некоторую константу (в исходниках разных библиотек я видел значения от 2 до 10). Во входную очередь сыплются имена файлов, которые потоки пула открывают, читают и засылают прочитанные блоки во входную очередь пула №1.
Примечание: расход памяти регулируется ограничением максимальной длинны входной очереди пула № 1. Практически получается, что пул №1 ограничивает нагрузку на пул №2, который в норме недонагружен.

Отдельный поток, который совершает обход дерева каталогов и засылает найденные имена файлов во входную очередь пула №2. Длину этой очереди, тоже можно ограничить, но не так жестко (я бы задал размер в несколько сотен).

P.S.: Все очереди с ограничением длины должны быть, конечно же, с блокировками (не lock-free), так как через них происходит регулировка нагрузки (иначе все потоки нагрузятся на 100%).
Размер блоков данных, поступающих на вход пула №1 не надо делать слишком маленьким (я бы задал 64 килобайта, например).

Лучше всего это делать НИКАК.
А параметры передавать через связываемые переменные.

Тут по-русски общая теория вопроса без относительно SQLite.

1. Закачка страниц из сети при помощи libcurl.
   
2. Разбор страниц в DOM при помощи libxml2 (или libxml++).
   
3. Выборка интересующих элементов (ссылки, картинки, и.т.д.) при помощи XPath запросов к DOM.
   
4. Многопоточность: заброс новых ссылок в общую очередь + пул потоков, выбирающих себе задания из этой очереди и отрабатывающих по пунктам 1, 2, 3.
   
   

так как некоторые ссылки могут быть скриптами или css

С этим нет никакой проблемы. XPath //a выбирет только реальные ссылки на страницы, по которым возможно перейти.

*((int *) 0) = 1;
Ни в одном другом языке это не осуществляется так просто.

В режиме телепатии догадываюсь, что вы хотите реализовать. Видимо, речь идет о совершенно стандартном механизме порождения объекта соединения из объекта БД.
Чтобы понять как строятся подобные велосипеды загляните в код любой ORM или вообще любой ООП-обертки над драйвером БД. Вы увидите в большинстве случаев следующую картину:
1. Конфигурация БД представляет собой фабрику (да, да, те самые паттерны, которые неофитам НИНУЖНЫ).
2. Метод connect возвращает объект соединение.
3. Объект соединение (кроме методов по выполнению запросов) имеет метод close, который закрывает соединение (попытка выполнения запроса на закрытом соединении будет выдавать ошибку).
4. Соединение (как объект) живет один раз и не может быть переоткрыто после закрытия. Но из фабрики БД всегда можно открыть новое соединение.

Почему так:
Главный принцип ООП: отдельному понятию - отдельный класс. БД (на стороне клиента) представляет собой только конфигурацию: адрес сервера, имя юзера, пароль, имя БД и прочие параметры. Соединение к БД - это отдельная сущность, через которую создаются транзакции и курсоры (отдельные сущности), через которые выполняются запросы. Результат выполнения запроса - отдельная сущность. Отдельная строка в выборке - отдельная сущность (если только не кортеж). И только отдельные поля в строке имеют примитивные типы данных.

Завести vector<thread>.
Сначала в цикле породить все потоки и сохранить в вектор.
Потом другим циклом пройтись по всем и сделать join каждому.

P.S.: В реальном коде с точки зрения производительности лучше проверять is_regular_file тоже внутри потока. И нет смысла в цикле читать из файла все строки ради значения последней (может лучше было бы - первой) строки. Что если попадется многогигабайтный файл?

#include <iostream>

class Cam;

class OutputBuffer {
public:
    OutputBuffer() { std::cout << "OutputBuffer " << this << " initialized\n"; }

    void receive(Cam &cam) { std::cout << "OutputBuffer " << this << " receiving data from camera " << &cam << "\n"; }
};

class Cam {
    static OutputBuffer buffer;
public:
    Cam() { buffer.receive(*this); }
};

OutputBuffer Cam::buffer = OutputBuffer();

int main() {
    Cam cam1, cam2;
};

OutputBuffer 0x6013d1 initialized
OutputBuffer 0x6013d1 receiving data from camera 0x7fff7742970e
OutputBuffer 0x6013d1 receiving data from camera 0x7fff7742970f

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

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

В остальном приведенные рассуждения в целом верные, явных ошибок я не заметил.

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

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