关于捐款的问题

上次贝壳已经给捐款不痛快过一次了，这次还是得继续不痛快。
首先是一条低调的新闻，网易终止与红十字会的合作，据说原因是"过程无法监控"。作为一个慈善机构，过程和结果无法监控，在发达国家(好吧，成熟国家，省得犯了某些人的讳)是不可想像的。网易为什么要提出监控，红十字为什么不给监控，这个就要说到善款的结算过程和意义，以及当前中国非政府组织的现状。
已经上班的朋友可能知道，我国有两种税征收方式，连带征收和查账征收。查账征收中，国家会检查企业的出入账目，计算企业盈利，并从中抽取企业收入的一定比例，这个就是所谓的增值税。如果您不小心亏本了，或者打平，那么是无需纳税的，这个很合理。总不会说亏本继续纳税吧。企业怎么减小增值税呢？主要是购买各种东西，当然是生产过程所需的东西，这些东西会计入成本(因此出差报销需要发票，因为这些发票代表着出差这个东西的成本)。如果企业收集很多发票，做帐做到打平，不就可以节税了么？事实没这么简单的，每个企业都有所谓的总支出，而总支出是无法作假的。因为一般的发票(餐饮，手机等一般人能搞到的发票)在总支出中占的比例不得大于一定的值。换句话说，做300W的生意，如果花45W作为餐饮花费是合法的，如果花100W，那就只能按45W报账。而其他发票可不是一般途径可以搞的到的，毕竟上游厂商也要开增值税发票，从源头的1元成本增值到100元产品，增长的99元里面的税收，不是落入上游就是落入下游，大家商量着来吧。从此意义上说，捐款(尤其是企业捐款)开具发票和财务透明就尤其重要。我举个例子。
例如，你是一个企业老板，做的是把一种东西买进，加工，然后卖出的生意。东西的成本是8元，加工的成本是2元，卖出去是15元，其中渠道和营销需要2元成本(原谅我用这种很白痴的例子)，那么每个东西的净盈利就是3元。国家按照34%收税，简单点我们说税收就是1元(其实例子中还是有问题的，渠道成本超标了)。那么你每个东西纯利润就是2元。好，现在，你打算给灾区捐款，捐300(原谅我这种白痴比喻)。那么我们说，理论上你卖100个东西够么？不够！为什么？因为你要交税。你的纯盈利是3，可税交好就变2了，因此你要卖150个才够。
哪里有这种事情，我做好事还要缴税？这不是强盗逻辑么？所以一般企业捐款都要求开具发票，证明这笔钱是捐掉的。这样国家会把这笔钱计算为成本，不会让你交这种税。可如果捐款不给发票，那事情就有趣了。我做好事，还要缴税，而且很重。而且谁能开具这样的捐款发票呢？如果人人能开，那么好，我当场开个NGO，说是慈善，然后把企业盈利全部捐掉。这样我的企业永远打平(甚至可以亏损，享受国家补贴)，然后钱还在我自己口袋里面。因此可以接受捐款的慈善机构也不是说开就能让他开的，否则会成为大企业的避税所。一般情况下，一个NGO如果要开，必须要公开账目，而后获得国家认可。公开账目是获得国家认可的必要前提，如果账目不公开，国家不会认可的，否则就会产生偷税。而中国的现状是，即使开慈善组织，账目公开，也很难获得国家认可。大家只能把NGO注册成公司，给工商界开一般营业发票，然后上税。因此大家捐款只能捐给红十字会，而他的账目却是不公开的，因为你没别的选择。
而且账目不公开会产生一个更混帐的后果。如果说前面一个只是不合理，那么这种可能就只能说是混帐加没人性。那就是贪污。我们捐100，NGO提取50%(或者更高)作为运作成本，然后剩下的发给灾民，对外宣称全发了。因为你根本不知道自己捐多少，自己拿的是多少。例如，你自己捐了100，你知道你的朋友捐了500，那么如果这个NGO说总数捐了1000，你怎么知道是不是真的只有1000呢？如果公开账目，你可以核对你的捐款是否在里面。很明显，如果不在，这是有问题的。如果在，而且每个捐款人的款项都在，最后的这个总数一定是正确的。发放也是同样的问题，如果公开发放账目，你可以看你拿到没有。如果有写没有拿，这是有问题的。如果每个上面写的人都确认收到了后面的款项，那总发放数也一定是对的。而后，我们通过总接收和总发放可以算出一个组织的组织运作成本。如果有大量的善款被消耗了，那么我们就可以说这个NGO是有问题的，我们会更换NGO捐款。而造成这种高消耗的最大可能就是贪污。同时，我们也可以计算出NGO的其他问题。例如，一个NGO的工作人员拿2W去买药品，他和药品供应商很熟悉(这个情况很普通吧)。所以让他们给1W的药品，开2W的发票。实际上就是给2W现金，开2W发票，给2W药品。1W给红十字会，1W实体药品自己拿回去分掉。公开账目后可以发现，这种情况下药品价格会比正常价格高一倍。如果说为地方增加产值后，自己贪掉一部分的贪污是某种程度上是可以接受的。如果说尸位素餐，人浮于事的贪污是让人痛恨的。那么拿灾民的带血的钱的贪污就是不可忍受的，伤阴德的。更粗俗的说，生儿子没屁眼。也许，我们的红十字会账目不公开有其他理由。也许，我们的红十字会大量提留是有其他原因。然而，你这个样子，让我怎么相信你？
最后就是关于捐款的数目。有人骂姚明捐的不够多，好，我想最好的方法是这个人站出来。我们计算下姚明同志的总捐款额度和拉到的捐款额度，比上全年除税总收入，再计算下你的总捐款额度和拉到的捐款额度，比上全年除税总收入。如果你高过姚明，我们随便你骂。捐款这种东西，要骂可以，站出来。我不反对攀比，我反对的是说别人捐少了，自己却不多捐。不过估计这些人也有郁闷的理由，据说国家政府机关是摊派捐款，有个银行每人要1000多。这些人估计就是这么郁闷出来的。

