CG@CPPBLOG

提高民众辨别是非的素质，始终被认为是很重要的。“有关部门”时刻提醒我们要广泛学习，要能够识别假币；能够通过外包装和IMEI串号等方式，辨认假冒伪劣商品，包括水货；要能分辨虚假广告，要具备一定的科学知识，对有毒的食品添加物能够正确判断，包括苏丹红、孔雀绿，以及像甲醛和苯类化合物；要冷静分析，不要被一些居心叵测的人利用，防范诸如“掉钱包”、“问路”等方式的欺诈；要注意犯罪分子利用短信来诈骗钱财；在ATM柜员机取款要环顾四周，确保没有可疑人员时，快速操作，注意遮挡。等等等等。
 
我们老百姓何时变得如此专业和机敏，怪不得网上称中国遍地都是专家和特工。我们在如此多的领域具有相当专业的水平，且冷静沉着，判断准确，意志坚定，身手敏捷。这简直是一个拥有13亿邦德的国度，还不让美帝羡慕死。
 
其实我们写代码时，常常会面临同样的问题。我认为，如果一个设计依赖于其它设计的实现，那一定是有问题的。可是往往是这样，我们需要了解太多的原理和实现，只有广泛的学习，才能写出一个能用的东西，即便是看起来不需要了解的部分，它一旦更改了实现（当然它不会通知你），你就方寸大乱，到处出错。这时候你才知道，原来你是多么的脆弱，你多么需要它，需要学习。
 
假如我们在参数解包里存配置，而我不知道参数解包在高级中断里，也不知道存配置里使用了信号量，更不知道在高级中断里使用信号量会出错。天哪，出了问题是谁之过。
 
就像我们不能责怪政府一样，我们也不能责怪被调用函数的实现者，有时候我们确实想当然的做了一些事情，也怪我们知识水平不够。但我们真的希望我们可以傻傻的活着，因为简单就意味着少犯错误。
 
其实这一切归根到底都是结构的问题，就像一个不好的体制会出现很多问题一样，一个有问题的结构也会出现相应的问题。
 
但是好的体制在哪里，是美国式的民主吗？
 
没有好的体制，任何体制都有其问题。

 
相信各位牛人都写过多线程的程序（晕死，我们现在恐怕很少项目是单线程的，就算有，还有几个中断例程捣蛋，相当于多线程），必定学过什么信号量呀、事件呀、同步呀、互斥呀、死锁呀，研究过什么读者写者、生产者-消费者、哲学家就餐之类之类的。
 
好玩吧。
 
两个不同优先级的线程抢占一个资源，高优先级抢低优先级的，哟，我锁住。呵呵，把高的挂起，优先级反转。低优先级刚拿到一个指针，高优先级的就把它释放了（汗！）。低优先级的刚判断了一个条件，高优先级的立马把状态改变，于是低优先级下面的动作全错了。
 
资源争夺，系统分析员不可回避的问题。但是我们往往都不够重视这个问题，而今，高端参数部分的一个硬伤就是。多个线程公用变量和状态，由此衍生了许多bug。那如何解决，终极之道不是如何协调各个线程，而是避免资源争夺，减少资源公用。
 
一个男人一个女人，那是和谐社会；几个男人一个女人，呃，那是光棍聚会？？！！难免你争我夺呀。
 
记住这句话，这是我的，你要用，凭什么！
 
======
 
ps，突然想到关于领导的问题，假如有一个皇帝，见一民妇，貌甚美，预征用之，其夫忿，告之，乃我妻，望谅。帝曰，宪法云，普天之下，莫非王土，率土之滨，莫非王臣。刁民，还有什么是你的，都是我的，拿来吧你。
 
一个号称管理者的类往往手伸得很长，聚合在它之下的类往往没什么私人家当，跟奴隶没什么区别，“管理类”才不屑去调什么接口函数，直接就拿了人家的内部变量（虽然有时候被迫声明为public）来用，你不服，呀喝，我把你new出来的，你被我管着，还由了你了。这样的代码不少见呀，当然生活中更多。
 
再多说两句：
1 私人财产神圣不可侵犯。
2 安得广厦千万间，大庇天下寒士俱欢颜，一人一套（唉，房子呀）。

