bLercs

Тут давал ответ

Энтони Уильямс: C++. Практика многопоточного программирования
https://en.cppreference.com/w/cpp/thread

Вы не блокируете тред, вы блокируете мьютекс. Если мьютекс уже заблокирован другим потоком, то второй тред будет ждать пока освободится мьютекс и потом его заблокирует. Ожидание будет происходить непосредственно в методе lock мьютекса. Есть вариант try_lock - когда ожидания не происходит, но если мьютекс уже захвачен кем-то, то возвращается соответствующая ошибка.
В общем случае применение мьютекса выглядит так:

m.lock()
<unsafe operation>
m.unlock()

Конструкторы можно не удалять, просто в них нужно блокировать мьютекс объекта источника. Мьютекс объекта назначения блокировать не нужно, т.к. это конструктор и класс только создается и им пока еще никто не владеет, так что доступ к членам класса будет монопольный. Но в этих конструкторах надо создавать новые мьютексы для объекта назначения.

Я бы в такой задаче попробовал сделать архитектуру, основываясь на виртуальных базовых классах - т.е. множественном наследовании, при котором многократно наследуемый класс везде, где он возникает, определяется как виртуальный базовый. Как известно, если класс (напрямую или через своих предков) многкратно наследует некий класс как виртуальный, то при содании экземпляра такого класса создается только один экземплярэтого базового класса.
В частности, с помощью виртуального абстрактного базового класса, содержащего только чистые виртуальные методы, вполне можно сделать аналог интерфейсов, существующих в других языках: Java, C# и пр. - и пользоваться в C++ архитектурными наработками, сделанными с использованием интерфейсов.

1. Суммарно файлы на диске не могут весить больше, чем на этот диск имеет объём.
2. int64_t имеет максимальное значение порядка 18 квинтилионов. 18 квинтилионов байт - это порядка 16 млн дисков по 1тб

подсчитывает размер файлов в байтах в поддиректориях. Если взять папку, внутри которой лежит ОЧЕНЬ много лёгких файлов, то любой целочисленный тип будет моментально превышен

Это ещё почему?
Она же суммирует их => если нормально пишешь, то нет разницы - много маленьких или мало больших.

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

Значит у тебя в коде ошибка.

А вот если бы у тебя реально в int64_t значения не умещались, то тогда тебе следовало бы посмотреть на длинную арифметику.
В рамках того же буста есть Boost multiprecision library, которая предоставляет разные типы для работы с большими числами.
https://en.wikipedia.org/wiki/List_of_arbitrary-pr...

да и вывод будет нечитабельным

А вот это уже другой вопрос. Если вывод нечитабельный, значит виноват тот, кто задачу поставил, тк он по определнию будет нечитабельным, раз ты в байтах выводишь.
Можно сократить, если выводить, например, в кило-/мега-/гига- байтах, но тогда упадёт точность.
Можно добавить пробелы между разрядами - тогда будет легче читать.

С исторических времён повелось, что стек растет в этом направлении. При проектировании основными целями были оптимизация и экономия. Стек растет сверху вниз, а куча в в обратном направлении.