像
bind1st(mem_fun1<void, queue<char>, const char &>(&queue<char>::push), &queIndexes);
这种把bind1st/bind2nd与mem_fun等组合使用编译通不过的解决方法：
std::bind1st and std::bind2nd don't accept functors which take reference arguments, because they themselves form references to these arguments. You can
- use pointers for your function inputs instead of references
- use boost::bind
- accept the performance cost of copying the string
是因为
The issue is a defect in the library specification.
Take a look at this bug report against gcc and the resulting discussion: Bug 37811 - bind1st fails on mem_fun with reference argument
C++03 lacked the facilities to build a perfect bind library. This issue is fixed in C++11 with perfect forwarding and std::bind.
主要是在Qt中集成Python解释器用，对于没有提供.a文件的Python版本，若想集成进MingW编译的Qt中需要：
pexports c:\Windows\System32\python27.dll > python27.def
dlltool --dllname python27.dll --def python27.def --output-lib libpython27.a
最近通信课作业要在Android上模拟出支持105信道同时通信的CDMA系统。我负责CDMA核心编解码部分，好久没用java，真的生疏了-_-! 作业还要写文档，所以趁热先弄些图出来：
CDMA编码过程（限定用java搞的，没法）
CDMA解码过程
- 关键实现代码
/*!
UserKey类的编码方法
\return byte[] 编码后的字节序列（4字节，末尾4位未使用）
*/
public byte[] encode() {
byte[] result = new byte[4]; ///< 4 × 8 = 32bit > 28bit
final int mask = 15; ///< 0x0000000F
for(int i = 0; i < size/* key length */; ++i) {
if(i % 2 == 0)
result[i / 2] |= (mask & key[i]) << 4; /// 写入byte高位
else
result[i / 2] |= (mask & key[i]); /// 写入byte低位
}
return result;
}
/*!
UserKey类的解码方法
\param byte[] 多用户混合编码1个位的字节序列
\return int 本key与混合编码字节序列点乘后的和
*/
public int decode(final byte[] main) {
int result = 0;
for(int i = 0; i < size/* key length */; ++i) {
int decoded;
if(i % 2 == 0)
/* 解析byte高位到decoded，有符号位移 */
decoded = ((main[i / 2] & 0xF0) << 24) >> 28;
else
/* 解析byte低位到decoded，有符号位移 */
decoded = ((main[i / 2] & 0xF) << 28) >> 28;
result += decoded * key[i]; /// 点乘相加
}
return result;
}
- 技术难点
1、同时支持105信道通信
本实验选用的是7位的用户码，共7个，理论上只CDMA的话仅能支持7个信道。所以要在CDMA基础上加入TDMA，其中TDMA需要一帧分为15时隙，这样15×7=105信道。
2、同时进行105信道混合编码
我们如果支持105信道，其中需要同时把105个用户的数据进行混合编码。更细节的，同时把105用户的数据的第1位混合成15个长度为4byte的字节序。0-6信道使用CDMA把各自（各选用1个用户码）数据的第1位的编码进行混合，成为1个4byte，占用1个TDMA帧的第1个时隙；依次类推7-13信道使用CDMA混合编码第1位后占用第2个时隙。
3、从105信道中解码
依次使用key对相应时隙的字节流进行全解码，每解码一遍，解出1个信道的所有数据。
4、数据对齐
本CDMA编解码恒定提供105信道，没有空信道。因此对于实验用字符串数据，可以在短数据编码完毕后（此时至少存在1个信道，其数据仍未编码完毕），恒定使用位0编码。这样在解出字符串数据后，简单的使用trim操作即可还原原始字符串。
一直以来找论文等学术资料都是去校图书馆的，校图书馆对于在校生是最好不过的了，内容针对性强，又对学生免费。但是不方便访问学校图书馆的人们通常通过免费的学术搜索引擎来查找学术文献。本篇文章对微软的Microsoft Academic Search（MAS）进行详细评测，拿来做对比参照的自然是Google Scholar（GS）。先说下MAS和GS迥异的风格吧，GS忠实的服从Google的简洁原则，整个学术搜索界面非常简洁：没有归类，没有作者相关信息，没有数据可视化，没有……，但是GS有海量的数据库，从下文的分析也可以看出GS的数据库容量不是盖的。MAS继承了微软的以人为本原则，注重用户体验，拥有丰富的功能。但是MAS比起GS更复杂也更不成熟，评测中也指出了当前MAS的一些缺点，并提出了个人的改进意见。
优点
- 良好的文献分类系统
如果我试图搜关于Read-Copy Update（RCU）的文献，用MAS就可以很方便的勾上Computer Science，放心的搜“RCU”。没有分类系统的学术搜索引擎（如中文GS，但是英文GS的高级搜索中有），直接用“RCU”这样的缩写关键词搜索通常不会有什么好结果的。
- 摘要中有关键词链接
打开一篇聚类相关的搜索结果链接，里面摘要部分有关键词链接！想从聚类查找相关技术文献非常的方便，只需点击感兴趣的关键词。
- 丰富的数据可视化
MAS有帅气的数据可视化，能够用图描述作者与联合作者们的关系、作者与作者间关系、作者文献引用关系、重要会议时间表以及领域趋势等。下面仅抓取算法大师Donald E. Knuth与联合作者们的关系图：
但是，我通过使用数据可视化也发现，MAS的数据可视化是基于Silverlight的。我的系统中虽然装有Silverlight，但64位的IE9仍然无法使用MAS的数据可视化功能。可能是由于对64位浏览器支持不好，同样的页面在32位的Opera中打开就没问题！另外Silverlight for linux总觉得不大靠谱，那样的话，像数据可视化这些MAS的高级功能在linux下就不太好用了。
缺点
- 缺乏多国语言支持
在MAS中输入关键词“文本聚类”后，居然无结果。后试了“数据挖掘”、“聚类”等均无结果，好像MAS暂时还不支持中文搜索。可能MAS需要抓取中文的文献，并且需要支持中文的索引，甚至还需要支持中文学术文献的内容抽取算法。关键词提交到服务器还需要有个优秀的中文分词器进行分词，然后分出多关键词来一起搜索。内容抽取需要中文分词，关键词分解同样需要中文分词，看来中文分词是MAS支持中文学术搜索的关键。这里测试的在搜索“聚类”的结果页面已经出现了拼音，可惜是匹配作者的：
- 同名作者难以区分
MAS试图对同名作者进行区分，来带给使用者更好的用户体验（GS完全不支持）。比如，要找“魏洪兴”的文章，名为“魏洪兴”的人可能很多，尤其在MAS不支持中文的情况下，任何同音名字都是一样的拼音。
这三个魏洪兴应该是同一个人，但是MAS却归到三个不同的作者。当然这并不会带来什么严重影响，只是预期的良好用户体验未达到。处理这个问题，可以通过研究更加智能的算法来解决。但是算法不是万能的，算法需要在给出足够多的信息时才奏效。而学术文章，虽然都有作者单位标注，但是作者可能会换单位，或者单位名字写的有些不同，这都较大影响算法的精确性。另一个万能的解决方案是人工识别，但这需要很多的人力，并不断的维护。免费的学术搜索引擎并不是文献数据库，过多的人力消耗是不允许的。MAS开发组已经认识到这一点，向wiki学习，开放了作者信息修改：
- 引用上下文摘取有问题
MAS试图通过引用上下文提供当前学术文章被引用的原文信息，这样可以让用户了解到本篇文章在其他文章中引用情况。但是从机器自动摘取的只言片语的引用片段很难找到有价值的信息，只有足够长度的文字片段才能够提供给人可以理解的信息。那么引用上下文摘抄多长才算合适呢？过长影响阅读，过短又不能够提供什么有用信息。
上面红色方框圈出来的引用上下文就完全不知道在说什么。个人觉得自动摘取引用上下文这个功能可以没有，因为与实现的复杂度衡量，它带给用户的帮助并不大。另外，如果继续把这个功能做下去的话，MAS可以让用户选择是否显示引用上下文，甚至直接把摘要片段集成到引用文献中（鼠标移到引用文献链接自动显示引用上下文啥的）。当然引用片段摘取算法也有待提高，可以找个语言学家来讨论下摘取多长才合适。
- 搜索结果中作者列表过长
MAS搜索结果中总是完整显示作者，这一点原本比GS的搜索结果中把作者、出版来源、及出版日期浓缩到一行中更加清晰。并且前面也提到了，MAS有良好的文献分类系统，可以在搜索结果中清晰的看到出版来源、出版来源分类（会议、期刊等）和出版日期。但是，事情不是绝对的，有时候该缩写时也要缩写呀，下面就是一个MAS结果中的坏例子（这里仅摘取一角）：
该篇文献居然显示满屏的作者（这里满屏一点都不夸张，1366×768分辨率，标准字体，IE9），并且有些文献还没有摘要。这不仅严重影响美观，还考验用户寻找符合要求的文献的耐心。设想，如果人品不好，搜索结果中篇篇都是这情况，谁还有耐心翻N页来寻找文献呢？建议MAS能够在作者中区分主要作者和次要作者，完整显示主要作者名字，并用几个完整的次要作者名字填充满整行。
- 数据库容量小
通过把MAS和GS对《Data Mining: Concepts and Techniques》这本数据挖掘经典的搜索结果进行对比分析，我们可以从引用次数看出，GS的数据库的确给力（如果GOOGLE的引用计数靠谱的话）。
MAS数据库容量可以比不过GS的，因为MAS有良好的文献分类和用户体验。但是MAS的数据库也不能太小哇，至少别搞的用户找个文献没找到后转投GS了。我试了几个经典计算机文献都可以轻松找到，希望MAS继续增大“库存”。
总结
总的来看，Google把GS打造为一个简单好用的工具。这个工具可能没有直接提供你所想要的便捷功能，但是它通常能帮助你找到你想要的文献，有时需要花费点力气。而微软把MAS打造为一个豪华的平台（我想未来MAS会整合进Bing搜索引擎这个大平台中）。有这个平台，你可以在各学术文献间来回穿梭，方便之余可能会由于数据库较小偶尔碰到找不到所求。上面提到的目前MAS存在的许多问题，多半是由于MAS尝试给使用者带来更好的操作体验而引入的。最后，希望MAS这个后起之秀能越来越好。