前两周，各种课程设计和实验，各种团队活动占据了我几乎所有的时间，睡觉都没啥时间，更不用说写博客了。
今天下午刚刚投出高频课设的PCB，暂时得以清闲，赶紧来写写博客，待我整理完微机原理的课设，后面的课设和实验也该总结了～～
QT，是我最近一直在使用的编程框架，非常便捷和强大～不但封装了各种复杂的系统操作，而且非常容易实现跨平台的C++编程。
QT的程序，一般来说，只要不是跟系统直接相关的程序，都能极为顺利的实现跨平台，但是事情总有些不顺的地方，偶尔，切换平台以后，它会DT的出现各种错误，这其实是我还不甚了解QT造成的，下面，我还是基于之前的微机原理课设，说说QT中这么几种阻碍跨平台的情况。
QT工程的跨平台问题
在Windows下全部编译通过后，移植到Linux下（感谢葆光的帮助），发现出现了文件未找到的错误，经检查，发现是lib文件的问题。
lib文件是编译过程中生成的中间文件，在Windows下的格式是“xxx.lib”，而我在pro文件中指定lib文件时使用的如下方式：
LIBS += dian_matrix_libd.lib
后来发现，这样的写法是非常不具有跨平台特性的。可以说是硬编码，因为Linux平台下的lib文件是xxx.o的形式，这样看来，直接指定名称及后缀是非常不可取的。
避免方法：使用如下形式：
LIBS += -ldian_matrix_libd
QT是个跨平台框架，自然会提供全套的跨平台服务，-l前缀是QT工程文件中表征lib文件的标记，加上这个前缀，QT工具会自动寻找对应lib文件，完成跨平台的任务。
针对这个问题，我想，在使用一个工具时，应该了解它的设计宗旨，如果某个功能在它的宗旨之内，而这个工具又是一个优秀工具的话，它一定会以某种形式提供这个功能。
编码的跨平台问题
在Linux系统下编译完成后，发现运行结果异常，表现为汉字显示的乱码，大致如下图所示：
之前在Windows平台下其实也遇到过类似问题，通过VS调试后发现是编码错误，因为HZK16文件是基于ascii码编制的字库文件，使用如下方式获取文件的偏移量：
// get the word's zone/bit code
unsigned char zoneCode= word[0] - 0xa0;
unsigned char bitCode = word[1] - 0xa0;
long offset = (94*(zoneCode-1) + (bitCode-1))*32;
然后使用随机读取的方式获取文字点阵信息。
这种方法严重依赖字符的编码方式，只能使用ascii编码才能正确访问，wstring使用 unicode编码，ubuntu下使用utf-8编码，造成了显示乱码的现象。
解决方案：
使用QT库提供的QTextCodec类完成各类编码的转换工作，使其统一转换成“GB18030”编码方式，就可以正常的访问汉字字模信息了。
住：此部分两张图片为Windows下的截图，只为更清晰的说明，不是证明。
---------------------------------------其他跨平台问题---------------------------------------------
文件路径问题
在Linux下运行编译结果时，发现找不到HZK16文件，但是明明已经放在目录下了。经分析，最终确定是文件路径的分隔符“\”和“/”的问题。
使用QDir::toNativeSeparators函数可以解决此问题。
注：这个问题是经常出现的，非常让人烦恼，最近的编程中，发现QT含有QDir, QFile, QFileInfo 等多种类支持很多的文件操作，几乎将所有的文件操作（包括文件名、路径、目录的获取）封装起来，非常容易实现跨平台编程。
串口端口问题
在Windows下使用的是COM1~COMn的形式，而Linux下使用的ttySn的形式，如何编写跨平台的程序？
目前为止，我还没有找到一个非常好的方式，只是使用了条件编译的方式来限定不同的字符，如下：
// add serial device name to the combo box.
QString commonName=
#ifdef _WINDOWS
"COM";
#else
"/dev/ttyS";
#endif
for (int i= 0; i < 4; i++)
{
QString fullName= commonName +
#ifdef _WINDOWS
QString::number(i+1);
#else
QString::number(i);
#endif
serialDevice->addItem(fullName);
}
OK，在微机课设中，我遇到的跨平台问题大概就这么些了，将来若再遇到棘手的问题，一定会贴上来供大家分享的，嘿嘿～～