关于地震的预报

贝壳这几天一直在关注地震的事情，其中经常能听到一个消息，其实地震前已经有了预测，只是因为奥运压了下来。而后贝壳在youtube上找到了一个视频"小动物曾经给予我们的警告！！(四川电视台新闻视频 )"，是关于10号在四川电视台播出的新闻，其中就有大量出现蟾蜍的解释。这个事情让贝壳觉得很惊讶和伤心，莫非上万的人命不及政治任务？不过今天，贝壳在wikipedia上找到了这个事情的全面分析，可见wikipedia也不是全无是处么。
2008年5月10日，四川绵竹市西南镇檀木村（距离震中不到100千米）日前出现了大规模的蟾蜍迁徙，有数十万只蟾蜍在一制药厂附近公路上行走，但当地林业部门解释称，这是蟾蜍正常的迁徙。地震发生后，有网民十分激动，并留言指责“专家还不如蟾蜍”，而有动物学家亦认为，“动物感受地壳变动的能力较人类敏感，因此它们能预知自然灾害也不足为奇。”。但是经过网民搜索，发现蟾蜍大规模迁徙现象曾在2006年4月于重庆、2007年5月于河北唐山、2007年9月于山东临沂、2005年7月于吉林长春、2008年5月于江苏泰州、2007年4月于四川成都等全国大范围地区多次发生并被报道，完全不于地震相关，应属一种自然现象。
OK，上面我们可以看到，有这个报道是不假，可出现现象和发生地震间不正相相关。要是出现一次防震一次，的却非常麻烦。所以这次的事情，可谓事出有因。我们也可以想像一下国家的立场，如果确认有地震，跑不掉躲不开，那为何不报呢？一方面避免了人员财产损失，一方面展现了高科技，一方面还不会给奥运带来麻烦。所以我估计最严重是国家并不确认地震，因此为了奥运而不做可能性的防范。
不过由此我到想到一个关于地震预报上的缺陷。大家知道，我们国家很多事情是领导负责制。好不好，看领导。事情做好了固然领导有很大好处，可出问题领导也会倒大霉，因此很多人不求有功但求无过。唐山地震的反思中就有消息说其实地震前已经有了现象，可是领导对于不确定的东西不敢报，怕负责。毕竟地震这东西谁都说不好，就算我们看到各种景象，可万一不地震怎么办？对于地震这种问题，领导负责制是非常荒谬的。但是如果没有一个制度去平衡，恐怕我们又会陷入另外一个极端。地震局一有情况就报，也是怕负责。那我们会陷入漫天地震预报，就是不见地震的情况下。
对于这种情况，实话说贝壳也没有什么好的想法。不过如果让贝壳做选择的话，贝壳还宁可听到一堆未必发生，也不愿意听不到将要发生。大家可以想想，你是愿意多听几次下雨没碰到呢？还是愿意下雨前完全没预报呢？

