In issue #170, there was some discussion about removing the PostError macro. This would remove the __FILE__ and __LINE__ reporting in the error messages. Instead, code can make direct calls to LogError without this information.
The macro removal would remove the need for one of the FormatLogMessage overloads.
The remaining FormatLogMessage overload has fairly minimal use, and I would suggest the internal uses of Log don't really need to format the "op2ext.dll" module name into their log messages. I would recommend removing such formatting from internal calls. This would increase consistency between internal uses of Log with internal uses of LogDebug and LogError.
The one remaining use of FormatLogMessage would be for the exported Log method that is part of the op2ext API. It's tempting to inline the formatting into that method, though issue #64 might suggest adding additional method exports that would make use of such formatting. In that case, it might make sense to retain the FormatLogMessage method, but perhaps move it out of the now rather generic logging code, and instead put it somewhere more project specific.
In issue #170, there was some discussion about removing the
PostErrormacro. This would remove the__FILE__and__LINE__reporting in the error messages. Instead, code can make direct calls toLogErrorwithout this information.The macro removal would remove the need for one of the
FormatLogMessageoverloads.The remaining
FormatLogMessageoverload has fairly minimal use, and I would suggest the internal uses ofLogdon't really need to format the "op2ext.dll" module name into their log messages. I would recommend removing such formatting from internal calls. This would increase consistency between internal uses ofLogwith internal uses ofLogDebugandLogError.The one remaining use of
FormatLogMessagewould be for the exportedLogmethod that is part of the op2ext API. It's tempting to inline the formatting into that method, though issue #64 might suggest adding additional method exports that would make use of such formatting. In that case, it might make sense to retain theFormatLogMessagemethod, but perhaps move it out of the now rather generic logging code, and instead put it somewhere more project specific.