eXile 的专栏

在这个例子中，s所引用的临时变量的生命期和s的生命期是一致的。

gips现在只有高级会员能下了啊，而且好象只能用三个月。。

FROM JAVAEYE:
注释与文档的本质，是为了便于软件的开发和维护，而不是在一道一道的工序之间作为“交接班”的说明

FROM JAVAEYE:
很多大公司的代码都没有任何注释，很多大师写代码也没有注释（看看junit就知道了，大家可能不知道这个东西是两个大师在飞机上试验结对编程的副产品）。原因在于他们根本就不能容忍任何注释造成的味道。

FROM JAVAEYE:
实际上过多的注释妨碍了重构的进行，如果你想让代码僵化那么就写大量的注释好了，越多越好，甚至注释:代码=10:1。重构的结果往往是删除掉大量的注释，因为它们或者已经不适合代码当前的结构，或者已经不再需要，因为代码的结构已经非常清晰了。而且我并不知道是否还有可能进行下一次重构，那么我写太多的注释是不是很有可能是在做无用功？我其实只要写很少量的注释就足够了。

FROM JAVAEYE:
就说注释好了，比较一下：
1。可运行的代码
2。测试代码的单元测试和其他测试
3。注释

这个重要性应该是向下递减的。没有1，其他都没有意义了。没有2，就没有一种可执行、可重复的方法来验证1的正确性。

至于注释，对于程序的功能、正确性和可靠性，对于客户来说是没有任何意义的，所以除非有特殊的理由，我们才去写注释。

一般来说，坚持写注释的人最重要的观点是便于自己或后来者理解代码，减小程序维护和变更的成本。这个我们当然喜欢，但是要注意几点：
1。注释到底是不是最好的工具来加快和精确理解
2。达到这样的目的需要多少成本

第一点，首先绝大多数注释是细节程度上的，基本上和代码本身处于同一层次，因此我们需要看一看代码本身是否比注释更有权利。
注释的目的基本上是为了说明
1：代码实现中的权衡
2。代码本身的目的
3：别的代码使用该代码的方法

以Java举例，注释包括包注释、类注释和方法注释。在99%的情况下，我认为只有包注释和类注释才有意义，因为一个包和
类只有自己的名字来解释自己的含义，如果是一个简单的类，譬如说是Rectangle，当然这个名字已经说明了一切。但很多时候，
一个类里面包含很多方法，很难简单地用一个类名字来描述整个类的意图和作用这个时候，这个时候代码本身是不足的，需要类注释的。

对于方法层次上的注释，除非你这个方法用了非常复杂的算法，那么我们最先关注的是它的目的，这个目的用方法的名字就足够了，
如果你认为它有三个目的，或者有几个阶段，那你必须重构，直到达到这个目标。这里代码比注释的好处是能够优化代码本身的结构，
易于重用和新变化，没有同步的成本，更重要的是它是可执行的。

有的时候，例如内部实现是错误的，我们需要修改代码，这个时候我们也需要理解这个代码地实现方式，但我认为一旦达到了上面的要求，对一个程序员来讲，代码更精确、更简单地能够被理解，而不是注释，除非注释逐行解释代码地实现。

至于别的代码如何来使用你自己的代码，我不由得回忆起当初学习delphi地经历，在我使用一段delphi以后，我很多时候都是凭自己对delphi函数命名的习惯的猜测去调用一个个函数，而不是依靠delphi地API文档和delphi源代码里面的注释（实际上非常少），真的无法理解就去看源代码。而对于一些我完全是初学的类或者函数，我的做法首先是去寻找范例代码理解函数调用的顺序，至于这种理解是否正确
最终取决于我自己的不断测试。对于一些复杂的方法，我会在基本已经理解，并且能够使用的情况下再去看是否还有别的什么"诀窍",后门等等。因此，在这方面单元测试无疑比注释更有用，但是如果一个方法确实比较复杂，并且不同地类和函数之间有一定的依赖关系，我们需要专门的API文档，注释根本做不到这一点。

第二点，注释的成本。注释无法验证，注释不能执行。因此，注释必须完全通过手工来进行维护，当一个类被重构为一个类层次，
当一个方法被抽取成两个方法，当一个类的某些方法被移到另一个类，一个类地实现被改变（接口不变）的时候我们都必须手工去维护
这些东西，并且无法知道我们的注释到底是不是正确揭示了这个类、方法的意图和实现思路。这个成本是非常高的，特别是当我们
知道注释既不能为客户提高更多的价值，也不会对其他程序员理解代码有多大的帮助。当然，如果我们有足够的人力、物力愿意干这样的活，有些时候也会稍微有点帮助。

