(00XX系列)抽抽Windows宽字符的棉絮(附日志文件源码)

        爷最近和可爱的冬瓜私底下开始了一个游戏的非秘密非官方性的民间活动。虽然是非秘密性，但是爷不太想提，因为还没什么成果。所以说大家看到一些"非XX"的字眼，其实代表的意思就是"XX"。因为官方拥有对"非XX"的解释权。
        反正就是缺少这么个日志模块，爷坚决的使用了unicode字符做为统一接口。折腾了若干麻烦，爷这里一一抽出。这个日志和江湖流传的日志一样，属于同基因产品，无异变也无混血。

先来介绍下都使用了哪些宽函数：
1.字符类型上使用wchar_t
2.格式和拷贝函数使用了_snwprintf和wcsncpy.这里我又查了下是否有_wcsncpy之类的函数。发现还真有，但是多了个locale_t locale 参数。感觉很奇怪，似乎是一个长度。我觉得这种拷贝类的只要提供一个dst的长度就足够简洁了。
3.文件打开上使用了_wfopen_s(/.../, L"a,ccs=UTF-8");表示建立一个UTF-8的编码。我尝试过UNICODE。但是是4个字节，无法对ANSI一些编码进行自适应。
4.文件写入的函数不变。因为写入都只是二进制流，只要控制好写入的大小就行。fwrite的第三个单元大小参数设置为2。
5.变参的参数格式化使用vswprintf。这里要批下vswprintf，如果是格式的内容大小大于给定的长度，居然返回-1！导致在写入文件的时候还要判断正负数，非常的不便
6.微软提供的_s安全函数。如果超出长度，程序直接终止。这有点无奈，对于一些应用程序来说，既然我已经给定了长度，超出的截断掉就好，用不着把整个程序结束掉。但是如果一些溢出代码长度恰好在指定范围内，但是行为超出，也只能稍微的加以生化毁灭。但是既然是微软平台的问题，强烈建议_s的安全性不以独立的函数调用，直接融合进去。所以对一些用户输入的东西，还是尽量用_s的东西。而这个日志模块的记录完全是由程序员和一些程序内部信息控制，完全隔离了用户的输入。


        最后是用了一个宏技巧。在写入日志的时候，不用每次都手动的输入__FILE__之类的信息参数。既然C标准支持宏的可变参，实现起来就容易多了：

//是否开启文件名、函数名、行数等写入信息
#define SCRIPT_LOG_DETAIL

#define __WFILE__2(x) L ## x
#define __WFILE__1(x) __WFILE__2(x)
#define __WFILE__ __WFILE__1(__FILE__)

#define __WFUNCTION__2(x) L ## x
#define __WFUNCTION__1(x) __WFUNCTION__2(x)
#define __WFUNCTION__ __WFUNCTION__1(__FUNCTION__)

#define __WLINE__2(x) L ## x
#define __WLINE__1(x) __WLINE__2(x)
#define __WLINE__ __WLINE__1(__LINE__)


#ifdef SCRIPT_LOG_DETAIL
#define SCRIPTLOG_TRACE_DETAIL(level) scriptlog_trace(level, L"<File>:%s\n<Function>:%s\n<Line>:%d\n", __WFILE__, __WFUNCTION__, __LINE__)
#else
#define SCRIPTLOG_TRACE_DETAIL 
#endif

#define LTRACE(level, format, ...) \
	SCRIPTLOG_TRACE_DETAIL(level); \
	scriptlog_trace(level, format##L"\n",  __VA_ARGS__);

最后一个好消息，如果需要可以直接向我索取。javaeye上需要注册3天(数据可能不准)以上才能下载。虽然方法不错，但是一般浏览到你信息的人基本都是有些急问题直接搜索的，你再给个3天，从精神上间接的杀死对方。建议改个30分钟就足够了。