归档 2011年8月

最后更新于 .

各位C、C++开发的朋友们,有没有想过小小的printf也会有陷阱呢?这篇文章,我们就深入来探究一下(代码均在suse10 32位系统下编译测试通过)。
废话不多说,直接上代码:


int64_t a = 1;
printf("%d\n", a);

结果是多少呢?当然是1,你可能会说。
我们来看一下结果:

1

果然是1!但是你会不会以为是 a 首先被自动转化成了 int 类型,然后输入为 1的呢?
如果真这么简单,本文到此也该结束了。我们换一个写法:

int64_t a = 1;
int b = 2;
printf("%d, %d\n", a, b);

这次的结果是多少呢?1 和 2?真的吗?我们来看一下结果:

1, 0

好吧,你可能该惊讶了 ...

最后更新于 .

在日常的前后台联调中,我们都习惯用host的方式来使某个域名的cgi都访问测试环境,然而这有一个显而易见的问题:
如果一个域名下有十几个CGI,而这次提测的只有其中的一个,那么要想整个环境可用,你除了要保证这个CGI可用之外,和你完全无关的十几个CGI也要全部调通。

很纠结,不是吗?

其实我们有更好的方式,那就是用反向代理,我们可以用nginx来实现。

以 appsupport.qq.com 这个域名举例,比如本次提测的cgi路径是:


/cgi-bin/appstage/send_topic.cgi

这个cgi要访问测试环境: 172.16.197.186;而这个域名上的其他cgi都要访问正式的外网环境(如10.137.148.124)。

http://nginx.org/en/download.html下载windows版本的nginx,解压到C盘,然后修改他的nginx.conf文件如下:


#测试环境
upstream test_env {
server 10.6.207.119;
}

#预发布环境
upstream pre_env ...

最后更新于 .

相信对于这个标题,用过lisp的朋友一定不陌生,本来也是准备了一大堆理论要讲,想了想还是直接举例子比较好。

就举最近产品提的一个产品需求吧,简单描述一下:


  1. 对于不同的第三方应用,有不同的频率限制。没有配置则使用默认值

  2. 对于不同的第三方应用,在不同的时间段,有不同的频率限制。没有配置则使用默认值

公司内部都是用C++,当时第一点想到的肯定是配置一个xml文件,里面配置上这些参数,在进程启动的时候,用tinnyxml或者其他xml解析器把xml解析成C++可以辨识的数据结构。
我们来看一下这个xml配置有多复杂:



























这个配置可以说已经非常复杂了,而最重要的是,这种产品上的需求,说变就变,如果真的现有的配置格式满足不了新需求,那么只能变更了。做哪些变更呢?


  1. 配置文件格式

  2. 配置文件解析代码

  3. 数据结构代码

  4. 计算逻辑

  5. 重新编译发布

一个小小的产品需求变更居然会带来这么多修改量,这是很不合理的,况且需求变更从来都是最频繁的事情。

我们对这五个操作步骤考虑一下:
如果把计算逻辑从C++中剥离出来,放在脚本里,由脚本解析器作为一个通用的配置文件解析工具,那么1,2,3,4,5步就都不需要修改任何C++框架代码

好吧,我们已经得到答案了,其实C++框架只是想要一个频率限制的值而已,那么这个值究竟是怎么算出来的,就交给脚本去做吧。
而对脚本来说,xml什么的配置文件完全没有必要,因为在python ...

每日归档

上个月

2011年7月

下个月

2011年9月

归档