JAVAEYE上真是有不少明言警句啊, 看来都是高手。。。

FROM JAVAEYE:
阅读有些test case只能让你云里雾里，而阅读有些则让你马上就知道这段代码的用途。其实找并不是这些test case写的有水平差别，而往往是有针对问题角度的差别。而进一步，你会发现阅读这些test case如果按照一定顺序，就会从最初的动机到最终的实现细节都有一个清晰的理解，而如果我们能够在写这些test case的时候就标注出这个理解顺序，将是十分核算的。而实际上很多时候我们书写的顺序就是最终我们适于阅读理解的顺序。

FROM JAVAEYE
就是因为“文档/注释”在代码的频繁修改中太容易过时，而且也太容易为人所忘记，所以在我的实践中不写文档，我的文档就是我的“代码+单元测试”，想知道我的想法，看“代码+单元测试”就行了，没有任何形式的文档比“代码+单元测试”更能体现我的设计
- 我们的文档是十分简短和松散的，一般放在wiki上，起到story guide的作用，但如上所说，随着开发很快就过时了，从中你能找到设计的逐步迭代，但它和最终的产品是有差别的
- 对于我们开发工程师来讲，“代码+单元测试”就是我们的文档，对于客户来讲，有专门的产品文档供他们使用，但是那是由文档工程师写的

FROM JAVAEYE:
对于大多数的中国的软件开发团队来说，难以实现敏捷的最重要问题是人的素质问题。一个敏捷团队要求每个成员都有较好的OOP和OOD的能力。.......实现敏捷是一个渐进的过程。构造一个在技术上有敏捷能力的团队有两种方法，一是用足够的钱去招聘有足够能力的程序员(大部分企业没有那么多钱)。二是将现有不符合敏捷技术要求的程序员培养为合格的敏捷工作者。而在培养的路上，单元测试正是一个很好的驱动方式和实践平台。

@neoragex2002
这个老兄还是对ＴＤＤ有一个起码的了解以后，再来讨论这个问题吧。

signal/slot机制正是在C++中解决这种问题比较好的办法，可以看我的办法：
http://www.cppblog.com/eXile/archive/2008/01/09/40782.html

只要是原创的，发在几个blog也无所谓啊，独家不独家的有什么关系呢

谢谢，改过来了。

http://www.javaeye.com/topic/5876
关于文档和注释的讨论

http://www.javaeye.com/topic/6294
关于文档和注释的讨论

而且你的这种实现存在死锁的可能性, 即使不死锁，也会使线程反复切换，效率不高

这种办法很容易导致写饥饿...
一般来说写的优先级应该比读高一些

修正了一个bug ( signal.h: 92)

template<...>
class signal
{
//....
template <class T>
void connect(SP_NS::shared_ptr<T> const& f)
{
_connect(slot_type(f.get()), f);
}
};

没大明白，有代码就好了。。。

@weiliang
Re : 对象属性 编辑控件 ?
在qt solution中已实现了这种控件，安装后即可使用

不错，有点吸引力

另外, 保证你的模块不出差错, 不是靠文档和注释, 而是靠测试,
文档和注释,也分两种, 一种是给自己看的, 一种是给别人看的, 这两种写法是不一样的,
对于写给自己看的文档, 如果会影响开发进度的话,为什么要写它呢?这说明写文档的方法不对.

我觉得, 好象你理解的设计总在变化这句话有偏差, 设计变化的原因主要有两点:
1) 需求的变化, 主要是系统功能的改进, 扩充, 版本的升级
2) 需求的细化, 主要是需求本身不会考虑到所有的实现细节, 在实现时才发现有设计不当的地方.

这个问题, 称之为重构.
在没有单元测试的保证下, 进行重构是一种危险的行为. 正如你说的一样, 要指望不出问题, 那是奇迹. 这也不能怪软件工程没学好, 因为我们学的软件工程本身就是有缺陷的.

"把需求看好、文档写好、时间安排好，这才是硬道理…… "
这是不对的, 设计的唯一不变的特点就是: 它总是在变化.
--是不是有点有饶口 :) , 这是<<设计模式Head First>>中的一句话.
所以我们做的, 是如何应对变化.
推荐看一下: <<重构，改善既有代码的设计>>

其实qmake很方便的，有了qmake，我都很少使用ＩＤＥ了。

个人认为boost现有的signal 实现并不怎么样, 应该在下一个版本中有较大的更新。
再来解释一下，使用trackable是为了把它作为一个基类，trackable对象销毁时，能自动断开相关连接。而connection的设计是因为boost::function并不能也无法提供一致的相等性比较，所以用connection来管理slot 的连接。当然设计的关键之处是还是要防止悬挂指针的出现,所以slot管理器并不直接操作slot的实例。

