Как выставить и зарегистрировать одно ядро ​​буфера буфера на другое

Question

В DLL и исполняемом файле используются boost :: log. Они в конечном итоге используют разные ядра логов. Как я могу открыть ядро ​​dll для исполняемого файла и зарегистрировать dll-core для exe-core, чтобы я мог перенаправить оба в один файл журнала.

Я написал минимальный пример, чтобы проиллюстрировать, где я спотыкаюсь:

LogUser.hpp

#pragma once 

#ifdef DYNLIB_EXPORTS 
#define DYNLIB_API __declspec(dllexport) 
#else 
#define DYNLIB_API __declspec(dllimport) 
#endif 

class DYNLIB_API LogUser 
{ 
public: 
    LogUser(); 
    ~LogUser() {} 
}; 

LogUser.cpp

#include "LogUser.hpp" 
#include <boost\log\trivial.hpp> 
LogUser::LogUser() 
{ 
    BOOST_LOG_TRIVIAL(trace) << "LogUser constructed"; 
} 

main.cpp

#include <boost/log/trivial.hpp> 
#include <boost/log/utility/setup/file.hpp> 
#include <boost/log/utility/setup/common_attributes.hpp> 

#pragma comment (lib, "dynlib.lib") 
#include <dynlib/LogUser.hpp> 

void setupLogging(); 

int main() 
{ 
    setupLogging(); 
    BOOST_LOG_TRIVIAL(trace) << "main enter"; 
    LogUser dynamicLogUser; 
    BOOST_LOG_TRIVIAL(trace) << "main exit"; 
    return 0; 
} 

void setupLogging() 
{ 
    using namespace boost::log; 
    add_common_attributes(); 
    register_simple_formatter_factory< trivial::severity_level, char >("Severity"); 
    add_file_log 
     (
     keywords::file_name = "file.log", 
     keywords::format = "[%TimeStamp%] [%ThreadID%] [%Severity%]: %Message%" 
     ); 
} 

LogUser компилируется в в LogUser.dll. Конструктор LogUser создает сообщение трассировки, которое заканчивается на консоли. Main перенаправляет свой вывод в файл журнала, но не перенаправляет вывод dll в тот же файл журнала. Я полагаю, что dll содержит свой собственный logcore, и мне пришлось бы сначала перенаправить свои сообщения на другое ядро. Я столкнулся с проблемой, и я не могу найти простое решение, хотя кажется, что во время установки это должен быть однострочный вызов. И getter для синтаксиса logcore singleton в интерфейсе dll.

Есть ли стандартный способ, который мне не хватает? Как я могу перенаправить этот журнал здесь?

Редактировать # 1: - выводить на мою систему и вымысел того, что я хочу.

Edit # 2: - я foubd возможное решение here. - Если этот вопрос решает проблему, я удалю этот вопрос из-за того, что вы клоун.

Редактировать # 3: Я внедрил предлагаемое решение из EDIT # 2. Это работает, но не то, что я хочу.

По существу, вы должны #define BOOST_LOG_DYN_LINK. К сожалению, это не работает, поскольку журнал использует другие библиотеки, которые рекурсивно также должны быть добавлены. Я закончил с #define BOOST_ALL_DYN_LINK. Все импульсы теперь сделаны динамическими и с V1.59, которые могут быть 30 DLL. В моем минимальном примере мне пришлось предоставить dll для chrono, date_time, файловой системы, log_setup, журнала, регулярного выражения, системы и потока (.count = 8).

Так что, хотя результат - это именно то, что я хотел, чтобы путь к нему был другим, это отличает этот вопрос от другого вопроса. Подход DLL гарантирует, что существует только один dll singleton ядра. Я предпочитаю иметь 2 ядра из-за необходимости снабжать dll, так что объединение двух вместе приемлемо для меня.

Есть ли способ получить тот же результат, если вы все еще связываете статически?

Answer 1

Boost.Log requires будет создан как общая библиотека, если вы используете его из нескольких модулей. Дизайн библиотеки опирается на это требование, и ядро ​​регистрации не является единственным синглтон в библиотеке. В зависимости от функций библиотеки, которые вы используете, вы более или менее склонны сталкиваться с трудностями при отладке проблем, если нарушаете это предварительное условие. Также возможно, что код, который работает с вашей текущей версией Boost.Log, будет работать с другой версией.

Answer 2

Все это сводится к глобальным переменным. «Singleton» - это просто другое имя глобальной переменной.

Если вы связываете как свой исполняемый файл, так и свою DLL статически с Boost, то каждый из них имеет свой собственный singleton (глобальная переменная). Если вы хотите поделиться ими, вам необходимо связать как исполняемый файл, так и вашу DLL с общей библиотекой ведения журнала, чтобы они делились одним и тем же глобальным синглом.

Это как раз следствие использования разделяемых библиотек: они имеют тенденцию заставлять другие библиотеки также делиться из-за глобальных данных.