关于地震的问题

大家知道贝壳不是穷人(至少算起来，在社会上不算穷人)，这次地震了，公司组织捐款。老实说，公司里面要是普遍捐1000的，贝壳最多也就挠挠脑袋，说句"半个手机又没了"，就扔出去了。或者要是有说法，说你要带头怎么怎么的，贝壳最多也就是想想，捐了也就捐了。不过这次情况比较特殊，贝壳在出差，所以就出了点不愉快的事情。
因为贝壳在出差，所以无法直接捐款。公司组织了垫付捐款，让每个人讲个捐款额度，然后公司垫付捐款，回来再给。结果公司的一帮同事自己捐100，哄(发阴平声，一声)贝壳捐500。贝壳不想当这个出头鸟，所以就准备捐200。结果完后一统计，贝壳觉得不大对，怎么这多阿。赶紧问统计的同事，结果他回一句，你不是捐500么？
贝壳马上找负责捐钱的人联系这个问题，到不是说不想捐，而是要捐不要捐完全是我的自由，不经过我的同意怎么能随便说我要捐多少呢？大家可能觉得献爱心么，怎么还计较这个。实话说，要是哪个捐了自己一年工资，我随便你说这话，否则闭嘴。我高兴怎么捐是我自由，捐钱是捐钱，财务问题是财务问题。不经过本人同意就捐款，说起来回来让我认还是不认呢？认了就破财当出头鸟，不认回头还指不定别人怎么戳脊梁骨呢。这种随便让人一统计就捐钱的做法是否有点太不严谨了呢？
说到这里，贝壳还想起昨天看的一个笑话。一个照片，上面写，"XX慈善基金会请您捐款XXXX..."。说实话，昨天我是当笑话看的，今天我就有点笑不出来了。诚然，地震了，大家都很难过，我们想为灾区的人民做点什么，可做什么呢？怎么做呢？我的一个朋友在MSN签名上写，每次地震就捐款，捐款了就盖楼，盖楼了就回扣，回扣了就豆腐渣，豆腐渣了一震就倒，倒了继续轰轰烈烈的捐款。所以她的结论是，一分不捐。
我还是得强调一点自己的观点，每个人有捐的自由，也有不捐的自由，所以我觉得这个朋友的做法并没有什么错误。不过我们可以想想地震灾情最严重的是什么？学校。谁有听说政府机构有什么问题么？没有。要说缺钱，说地方贫穷，说着急上教育，说我们没办法。为什么死的都是孩子，而不是公务员？难道政府比学校更有钱？难道政府应该比学校更有钱？另外贝壳曾在哪里看过一个报道(请恕贝壳找不到原文)，说这次受灾的聚源中学，被称为“危房”的旧校舍没事，新校舍反到倒了。对比对比各地的白宫式衙门，不觉得讽刺和悲哀么？
http://bbs.yaolan.com/thread_50222085.aspx
http://www.my1510.cn/article.php?e5d36d79e4f603f0
还有就是贝壳看到的一个资料，凤凰的节目，江河水走西南的记者写的blog。[http://www.my1510.cn/article.php?f734ba3f59d26040]其中就谈到了，过度的开发水利资源有导致地震的可能。关于这个问题，贝壳以前从未得知(当然，贝壳也不学水利地质，所以也不知道这个问题的具体情况)，以前一直认为水坝这种东西，修越多越好。那么现在我们是否应当关注这些问题，关注水坝的负面效应。如果这是真的，即使因为实际需要而修建水坝，也至少不要为毁坏我们家园而感到骄傲。
最后就是这次中国政府的态度，我得说，主旋律是好的。反应迅速，信息公开。和三十年前的唐山，今年二月的雪灾比，相信大家心里都有数。但是我还是得说，还是不足够。很多国家的救援队不得进入灾区，新闻报道也主要以新华社为主，报道以主旋律为主。虽然说我可以理解这些行为的理由，但是我觉得，我们可以更公开。让我们看到失去生命的人群，失去生命的城市不会让我们感恐慌，一直说没事才会让我们恐慌。让我们看到有发国难财的人，有明哲保身的人，自私的人，也不会让我们止步不前，而是会让我们更明白自己在这种时候怎么做。

上帝都反奥，我们怎么办

听说北京地震了，全国地震了，这奥运还办不办？

python的几个改进

首先需要增加的就是kill掉线程的方法，目前我们统统是调用系统函数。有没有搞错阿，需要针对系统写代码不说，还不安全。在线程关闭的过程中没有辗转开解和安全捕获。从最安全的角度上说，要关闭线程最方便的就是给其他线程抛异常。python并非不可以给其他线程抛异常，可非常麻烦不说，具体执行的时候发现，其实根本不是抛异常，而是在执行过程中检查异常。这样当程序在调用外部代码的时候死循环，想kill线程的时候根本不可行。所以安全的关闭线程的异常和直接kill掉线程的方法都要有。
其次，这东西没有什么可以快速辅助处理集合的工具类，例如STL中的set_union等等。虽说每个都不难，可是统一的实现和各自的实现毕竟是有差别的。很多时候，我们只需要抽象的计算两个集合，一个和一个的交集，就OK了。

反射的几个类型

所谓反射，其实就是在运行时可以获得代码数据的技术，算是面对对象编程语言的专利。从这个意义上说，反射可以分为三个类型。
头一类是RTTI，其实这根本不算反射，本质上只能说多态。RTTI是一种鉴别某个对象是否为某个类的派生实例的技术，在C++中就有实现。简单的方法就是实现一个特定的虚函数，将当前对象所属的类虚函数表和所属父类的虚函数表一一返回。这样对比某个类的虚函数表，就可以知道是否为派生实例了。支持RTTI，程序才算真正支持了面对对象，而反射则是更高一层的技术。
第二类就是在C#和Java中盛行的反射技术，这种技术的核心在于可以通过名称寻找到对象。例如，我们可以寻找到一个叫做abc的对象，枚举其中的成员和方法，并且执行调用，这才是反射最大的意义。当我们遇到不同的数据输入时，我们可以调用不同的方法来处理这个数据，并且这个过程是动态配置的。而在C++中，我们无法通过编译器支持这个能力，必须手工的建立一个名称和一个对象的关联关系表，在合适的时候通过这个表，获得某个名称的函数入口指针。其实C#和Java中实现的方法和VM息息相关，他们的代码在目标文件中还保持着命名空间-类-对象的结构，Java还进一步的保留了源码(只是被翻译为了更快的P代码)，而C#只保留了IL代码。这样VM在执行的时候自然可以很轻松的找到对应的函数，并且获得函数签名。而C类语言的特征是汇编时代的"符号链接"方式，编译的时候保有符号，完成链接就没了。
中间插一句，其实我们完全可以写一个只支持高阶语言的系统。这样的系统未必高效，可一定方便阿。
最后一种则是python中的系统，当用户调用一个类中的函数的时候，使用一个专门的函数来决定调用哪个。因此当对付SOAP这种东西的时候，python可以直接上。而C#，Java，C++都要通过工具生成代理方法。再用代理方法去调用公共函数库，实现调用。因为python直接将调用定向到了一个统一的函数上，所以压根不需要这步。不过这步的代价是严重的性能问题，因为每次函数调用都要去检查调用目标。python是纯脚本语言，占了这点便宜，所以才能这么干。

C++继承,虚,转换规则探究

以下讨论的东西都是在VS2005下跑出来的，如果想知道别的编译器规则，请照跑一遍。以下是类定义，函数内容为打印出当前函数名称，所以就不再贴了。
class Base
{
public:
Base();
Base(const Base & o);
virtual ~Base();
virtual Base & operator = (const Base & o);

void function1();
virtual void function2();
void function3();
virtual void function4();
//virtual void function5();
virtual void function6();
};
class Derive : public Base
{
public:
Derive();
Derive(const Derive & o);
virtual ~Derive();
virtual Derive & operator = (const Derive & o);

void function1();
virtual void function2();
virtual void function3();
void function4();
//compiler error
//int function5();
protected:
virtual void function6();
public:
};
首先我们讨论继承下的构造/析构顺序。
pa = dynamic_cast(new Derive ());
delete pa;
Base::Base
Derive::Derive
Derive::~Derive
Base::~Base
关于这段代码多说两句，如果我们把class Derive : public Base中的public删除，就会出现C2243错误，看来默认是私有继承。
先是基类构造，然后是继承类构造。先是继承类析够，然后是基类析够。然后我们将virtual ~Base();的virtual删除，结果就变成了。
Base::Base
Derive::Derive
Base::~Base
注意继承类的析构没了。所以如果你打算让人继承你的类，记得将类的析构改成virtual，否则他怎么写析构都不会被调用的。
然后是虚函数继承。
pa->function1 ();
pa->function2 ();
pa->function3 ();
pa->function4 ();
结果是这样。
Base::function1
Derive::function2
Base::function3
Derive::function4
Derive::function6
看来，虚特性出来不出来完全看基类。注意到上面的function5么？假设你继承了一个类，打算写一个函数，和基类里面的某个虚函数具有一样的名称和参数，但是返回不一样。嘟嘟～～抱歉，编译器错误。而且注意function6，即使在继承类中声明说这是保护函数，也可以通过公开的基类函数的虚特性进行调用。
下面我们要说一下拷贝构造函数，这不可避免的要说到定义。
Derive::Derive(const Derive & o)
{
printf ("Derive::Derive copy constructer\n");
}
猜猜这个会出什么结果？
Base::Base
Derive::Derive copy constructer
要是经常看我blog的人就不会意外，继承类的拷贝构造函数调用的是基类的普通构造函数。如果你打算让基类也拷贝构造，那这么做。
Derive::Derive(const Derive & o):Base (o)
{
printf ("Derive::Derive copy constructer\n");
}
然后是拷贝构造函数的使用时机。运行代码如下，我们逐步分析。
Base ta = *pa;
Base::Base copy constructer
Base::~Base
当对象声明时，如果加一个=，则以=后的对象来构造当前对象，这是拷贝构造的第一个用法。
Derive tb = *static_cast(pa);
Base::Base copy constructer
Derive::Derive copy constructer
Derive::~Derive
Base::~Base
当然，如果我们声明继承类的时候，一样拷贝构造。
//compiler error
//Derive tc = ta;
当我们试图用基类构造继承类的时候，理所当然的，出错了。
void test1 (Base &)
{
printf ("test1\n");
}
test1(*pa);
输出：test1
如果我们以一个对象调用的时候，如果是引用，当然是不拷贝的。
void test2 (Base)
{
printf ("test2\n");
}
test2(*pa);
Base::Base copy constructer
test2
Base::~Base
如果是直接调用，首先是拷贝构造，然后调用，最后析构。
Base& test3 ()
{
printf ("test3\n");
return Base ();
}
pb = &test3();
test3
Base::Base
Base::~Base
当返回对象引用的时候，只有很正常的构造和析构。
Base test4 ()
{
printf ("test4\n");
return Base ();
}
pb = &test4();
test4
Base::Base
Base::~Base
返回对象本身的话，哎，怎么会这样？
熟悉语言的应该看出来了，return Base ();的时候，先跑了一次构造，建立在栈里面，返回的时候要copy到堆中。拷贝构造呢？
这就是传说中的返回构造优化拉，直接构造在堆上面，省掉一次copy，下面我们看看原始的状态。
Base& test5 ()
{
Base b;
printf ("test5\n");
return b;
}
pb = &test5();
Base test6 ()
{
Base b;
printf ("test6\n");
return b;
}
pb = &test6();
Base::Base
test5
Base::~Base
Base::Base
test6
Base::Base copy constructer
Base::~Base
Base::~Base
大家看到了？5的时候先构造，再传回，和返回对象引用的时候行为一致。6的时候可没有返回构造优化，于是先构造，然后拷贝。删除的时候先删除原始对象，再删除拷贝对象，大家可以自行证实这点。
我们再修改上面的调用为下面的。
Base td = test5();
Base::Base
test5
Base::~Base
Base::Base copy constructer
Base::~Base
首先是5的构造，析构，然后才是td的拷贝构造，析构。这个顺序，熟悉语言的人应该感觉到奇怪了吧。按照推论，应当是先拷贝再析构的。如果你这么觉得，还是先看完下面的东西吧。
Base te = test6();
Base::Base
test6
Base::Base copy constructer
Base::~Base
Base::~Base
这才是预计的顺序。注意，这里并没有调用两次拷贝构造。虽然贝壳并不了解机制，不过估计又是一种返回构造优化。
5中例子觉得迷惑的人，不妨在拷贝构造里面打个断点，看看你copy的对象是什么，无效对象！！！！
返回引用的情况下，一旦返回对象的生命周期结束了，返回的数据就无法保证有效。因此返回局部对象是非常危险的，唯一的里外就是3例子中在返回的时候构造一个新的对象而引发的返回构造优化。
下面是拷贝构造和operator =的区别和调用时间。
Base ya = *pa;
Base yb;
yb = *pa;
Base::Base copy constructer
Base::Base
Base::operator =
Base::~Base
Base::~Base
上面一个是拷贝构造，下面一个是普通构造加operator =。
最后是全部的定义和源码，类的定义参考最上面的。
void test1 (Base &)
{
printf ("test1\n");
}
void test2 (Base)
{
printf ("test2\n");
}
Base& test3 ()
{
printf ("test3\n");
return Base ();
}
Base test4 ()
{
printf ("test4\n");
return Base ();
}
Base& test5 ()
{
Base b;
printf ("test5\n");
return b;
}
Base test6 ()
{
Base b;
printf ("test6\n");
return b;
}
int _tmain(int argc, _TCHAR* argv[])
{
Base *pa, *pb;

pa = dynamic_cast(new Derive ());

// test inherit function rule
//pa->function1 ();
//pa->function2 ();
//pa->function3 ();
//pa->function4 ();
//pa->function6 ();

//test copy constructer
//pb = dynamic_cast(new Derive (*static_cast(pa)));
//delete pb;
//Base ta = *pa;
//Derive tb = *static_cast(pa);
//compiler error
//Derive tc = ta;
//test1(*pa);
//test2(*pa);
//pb = &test3();
//pb = &test4();
//pb = &test5();
//pb = &test6();
//Base td = test5();
//Base te = test6();

//diffrence between copy cotr and operator =
//Base ya = *pa;
//Base yb;
//yb = *pa;

delete pa;
return 0;
}