关键字mutalbe是一个比较新的C++ 特性，所以你用的编译器可能不支持它。如果是这样，你需要找到另一种方法让编译器允许你在const成员函数里修改数据成员。一种方法叫做 “fake this”（伪造this指针） ,你建立一个指向non-const指针，指向的对象与this指针一样。当你想修改数据成员时，你通过“fake this”访问它：( 实质是用const_cast<type>去掉const属性 )
这个函数使用了const_cast(参见条款2)，去除了*this的const属性。如果你的编译器不支持cosnt_cast，你可以使用老式C风格的cast：
再来看LargeObject里的指针，必须把这些指针都初始化为空，然后每次使用它们时都必须进行测试，这是令人厌烦的而且容易导致错误发生。幸运的是使用smart(灵巧)指针可以自动地完成这种苦差使，具体内容可以参见条款M28。如果在LargeObject里使用smart指针，你也将发现不再需要用mutalbe声明指针。这只是暂时的，因为当你实现smart指针类时你最终会碰到mutalbe。
Lazy Expression Evaluation(懒惰表达式计算)
有关lazy evaluation的最后一个例子来自于数字程序。考虑这样的代码：
通常operator的实现使用eagar evaluation：在这种情况下，它会计算和返回m1与m2的和。这个计算量相当大（1000000次加法运算），当然系统也会分配内存来存储这些值。
lazy evaluation方法说这样做工作太多，所以还是不要去做。而是应该建立一个数据结构来表示m3的值是m1与m2的和，在用一个enum表示它们间是加法操作。很明显，建立这个数据结构比m1与m2相加要快许多，也能够节省大量的内存。
考虑程序后面这部分内容，在使用m3之前，代码执行如下：
现在我们可以忘掉m3是m1与m2的和（因此节省了计算的开销），在这里我们应该记住m3是m4与m1运算的结果。不必说，我们不用进行乘法运算。因为我们是懒惰的，还记得么？
这个例子看上去有些做作，因为一个好的程序员不会这样写程序：计算两个矩阵的和而不去用它们，但是它实际上又不象看上去的那么做作。 虽然好程序员不会进行不需要的计算，但是在维护中程序员修改了程序的路径，使得以前有用的计算变得没有了作用，这种情况是常见的。 通过定义使用前才进行计算的对象可以减少这种情况发生的可能性（参见Effective C++条款32），不过这个问题偶尔仍然会出现。
但是如果这就是使用lazy evaluation唯一的时机，那就太不值得了。一个更常见的应用领域是当我们仅仅需要计算结果的一部分时。例如假设我们初始化m3的值为m1和m2的和，然后象这样使用m3：
很明显，我们不能再懒惰了，应该计算m3的第四行值。但是我们也不能雄心过大，我们没有理由计算m3第四行以外的结果；m3其余的部分仍旧保持未计算的状态直到确实需要它们的值。很走运，我们一直不需要。
我们怎么可能这么走运呢？矩阵计算领域的经验显示这种可能性很大。实际上lazy evaluation就存在于APL语言中。APL是在1960年代发展起来语言，能够进行基于矩阵的交互式的运算。那时侯运行它的计算机的运算能力还没有现在微波炉里的芯片高，APL表面上能够进行进行矩阵的加、乘，甚至能够快速地与大矩阵相除！它的技巧就是lazy evaluation。这个技巧通常是有效的，因为一般APL的用户加、乘或除以矩阵不是因为他们需要整个矩阵的值，而是仅仅需要其一小部分的值。APL使用lazy evaluation 来拖延它们的计算直到确切地知道需要矩阵哪一部分的结果，然后仅仅计算这一部分。实际上，这能允许用户在一台根本不能完成eager evaluation的计算机上交互式地完成大量的计算。
现在计算机速度很快，但是数据集也更大，用户也更缺乏耐心，所以很多现在的矩阵库程序仍旧使用lazy evaluation。
公正地讲，懒惰有时也会失败。如果这样使用m3：
一切都完了，我们必须计算m3的全部数值。 同样如果修改m3所依赖的任一个矩阵，我们也必须立即计算：
这里我们我们必须采取措施确保赋值给m1以后不会改变m3。在Matrix<int>赋值操作符里，我们能够在改变m1之前捕获m3的值，或者我们可以给m1的旧值制作一个拷贝让m3依赖于这个拷贝计算，我们必须采取措施确保m1被赋值以后m3的值保持不变。其它可能会修改矩阵的函数都必须用同样的方式处理。
因为需要存储两个值之间的依赖关系，维护存储值、依赖关系或上述两者，重载操作符例如赋值符、拷贝操作和加法操作，所以lazy evaluation在数字领域应用得很多。另一方面运行程序时它经常节省大量的时间和空间。
总结
以上这四个例子展示了lazy evaluation在各个领域都是有用的： 能避免不需要的对象拷贝，通过使用operator[]区分出读操作，避免不需要的数据库读取操作，避免不需要的数字操作。但是它并不总是有用。就好象如果你的父母总是来检查你的房间，那么拖延整理房间将不会减少你的工作量。实际上，如果你的计算都是重要的，lazy evaluation可能会减慢速度并增加内存的使用，因为除了进行所有的计算以外，你还必须维护数据结构让lazy evaluation尽可能地在第一时间运行。在某些情况下要求软件进行原来可以避免的计算，这时lazy evaluation才是有用的。
lazy evaluation对于C++来说没有什么特殊的东西。这个技术能被运用于各种语言里，几种语言例如著名的APL、dialects of Lisp（事实上所有的数据流语言）都把这种思想做为语言的一个基本部分。然而主流程序设计语言采用的是eager evaluation，C++是主流语言。不过C++特别适合用户实现lazy evaluation，因为它对封装的支持使得能在类里加入lazy evaluation，而根本不用让类的使用者知道。
再看一下上述例子中的代码片段，你就能知道采用eager还是lazy evaluation，在类提供的接口中并没有半点差别。这就是说我们可以直接用eager evaluation方法来实现一个类，但是如果你用通过profiler调查（参见条款M16）显示出类实现有一个性能瓶颈，就可以用使用lazy evaluation的类实现来替代它（参见Effective C++条款34）。对于使用者来说所改变的仅是性能的提高（重新编译和链接后）。这是使用者喜欢的软件升级方式，它使你完全可以为懒惰而骄傲。
My总结：使用构造函数初始化成员变量指针为0，使用智能指针。
