之前有朋友在博客里希望我能列出自己使用的所有Vim插件，一直没有时间，趁周末的最后的几个小时，就给大家列一下，大家可以实行拿来主义，取自己需要的，呵呵～ OK，一个个来说吧～～

plugin:

• 编程相关:
  • 公共:
    • taglist 相信无人不知其大名，用来提供单个源代码文件的函数列表之类的功能。最近在使用一个针对面向对象语言的类似插件-tagbar.vim，也很不错。
    • NERD_commenter 提供快速注释/反注释代码块的功能
    • DoxygenToolkit.vim 添加doxygen注释
    • UltiSnips 提供超强的快速生成代码段的功能(超越snipmate)
    • mark.vim 给不同的单词高亮，表明不同的变量时很有用。（特别说明一下，vim.org上有两个Mark.vim，请使用链接中指向的那个，另外一个是有bug的）
    • authorinfo 自动生成/更新文件的作者信息(本博编写)
    • checksyntax  一个通用的语法检查插件，支持c,js,等等
    • Indent Guides 用来帮助缩进对齐的插件，需要的时候会很好用
  • c/c++:
    • omnicppcomplete 提供C ...

其实我想只要能看到这篇博客的朋友，又是学过C/C++的都应该知道，如果一个对象需要作为函数调用的一个参数，同时对象分配的内存又非常大的时候，应该使用const T&来作为参数。

虽然知道这一点，但是我还是经常会在传递string参数的时候，直接不使用引用，今天仔细看了一下string的写时copy，突然想到，大家看到string就要求传递引用会不会只是一种惯性驱使呢，string的copy真的会把分配的内存全部copy一遍？

我们其实做一个简单的实验就知道了，代码如下：

