vScherba

Вообще, ваш пример - это как раз наиболее правильный, современный и масштабируемый подход к взаимодействию потоков через обмен сообщениями. Он называется MPI (Message Passing Interface). В Erlang и D, например, используется как механизм по-умолчанию для взаимодействия потоков.
В boost как раз есть плюсовая обертка над MPI. Мне не приходилось ее использовать, в доках сразу же рассказывается, как это круто все работает между процессами. Подозреваю, что внутрипроцессный механизм там также присутствует в качестве частного случая.

Как сказал @Lol4t0, можно использовать boost::asio::io_service, хотя этот подход направлен больше на события завершения ввода/вывода (там реализация паттерна Proactor в чисто виде), но никто не запрещает использовать чисто dispatch или post и получить такое подобие MPI.

Не скажу за все языки, но в C++ std::list редко бывает эффективнее других контейнеров. Но бывают случаи, когда он предпочтительнее, например, в графовых структурах данных типа Boost Graph Library.

Никогда не используйте CreateThread в C/C++ приложениях, используйте _beginthreadex. Об этом написано в каждом учебнике по WinAPI и в самой MSDN. Это сразу не понравится ревьюверу.
Конечно, можно в комментариях обосновать, что CreateThread использован специально, что в потоковой функции не используются вызовы CRT, но все равно, смысла в этом мало, потоковая функция может в будущем измениться.

Можно использовать оконные сообщения WM_USER через PostMessage. У Вас передаются целые числа, которые влезают в lParam, wParam, так что даже не придется перекачивать данные через общую память, пайпы и сокеты.
Даже не обязательно создавать для этого окно, можно использовать PostThreadMessage.
В родительском процессе читать уведомление в цикле выработки сообщений. Если такового нет, то создать в новом потоке.

Хм, ну почему же нельзя?

#include <boost/preprocessor.hpp>
BOOST_PP_STRINGIZE(BOOST_PP_MUL(A, B))

MsgWaitForMultipleObjects[Ex]
Если используете ATL в проекте, то можно заюзать AtlWaitWithMessageLoop. А если не используете, то посмотрите ее исходник в качестве примера юзания MsgWaitForMultipleObjects.

Это классический случай множественного наследования интерфейсов. Т.к. они не содержат состояния, нужно просто убрать ключевое слово virtual.
Кстати, для чего Вам здесь понадобилось виртуальное наследование?

А попробуйте явно указать кодировку вместо CP_ACP.

Часто для перекодировки используется прием:

string str = _bstr_t(wstr).operator char*();

.operator char*() в реализации использует WideCharToMultiByte. Если этот прием также сработает неправильно, скорее всего баг у Майкрософт.

По Windows могу предложить ShellExecuteEx, которая открывает файл в приложении по-умолчанию и возвращает hProcess. По hProcess можно ждать закрытия приложения. Но если Вам нужно отследить не закрытие приложения, а закрытие файла, тогда можно в цикле с некоторым Sleep пробовать открывать файл эксклюзивно, пока не получите успех.
Есть еще ReadDirectoryChangesW, но по-моему она не уведомляет об освобождении дескриптора файла.
Еще момент: есть такие приложения, которые не держат файлы открытыми, например если открыть текстовый файл блокнотом, то notepad считывает файл в память и сразу закрывает его, то есть не держит handle.

А почему бы не опубликовать этот вопрос около программирования прямо здесь? Мне кажется, в русскоязычном IT сообществе полно грамотных людей. И никто не будет его модерировать.

Я в код не лазил, но по описанию ошибки понятно же все «explicit specialization in non-namespace scope». Сам раньше сталкивался. Вы где-то внутри структуры OS_FunctionClassImpConst0__cdecl специализировали шаблон. Стандартом это запрещено, специализировать шаблон можно только внутри пространства имен, в том числе и глобального. Но MSVC позволяет внутри структур/классов.

Можно также стандартным std::ofstream ofs(имя_файла); ofs.seekp(нужный_размер); ofs << '\0';
Этот код, как и версия от agmt резервирует файл на диске нужного размера. Если места не хватит, обрабатывайте ошибку. Если ошибки не возникло, у Вас есть гарантированно выделенное место на диске, которое никто не займет.
В Вашем же примере, после определения достаточности места, другое приложение может заполнить диск, и об этом Вы узнаете только во время непосредственной записи в файл.

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

Напечатает то же самое, что эквивалент: cout << (sizeof(char *) == 8). Приоритет "<<" выше, чем "?:".