Aegisys[0GiNr]

一口气看完了四集，正如沈阳晚报所言：

看美食节目让人看得垂涎欲滴并不奇怪，但看得热泪盈眶却是怪事，《舌尖》就是让人眼泪和着口水一起流的节目。《舌尖》真正聚焦在烹饪上的时间并不多，更多的画面是在展现劳动者如何捕猎、采掘、加工、制作这些自然馈赠的食材，整个过程夹杂着劳动者为生活、生存而流下的汗与泪。

一代人的记忆啊。

另外手贱升级了新版的百度空间，暂时还没有发现换回旧版的方法。

http://www.cnbeta.com/articles/184365.htm

By Aegisys[0GiNr]

BLOG里好久没有写什么有价值的东西了，于是发篇水文。转载请声明作者Aegisys，如有错误请指出，谢谢。

拉氏变换（即拉普拉斯变换）是一个很神奇的玩意，它的定义很简单：

变换的结果是一个关于复数s的函数F(s)，上述式子被我们称为“单边拉普拉斯变换"，原因是积分下限从0开始，当然你也可以从负无穷开始，这时的变换就是双边的了。

同时我们有其反变换：

这个变换广泛用于解常微分方程上和计算某些实广义积分，不过这些东西看起来比较麻烦，似乎有点脱离现实，所以本文不讨论。本文只讨论那些有趣的应用。

1）数字信号处理

如果把拉普拉斯变换中的t离散化，并令s=lnz，把积分号换成求和号，我们就可以得到Z变换：

这个东西叫做单边Z变换，同时也有双边的。这个变换其实就是一个滤波器，对前来的信号作卷积运算，从而输出处理后的信号，用过AA或者CE的同学应该知道，像这些软件对音频的许多处理都建立在一个滤波器上，如调节频率，添加回声，去除噪声等，其理论基础就是Z变换。

但是具体的一个Z变换是如何计算得到的呢？比方说我想去除录音时50Hz电流干扰，这时如何计算我们需要的Z变换？

在计算有关频率的滤波器参数时，我们的办法通常是把z换个形式：（注意z是

PaintsNow的总码量已经超过15000行了，其中包括约5500行的核心，约8500行的API框架和1000余行的测试脚本，也算是我自己开发的最为庞大的程序了。目前程序离初步的设想还遥遥无期，不过我并不在乎什么时候能写出个样子来，反正每天写一点也是好的~

去年6月开始编写第一个demo，当时对OpenGL的API和原理基本没啥了解，边摸索边写。之前写过的最大的程序是08年的KsSuperGraphEx（约10000行，基本就是堆代码），当时还不知道设计模式为何物，后来也一直没怎么学习过。结果后来写paintsnow（当时起的名叫KsGameStudio）第一个demo时架构烂得一塌糊涂，写了3000余行后实在无法再写下去，每新加一个功能都得修改一大堆代码，结果BUG越来越多，无奈只好推翻重来。

第二个demo删掉了第一份demo中很花哨但是后来发觉一点用也没有的东西（如序列化和动态创建支持），这些花哨的功能看似灵活强大，但实际上不仅仅性能堪忧，而且给编码带来了不少的麻烦。我不想把类库做成MFC那样需要一大堆宏的支持才能正常的运行的玩意儿，我写接口的原则是simple but strong，在这一点上后来接触到的lua是一致的。

很纠结的是第二个demo也没有活太久，原因是暑假放假回家后先休息了两天，然后第三天开始看代码时就觉得浑身不舒服。先试着续了几行，

微博为什么要限定140字？大家都说是从twitter上学来的，人家是140字，我们也照搬。

这是一个奇怪的数学，不过比这个数字还令人费解的便是国内的微博供应商清一色地学来了这个数字，好像不是140的微博就不是微博似的。

于是乎我们看到了清一色的刷屏（即把文字拆分为140字为单元的微博再去发）和清一色的文字转图片。起初我还觉得蛮正常的，直到今天看到云风微博里的一句话：

"新浪宁可让用户把文字转成图片，浪费双方的流量和自己的硬盘，也不肯让用户多发几个字。这得多猪脑的产品经理才想的出来？难道是为了防治文字被检索？"

想想也是，如果不是真的防搜索引擎的话（为啥要防），把单条微博的字数限定在140字，这显然是在给用户制造障碍。可问题是，似乎很少有人感觉到有什么不适，甚至觉得这就是微博的特色，让发布者长话短说，同时节约阅读者的版面。

可是这两者皆不能成立，若是真有长篇大论可发，压成140字未免太不现实，若是节约阅读者的版面，则可以通过只显示140字（后面用省略号代替，点开后可看全文）来解决，似乎也没啥问题。

奇怪是大家很舒服地接收了这个蹩脚的设定并且引以为荣，这有些像iPhone的电池。iPhone 的电池是不方便更换的，但是这一点恰恰成为某些果粉颇

看图说话：

46条，一言以蔽之，就是抢劫合法化，盗版公开化，手续暗箱化，收益关卡化，法律流氓化。

在C++中，基类的构造函数和析构函数中不推荐调用虚函数接口，原因很简单，因为基类的构造函数执行时，派生类的实例还没有构造，所以虚表指针还是指向基类的虚表，如果这时调用虚函数的话，就会直接调用基类相应的虚函数（即使派生类重载了它）；同理，在析构函数执行时，派生类的实例已经不存在，这时虚表指针依然指向基类的虚表，同样也不行。

但是，VC在处理上述错误情况时似乎容易误导程序员。

如果被调用的是正常的虚函数（即基类中也有一份实现的虚函数），那么默认情况下不会产生任何报错，这样就可能违背程序员想在基类中调用派生类虚函数的初衷。

如果被调用的是纯虚函数，那么VC就会报成unsolved external symbol错误。一般情况下程序员都会觉得莫名其妙（因为纯虚函数本来就不需要实现），背着常理实现一个，程序居然能够编译通过。但是这样的修补实际上返回到了上面那种错误，无济于事。

下面是一段测试代码：

#include <iostream>

using namespace std;

class A

{

public:

A::A(){ foo(); }

A::~A(){ foo(); }

virtual void foo() = 0;

};

class B

{

public:

virtual void foo(){ cout << "hello" << endl; }

};

int main(void)

{

B b;

return 0;

}

这段代码在VC中编译中，会提示没有找到A::foo() 这个

作者向歌