其实主要目的呢，是为了玩玩Boost.asio函数库。
最近在看Windows并发编程指南，说到IO完成端口、线程池什么的。然后我想到Boost.asio说内部实现用的是IO完成端口，并且它也可以搞多线程，于是决定试试看。
因为SNTP协议是相对比较简单的嘛，所以就用它来做实验。按照RFC1361写了个简单的服务器，经过测试确实Windows和Linux下都能编译都能运行。目前只开了一个线程给它跑，不过个人感觉效率很好速度很快。
然后其实本来是打算给Windows那个Internet时间同步用的，但是搞到最后Windows也不认它，总是同步失败。 我都用NTPTOOL工具去测服务器了，发现很正常啊，不知道Windows是不是用了自己的NTP协议还是怎么的。总之最后我又给写了个Windows用的NTP客户端。
服务器启动的时候会先到一台NTP服务器上去获取时间，计算和当前机器上的时间的差，然后以后向客户端提供时间的时候都会用这个差作为偏移去校正。之所以这么做，是因为OpenVZ虚拟化环境下的我那台VPS不让改系统时间（汗）
这个步骤暂时没提供任何设置，要去掉只能改代码。本来就是实验嘛所以也不会关注那么多。
服务器和客户端的代码都在这个压缩包里（同一个文件里），有兴趣的欢迎交流w 还有一些出错的时候是没有输出提示的，原因：懒（殴
sorasntp
最近做了个Jubeat Analyzer的谱面转成Yubiosi谱面的工具。在制作工具的过程中，遇到了一个问题，就是源谱面文件中字符串的编码问题。
Jubeat Analyzer是日本人造的软件，然后它保存的谱面又没有用Unicode，所以在中文操作系统上看就会乱码。对于编码转换问题，其实C++是可以直接支持的。对于一个支持输出宽字符的文件流，把区域设置到japanese就可以了，像这样：
std::locale jpLoc("japanese");
std::wfstream fs("c:\\nanika.txt", std::ios::in);
fs.imbue(jpLoc);
如果问题这么简单就解决的话就好了……
问题是，源文件中不仅仅包含ShiftJIS编码的部分，而且还包含GBK编码的部分。比如某些地方的注释，某些 m="音乐文件名" 的地方。因为如果音乐文件名用的是ShiftJIS，那么在中文系统下就没办法正常读取音乐了。
这种情况下，来一个imbue不能解决问题。因为它读到ShiftJIS不能表示的字符的时候，这个流就给你eof掉了……
既然这样，那我就一行一行读，不同情况不同处理。自己转成Unicode。好吧，怎么转
用MultiByteToWideChar固然简单，但是我想要用C++标准库去做而不是调用系统API。因为你看，wfstream都可以读取ShiftJIS文件到wstring，那么说明内部一定有什么代码实现编码转换的。我想办法调用这编码就行了。 继续阅读在C++中进行字符串编码转换 →
现在域名是 blog.sorayuki.net ~