写一个Windows上的守护进程（4）日志其余
写一个Windows上的守护进程（4）日志其余
这次把和日志相关的其他东西一并说了。
一、vaformat
C++日志接口通常有两种形式：流输入形式，printf形式。
我采用printf形式，因为流输入不好控制格式。
printf形式要求日志接口支持不定长参数，我没有直接在日志实现类里边支持不定长参数，而是只接受一个字符串参数，可以参见第一篇。
为什么呢？
如果要成为不定长参数，就是这样
bool log_string(const LOG_LEVEL level, const char* file, const int line, const char *s, ...);
那么在每一个log_xxx的变体里就都要写_vsnprintf_s那一套代码了，而且是完全一样的（我不知道__VA_ARGS__宏是否可以传递），这显然是不好的做法。
我把不定长参数的处理放在了宏定义里，类似：
#define ErrorLog(s, ...) _Log(LOG_ERROR, __FILE__, __LINE__, vaformat(MAX_LOG_BUFFER, s, __VA_ARGS__))
vaformat就是处理不定长参数的：
std::string vaformat(const size_t max_size, const char* msg, ...); std::wstring vaformat(const size_t max_size, const wchar_t* wmsg, ...);
因为并不知道格式化后有多长，所以要指定最大长度，如果格式化后的长度大于最大长度，则截断。vaformat里还有一个小技巧，当指定的max_size小于1024的时候，使用栈空间，否则申请堆内存，这是从std::string的实现中学来的——SSO短字符串优化。
可以看下vaformat的实现，两个版本的代码基本一样，这样当然是不好的，但是我不知道怎样把他们合并起来，这是一个todo。类似的问题下面还有。
二、CLastErrorFormat
这个东西是用来解决第一篇里提到的记录LastErrorCode的问题的。
它的主要功能就是把error code转换成文本描述，合适的构造也可以省去GetLastError的调用：
class CLastErrorFormat : public boost::noncopyable { public: CLastErrorFormat() : m_code(GetLastError()) { } CLastErrorFormat(const DWORD code) : m_code(code) { } ~CLastErrorFormat() { } public: const DWORD code() const { return m_code; } const std::string& str() { //... } const std::wstring& wstr() { //... } private: //... };
日志实现类里对应的接口：
bool log_last_error(const LOG_LEVEL level, const char* file, const int line, CLastErrorFormat& e, const std::string& prefix);
接受一个CLastErrorFormat的引用，然后在记录日志的时候，把error code和其对应的描述也记录下来：xxx, error code: 999, error msg: yyy
最终的日志接口是有两个版本的：一个接受一个CLastErrorFormat参数；另一个省去，在函数内部自己构造。
三、str_encode
我不可能在日志文件里一会记宽字符串，一会记窄字符串，那就没法看了，又考虑到日志文件的大小，我最终决定，按照窄字符串SystemCurrentCodePage（在简体中文版的Windows上，就是GB2312）编码记录日志，所以对于宽字符串我还要转换成窄字符串。
Windows提供了两个API来做编码转换：MultiByteToWideChar和WideCharToMultiByte，而这两个API总是要两次调用才能安全的转换。我将其稍稍封装了一下，做成了两个函数：
std::wstring multistr2widestr(const unsigned int from_code_page, const std::string& s); std::string widestr2multistr(const unsigned int to_code_page, const std::wstring& ws, const char *default_char = NULL);
注：SystemCurrentCodePage的代码页编码就是CP_ACP。
这样在记宽字符串的时候总是会慢一些，所以我代码中，能用窄字符串的地方我都用窄字符串了。
四、any_lexical_cast
代码中总是免不了要做类型转换，特别是把数字转换成字符串，为了简单一点，我使用了boost的lexical_cast，虽然大家都说这货效率低，因为使用了C++的流，但是我坚持“先正确，再优化”的原则，还是使用了它。
然而，这个东西使用起来有两处不便：
1. 转换失败的时候会抛异常
2. 把bool转换成string的时候是0或1，不是true或false
为了解决这两个问题，我又做了一下封装：
1. 转换失败的时候，填充为默认值。调用者必须提供默认值
2. 特化对于bool和string之间的转换
这就是any_lexical_cast：
template<typename Target, typename Source> Target any_lexical_cast(const Source& src, const Target& fail_value) { Target value = fail_value; try { value = boost::lexical_cast<Target>(src); } catch (boost::bad_lexical_cast&) { value = fail_value; } return value; } template<> bool any_lexical_cast<bool, std::string>(const std::string& src, const bool& fail_value); template<> bool any_lexical_cast<bool, std::wstring>(const std::wstring& src, const bool& fail_value); template<> std::string any_lexical_cast<std::string, bool>(const bool& src, const std::string&); template<> std::wstring any_lexical_cast<std::wstring, bool>(const bool& src, const std::wstring&);
具体实现请参看源码。
五、CSelfPath
日志初始化接口通常需要提供一个路径参数，以指定日志存放路径。我为其增加了一个默认路径：当传递空字符串时，将日志文件放在应用程序所在路径的log目录下，若log目录不存在，则先创建。
获取应用程序所在路径本可以放在日志模块内部，但考虑到别的地方可能也会用到，而且应用程序一旦启动，路径就不会变，所以就做成了一个单例类CSelfPath。
CSelfPath仅在构造函数中调用GetModuleFileNameA一次获取路径并分割成目录、文件名等等部分。
六、CLoggerImpl与Logger
日志的实现类里边有好多东西我都不想给调用者看到，典型如private的成员；还有日志实现类的接口并不易用。所以我在日志实现类和调用者之间又引入了一个间接层Logger，它的主要作用就是隐藏日志实现类和使接口更“亲民”。当然除了这个我还给了它一些别的功能：控制日志输出级别。Logger并不是一个类。
七、Disable 3rd party library warning
我在使用boost关于string的algorithm的时候，发现编译器会大段的警告，这来自boost库中对std::copy的使用，而我明确的知道boost库的这段代码是正确的。这些警告又多又烦人，有没有安全的办法消除这个警告？
肯定有了：
#pragma warning(push) #pragma warning(disable:4996) #include <boost/algorithm/string.hpp> #pragma warning(pop)
上面的代码保存为一个头文件：boost_algorithm_string.h。以后要包含boost/algorithm/string.hpp时，均以boost_algorithm_string.h代替。
源码：https://git.oschina.net/mkdym/DaemonSvc.git （主）&& https://github.com/mkdym/DaemonSvc.git （提升逼格用的）。
2015年11月1日星期日
