{C++} concept给毙了:(
莫华枫
一点兴趣都没了。:(
bs还是出来新搞个语言算了。
--
反者道之动，弱者道之用
m...@seaskysh.com
longsh...@gmail.com
http://blog.csdn.net/longshanks/
莫华枫
GCC G++
Concepts
In July 2009, the C++ standards committee decided to remove concepts from C++0x
techabc
Kenny Yuan
在CS这一行混，会比较满意的一点是：好用的“新”语言从来不缺乏（不一定是时间上的“新”，很多情况只是因为原来太闭塞）
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL1: http://csbabel.wordpress.com/
URL2: http://blog.csdn.net/yuankaining/
pongba
但赞同Kenny的意见。复杂性的确是一个很大的负担和诱惑。
Concept的concept很不错，功能也很强大和适当，从一开始发展我就看好这个特性本身，不过，Concept放在C++里面有点像投错了娘胎:D C++的教科书真的不能加页数了...
Concept的非侵入式接口意味着它完全可以适用于动态语言如python, scala, ruby，如果经过适当的人推动也许会使得其所的出现在某门动态语言里面吧。
C++的现状，BS的一句话恐怕最合适不过了：在C++中有一门更紧凑的语言挣扎着想要脱出。
没有就没有吧，目前已经很复杂了，复杂到能吓跑一些人的程度了，怕是越修补坏处越多吧
在CS这一行混，会比较满意的一点是：好用的“新”语言从来不缺乏（不一定是时间上的“新”，很多情况只是因为原来太闭塞）
--
刘未鹏(pongba)
Blog | Mind Hacks
http://mindhacks.cn
TopLanguage
http://groups.google.com/group/pongba
pongba
lambda 是不错的，搞搞好还是个比较实用的特性。不过话说回来，这东东又是一个双刃剑，特别是在无GC的C++语言里，用得不恰当很容易导致控制结构复杂的程序和内存问题。连在有gc的java里lambda的加入都受到了阻碍。
其实 auto 和 range-based for-loop 是非常实用的两个特性。
莫华枫
Concept的非侵入式接口意味着它完全可以适用于动态语言如python, scala, ruby，如果经过适当的人推动也许会使得其所的出现在某门动态语言里面吧。
这样的话concept模糊了动态语言和静态语言的界限
莫华枫
2009/7/21 莫华枫 <longsh...@gmail.com>C++0x还剩下什么？
lambda 是不错的，搞搞好还是个比较实用的特性。不过话说回来，这东东又是一个双刃剑，特别是在无GC的C++语言里，用得不恰当很容易导致控制结构复杂的程序和内存问题。连在有gc的java里lambda的加入都受到了阻碍。
其实 auto 和 range-based for-loop 是非常实用的两个特性。
initial list也是挺实用的，就是这语法忒涩了。
Jeffrey Zhao
Linker
sagasw
Atry
qiaojie
莫华枫
GCC G++
一些wish:
1.发发牢骚：去掉吧，全都去掉，C++0X就集中精力把AST MACRO搞出来就行了。
2.冷静下来。C++0X应该要作为一个新的语言，在编译器里提供选项，逐渐将一些旧的东西变为deprecated的。
GCC G++
范飞龙
范飞龙
up duan
有了concept以后，C++才能抬起头来对D、C#之类的语言说：怎么样？你们的武器都不如我的新式武器好用吧，而没有了concept，C++可以炫耀的装备几乎缩减为0了。
Googol Lee
看了一下报道，基本上最大的问题就是如何把这个特性简单化，还有就是进度表的时间不够了。
而且看样子，concept在下一版也不会加入了。C++的模板加入的并不成熟，很多已有的代码还有现在的库为了使用时的成熟，使用了很多技巧。如果引
入concept，这些东西的升级是个问题。
这半年写代码最大的感受，模板不能分离声明和实现实在是太别扭了。我现在更多的使用独立的头文件来定义一个类，在使用时直接引用这个头。如果需要更换其
他类的话，只用改这个头文件就可以。这样可以避免很多编译和调试上的麻烦。
现在比较担心0x里是否还有一些和concept相关的概念，这些概念会怎么办？
On 7月21日, 上午10时36分, 莫华枫 <longshank...@gmail.com> wrote:
> 都听说了吗？concept给标准委员会毙了。不敢相信，C++0x还剩下什么？
> 一点兴趣都没了。:(
> bs还是出来新搞个语言算了。
>
> --
> 反者道之动，弱者道之用
> m...@seaskysh.com
> longshank...@gmail.comhttp://blog.csdn.net/longshanks/
久远
Zhang Chiyuan
--
pluskid
http://blog.pluskid.org
yq chen
第一个感觉是很震惊，第二个感觉是拒绝相信。这个东西可以大幅度减轻泛型代码的编写，结果...只能是无语。
missdeer
On Jul 21, 3:18 pm, qiaojie <qiao...@gmail.com> wrote:
> 呵呵，看起来这个事情从一个侧面印证了我之前所做的C++正走向没落的判断。怎么说呢，C++的语言特性已经太过复杂了，再加入各种新特性只会越补越乱。
> ＂在C++中有一门更紧凑的语言挣扎着想要脱出。＂这句话确实是点名了C++的要害。不过我觉得现在也没必要再去搞个什么新语言了，保持现状是最佳的选择。
>
> 2009/7/21 pongba <pon...@gmail.com>
>
> > 比较惊讶。
>
> > 但赞同Kenny的意见。复杂性的确是一个很大的负担和诱惑。
>
> > Concept的concept很不错，功能也很强大和适当，从一开始发展我就看好这个特性本身，不过，Concept放在C++里面有点像投错了娘胎:D
> > C++的教科书真的不能加页数了...
>
> > Concept的非侵入式接口意味着它完全可以适用于动态语言如python, scala,
> > ruby，如果经过适当的人推动也许会使得其所的出现在某门动态语言里面吧。
>
> > C++的现状，BS的一句话恐怕最合适不过了：在C++中有一门更紧凑的语言挣扎着想要脱出。
>
> > 2009/7/21 Kenny Yuan <yuankain...@gmail.com>
GCC G++
Fortran 77 -> Fortran 90 -> Fortran 95 -> Fortran 2003 -> Fortran 2008, 这里面特性加得才叫激进。
Linker
莫华枫
这里牛人这么多，没有人想过带头设计一个类C++语言吗，就像BS说的那种“更紧凑的语言”，名字嘛，C--之类的都不错啊。
肖海彤
On Jul 21, 2:22 pm, pongba <pon...@gmail.com> wrote:
> 比较惊讶。
>
> 但赞同Kenny的意见。复杂性的确是一个很大的负担和诱惑。
>
> Concept的concept很不错，功能也很强大和适当，从一开始发展我就看好这个特性本身，不过，Concept放在C++里面有点像投错了娘胎:D
> C++的教科书真的不能加页数了...
On Jul 21, 2:22 pm, pongba <pon...@gmail.com> wrote:
> 比较惊讶。
>
> 但赞同Kenny的意见。复杂性的确是一个很大的负担和诱惑。
>
> Concept的concept很不错，功能也很强大和适当，从一开始发展我就看好这个特性本身，不过，Concept放在C++里面有点像投错了娘胎:D
> C++的教科书真的不能加页数了...
C++ 是太复杂, 比起教科书表面说到的章节, 费劲的程度高的多 :(
而且 BS 一直不同意 C++ 可以提供子集功能, 而全功能的C++ 太难用对了.
例如, 允许操作符重载, 同时对象拷贝和赋值过程可能会抛异常的情况下, 要编写异常安全代码, 而且要代码演变过程中要保持异常安全, 不知道有多
么费劲.
BTW: 美国战斗机开发规范不用异常, google C++ style 也不用异常, windows 开发也不用异常, 说起来, 一个这么大
的特性, 遭到这么多大项目的抛弃, 不能有所反思吗 ?
肖海彤
为什么?
因为现在用到 C/C++ 的场合, 都是要求比较高的场合: 要么要求速度快, 要么要求使用资源地, 要么要求充分利用硬件/OS 的能力, 等
等, 不然, 大堆其他语言有更简单的解决方案.
拿网络编程来说, 如果要编写局域网file server 中, 为少量用户(连接) 服务, 要求吞吐量最大, 那么最好的架构是每
session 一个服务进程 , socket buffer 和内部 buffer 都加大; 如果是编写应用服务器, 后端有比较复杂的逻辑,
连接数几十到几百, 那么多线程服务器是最合适的(这很有可能不用 C/C++ 来做了, java 足矣) ; 如果要同时为上万, 几十万个连接服
务, 又只能回到单线程服务器上来了.
说这些有什么用呢 ? 我是想表达, C/C++ 面对的应用领域, 要求都比较高, 如果一个通用的网络库, 能够同时适应 n 多种情况, 要
么就是 n多种情况下表现都很一般(太多一般化的开销, 例如 ACE 每次 event 处理返回之后, 重新安排 timeout 时间, 这种开
销, mass connections 下就会显得很大浪费), 要么就是一大堆的 traits, 控制各种场合下的表现, 用起来特别的复杂.
既然如此, 那不如就认了, 每次都自己动手准备工作好了, 站在 raw iron 上面.
On Jul 21, 9:49 pm, missdeer <missd...@gmail.com> wrote:
> 是啊，不要加什么特性到语言中了，弄好几个库就够了
jadedrip
concept 除了简化错误输出，其实也没什么大用
Shuo Chen
qiaojie
莫华枫
一套全新的模板系统带来的复杂性让人放弃了吧
concept 除了简化错误输出，其实也没什么大用
Cheng, Long
莫华枫 写道:
>
>
> 2009/7/21 久远 <d3dc...@gmail.com <mailto:d3dc...@gmail.com>>
>
> 这里牛人这么多，没有人想过带头设计一个类C++语言吗，就像BS说的那种
> “更紧凑的语言”，名字嘛，C--之类的都不错啊。
>
>
> 要是这边搞出个什么语言来的话，怎么也得叫TopLanguage吧。:D
>
> 相比之下，如果要从C当中发展出一个语言的话，C with concept要比C with
> class更加适合。
> 相比oop，concept是独立于C原有机制的机制，对C本身的东西干扰更小。
>
>
> --
> 反者道之动，弱者道之用
> m...@seaskysh.com <mailto:m...@seaskysh.com>
> longsh...@gmail.com <mailto:longsh...@gmail.com>
> http://blog.csdn.net/longshanks/
GCC G++
qiaojie
肖海彤
> 我还是比较喜欢在C++里使用异常的C++从来都不是一门安全的语言，用了C++就要做好跟越界、野指针、内存泄漏等错误做斗争的心理准备，
> 不能指望用语言特性来解决这些问题，也不能寄希望于C++库。基本上，合理使用C++异常还是能获得开发效率上的正收益的。我最排斥的是花
> 里胡哨的模板技巧，对提升开发效率毫无帮助，无端的增加复杂性和编译时间，浪费生命的元凶。
越界, 野指针, 内存泄漏这些问题都很显性, 容易发现和处理.
但是异常安全不然, 不是那么显性的, 这里并不是指异常引发的资源泄漏, 那些好处理, 主要是程序的内部状态的异常安全. 更糟糕的是, 假设原来
的代码是组织得很好的, try catch, rollback 先包好可能抛出异常的代码, 然后是不会抛出异常的代码, 但是随着代码的演变,
不会抛出异常的某个函数, 修改成会抛出异常的话, 忘记调整, 又会引发一个出错点, 而且颇隐蔽.
肖海彤
让人放心得下.
On Jul 22, 9:36 pm, qiaojie <qiao...@gmail.com> wrote:
> 有了C#还有必要再去重复发明轮子吗？
>
> 2009/7/22 Cheng, Long <long.x.ch...@gmail.com>
>
> > 一定要是动态语言+JIT。再去走c++那种静态编译的路子没有任何前途。
董诣
翁翊成
棘手。
不过我还是赞成使用异常，尤其是从程序的最基础最开始的部分就使用，在main的部分直接来个最外层的try块，捕获所有异常，如果这里抓到了异常，
就给用户报个错，然后把程序关掉。
其实对于类似unhandled exception等运行期的错误，系统也提供了抓错误的机制，可以把core dump写文件，如果用户环境允许的话，还可以在报错对
话框中让用户上传dump文件，方便抓到错误。当然，如果提供上述的机制来抓错误，每一个发行包的符号文件是非常有必要进行归档甚至直接在版本
库中打tag的。
qiaojie
越界, 野指针, 内存泄漏这些问题都很显性, 容易发现和处理.
> 我还是比较喜欢在C++里使用异常的C++从来都不是一门安全的语言，用了C++就要做好跟越界、野指针、内存泄漏等错误做斗争的心理准备，
> 不能指望用语言特性来解决这些问题，也不能寄希望于C++库。基本上，合理使用C++异常还是能获得开发效率上的正收益的。我最排斥的是花
> 里胡哨的模板技巧，对提升开发效率毫无帮助，无端的增加复杂性和编译时间，浪费生命的元凶。
但是异常安全不然, 不是那么显性的, 这里并不是指异常引发的资源泄漏, 那些好处理, 主要是程序的内部状态的异常安全. 更糟糕的是, 假设原来
的代码是组织得很好的, try catch, rollback 先包好可能抛出异常的代码, 然后是不会抛出异常的代码, 但是随着代码的演变,
不会抛出异常的某个函数, 修改成会抛出异常的话, 忘记调整, 又会引发一个出错点, 而且颇隐蔽.
肖海彤
> 你说的这个例子反倒是证明了应该用异常。假设一个不会出现异常的函数修改成会出现异常，那么如果你不用异常机制，只有用错误返回值，这样你就必须修改所有调用这个函数的代码去处理错误返回值，而且所有被修改的函数如果原来是不返回错误的，现在也要修改成返回错误的，然后再去修改所有调用这些函数的代码，牵一发而动全身，一旦有所遗漏整个程序的健壮性就难以保证。
这反而容易保证, 用 pc-lint 指示, 说明一个函数的返回值不能被忽略, pc-lint 跑一次就可以了.
> 其实你说的异常安全并不是一个严重问题，因为90%以上的异常发生以后，整个程序或是某个任务只需要简单的向用户报告错误信息，然后体面的终止，一般都不需要从异常中恢复状态并继续执行的，绞尽脑汁去想什么异常安全代码是不明智的也没那必要。在erlang里一旦发生异常则这个进程立刻终止，很好的诠释了这种异常的使用哲学，建议好好体会一下。
呵呵, stl 一些容器会抛异常, 一些 ini 支持库, 没有的 key 也会跑异常, 等等等等, 异常发生的情况多种多样, 而不是所有程序
都能够随时终止的.
其实, 如果 new, stl 可以控制抛或者不抛异常, 自己的代码倒是容易控制.
肖海彤
> 你说的这个例子反倒是证明了应该用异常。假设一个不会出现异常的函数修改成会出现异常，那么如果你不用异常机制，只有用错误返回值，这样你就必须修改所有调用这个函数的代码去处理错误返回值，而且所有被修改的函数如果原来是不返回错误的，现在也要修改成返回错误的，然后再去修改所有调用这些函数的代码，牵一发而动全身，一旦有所遗漏整个程序的健壮性就难以保证。
设计到异常安全的问题, 用异常并不是将一个不会抛异常的函数改成抛异常, 中间的代码不用管就万事大吉了 --- 如果是倒好了.
中间直接间接调用这个函数的代码, 有一些可能原来是异常安全的, 有一些原来可能是异常中立的, 这系列函数, 都受到影响, 整个调用链全受影响
了, 这个影响比返回值的影响更大.
而且返回值的检查代码是很简单直接的, 忘记检查也很容易看出或者用工作查到, 异常安全问题就未必了.
刘逸哲
--
刘逸哲
阿里巴巴搜索技术研发中心(ASC)
Tel：010 - 65986654 手机:13504406013
Y!ID: liuy...@yahoo.cn 旺旺: liuyizhey
地址：北京市朝阳区西大望路1号温特莱中心A座16层 100026
qiaojie
2009/7/22 肖海彤 <red...@gmail.com>:
>>
>> 你说的这个例子反倒是证明了应该用异常。假设一个不会出现异常的函数修改成会出现异常，那么如果你不用异常机制，只有用错误返回值，这样你就必须修改所有调用这个函数的代码去处理错误返回值，而且所有被修改的函数如果原来是不返回错误的，现在也要修改成返回错误的，然后再去修改所有调用这些函数的代码，牵一发而动全身，一旦有所遗漏整个程序的健壮性就难以保证。
>
> 设计到异常安全的问题, 用异常并不是将一个不会抛异常的函数改成抛异常, 中间的代码不用管就万事大吉了 --- 如果是倒好了.
> 了, 这个影响比返回值的影响更大.
>
> 而且返回值的检查代码是很简单直接的, 忘记检查也很容易看出或者用工作查到, 异常安全问题就未必了.
>
Justin L
感。
C++干脆分成两拨，一拨继续用oop的方式，一拨绝对使用gp，或者说得更纯粹一些，c with concept。这样不是皆大欢喜。
用oop用得发了毛的程序员，都转而使用c with concept。不要考虑像动态语言转型了，那python那坨发展了这么就的语言不是浪费了
么？做一个纯粹的C++，没有悬念的C++不是更好。
那帮boost之流的发展派，可以自顾自的玩深沉，以后觉得合适了再发展出C++的下一个进化版，岂不更好。
On 7月22日, 上午8时09分, 莫华枫 <longshank...@gmail.com> wrote:
> 2009/7/21 久远 <d3dco...@gmail.com>
>
> > 这里牛人这么多，没有人想过带头设计一个类C++语言吗，就像BS说的那种“更紧凑的语言”，名字嘛，C--之类的都不错啊。
>
> 要是这边搞出个什么语言来的话，怎么也得叫TopLanguage吧。:D
> 相比之下，如果要从C当中发展出一个语言的话，C with concept要比C with class更加适合。
> 相比oop，concept是独立于C原有机制的机制，对C本身的东西干扰更小。
>
> --
> 反者道之动，弱者道之用
> m...@seaskysh.com
> longshank...@gmail.comhttp://blog.csdn.net/longshanks/
Justin L
要么规定C++都要处理异常，这样好办了，大家都抛异常。编译器厂家银也可以做优化，如果有碰到没有接异常的代码，那就走编译器默认的异常处理，就像有
默认的构造函数那样。
要么大家都别用C++异常了。程序并不一定需要走那种途径，C程序员使用do while(0)也是照样吃饱穿暖。
但是C++给出来一个这么高深的玩意（用还是不用异常，还真不知道是不是一个值得思考的问题)。结果就是：法典里面不写清楚，糊涂官杀糊涂百姓。（有历
史的原因——这么多代码已经在外面了，也不能把原先的代码毙了）
莫华枫
sagasw
好像语气上多少有些不满意，但是基于标准定稿时间上的考量（Herb sutter的说法以及c++ standard group里面大多数的猜测），这个东西被拖出来了。
我好奇的是为何BS不能自己拉队伍基于GCC来实现concept，既然已经在这上面耕耘了七八年了。
张慧聪
莫华枫
更重要的是BS的这篇吧？http://www.ddj.com/architect/218600111
好像语气上多少有些不满意，但是基于标准定稿时间上的考量（Herb sutter的说法以及c++ standard group里面大多数的猜测），这个东西被拖出来了。
我好奇的是为何BS不能自己拉队伍基于GCC来实现concept，既然已经在这上面耕耘了七八年了。
2009/7/23 莫华枫 <longsh...@gmail.com>Words from Sutter about concept : http://herbsutter.wordpress.com/2009/07/21/trip-report/
--
反者道之动，弱者道之用
m...@seaskysh.com
longsh...@gmail.com
http://blog.csdn.net/longshanks/
翁翊成
其实说到底，我感觉跟C++的设计者琢磨不定的想法有关。（BS本人也不知道方向）
要么规定C++都要处理异常，这样好办了，大家都抛异常。编译器厂家银也可以做优化，如果有碰到没有接异常的代码，那就走编译器默认的异常处理，就像有
默认的构造函数那样。
要么大家都别用C++异常了。程序并不一定需要走那种途径，C程序员使用do while(0)也是照样吃饱穿暖。
while前面再设置个变量保存错误码，break前设置错误码，while结束后就可以进行错误处理:-D
但是C++给出来一个这么高深的玩意（用还是不用异常，还真不知道是不是一个值得思考的问题)。结果就是：法典里面不写清楚，糊涂官杀糊涂百姓。（有历史的原因——这么多代码已经在外面了，也不能把原先的代码毙了）
肖海彤
> 只不过C++提供的异常仅仅就是他能工作而已。
据说 intel 正在结合软硬件, 研究 STM 技术, 不知道我有没有理解错: 如果成功了, 异常就很好用了: 做一个任务的开头, 开始一
个 transaction, 中间要改什么都可以随便改, 最后可以 commit or rollback, 和数据库的一样, 但是可以对内存数
据工作.
不知道能不能有真正的成果出来.
肖海彤
不过 C++ 上, 加 feature 应该也无法缩减这个周期.
On Jul 22, 10:17 pm, 刘逸哲 <lyz10m...@gmail.com> wrote:
> C++ 挺好的啊
> 一直用着也够用啊，有没有新特性其实问题真不大
>
> 2009/7/22 qiaojie <qiao...@gmail.com>
肖海彤
你是指 client 程序吗 ?
对于可靠性要求高的服务器程序来说, new 抛出异常了, 这个 session 可以不做了, 但是服务器不能崩溃.
> 好吧，还有10%的情况，确实可以处理这个异常，并且恢复状态继续重试或者换个方法继续执行，我也承认C++的异常机制设计的并不是很好，所以要保证异常安全并不是件简单的事情，但是对于这种情况，你在稍微底层一些的代码把异常接住，然后换成错误返回值向上汇报就是了，不要忘了异常是很容易转换成错误返回值的，这条同样适用于C++模块的边界。
> 作为程序员嘛最怕的就是一根筋通到底，认为异常好就不管什么地方都用异常，恨不得加减乘除都要抛异常（整数除法确实会引发异常），发现点缺陷了就写个编程守则彻底禁止，若干年后成长了再回头看看，才会发现自己当初的想法多么幼稚。
我的看法不同, 对于水平不一的团队而言, 规定一个简单明确的一致性做法, 比起让程序员自由裁决的效果要好. 我看google C++
style 里面的规定也没有很多自由发挥的空间.
莫华枫
莫华枫
Linker
Shen ShenJie
只希望D能真正的发挥作用，做出好用的IDE，大规模的书籍上市，D才是真正超越C++的优秀语言啊。
Linker
就目前的这个架势，半死不活很多年。
2009/7/23 Shen ShenJie <coo...@gmail.com>:
>> 只希望D能真正的发挥作用，做出好用的IDE，大规模的书籍上市，D才是真正超越C++的优秀语言啊。
>
> 其他情况下，C#已经让我非常非常舒适了，如果要高性能的跨平台，D确实不错，但是D缺乏库的支持、IDE的支持，大量的书籍的支持，很难发展
>
--
Regards,
Linker Lin
linker...@gmail.com
Lych
> 学Haskell吧。
> 保准你满意。
话说这帖子里只有这个回复让人眼前一亮，仔细一看，果然是这家伙发的……
2009/7/21 Linker <linker...@gmail.com>:
> 学Haskell吧。
> 保准你满意。
>
> 2009/7/21 莫华枫 <longsh...@gmail.com>:
>> 都听说了吗？concept给标准委员会毙了。不敢相信，C++0x还剩下什么？
>> 一点兴趣都没了。:(
>> bs还是出来新搞个语言算了。
>>
>>
>> --
>> 反者道之动，弱者道之用
>> m...@seaskysh.com
>> longsh...@gmail.com
>> http://blog.csdn.net/longshanks/
>>
>
>
>
stlf
代C++视图用模板机制以及编译器的力量来突破其类型限制，但现在看来很不自然。
加入concept的目的是让泛型编程更直观更自然， 但这对编译器又提出了新要求， 这个要求可能和原来的一些（比较新的）特性可能有重复。
另外程序生产力主要还是要依靠运行时产生，编译期产生的生产力主要在设计方面体现， 然而现在看起来这种设计产生了对抗类型系统（而不是解决实际业务）
上的复杂因素。
concept绝对是C++一个关键点， 她涉及到语言设计、历史的兼容、编译器厂商的支持等诸多关键因素。她的正式出现应该经过非常周全的考虑且需要
经过反复认证和协调。
可能现在时机还不够成熟， BS又在诸多因素中选择了更加稳妥的折中选择。
On 7月21日, 下午4时01分, up duan <fixo...@gmail.com> wrote:
> concept的实现有多么复杂？我觉得似乎不是很难实现的而且用处极大的特性啊，为什么cut了？莫非有人喜欢SFINAE？
>
> 有了concept以后，C++才能抬起头来对D、C#之类的语言说：怎么样？你们的武器都不如我的新式武器好用吧，而没有了concept，C++可以炫耀的 装备几乎缩减为0了。
Long Cheng
另外，发布版的调试是可以在build出来的binary后将符号文件放到一个符号服务器（symsrv），并且符号文件可以处理放入带版本管理信息的源代码信息，这样不需要将版本的代码归档，调试的时候windbg或者vs可以自动从svn抓对应版本的源代码。
肖海彤
后将宏将标准异常名全部另行 define 走, 变成自己实现的, 构造函数捕获 stack 信息的异常; 然后才 include stl 其他
文件. (仅适合所有module 都有 source 的情况了).
(没有确实实施过, 仅仅是想法 :) )
Linker
Long Cheng
翁翊成
techabc
Linker
On 7/27/09, techabc <tec...@gmail.com> wrote:
> 看到这篇对C++ 0x Concepts被否的影响有更多信息：
> C++0x Concepts的兴衰 <http://www.cppprog.com/2009/0726/2009/0726/140.html>：
> http://www.cppprog.com/2009/0726/140.html
pi1ot
On 7月27日, 上午11时49分, Linker <linker.m....@gmail.com> wrote:
> 我觉得不会有啥影响。就像c很多年没变也用的很多一样。语言的生命力主要还看用的人在什么水平，如果把vb改的像haskell一样是被淘汰的命运。
>
> On 7/27/09, techabc <tech...@gmail.com> wrote:
>
> > 看到这篇对C++ 0x Concepts被否的影响有更多信息：
> > C++0x Concepts的兴衰 <http://www.cppprog.com/2009/0726/2009/0726/140.html>：
> >http://www.cppprog.com/2009/0726/140.html
>
> --
> Sent from my mobile device
>
> Regards,
> Linker Lin
Linker
殷远超
bneliao
c++的高效来自对内存等底层像c一样的直接操作，来自对c 89标准的兼容，
而同时由于没有gc，也对编写应用软件增加了很大的复杂性；
c++有对oop的支持，却没有Java，c#般对oo范式的简练高效的支持，
gp的引进减轻oop 的缺陷，而现在没有concept也只是半吊子的gp支持，
我感觉concept对c++ 的gp犹如数学中极限概念对无穷小的理解，古希腊人由于没有极限这个很直观的概念，只能
通过反证等很复杂的方式对无穷情况的处理，现在c++模板编程又是何其的相像，由于缺乏concept很直观直接的语言支持，
c++只能通过各种各样几乎达到极限的取巧的方式来处理；
c++增加闭包处理，但c++函数天生不是first-class，使得c++以后怎样发展都很难达到haskell等函数语言对fp的支持程度；
同时c过程式的编程方式，可以改变的对象状态都和fp有一定的冲突，函数的副作用很难避免，在未来的多核或多线程的编程模型中缺乏c++语言层面的支
持，或许c++只能通过库的方式来得到一些缓解；
c++的未来很尴尬。。。
joyfire
退出就可以了。
On 7月22日, 下午11时26分, qiaojie <qiao...@gmail.com> wrote:
> 2009/7/22 肖海彤 <red...@gmail.com>
>
>
>
> > > 我还是比较喜欢在C++里使用异常的C++从来都不是一门安全的语言，用了C++就要做好跟越界、野指针、内存泄漏等错误做斗争的心理准备，
> > > 不能指望用语言特性来解决这些问题，也不能寄希望于C++库。基本上，合理使用C++异常还是能获得开发效率上的正收益的。我最排斥的是花
> > > 里胡哨的模板技巧，对提升开发效率毫无帮助，无端的增加复杂性和编译时间，浪费生命的元凶。
>
> > 越界, 野指针, 内存泄漏这些问题都很显性, 容易发现和处理.
>
> 这些错误并不是那么容易发现的，主要的问题是发生错误后程序不一定立刻在有问题的代码处出错，而是经常会在其他不相干的地方引发错误，甚至有时候也不会观测到程序出错，而是在偶然的情况下才出现可观测到的错误，以致错误的重现和调试都变得困难。
>
>
>
> > 但是异常安全不然, 不是那么显性的, 这里并不是指异常引发的资源泄漏, 那些好处理, 主要是程序的内部状态的异常安全. 更糟糕的是, 假设原来
> > 的代码是组织得很好的, try catch, rollback 先包好可能抛出异常的代码, 然后是不会抛出异常的代码, 但是随着代码的演变,
> > 不会抛出异常的某个函数, 修改成会抛出异常的话, 忘记调整, 又会引发一个出错点, 而且颇隐蔽.
>
> 你说的这个例子反倒是证明了应该用异常。假设一个不会出现异常的函数修改成会出现异常，那么如果你不用异常机制，只有用错误返回值，这样你就必须修改所有调用这个函数的代码去处理错误返回值，而且所有被修改的函数如果原来是不返回错误的，现在也要修改成返回错误的，然后再去修改所有调用这些函数的代码，牵一发而动全身，一旦有所遗漏整个程序的健壮性就难以保证。
> 其实你说的异常安全并不是一个严重问题，因为90%以上的异常发生以后，整个程序或是某个任务只需要简单的向用户报告错误信息，然后体面的终止，一般都不需要从异常中恢复状态并继续执行的，绞尽脑汁去想什么异常安全代码是不明智的也没那必要。在erlang里一旦发生异常则这个进程立刻终止，很好的诠释了这种异常的使用哲学，建议好好体会一下。
Linker
我有些同意这个观点，也可能跟我目前手头的系统有关。我只需要当系统运行了几个小时甚至几天又崩溃的时候，能给程序员留下尽量详尽的现场信息，然后安全
退出就可以了。
Shuo Chen
On Jul 21, 10:36 am, 莫华枫 <longshank...@gmail.com> wrote:
> 都听说了吗？concept给标准委员会毙了。不敢相信，C++0x还剩下什么？
> 一点兴趣都没了。:(
> bs还是出来新搞个语言算了。
>
> --
> 反者道之动，弱者道之用
> m...@seaskysh.com
> longshank...@gmail.comhttp://blog.csdn.net/longshanks/
yichen wang
Linker同学的这句名言“击穿”了我；我自己也是这种态度，我更喜欢的是仔细看代码，在大脑里呈现出架构，在大脑里想象程序的执行，最后用调试来验证自己的想法。
真是谢谢Linker同学向我推荐TL。
2009/7/26 Linker <linker...@gmail.com>:
--
Stay Hungry. Stay Foolish.
Devil Wang
yichen wang
Linker同学话也有极端的地方，不过，接受合理的部分，忽略不合理的部分就好了。
居振梁
要不我等初学者怎么理解？
--
御剑乘风来，除魔天地间。有酒乐逍遥，无酒我亦颠。
Thinking Like Children, Fighting As A Martial Artist
"Beta": http://www.xspirits.org
Alpha: http://www.wargrey.net
Blog: http://blog.xspirits.org
一饮尽江河，再饮吞日月。千杯醉不倒，唯我酒剑仙。
yichen wang
我个人对这句话的感觉就是，在编码时应该预先对你的系统有一定的思考，对程序的结构，数据的处理过程有了一个明确的认识，对于程序工作后数据和控制是如何在一起最终形成的结果有了了解。然后，编码和并生成程序。当了有程序以后，程序运行结果与预期不符合，再开始借助调试器，去寻找是实际代码的哪里和大脑的预设不一致，知道问题，解决它，并修正大脑中的思路和认识。。
与此对立的是，我见过的很多程序员写代码完全不管这些，一分钟输入30行代码，代码完成直接F5，然后通过无数次的crash/debug/step-in/out来帮助自己了解自己的代码，这样费时费力，而且不容易形成整体认识。
从这个角度想，抛弃调试器才能成为好程序员；形象化一下，你应该一开始就造大楼，就算哪里漏水，榔头修好即可；而不是一上来先造狗窝，然后用你的榔头把它敲成大楼。
就算你是新人，一开始做不到直接建大楼，必须先建狗窝，心里也要明白，这是不对的，这不是我努力的方向。
我的“说说”可入法眼？居兄也是TL的老人了，自称是“初学者"是不是有些不符合技术人员应有的开阔胸襟呢？^_^无攻击意味。
2010/2/26 居振梁 <juzhe...@gmail.com>:
--
Stay Hungry. Stay Foolish.
jigsaw
1 instruction level的Debug
2 core dump 分析
2010/2/26 yichen wang <wangyic...@gmail.com>:
yichen wang
yichen wang
一时找不到合适的禅语来印证，说个佛学书籍看到的小典故吧。
观世音大力士本身是男的，他有诸多法像示人，帮助世人解脱。他变身成一个美女，在路边引诱路人，然后两人苟合，在OOXX到高潮时，突然化作白骨，吓的路人落荒而逃。
这个典故就有些类似，有冲击力，有道理，似乎又不对。
2010/2/26 yichen wang <wangyic...@gmail.com>:
jigsaw
2010/2/26 yichen wang <wangyic...@gmail.com>:
yichen wang
2010/2/26 jigsaw <jig...@gmail.com>:
pi1ot
jigsaw 写道：
Dbger
Believe it or not, I will never be a programmer as you defined.
技术博客:http://debuggingnow.com
我的豆瓣:http://www.douban.com/people/baiyanhuang/
Mikster.Z
Fuzhou Chen
对代码的认识，我认为是底效也糟糕的工作方法。
不过对我这种主业是读别人代码的人，debugger在帮助理解代码时的作用是不可替代的。
举一个很简单的例子，当我接到一个到处使用COM的代码时——当然是产品代码，几十万
行的那种——往往是满天的IXXX interface，如果只看代码，想一两天内理解这个程序的主要
功能和调用关系，比如一两天，基本不太可能。如果那调试器跟一遍程序加上勤于笔记，
几次下来调用关系就能理顺了。
另，正如之前我和老莫前辈争论的那样，我个人是乐于看见concept被毙掉的。我更期望能
看到这个功能出现在一个新的语言上，而不是在已经本来已经表现力过剩的C++上继续添加
复杂度。
P.S.：这贴水了……
2010/2/26 Dbger <baiya...@gmail.com>:
> 当我接触一个新的系统，可能我也会看设计文档去了解设计，但最重要的一步还是通过debug来亲历系统的运行过程。
>
> Believe it or not, I will never be a programmer as you defined.
>
>
> 技术博客:http://debuggingnow.com
> 我的豆瓣:http://www.douban.com/people/baiyanhuang/
>
>
> 2010/2/26 pi1ot <pilo...@gmail.com>
--
《采莲》·江南
为卿采莲兮涉水，为卿夺旗兮长战。为卿遥望兮辞宫阙，为卿白发兮缓缓歌。
另抄自蒜头的评论：http://www.douban.com/review/1573456/：
且祭一束紫琳秋，为一段落花流水的传说
且饮一杯青花酒，为一场几多擦肩的错过
且焚一卷旖旎念，为一腔抛付虚无的惜怜
且歌一曲罢箜篌，为一刻良辰春宵的寂寞
sagasw
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
居振梁
你这个观点我也同意，而且我自己也确实很少用调试器，除非碰到特别难缠的情况。
不过总得来说我代码写的不多，调试器用的少也是因为怕麻烦(不Anti但是仍然坚持不用IDE)。
我个人对这句话的感觉就是，在编码时应该预先对你的系统有一定的思考，对程序的结构，数据的处理过程有了一个明确的认识，对于程序工作后数据和控制是如何在一起最终形成的结果有了了解。然后，编码和并生成程序。当了有程序以后，程序运行结果与预期不符合，再开始借助调试器，去寻找是实际代码的哪里和大脑的预设不一致，知道问题，解决它，并修正大脑中的思路和认识。。
我的“说说”可入法眼？居兄也是TL的老人了，自称是“初学者"是不是有些不符合技术人员应有的开阔胸襟呢？^_^无攻击意味。
jiang yu
——其实这是我的境界不够。
调试是静态的，而日志是有时序的，日志可以拿来推理。
F5可以解决的问题一般不是真正的bug——就是你的代码问题罢了，而实际上我已经很少F5，有更好的办法解决代码问题.
1. TDD，先写测试再写代码。（当然这点我也没有完全做到，本文重点不在tdd，就过吧）。
2. log
写测试，run，出错了，写log输出到屏幕，分析日志，改掉错误，再run，不断循环，...
最后为了保证整体的输出干净整理一下日志
写log优于F5的地方在于你只看你想要的结果，并且你为调试做了努力（调试也是代码的一部分），这个努力不断的积累下来，就越来越轻松了。而每按一次f5你只会感觉又像回到了从前，跟上一次F5相比，也没有什么进展。
Liu Jeffery
“调试是静态的，而日志是有时序的，日志可以拿来推理。
F5可以解决的问题一般不是真正的bug——
“写测试，run，出错了，写log输出到屏幕，分析日志，
Yongwei Wu
编译，就已经完成了一半；通过单元测试，一个人的工作就基本完成了。——但
是，和别人联调呢？这时，好的调试器绝对可以提高生产效率。
事实上，强调调试器用处的朋友们很多都提到了他们需要调试“别人的”代码。
2010/3/1 Liu Jeffery <php...@gmail.com>:
--
Wu Yongwei
URL: http://wyw.dcweb.cn/
Fuzhou Chen
事实上调试器支持也一直是我反对轻易使用concept之类的新概念的一个原因。
对比一下模板元编程就知道了，现在哪一个调试器能对元编程提供起码的支持？
而没有调试器支持的情况下像我这种人就失掉了帮助理解他人代码的最有效手段
——别想着拉原作者来开讲座，一来他们可能早就已经离职，二来他们往往
不情愿，三来即使他们愿意，我们的工作时间也不允许，因为我们这种直接处理
客户要求的工作时间要求都非常紧，平均都是要求一周之内给答复，有时甚至是
两天内。这时候我们就得回到最最原始的状态，就是从头看代码，虽然可行但效
率大打折扣，加班加点自然不可避免。
顺便说一句，千万不要小看程序员卖弄语言特性的能力。
所以我一贯的观点是新的语言特性可以自由用在小项目里，大体上一万行以下都
是可以自己控制的。但大规模的项目，或者说必须涉及多人合作的项目，没有调
试支持的语言特性最好避免使用。
2010/3/1 Yongwei Wu <wuyo...@gmail.com>:
--
居振梁
省的不同的语言有自己的库，用起来还要额外去学。
“调试是静态的，而日志是有时序的，日志可以拿来推理。
F5可以解决的问题一般不是真正的bug——就是你的代码问题罢了，”
“写测试，run，出错了，写log输出到屏幕，分析日志，改掉错误，再run，不断循环，...”