#include <iostream>
#include <string>
#include <vector>
#include <map>
using namespace std;
void test1(string c)
{
    printf("c[%u]\n",c.c_str());
}
void test2(const string& d)
{
    printf("d[%u]\n",d.c_str());
}
void test3(const string e)
{
    printf ...

注：本文是公司同事的一个分享，由于很有代表性，特分享在此，希望对大家有用。 上次welkin在处理一个豆瓣的cgi时遇到1个奇怪的问题，就是对一个string对象的修改引起了另一个string对象的同步修改。后来定位到原有，是因为有函数对string对象的buf内容直接进行了操作，破坏了“写时拷贝”的规则。下面这个例子说明了问题是如何产生的，已经如何避免：

int main()   
{   
    string str1 = "abcd";   
    string str2 = str1;   
    char *p1 = const_cast<char*>(str1.c_str());   
    p1[0] = 'o';   
    //这里str1和str2同时被修改了   
    printf("%s %s\n", str1.c_str(), str2.c_str());   
    string str3 = "abcd";   
    string str4 = str3;   
    char *p2 = &(str3[0]);   
    p2[0] = 'o';   
    //这里只有str3被修改，str4不变   
    printf ...

首先庆祝一下QQ餐厅正式不删档公测，本以为终于可以不用那么晚发版本了，结果昨晚入口CGI出现问题，折腾到凌成4点多，杯具……

先截个餐厅的图给大家看一下：

先来介绍下背景，公司是使用自己写的webserver，然后用fastcgi的方式运行CGI，结果前端返回502错误。和运维的同学确认后，了解到当CGI在执行完却没有返回给webserver任何数据，就会报502错误。
检查了一下代码，任何出错都会有错误返回。
于是strace了一下进程，发现在出现一次如下的错误之后，以后的请求就全部都会出错。

其实这个CGI和平常的CGI没有什么区别，只是由于用到了模板类，所以使用cout来进行输出而不是printf，结果问题就出在了cout上。

与printf不同，cout在出错之后，会保存出错的状态，而由于fastcgi是一直在内存里的，所以在cout第一次出错之后，后面的就全部都会出错。
解决的方法是：
在每次开始cout数据之前，调用一下cout.clear()

之后，问题得到解决，在出现上图中的错误之后，以后的数据也一样可以正常输出。

但是这样毕竟不是办法，因为当访问量非常高的时候，用户遇到错误的概率也是非常高的。

以为是cout的数据不全，于是尝试在CGI输出的最后，我加了一行：cout<<flush;，结果发现出错的概率反而变高了许多，于是就去掉了。

目前猜测的问题还是底层库可能有头文件和.a不一致的问题，之前碰到一个应为这个问题写越界的，还有一个也是这个原因结果编译成可执行时，cout会core，看来底层库的统一也是件大事啊

参考文章：
endl cout 缓冲区执行时立即刷新

最近在使用django开发的时候，遇到了很多问题，特此记录在此，希望对以后的同学有所帮助。 一.django的ManyToManyField，当关联自身时，实现单向关联。 比如代码如下：

class MManConfType(models.Model): 
    linkconftype = models.ManyToManyField(‘self’,null=True,blank=True)

在这种情况下，当类型1关联了类型2的时候，那么类型2也一定关联了类型1，所以linkconftype就会始终是大于两条记录 解决的方法就是，增加symmetrical=False的定义，即：

linkconftype = models.ManyToManyField(‘self’,symmetrical=False,null=True,blank=True)

官网上的解释如下：

ManyToManyField.symmetrical Only used in the definition of ManyToManyFields on self. Consider the following model ...

最近工作忙的要死，明明积压了一大堆博文要写，结果却始终没有时间，也沉静不下心情来写。不过知识这种东西，如果不及时沉淀下来，恐怕很容易就会忘记了，所以还是赶紧写一下。
前几天在开小组例会，同事提到了一种makefile的写法，编译过大型工程的朋友应该都知道，当多个模块要协作编译的时候，通常要进入一个个目录去编译，所以，makefile可能如下所示：

all:
    cd dir1;make all;
    cd dir3;make all;
    cd dir2;make all;
clean:
    cd dir1;make clean;
    cd dir3;make clean;
    cd dir2;make clean;

当然，我们也可以用makefile自身的特性，即 make all/clean -C dir1来进行编译，但是实际上两种写法都避免不了3个问题：
1.当新加入一个模块的时候，要写入两句代码，一句是all，一句是clean ...

最近一直在思考，如果又那么多需求需要在vim里面调试gdb，执行python文件，链接数据库，与其每一个都去用vim脚本实现，为什么不直接把终端所有操作接管呢？

然后我去了www.vim.org的首页，然后，我居然真的看到了这个插件：
Conque Shell
下载链接：http://www.vim.org/scripts/script.php?script_id=2771
这个插件目前的评分是 Rating 447/122, Downloaded by 1280 ，也就是差不多每个评分的人都是4分（Life Changing！），而我也是毫不犹豫的选择了这个选项。

废话不多说，先来上图，对，你没有看错，这真的是vim.
在vim中打开bash:

    
在vim中连接mysql:

在vim中打开python解释器:

哈哈，怎么样~~，是不是真的很酷！，OK，还有两张图，我们在最后再贴出来。来看一下这个插件的详细信息吧

一.简介 ...

今天在把django开发的系统从开发环境搬到外网的时候，发现凡是中文写入Mysql的时候，都会报错：

Data truncation: Data truncated for column xxx

网上搜了一下，排除了字段本身长度不够，剩下只能是因为mysql的默认编码不是utf-8导致，于是请教了数据组的同事，有两个命令可以修改Mysql 库或者表的编码：

修改库的编码：

alter database dbname CHARACTER SET = utf8;

修改表的编码：

alter table tablename CONVERT TO CHARACTER SET utf8;

之后一切OK。

在次仅作记录。

在vs中使用vim的映射已经不是什么新鲜事了，不过ViEmu $99的价格实在让人望而却步，但是现在好了，我们多了一个选择：

vsvim
主页：
http://visualstudiogallery.msdn.microsoft.com/zh-CN/59ca71b3-a4a3-46ca-8fe1-0e90e3f79329

这个是以vs2010的标准插件形式存在的，所以也只支持vs2010.
废话不多说，先来看几张图：

注意画红圈的地方（我好不容易才抓拍到的光标呀），用起来比较舒服的原因之一就是保持了和vim一样的块状光标（ViEmu就给改了），所以第一感觉还不错。

打开上面的config按钮，界面如下：

上图就是默认的样子。

我大体试了一下其模拟的按键，hjkl是没有问题的，G、gg、u也没有问题，但是zc、zo、C-R、之类的就都不能用了，命令行方面，试了一下:new、:e 之类貌似都不能用。

不过我觉得这样的确已经不错了，本身只是想要vim的按键方式而已，而且除了需要实时预览html的情况，我基本也不会用到vs……