DLL и исполняемый файл оба используют boost :: log. Они заканчивают тем, что использовали различные ядра одиночного журнала. Как я могу выставить ядро dll исполняемому файлу и зарегистрировать ядро dll на exe-ядре, чтобы я мог перенаправить оба в один лог-файл.
Я написал минимальный пример, чтобы проиллюстрировать, где я спотыкаюсь:
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, и мне нужно было бы сначала перенаправить его сообщения на другое ядро. Я погуглил проблему и не могу найти простое решение, хотя во время установки мне кажется, что это должен быть вызов из одной строки в основном. И получатель к бустеру logcore singleton в интерфейсе dll.
Есть ли стандартный способ, который мне не хватает? Как бы я перенаправил эту запись сюда?
Редактировать # 1: — вывод в моей системе и выдумка того, что я хочу, чтобы произошло.
Редактировать № 2:
— Я сомневаюсь в возможном решении Вот.
— Если этот совет решит проблему, я удалю этот вопрос из-за того, что являюсь клоном.
Редактировать № 3:
Я реализовал предложенное решение от EDIT # 2. Это работает, но не то, что я хочу.
По сути, вы должны #define BOOST_LOG_DYN_LINK
, К сожалению, это не работает, так как журнал использует другие библиотеки, которые также должны быть добавлены рекурсивно. Я закончил с #define BOOST_ALL_DYN_LINK
,
Все ускорение теперь сделано динамическим и с V1.59, который может составлять 30 dll. В моем минимальном примере я должен был предоставить dll для chrono, date_time, filesystem, log_setup, log, regex, system и thread (.count = 8).
Так что, хотя в результате я точно хотел, чтобы путь к нему был другим, это отличает этот вопрос от другого.
Подход DLL гарантирует, что в ядре присутствует только один dll-синглтон.
Я предпочитаю иметь 2 ядра, а не поставлять dll, поэтому для меня приемлемо объединение двух цепочек.
Есть ли способ получить тот же результат при статическом связывании?
Boost.Log требует быть построенным как разделяемая библиотека, если вы используете ее из нескольких модулей. Дизайн библиотеки опирается на это требование, и ядро протоколирования — не единственный синглтон в библиотеке. В зависимости от используемых вами библиотечных функций вы, более или менее вероятно, столкнетесь с трудностями при отладке проблем, если нарушите это предварительное условие. Также возможно, что код, который работает с используемой в данный момент версией Boost.Log, будет поврежден другой версией.
Все это сводится к глобальным переменным. «Синглтон» — это просто другое имя глобальной переменной.
Если вы статически связываете свой исполняемый файл и свою DLL с Boost, то каждый из них имеет свой собственный синглтон (глобальная переменная). Если вы хотите поделиться ими, то вам нужно связать и ваш исполняемый файл, и вашу DLL с общей библиотекой журналов, чтобы они использовали один и тот же глобальный синглтон.
Это всего лишь следствие использования разделяемых библиотек: они имеют тенденцию заставлять другие библиотеки также делиться из-за глобальных данных.