仿函数可以代替函数指针，而且它可以保存状态（类里面含有成员变量），相当于函数指针指向的函数有局部静态变量，同时它可以同时存在多个实例。

      代码审查除了显而易见的对源码本身正确性以及可维护性等方面的验证，交流和学习也应该是其目的之一。和白盒测试相比，在很大程度上有共通之处，但侧重点不同。代码审查更偏重整体性，而白盒测试更偏重局部性。
      代码审查一般基于3种目的，包括审查代码风格，审查正确性以及是否与设计相符，还有特定目的的审查，比如效率、容错性、安全性等等。对于我们来说，对于不同部分的代码，可能有不同的目的，有时候甚至多种目的结合起来审查。但是不论如何，每次代码审查都应该确定目的，有的放矢，否则可能很难控制时间和质量。
      形式上应该是多样的，针对审查对象，应该有自查，互查，小组走读等各种方式以区别对待，否则可能难以发现隐藏较深的问题，或者因大量的讨论和会议丧失效率。但是如何区别就成了一个问题，对我们来说，什么样的问题才需要小组走读，由谁来判断，如何判断是需要明确的。
      代码审查的资源消耗是非常大的，这取决于审查的形式，审查的目的（涉及深度和广度），以及审查的频率。要认识到成本收益比和边际收益递减的规律，当然我们目前审查不足，增加审查力度的边际收益应该还是比较大的。还有一个问题就是过程成本，或者说管理成本，如何保证审查的有效性以及缩减组织审查造成的资源损耗，制度化、规范化应该是一个办法。
      审查人员的素质也是关键的。不是说任何人都能成为审查人员，他必须在对象问题上具有一定的权威性，否则审查错误比不审查还要糟糕。而我们目前的情况是，所有具有一定资质的人员，都肩负着管理任务，大多数时间都消耗在公共、行政或者其它事务上，造成在审查力度上的不足，如何协调也是我们需要解决的一个问题。
      最后的一点是期望收益的问题。如果我们希望审查发现所有问题，或者实行对审查人员的问责制，可能会造成大家都不愿意去审查代码。审查只是一个保证手段，就好像测试一样。如果一旦发现问题，就责怪审查人员为什么没有发现，那是不可取的。

1、

 
2、C++的异常处理是不可恢复的。
 
3、用懒汉式的单件如下，可能产生线程不安全。

首先，在判空时重入会被new两次，其次，返回实例的指针，可能会被会被delete掉。

1、指向非静态成员函数的指针不是普通的指针，要包含包括this指针等信息，具体取决于编译器的实现。
2、指向虚的非静态的成员函数形成虚调用，指向基类的成员函数的指针可以产生对派生类重载函数的调用，可以实现C＃中的委托。
3、委托？反射？托管？

1、研究了一下每日编译的实现，主要是vss和vs.net的命令行方式工作，一个简单的批处理如下：

究竟如何评估软件成本（工作量）？COCOMOII太复杂，其它的计算方法并不适用我们，Deiphi？我们缺少真正的专家。仅仅从需求页数、代码行数、人月生产率、千行故障率、bug消除率、测试用例数、等等是否能够估算出我们的工作量？我们的历史数据是否足以代表我们的真实状况？我们还要考虑到人员无法100％投入，在线问题的维护、部门或公司公共事务的处理，到底我们能投入百分之几？太多的变数，让这成为一个无法求解的方程式。
或许，只能慢慢地试，让这个公式逐步求精，要接受失败。

MOI——激励、组织、创意
MOTIVATION(激励)、ORGANIZATION(组织)、IDEAS/INNOVATION（想法/创意）
作为管理者，首先应该能激发下属的工作激情，树立他的自信心；然后能够组织和协调整个团队，在发生冲突，或者出现障碍时，能够提出好的见解，虽然可能不是解决方案。

处理复杂问题的方法
鉴于人能处理复杂问题的规模，我们在解决一个复杂问题时，首要要想到的就是“分而治之”，而这一切的前提是，确定问题的范围，没有范围的问题，是无法分割的，这就是规约的作用。

软件风险管理
没有任何一个软件是没有风险的，隐藏风险不如正视它，把风险列举出来，在项目早期去规避它或者为它做准备，临危不乱，可能更有效。但要注意的是，这一切的根本是如何识别风险，这需要领导者具有丰富的经验和敏锐的观察力。

调用堆栈的获得：
     54：进入函数时，会调用 link a6 指令，将A6压栈，再将栈顶指针存入A6，退出函数做相反操作。
     VC（debug）：进入函数时，会调用 push ebp ；mov ebp, esp，同54原理。退出函数做相反操作。
     以 VC 为例，说明调用堆栈的获得。
     ebp-+     +--------------------+
         |     |    . . . . . .     |
         |     +--------------------+
         +---  |         sp1        |---+
               +--------------------+   |
               |         pc1        |   |
               +--------------------+   |
               |    . . . . . .     |   |
               +--------------------+   |
          +--- |         sp2        |---+
          |    +--------------------+
          |    |         pc2        |
          |    +--------------------+
          |    |    . . . . . .     |
 
        获得 pc 指针的操作：

          若想得到函数名需要反查调试信息表。