SQLite现在的版本可以加密了吗？我好象在它的文档里没有找到相关说明啊？

这篇文章说的还是socket编程的模型。
使用ＡＣＥ，主要用的还是Reactor或Proacoter框架，到那时，还认为ＡＣＥ不难的，那都是高手。。。

有一定道理。不过如果Ｄ再成熟一些的话，选择Ｄ＋wxD 也不错。

在c++中，应用设计模式却不使用智能指针，内存管理迟早会变成一件极其痛苦的事情， 孟岩(?)甚至说在C++中不使用shared_ptr,就不要谈面向对象设计。。。

@力为
呵呵，如果MFC也跨平台，唯一的可能就是Windows已经失去了大部分江山。。

遗憾啊，对eXtreme 比较熟....

@fr3@K
这就要看CTest 是值语义还是指针语义了，对于指针语义，我觉得最好采用第二种接口类办法，这样概念上不会混淆，也便于将来派生新的功能。

1)Adapter: 使风格统一, 不受外来库API的污染，
使 2)Bridge：用beta版的lib开发软件，或者是开发所依赖的库有较大的可能 在软件的生命期内发生改变时，通常使用该模式
这些确实需要有时间和实践来理解，才能有深刻的体会。。。

QSettings有它自己的序列化机制，要控制它的编码方式，最好还是用自己的INI配置类吧。

信息产业部教育中心总工程师沈林兴把五笔字型输入法、汉字激光照排系统和汉语编程作为汉字在计算机应用中的三大里程碑，“而汉语编程更具革命性意义。”他欣喜地看到
这一颠覆已经悄然开始。

　　近日，用汉语编程实现的数据库开发环境将通过江苏省科技厅的验收。按照进程，汉语程序设计语言数据库开发环境项目完成后一年，项目承担方——南京汉语编程有限公司将以汉语编程数据库教育版为推广重点并进行其他工程开发。项目完成后两年，汉语编程数据库标准版将以OEM方式与国内PC制造商捆绑销售。项目完成后三年，将推出汉语编程数据库企业版参与政府、企业、部队信息化建设，部分替代进口产品。

　　江苏省科技厅将对该项目投资三百万元。

　　同样看好汉语编程的还有重庆市科委，他们的预期投资是上千万。汉语编程作为重大科技发明发现正在申请重庆市的国家级项目。

　　重庆药监局正在应用汉语编程开发的数据库实现对所有下属药店的监管。目前这个项目完成了大部分，6月底将最后完工。

不许笑，这个可曾经是某政府投资几千万搞的项目, 据说是要搞中国人自己的编程语言。。。

weak_ptr的主要目的是为了解决引用计数的循环引用问题
boost 出于线程安全的考虑，并没有为weak_ptr提供->重载或get方法，所以不能直接使用, 还得转化成shared_ptr

@xiehp@sohu.com
这就是 it++ 和 ++it 的区别

@missdeer
那就应该分析一下测试的环境. 看一下有连接时,无连接时, 局域网中, 公网中.
asio本身带的例子是很简单的, 都是用法演示,最多也就服务器设定几个线程.
在局域网中进行这样的测试是没有什么意义的.
boost 的 thread 和asio都是有可能作为系统支持库进入std::tr2的.

好人越来越多了.....

刚准备自己写一个呢, 真是超爽啊, 太谢谢了....

不错不错

asio本身并不占用多少资源, 如果网络连接数不多,但占用CPU很厉害, 那肯定时是自己写的程序某个地方出了问题.

至于Observer::update(void*)可以利用ObserverAdapter实现接口强制，再利用 std::tr1::tuple 之类的来弥补类型信息的不足

发现这种设计还有两个优点：
（１）observer虽然用于解藕很不错，但是在Ｃ＋＋中，最大的问题是容易出现悬挂指针，而且出现后不易调试。这个实现在这一方面做得很不错，可以最大限度的防止这类问题的出现。
（２）由于定义了抽象接口，很容易扩充为线程安全的实现

不错, 和我的做法一样.

看来D的编译速度已经超出了某些人的想象极限.......

(1)http://qiezi.javaeye.com/blog/26685
D语言编译速度非常快(这也是Walter Bright对C++不满的一个重要原因)。dsource.org中的mango项目包含755个D源文件，但在我的机器上编译成.lib文件只需要4秒时间。
(2)
D is not a scripting language, nor an interpreted language. It doesn't come with a VM