引用:
作者: sjinny  花括号的第一个作用是表达作用，即使会依赖于程序员之间的约定，但是这仍然能够用来表达一些信息，这是为了以后的理解和维护而着想的。以后的需求会变，但是在改动代码之前，至少应该知道这段代码以前的设计情况。
你那段代码的确可以把running泄漏到外面去，但是如果是一开始写代码的人这么做的，那么只能说这是有意而为之，这是初始设计者所设计的；如果是维护者的修改，那么至少代码本身能够表达这样的信息：维护者把一个在最初设计中的局部变量泄露到了最初设计的作用域之外。而如果代码没有那么写，那么维护者根据什么来了解最初的设计？如果没有了解到最初的设计，那么如何判断修改的风险？ |
我始终不明白你这个“意图”论是什么意思。
代码:
{
Integer i = new Integer(1);
Integer j = i;
print(j);
}
这个意图哪里不清楚了？有什么东西需要编译器去“猜”了？所谓“修改的风险”又指什么？能不能麻烦举个具体的例子？
引用:
作者: sjinny 内存，未必可以延后释放。延后释放的问题我之前的帖子里谈了。 |
大家不理会你那个“谈话”就说明大家不认可。你的结论和论据之间跳跃过大，要不迁就一下我们，放慢思考的速度？
引用:
|
而Elminster把对象生命期与内存生命期分离开的想法正好与我相反。如果把这两者分开仅仅是产生一个手动版本的析构函数，那么就失去了析构函数最大的优点：在生命期结束时自动调用。
|
早八百年我就在这个坛子上说拷贝构造和析构都是看上去很美，但是有毒的东西。它把内存管理和其它资源的管理混为一谈，不仅仍然没有作好资源管理的工作，反而给自己带上镣铐，让编译器的优化不能尽其所长，让gp的编写很难通用（因为在函数边界传递一个T这么一个简单的动作其后果是不可预料的）。当时好像所有人都反对我吧？嘿嘿，现在看来情况有所好转啊。
引用:
|
我之所以要把其他资源绑定到内存上，是因为无论是内存还是对象，都需要有生命期管理，而这其实恰恰是现在管理的最大麻烦之一。
|
不同的东西的生命期管理有不同的特点。
引用:
生命期的管理，我认为是一个普遍的问题，也应该存在通用的解决方案。所以实现了一个良好的生命期管理机制之后，那么所有的资源管理问题都能够从中获得好处。
栈可以看成一种内存管理机制，但是也可以看成一种生命期模型：它是一种嵌套的、FILO的生命期模型。从这个角度看，对于栈来说，内存管理和对象管理是一样的。
|
内存管理远远不是filo这么简单。
引用:
|
至于那些优化，如果会损及语义，那么很可能是不合算的。
|
两点：
1。优化是重要的。一个损及优化能力的语言语义模型是失败的，尤其对c++这种号称关注系统级编程的语言。
2。语义的一致和完整性是重要的。为了优化而不惜破坏语义完整性（如c++的rvo）是可怕的。
综上，既然优化没错，语义完整性也没错，那就是c++错了，是妄图把内存管理和副作用混为一谈错了。