C++ 的高级特性到底有多少实用价值?

[hunter]

我一直在努力的学习C++， 最近被GP给搞得快爽死了， 同时我工作也是在维护代码，我看我们这个小公司的代码结构极其混乱，什么多态，模板，stl
根本没人用， 加上今天我看论坛里面有人问有多少人用boost库，好多人在工作中都没用，难道C++的这些高级特性真的成了摆设吗？到头来最重要的还
是良好的编程风格，高效的算法，对业务的精确理解能力，C++的这些高级玩意对我们的时间工作有多少帮助? 似乎实际上我们大多数时间并不需要这些高级
的特性。
大家都有同感吗? 刘老大出来解释解释。

[翁翊成]

共产主义会实现的^_^

2008/4/24 hunter <hunt...@gmail.com>:

[red...@gmail.com]

老实说, 一个项目如果不是有水平好的人专门长期照顾着, 还是不要用这么多高级
特性, 第三方库 c++ 库 (简单的c库不算)都要少用, 只用标准库, 操作系统 api,
最多允许项目里面组织一个刚刚够用的库, 不要和其他项目一起组织什么强大的基
础库. 代码多一点, 冗余一点, 怕什么, ? 简单平凡的代码, 随便找个人过来, 很
快就可以读懂, 容易找出问题或者要增强特性要改什么地方.

反之就麻烦了, 说要加个什么功能, 开始读代码, 不好好将第三方库的设计思想,
API 看一遍, 会读不懂, 如果是第三方框架库, 更惨, 要看的东西更多, 到时候就
会发现, 已经读了三天的代码, 还是不知道系统到底怎么运作; 自己内部有强大的
基础库也是一样; 用了很多高级特性也会导致代码不简单平凡.

这个和 C++ 标准库太小, 高级特性太hack 很有关系, 虽然 Java 有很多其他缺
点, 但是这方面 C++ 确实太差.

[翁翊成]

代码多一点？冗余一点？
说实话，如果大量使用boost这样威力强大的库，相比较于不使用该库的代码，不知会简洁多少！
话说读懂代码，你找个不熟悉业务逻辑的人来读，虽然代码容易看懂了，如果项目没有健全的单元测试，很有可能新人改个东西，把系统干掉了。
而反观boost，实际上boost对代码起到的作用不仅仅是提供了特性，更是简化了很多操作逻辑！

2008/4/24 <red...@gmail.com>:

[Wang Xin]

大量使用boost这样"强大"的库，最终导致的结果十有八九不会是代码简洁，而是整个team内部混乱不堪，项目迟迟不能交付（引自某位在某家对于C++使用颇激进的公司内的朋友的原话，该公司的名我就不点了，反正是业界著名的一家公司）

在08-4-24，翁翊成 <wen...@gmail.com> 写道：

--
Everything is possible and available if we trust ourselves!

[翁翊成]

国内从业人员素质的参差不齐，有这样的结果也是很正常的。
C++语言很多领域都没有一个神一样的标准存在，大多商业颜色比较浓重的语言（JAVA/C#==）都由一个领袖提供一套事实上的标准，而C++不具备这个条件。
最具有这样气质的C++库实在太少了。

2008/4/24 Wang Xin <cber.w...@gmail.com>:

[XiongJia Le]

那个国家 人员素质很齐?

公司一大 人一多 肯定有高下, 除非只有 2 个人的小项目, 那肯定很齐

2008/4/24 翁翊成 <wen...@gmail.com>:

[翁翊成]

多说一句闲话，很多C++程序员比较以自我为中心，觉得自己写的代码才是最可信的。
网络上可以搜索到一大堆各种各样的一些公共功能的实现，尤其以XML为甚。
很多人拿来库用了用，编译不过就说库垃圾，高级的库会把问题扼杀在编译阶段。
不会理解编译期库给出的错误提示的程序员何其之多？哪怕仅仅是STL！

2008/4/24 翁翊成 <wen...@gmail.com>:

[翁翊成]

。。。
咋说呢。
很多出国的中国程序员，到国外进入不了IT行业。

2008/4/24 XiongJia Le <lexio...@gmail.com>:

[Wang Xin]

"国内"，记得我没有在前面提过那家公司是国内的公司吧
那家公司是一家global的公司，而且据我那朋友说，大部分的麻烦其实是来自他们国外的colleague

在08-4-24，翁翊成 <wen...@gmail.com> 写道：

国内从业人员素质的参差不齐，有这样的结果也是很正常的。
C++语言很多领域都没有一个神一样的标准存在，大多商业颜色比较浓重的语言（JAVA/C#==）都由一个领袖提供一套事实上的标准，而C++不具备这个条件。
最具有这样气质的C++库实在太少了。

2008/4/24 Wang Xin <cber.w...@gmail.com>:

大量使用boost这样"强大"的库，最终导致的结果十有八九不会是代码简洁，而是整个team内部混乱不堪，项目迟迟不能交付（引自某位在某家对于C++使用颇激进的公司内的朋友的原话，该公司的名我就不点了，反正是业界著名的一家公司）

[Wang Xin]

基本上来说，那些东西就是摆设
或者是学了后用来炫耀已经应付面试的

在08-4-24，hunter <hunt...@gmail.com> 写道：

[翁翊成]

具备C的特性（尤其以类型CAST为代表），支持面向对象和范型编程实在是个万恶的根源。
许多C++代码之丑恶，代码隐晦难懂，让无数程序员为之呕吐不止。
这个也是实在没办法，做项目基本都是要求按时高质量完成。
按时？都是老板说某年某月某日给我个某个牛X的系统。
就给那么点时间，何来这样的系统？

一个成熟稳定的产品，需要一个扩展能力很强的体系来支撑。
而基于这个体系进行应用开发时又需要有库来提供很多基本的操作。
不然，我们每次都实现一个STL？APR？BOOST？ACE？======
那样累都累死。

理想状态的开发环境基本是可遇而不可求，大多数的项目状况都是周期短，人员紧张。
真的很想找一个有非常良好的开发环境的地方了：（

2008/4/24 Wang Xin <cber.w...@gmail.com>:

[王晓轩]

boost中的有些东西还是相当有用处的，比如智能指针，Asio库什么的，但不是全部～～

 

C++中的很多高级特性是库作者的武器，对于平常的业务逻辑来说，用处并不大～

 

反而会增加成本，包括开发成本和维护成本～～

 

 

[darkness]

从仅有的经历来看，的确实用价值不高。
不仅仅国内，以前也接触过一些台湾，欧洲的商业代码，都不太常用。

[red...@gmail.com]

翁翊成 wrote:
> 代码多一点？冗余一点？
> 说实话，如果大量使用boost这样威力强大的库，相比较于不使用该库的代码，
> 不知会简洁多少！

用boost :
对于不是很熟悉boost 的程序员来说, 代码行数少了, 但是搞不好可读性, 易维护
性大大下降了.

所以我倾向于只用 boost 里面2,3分钟可以学会使用, 出错的编译信息也不会难到
天书一样看不懂的部分.

> 话说读懂代码，你找个不熟悉业务逻辑的人来读，虽然代码容易看懂了，如果项
> 目没有健全的单元测试，很有可能新人改个东西，把系统干掉了。
> 而反观boost，实际上boost对代码起到的作用不仅仅是提供了特性，更是简化了
> 很多操作逻辑！
>
单元测试, 那是两回事, 用boost 仍然必须有单元测试不是 ?

至于简化逻辑, 是通过 非 well-known 的知识, 难以检查的出错信息简化的逻辑,
是有成本的.

[Oldrev]

Boost的大用户个人就见过两家：Adobe，Autodesk（看 AutoCAD 的 about）。Adobe 为boost贡献了
GIL，Adobe 的软件质量是有目共睹的。

[yq chen]

我觉得还是简单一点好。
boost有很多很实用的功能，比如字符串算法、shared_ptr等，我用的话也就是用这些简单方便又不要编译而且又能提升抽象模型的东东。

使用一个工具的目的我认为是为了提升工作效率，简化系统实现难度,提高系统抽象程度，让一个人看看就能明白大致讲的是什么。如果像Java那样左一个框架右一个框架，还不如死了算了。

:)

2008/4/24 Oldrev <old...@gmail.com>:

[K.L.]

造成混乱的一个重要原因是C++是开放标准，区别于Sun支持的Java，微软支持的.Net，在那些语言里标准库在绝大多数场合下已经足够了。相比之
下C++的标准库太弱了，而每个领域都有一批不够工业强度的非标准库。《modern c++ design》的作者（Loki库的作者）曾谈到健康高
效的软件开发应该让程序员形成两个梯队：应用开发和库的开发，而C++领域中的现实是应用开发程序员同时充当库的设计者，而这些库一旦失去维护就会遗留
大量的混乱。boost的作用就在于用功能强大的并且具有工业强度的库给C++建立一个较强的标准，因此标准库和boost库的学习应该成为C++程序
员的必修课。反观国内的C++教材基本无视标准库的存在，提到STL的都凤毛麟角。

[jinq...@163.com]

高级特性是为库的开发准备的，目的是让库的使用更轻松。
应用程序的开发不应该使用高级特性，便于初级程序员维护。

--
金庆

欢迎访问：金庆的专栏 ( http://blog.csdn.net/jq0123 )
欢迎加入：上海程序员 ( http://groups.google.com/group/programmers_sh )

[nothanks]

一言中的

[red...@gmail.com]

好像没有这么轻松, 使用高级特性开发库, 再使用这个库开发程序, 不懂高级特
性, 很难用这些库, 即使手册已经写得很明白, 但是如果出现编译错误, 或者
namespace 选择问题造成的错误, 不懂高级特性的初级程序员, 根本就搞不定.

[chg]

唉……敢问仁兄在日常工作中大量地，深入地使用过Adobe的软件吗？我说的不是用PS给照片加个水印之类的小把戏。

“有目共睹”，哈哈哈哈！！！

[wing fire]

2008/4/24 Wang Xin <cber.w...@gmail.com>:

"国内"，记得我没有在前面提过那家公司是国内的公司吧
那家公司是一家global的公司，而且据我那朋友说，大部分的麻烦其实是来自他们国外的colleague

怪不得耳朵发烫，一上来就看到这个。
汗颜～

[wing fire]

Adobe开源的代码看过一点，确实是牛，技术很好，但是内部代码就没有了解过了。Adobe的代码质量可谓世界一流。Autodesk的代码就要差那么一点了。

个人认为，boost可以用，但是，不意味着能够成功编译运行就可以用。我认为，只有当知道如何取舍和选择的时候，才能用。我不会因为boost提供了某个东西就去用它，而是我需要某个东西，而boost恰好有，我才去用。

2008/4/24 Oldrev <old...@gmail.com>:

[wing fire]

曾经从CppUnit切换到boost.test。我差不多同时接触两者。本着当时的经验和认识，觉得CppUnit是最好理解的，最符合自己对单元测试的认识。于是选择了CppUnit.
之后的数年中，逐渐认识到CppUnit的复杂性，写test case复杂，管理第三方库复杂。随着对单元测试认识的变化，发现boost.test才是更好的C++平台的单元测试库。于是切换到boost.test.
促使我切换的因素很多，比如简单性，直接性（CppUnit废话很多），高质量单元测试的倾向(CppUni setup 的做法使得新手漠视单元测试的隔离性，老手也一样借此偷懒）。而强大与否，则是次要选择了，boost.test可以测试模板，但我用的次数屈指可数。

2008/4/28 wing fire <wing...@gmail.com>:

[Wang Xin]

在08-4-28，wing fire <wing...@gmail.com> 写道：

2008/4/24 Wang Xin <cber.w...@gmail.com>:

"国内"，记得我没有在前面提过那家公司是国内的公司吧
那家公司是一家global的公司，而且据我那朋友说，大部分的麻烦其实是来自他们国外的colleague

怪不得耳朵发烫，一上来就看到这个。
汗颜～

汗啊，原来你来了……
偶不多说了，剩下的交给你了

[wing fire]

2008/4/28 Wang Xin <cber.w...@gmail.com>:

在08-4-28，wing fire <wing...@gmail.com> 写道：

2008/4/24 Wang Xin <cber.w...@gmail.com>:

"国内"，记得我没有在前面提过那家公司是国内的公司吧
那家公司是一家global的公司，而且据我那朋友说，大部分的麻烦其实是来自他们国外的colleague

怪不得耳朵发烫，一上来就看到这个。
汗颜～

汗啊，原来你来了……
偶不多说了，剩下的交给你了

 

呵呵 你是连STL都不鼓励使用的，我还没到那个境界 。我自己是不自觉地对于自己不能彻底理解的东西保持审慎的态度。但是，大多数人不是啊。

美国同事非常激进，我自己的个人项目都还在用boost 1.33.1的时候，人家就在正式项目中用了boost 1.34.0。现在，有打算切换到1.35 + VS 2008,我晕倒.上次fix的boost的bug，还不知道1.35有没有fix呢。
稍微举几个不知深浅的例子。
1.memory pool是个好东西啊，于是我们用了boost.pool.如果按照pool的意图去用，也就算了。结果，把pool当作通用意图的pool来使用，结果性能极差。是unordered_free惹得祸，但是boost文档时解释的清清楚楚的。
2.shared_ptr也是个好东西。但是，那不是万能丹。结果，shared_ptr的析构函数占用了16%以上的运行时间。
3.ptr container.我是读过文档，但是没有用过这个东西。其实不用仔细看文档，这玩意儿一定是和多态对象有关啊。得，我们这位用它来自动释放内存。那叫一个乱。
4.其他太多了。
个人在使用boost时候，一直很顺利，但是一旦到了项目组，就发现问题一大堆。

[alai]

佩服，说得很好。boost虽然不错，但是如果不适合你的项目使用，又或者以不正确的方式使用，自然是不行的。

2008/4/28 wing fire <wing...@gmail.com>:

[pongba]

2008/4/28 wing fire <wing...@gmail.com>:

wingfire兄举的例子太好了！ 令我想起一句最近极有感触的名言：

It ain't so much the things we don't know that get us into trouble. It's the things we know that just ain't so. - Artemus Ward

看起来，"为了'高级'而'高级'"的C++用法还是真有不少的，尤其是那些'牛逼'（却又没有真正达到牛逼）的程序员。

--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

[pongba]

2008/4/28 pongba <pon...@gmail.com>:

还有感触就是，判断力太重要了。对"该不该用"的判断远远重要于"如何用"的知识。写到这里，脑子里闪出Andrei Alexandrescu当年的话：优秀的程序员俯拾皆是，但是优秀的架构师却是凤毛麟角。现在想来，就是因为后者需要极好的判断力（good judgment），而判断力这个东西，是需要经过了很多挫折失败、反省总结，才能够最终养成的。优秀的程序员往往是那些非常了解"怎么做"的人，也是最容易钻进细节不见森林的人。这样的能力固然是重要的，然而却不是最有竞争力的，说竞争力是因为能力也是"物以稀为贵"，"怎么做"的知识总是可以通过辛勤的积累来达到的，每个人都可以成为优秀的coder。但良好的判断力却需要一种新的看问题的视角和层面，如果没有观念和态度的改变，则是几乎无法养成的。

[王晓轩]

但不能一棍子打死吧，Boost里的很多东西还是值得尝试的～～

 

那个不提倡使用STL的同志还真是非常激进啊，呵呵

[Wang Xin]

:$
STL作为一个Generic Programming的Concept Validation Library来说，确实很不错，但在一些legacy/enterprise系统中，使用它不一定就能为project带来多大的效率提升，反倒是会影响已有的coding style以及一些sophistical issue，所以我才不提倡在目前的项目中使用的

在08-4-28，王晓轩 <totti1...@gmail.com> 写道：

但不能一棍子打死吧，Boost里的很多东西还是值得尝试的～～

 

那个不提倡使用STL的同志还真是非常激进啊，呵呵

[pongba]

2008/4/28 wing fire <wing...@gmail.com>:

2008/4/28 Wang Xin <cber.w...@gmail.com>:

在08-4-28，wing fire <wing...@gmail.com> 写道：

2008/4/24 Wang Xin <cber.w...@gmail.com>:

"国内"，记得我没有在前面提过那家公司是国内的公司吧
那家公司是一家global的公司，而且据我那朋友说，大部分的麻烦其实是来自他们国外的colleague

怪不得耳朵发烫，一上来就看到这个。
汗颜～

汗啊，原来你来了……
偶不多说了，剩下的交给你了

 

呵呵 你是连STL都不鼓励使用的，我还没到那个境界 。我自己是不自觉地对于自己不能彻底理解的东西保持审慎的态度。但是，大多数人不是啊。

呵呵，我也非常理解cber老大的理念：对于C++这门语言来说，要想找到能够正确判断对他的高级特性&库应该用到"什么程度才是适当的"的人，是挺难的。就算有人能够做到，也不代表项目里面的每个人都能够做到。而游戏规则又是很难制定的，如果我说"大家可以用高级特性和高级库，但是要注意适可而止"，估计很容易就偏向过度使用的那一端了。这是人的天性。

因此，如果把人的因素考虑进去（而不仅仅是考虑技术因素）的话，也许宁可偏向保守的一边，最小公分母式的做法在实践上是完全有道理的（除非能够制定详细的编码标准，以约束向错误一端的飘移，不过那又是一件麻烦事）。

总之，如果无法拿捏那个"度"，则最好还是偏向保守为妙。对C++来说，这里的前提极可能是成立的。

[lbaby]

对测试入迷了，兄弟能给点介绍么？
偶在梦想有一天能消灭人肉测试呢

On Apr 28, 12:50 pm, "wing fire" <wing.f...@gmail.com> wrote:
> 曾经从CppUnit切换到boost.test。我差不多同时接触两者。本着当时的经验和认识，觉得CppUnit是最好理解的，最符合自己对单元测试的认识-。于是选择了CppUnit.

> 之后的数年中，逐渐认识到CppUnit的复杂性，写test
> case复杂，管理第三方库复杂。随着对单元测试认识的变化，发现boost.test才是更好的C++平台的单元测试库。于是切换到boost.test.
> 促使我切换的因素很多，比如简单性，直接性（CppUnit废话很多），高质量单元测试的倾向(CppUni setup
> 的做法使得新手漠视单元测试的隔离性，老手也一样借此偷懒）。而强大与否，则是次要选择了，boost.test可以测试模板，但我用的次数屈指可数。
>

> 2008/4/28 wing fire <wing.f...@gmail.com>:
>
>
>
>
>
> > Adobe开源的代码看过一点，确实是牛，技术很好，但是内部代码就没有了解过了。Adobe的代码质量可谓世界一流。Autodesk的代码就要差那么一点了-。
>
> > 个人认为，boost可以用，但是，不意味着能够成功编译运行就可以用。我认为，只有当知道如何取舍和选择的时候，才能用。我不会因为boost提供了某个东西-就去用它，而是我需要某个东西，而boost恰好有，我才去用。

>
> > 2008/4/24 Oldrev <old...@gmail.com>:
>
> > > Boost的大用户个人就见过两家：Adobe，Autodesk（看 AutoCAD 的 about）。Adobe 为boost贡献了
> > > GIL，Adobe 的软件质量是有目共睹的。
>
> > > On Apr 24, 1:04 pm, hunter <hunter...@gmail.com> wrote:
> > > > 我一直在努力的学习C++， 最近被GP给搞得快爽死了，
> > > 同时我工作也是在维护代码，我看我们这个小公司的代码结构极其混乱，什么多态，模板，stl
> > > > 根本没人用，
> > > 加上今天我看论坛里面有人问有多少人用boost库，好多人在工作中都没用，难道C++的这些高级特性真的成了摆设吗？到头来最重要的还
> > > > 是良好的编程风格，高效的算法，对业务的精确理解能力，C++的这些高级玩意对我们的时间工作有多少帮助?
> > > 似乎实际上我们大多数时间并不需要这些高级
> > > > 的特性。

> > > > 大家都有同感吗? 刘老大出来解释解释。- Hide quoted text -
>
> - Show quoted text -

[翁翊成]

人肉测试。。。。
很多功能性的东西，不用人肉很难测呀，例如：程序界面 = =#

2008/4/28 lbaby <lba...@yahoo.com.cn>:

[Justin L]

窃以为，编程如果是艺术创作，那如何使用C++，就如同画国画了。拿捏得体，张弛有度。

写了的程序，还要退回一步看一看，有些地方一定要留白，有的地方一定要重彩——这也是国画中的重点。

On 4月28日, 下午4时54分, pongba <pon...@gmail.com> wrote:
> 2008/4/28 pongba <pon...@gmail.com>:
>
>
>
>
>

> > 2008/4/28 wing fire <wing.f...@gmail.com>:
>
> > > 2008/4/28 Wang Xin <cber.wang...@gmail.com>:
>
> > > > 在08-4-28，wing fire <wing.f...@gmail.com> 写道：
>
> > > > > 2008/4/24 Wang Xin <cber.wang...@gmail.com>:

[red...@gmail.com]

懂画国画的人, 比懂画工程图的人少多了.

Justin L wrote:
> 窃以为，编程如果是艺术创作，那如何使用C++，就如同画国画了。拿捏得体，张弛有度。
>

> 写了的程序，还要退回一步看一看，有些地方一定要留白，有的地方一定要重彩----这也是国画中的重点。
>
>
>

[Eli]

大家都不鼓励使用高级特性， 问题是最近我发现， C++恰恰是唯一（这么说不确切， 因为似乎D也不错）提供了足够的表达方式， 构建干净的正交的组
成部分， 并利落的粘合起来的语言。 如果在.NET下， 甚至可以把基础组成部分交给相对容易写的其它语言， 然后用C++/CLI中的C++特性当
作胶水去粘合。 只是这些做法限制比较多， 比如C++/CLI所在的.NET环境容易发挥优势在于它可以和任何一种.NET平台上的东西无缝融合。
要是在其它环境下， 可能很多更适合其它语言构建的东西， 也要用C++写。 另外就是， 拿C++当胶水， 就必须保证条件允许你经常的重新编译。等
等。

但是boost也好loki也好我个人不喜欢用， 就像做界面我也不喜欢用MFC或者QT， 在我这里， 可能这些高级特性带来的问题是， 掌握别人用
高级特性写的东西， 还不如自己利用这些高级特性自己构建的快； 确实， 如果在一个组织内部， 又缺乏维护者， 这就会成为问题。 不过呢， 可以
把复杂度封装在内部， 在外部给与需要的人恰当的接口， 这样就需要一个单独的工作， 既将一个复杂的实现适配为使用者适合的接口。 这个工作对于长期
维护这个库的人， 其实工作量相当的小。 但这样确实就需要两个团队， 或者至少得有专人负责。

不过， 如果没有高级特性， 说实话， C++对我而言， 一点吸引力也没有。 关键是使用类似于模板一类的高级特性， 我可以尝试新的表达概念的方
法， 而绕开DDD或者传统面向对象建模方式带来的弊端， 虽然我的尝试还远不成熟， 而且说实话， 拿C++表达仍然极其丑陋， 但这总比不让我试来
得好。 我觉得， 比如编译器玩的代码生成， 绝对不是什么机巧的东西， 而是很有必要的。 代码生成器， 真正的模板语言， 往往都是面向文本的，
这样他们就不可能真正承载任何概念， 所以在新的选择出现之前（不知道要等到啥时候）， 在我能自己设计并实现一门语言之前（这个可能永远没有盼头
了），我还是选择C++。

说实话， 如果不过分关注性能， C++的高级特性相当容易掌握， 关键是咱们想干什么， 还有除了书本上教的那些方法， 咱们还*想*怎么表达。 然
后是选择表达工具， 看看这个表达工具如何支撑自己。 在这方面我觉得C++反而是最好的， 谁叫它提供的东西多呢。 C++难掌握的其实是细节， 这
些细节， 随着你不断的表达， 然后碰见问题， 自然而然就一个一个解决了； 多解决几遍也就记住了， 知道下次该注意什么。 可是在
Java/.NET里， 简直就只能按照那几个所谓的大师比如某某， 某某和某某的方式来， 这不是一个有意思没意思的问题， 而是如何让设计更合理的
问题。

不是逗乐， 我现在甚至觉得， 拿C++去表达那些平凡的不能再平凡的业务逻辑， 很可能是C++的一个出路， 是C++最适合干的事情之一； 而不是
大家成天说的什么效率和抽象的结合， 这种传统的说法， 可能对只使用面向对象的C++子集更恰当一些。

最后说一句， 对于组织来说， pongba的说法是对的， 但是对于个人来说， 我觉得至少“高级特性”， 哪怕为了用而用， 也不算什么。 毕竟出
了问题， 我们就更了解如何去判断。 关键还在于责任感（在做好本职的前提下）， 和精力（干完工作， 就一定是老婆孩子热炕头么)了。

[lbaby]

呵呵，不要为了设计而设计，直观地表达业务就行了

[windstorm]

Eli做界面喜欢用什么？

2008/4/29 lbaby <lba...@yahoo.com.cn>:

[wing fire]

现在的项目我没有什么主导权。所以，只能就我以前的经验和个人项目的做法来谈。

1.单元测试库要尽量少地增加开发人员的负担。额外负担必须尽可能直白，傻瓜化。
市面上的许多讲到单元测试的书都是以XUnit为蓝本的，这导致CppUnit的接受程度颇高。CppUnit中规中矩，四平八稳，但不够犀利。个人认为boost.test最简单，只要一个BOOST_AUTO_TEST_CASE就可以开始了。CppUnit则要复杂一点，而这种复杂性是多余的，甚至是有害的。用CppUnit的时候，我看到有人为了共享测试代码，随便在test case里面加函数，然后复用，结果导致case不独立。boost.test倾向于不要建立.h文件，所以要复用不方便（或者，不习惯在Cpp中复用），反而不容易犯错误。
2.实施单元测试，必须能够让程序员看得到好处并尽快受益。新项目必须尽早引入单元测试，要早在正式编码之前。
想立刻让UT变得完美是不可能的，行政命令也不会有好结果。在推行单元测试的时候，教育很重要。必须让同事能理解单元测试为什么有效，如何工作，UT编写准则之类的问题。另外，在工作多年的程序员（对UT缺乏认识的）中推行单元测试，阻力更大。更要注意教育和反馈。最好的反馈就是帮助他们从单元测试中获益。例如，修改更轻松，思维更面向接口，bug更少，代码更容易理解等等。作为推动者，有义务去主动发现这些改善之处并积极地反馈给程序员。从而增强应用UT的信心和意愿。
3.必须充分自动化。
UT的任务之一是给代码编织一层细密的保护网。程序员应该认识到，单元测试是为自己服务的，所以，我们要的是完成任务而不是展示。能够自动地完成任务则是最好的。如果单元测试过多地干扰程序员的正常思考，就会招致更多的抵触（抵触总是存在的）或敷衍。敷衍是可怕的。我向来是把单元测试的运行作为build的一个步骤的。成功的单元测试不需要输出任何信息，最多在全部passs的时候给个OK就足够了。图形界面的测试工具在我看来也是鸡肋，新手的玩具而已。图形界面既不利于参数化运行，也不方便自动化，实在是降低开发效率的杀手。
4.不要追求完美的UT。
不是所有东西都很容易测试。UT要求被测试的东西可重现，可观测。 基本上，大部分的物理操作因为缺乏可重复性或可观察性，很难测试，例如database，GUI （注意，这不意味着在实现一个GUI库或db driver时就不能做UT了）。勉强UT全覆盖，既不现实，也不实惠。并且，这很可能让UT变得复杂，高成本，这是非常危险的和不值得的。我的主张是，很难测，那就不测，但要正确应对。我的做法是将难测的部分隔离到一些抽象层当中去。然后为这些抽象层写MockObject即可测试了。我曾经应用在数据库应用中，并很自然的得到一个良好的数据访问的抽象层，单元测试就只测了这个抽象层。而实际的数据库访问中的物理操作部分，则从单元测试中剥离出去。如果坚持分离物理操作和逻辑操作的话，这个剥离出去的部分一般很小很有限，也很容易测试。相反，如果不剥离，将导致单元测试的结果要依赖数据库的状态。这种额外的依赖性没什么好处。这里的关键是，必须让不可测的部分尽可能隔离，尽可能小，尽可能地将逻辑操作从物理操作中分离出来。被隔离部分所包含的逻辑操作仍然需要写UT。

2008/4/28 lbaby <lba...@yahoo.com.cn>:

[lbaby]

非常好，受教了

[pongba]

2008/4/29 wing fire <wing...@gmail.com>:

现在的项目我没有什么主导权。所以，只能就我以前的经验和个人项目的做法来谈。

1.单元测试库要尽量少地增加开发人员的负担。额外负担必须尽可能直白，傻瓜化。
市面上的许多讲到单元测试的书都是以XUnit为蓝本的，这导致CppUnit的接受程度颇高。CppUnit中规中矩，四平八稳，但不够犀利。个人认为boost.test最简单，只要一个BOOST_AUTO_TEST_CASE就可以开始了。CppUnit则要复杂一点，而这种复杂性是多余的，甚至是有害的。用CppUnit的时候，我看到有人为了共享测试代码，随便在test case里面加函数，然后复用，结果导致case不独立。boost.test倾向于不要建立.h文件，所以要复用不方便（或者，不习惯在Cpp中复用），反而不容易犯错误。
2.实施单元测试，必须能够让程序员看得到好处并尽快受益。新项目必须尽早引入单元测试，要早在正式编码之前。
想立刻让UT变得完美是不可能的，行政命令也不会有好结果。在推行单元测试的时候，教育很重要。必须让同事能理解单元测试为什么有效，如何工作，UT编写准则之类的问题。另外，在工作多年的程序员（对UT缺乏认识的）中推行单元测试，阻力更大。更要注意教育和反馈。最好的反馈就是帮助他们从单元测试中获益。例如，修改更轻松，思维更面向接口，bug更少，代码更容易理解等等。作为推动者，有义务去主动发现这些改善之处并积极地反馈给程序员。从而增强应用UT的信心和意愿。
3.必须充分自动化。
UT的任务之一是给代码编织一层细密的保护网。程序员应该认识到，单元测试是为自己服务的，所以，我们要的是完成任务而不是展示。能够自动地完成任务则是最好的。如果单元测试过多地干扰程序员的正常思考，就会招致更多的抵触（抵触总是存在的）或敷衍。敷衍是可怕的。我向来是把单元测试的运行作为build的一个步骤的。成功的单元测试不需要输出任何信息，最多在全部passs的时候给个OK就足够了。图形界面的测试工具在我看来也是鸡肋，新手的玩具而已。图形界面既不利于参数化运行，也不方便自动化，实在是降低开发效率的杀手。
4.不要追求完美的UT。
不是所有东西都很容易测试。UT要求被测试的东西可重现，可观测。 基本上，大部分的物理操作因为缺乏可重复性或可观察性，很难测试，例如database，GUI （注意，这不意味着在实现一个GUI库或db driver时就不能做UT了）。勉强UT全覆盖，既不现实，也不实惠。并且，这很可能让UT变得复杂，高成本，这是非常危险的和不值得的。我的主张是，很难测，那就不测，但要正确应对。我的做法是将难测的部分隔离到一些抽象层当中去。然后为这些抽象层写MockObject即可测试了。我曾经应用在数据库应用中，并很自然的得到一个良好的数据访问的抽象层，单元测试就只测了这个抽象层。而实际的数据库访问中的物理操作部分，则从单元测试中剥离出去。如果坚持分离物理操作和逻辑操作的话，这个剥离出去的部分一般很小很有限，也很容易测试。相反，如果不剥离，将导致单元测试的结果要依赖数据库的状态。这种额外的依赖性没什么好处。这里的关键是，必须让不可测的部分尽可能隔离，尽可能小，尽可能地将逻辑操作从物理操作中分离出来。被隔离部分所包含的逻辑操作仍然需要写UT。

赞！感谢:)

[Eli]

不是为了设计而设计， 而是为了更好的设计我觉得需要作出尝试。 pongba老是说C++程序员过于关注“细节”， 我是前阵子才回到C++的， 其
实对于其它语言的社区来说， 它们所关注的“设计”其实问题也非常多，包括一些流行的方法论。 我个人认为这基本上就是因为那些语言的表达能力缺乏的缘
故。

[pongba]

2008/4/29 Eli <Eli...@gmail.com>:

为什么要拿C++而不是Python这类语言作胶水语言呢？按Eli兄所说，因为C++的表达力。我现在倒是觉得C++的表达力并不强，Eli兄能举两个例子C++更方便完成而Python不方便的吗？

[Eli]

说来可笑， 我用TMP写了自己一套可组合的东西， 首先我认为屏幕上的一个区域是要显示东西， 然后这块区域有可能被点击、 悬停、 拖动等等大家常
见的情况， 我把它们分别做成可组合的Policy， 用Region<Policies>的方式连接起来。 不过在这里我在设计上分为状态、 规
则、 动作、渲染三个部分(这样都可以分别变化)， 比上面说的复杂一些。 不过每一小块代码量极小，而且特别容易扩展， 比如需要某特效了， 就做个
很小的Policies替换上去就行了。 事件机制一类的就更容易了， 按照类似eventHandler的方式， 用泛型实现一下，这样需要传递的参
数就是强类型了。 然后图嘛， 让美工画好切割好， 告诉我每一小块的坐标和长宽，每种特效需要用到的图片， 只是我没有把这些放到文本文件去， 因为
反正模板是需要重新编译的， 又没空做一个界面工具， 就自己在代码里配置了。

呃..， 献丑了..

[Linker Lin]

我觉得Boost的进程间通讯库很棒。（1.35）
个人对Boost的看法是应该适量使用。
不能为了用而用。

2008/4/29 Eli <Eli...@gmail.com>:

--
Linker M Lin
linke...@gmail.com
※※※※※※※※※
※※我思故我在※※
※※※※※※※※※

[Eli]

呃， 说白了就是靠MCD上讲的那一套， 尤其是在.NET平台， 我可以把VB/C#/F#的不同部件(因为他们擅长的方向可能导致我使用不同的语言
写不同的部分)， 用C++/CLI静态的编织在一起。 其实你要说别的语言不能做到， 确实不能这么说， 但只有C++/CLI是能保证静态的组装
的。 也许不认为这是表达力， 认为它是代码生成能力也可以，但是我认为后面一种看法稍微有点偏颇。 如果我一开始就设定是使用C++作为系统的骨
架， 实际上我不用管那是代码生成还是什么， 我定义自己的表达就可以了。

比如， 我为什么要POJO或者NOJO呢？ 我完全可以 Get<T>(), Set<T>()。 我不使用GetTitle()这样的方式， 既用
硬编码表示概念， 而是在系统里这样表达：

struct Title {
typedef 编程时需要知道的信息。
}

然后Get<Title>()。 这样， 一篇文章有Title，一个图片也有Title， 那么对于我来说， 我不需要有Article类也不需要有
Picture类， 我只要 Entity<Title, CreatedDate, XXX>就可以了。 相比GetTitle或者 string
title {get; set;} 这样的方式， 我就可以少做很多工作。 然而跟字典相比， 我获得了强类型， 也获得了静态检查。 如果我
article.Get<Subject>()或者数据类型不对就会报错。 当然， 我也可以将常用的方式， 比如Title/Author什么的，
做一些常用组合， 这样定义一个东西的时候， 我可能就是Entity<NormalContentNode, 独特部分..>这样就可以了。

可能有人会说， 对于支持泛型的其他语言， 比如C#， 我们也可以用Entity<接口>这样的方式或者和模板差不多的方式。 但对于
Get<T>()甚至Do<TAction>(TAction::ArgType args)这样的东西， 其它语言并没有提供足够的支持。 比如我可
以用TMP， 在持久化工作的地方， 仅仅通过配置， 就生成静态的强类型的ObjectDataMapper， 而再其它语言里如何做呢？

需要说明的一点是， 如果仅从节省工作量来看， 动态语言确实能够做的到， 甚至javascript都很方便， 想想javascript的
obj[methodName](args)所支持的东西， 肯定比C++的方式爽，更别提天生的函数式支持了。 不过我对动态语言的做法不感冒， 对
非强类型的做法更不感冒， 因为我认为越自由， 越灵活， 反而就需要越多的静态检查。 我发上一个帖子的时候没看见你这个贴， 不过我上个帖子里的例
子， 如果泛化一下， 不要把它当作GUI框架， 而是考虑我说的， 规则、动作这两部分，也许， 对于一个对象， 还有状态这一部分。 那么我觉得用
C++可以非常好的表达出不同的规则（虽然看起来很烂）， 然后我定义一个东西的时候， 比如Thing<States....,
Rules...., Actions....>这样， 我觉得是相当清晰的表达方式， 而且如果我设计的妥当， 可以让一些不合理的行为， 在编译期
就被查出来， 这个也是其它语言没有提供的。

想想我说的状态， 在设定规则的时候，我们可能根据一些状态做出判断， 如果我们这样：stateObj->getDisableState()（或者
this->getDisableState()如果我用MCD生成类体系的方式）， 这样我们就要求States中的某一个， 含有这个方法。 可对
于一个不会被Disable的东东， 我为什么非要写这样一个方法呢？ 那么我可以静态的设定一些潜规则， 比如当get<State>()时， 如果
没有设定相关的State， 就永远返回某个默认答案等等。 在考虑这个状态本身， 我State1,State2这样粘起来， 问题是对于那些最简单
的状态， 我就必须getState1(), getState2()用于区分， 这些工作又是何必呢？ 在我声明比如States<s1,
s2..>的时候， 唯一可以避免手工写代码同时可以进行标识的方式， 就是利用get<state>()这样的形式。 让我们好好想一想， 实际上
<>中的， 是一个我们脑海里的概念， 而getDisableState()这样固定函数签名的做法却把它具体到一个死标识， 本身就是损失信息了。
当我们在不同的地方写下getDisableState()的时候（如果使用传统面向对象和接口的方式， 这很普遍）， 我们之所以一遍又一遍的重
复， 就是因为这个概念并没有表达到软件中。像State这样的东西还是小技巧， 而get<Title>（）这样的东西， 其实更说明问题。

总而言之， 我的看法如果说有一定道理， 首先的前提就是静态的、 强类型的。 我的目标就是所有运行前就知道的事情， 就留给编译器， 剩下的， 如
果在.NET下， 我可以设置一个随时可废弃的包装层， 专门根据需要包装其它语言适用的接口， 在极端的情况下， 我拥有了两头： 获得所有静态语言
的优势， 同时可以把那些确实不是运行前就知道的知识， 放到一个最动态的语言里。

真正的让我觉得这种方式表达力更强更清晰的是， 除了具体的代码实现， 我组织一个系统时， 就完全是声明式的， 而且只要我的描述到位， 构建出来的
系统， 可以在运行前就得到自我检查。 这个回复写的又长又乱， 主要是我也还在摸索阶段， 而且说实话， C++， 包括C++/CLI， 仍然很
烂， 所以我这个摸索过程也是坑坑洼洼。 但是相比明天就开始自己实现一个预想中的语言， 凑合用C++， 总来的现实一些。

多说一句， 关于0x， concept我觉得其实帮不了我太多， 更多的是帮助编译器作者， 但是auto等一些其它方面我现在有点等不及了。 当
然， 如果还有其他语言或者其他做法和我这乱七八糟说的一堆是等价的， 也希望大家提醒我一下， 毕竟撞南墙墙撞半天， 回头一看万一有更好的东西，
会死人的...

On Apr 29, 12:56 pm, pongba <pon...@gmail.com> wrote:
> 2008/4/29 Eli <Eli...@gmail.com>:
>
>
>
> > 大家都不鼓励使用高级特性， 问题是最近我发现， C++恰恰是唯一（这么说不确切， 因为似乎D也不错）提供了足够的表达方式， 构建干净的正交的组

> > 成部分， 并利落的粘合起来的语言。 如果在.NET <http://%E5%A6%82%E6%9E%9C%E5%9C%A8.NET>下，
> > 甚至可以把基础组成部分交给相对容易写的其它语言， 然后用C++/CLI中的C++特性当
> > 作胶水去粘合。 只是这些做法限制比较多， 比如C++/CLI所在的.NET <http://%E5%9C%A8%E7%9A%84.NET>环
> > 境容易发挥优势在于它可以和任何一种.NET<http://%E5%A2%83%E5%AE%B9%E6%98%93%E5%8F%91%E6%8C%A5% E4%BC%98%E5%8A%BF%E5%9C%A8%E4%BA%8E%E5%AE%83%E5%8F%AF%E4%BB%A5%E5%92%8C%E4% BB%BB%E4%BD%95%E4%B8%80%E7%A7%8D.NET>
> > 平台上的东西无缝融合。

> > 要是在其它环境下， 可能很多更适合其它语言构建的东西， 也要用C++写。 另外就是， 拿C++当胶水， 就必须保证条件允许你经常的重新编译。等
> > 等。
>
> > 但是boost也好loki也好我个人不喜欢用， 就像做界面我也不喜欢用MFC或者QT， 在我这里， 可能这些高级特性带来的问题是， 掌握别人用
> > 高级特性写的东西， 还不如自己利用这些高级特性自己构建的快； 确实， 如果在一个组织内部， 又缺乏维护者， 这就会成为问题。 不过呢， 可以
> > 把复杂度封装在内部， 在外部给与需要的人恰当的接口， 这样就需要一个单独的工作， 既将一个复杂的实现适配为使用者适合的接口。 这个工作对于长期
> > 维护这个库的人， 其实工作量相当的小。 但这样确实就需要两个团队， 或者至少得有专人负责。
>
> > 不过， 如果没有高级特性， 说实话， C++对我而言， 一点吸引力也没有。 关键是使用类似于模板一类的高级特性， 我可以尝试新的表达概念的方
> > 法， 而绕开DDD或者传统面向对象建模方式带来的弊端， 虽然我的尝试还远不成熟， 而且说实话， 拿C++表达仍然极其丑陋， 但这总比不让我试来
> > 得好。 我觉得， 比如编译器玩的代码生成， 绝对不是什么机巧的东西， 而是很有必要的。 代码生成器， 真正的模板语言， 往往都是面向文本的，
> > 这样他们就不可能真正承载任何概念， 所以在新的选择出现之前（不知道要等到啥时候）， 在我能自己设计并实现一门语言之前（这个可能永远没有盼头
> > 了），我还是选择C++。
>
> > 说实话， 如果不过分关注性能， C++的高级特性相当容易掌握， 关键是咱们想干什么， 还有除了书本上教的那些方法， 咱们还*想*怎么表达。 然
> > 后是选择表达工具， 看看这个表达工具如何支撑自己。 在这方面我觉得C++反而是最好的， 谁叫它提供的东西多呢。 C++难掌握的其实是细节， 这
> > 些细节， 随着你不断的表达， 然后碰见问题， 自然而然就一个一个解决了； 多解决几遍也就记住了， 知道下次该注意什么。 可是在
> > Java/.NET里， 简直就只能按照那几个所谓的大师比如某某， 某某和某某的方式来， 这不是一个有意思没意思的问题， 而是如何让设计更合理的
> > 问题。
>
> > 不是逗乐， 我现在甚至觉得， 拿C++去表达那些平凡的不能再平凡的业务逻辑， 很可能是C++的一个出路， 是C++最适合干的事情之一； 而不是
> > 大家成天说的什么效率和抽象的结合， 这种传统的说法， 可能对只使用面向对象的C++子集更恰当一些。
>
> 为什么要拿C++而不是Python这类语言作胶水语言呢？按Eli兄所说，因为C++的表达力。我现在倒是觉得C++的表达力并不强，Eli兄能举两个例子C ++更方便完成而Python不方便的吗？
>
> --

> 刘未鹏(pongba)|C++的罗浮宫http://blog.csdn.net/pongba
> TopLanguagehttp://groups.google.com/group/pongba

[翁翊成]

昨天因为使用std::pair被人鄙视了。原因是我的代码很难读。
难道我这也算使用了高级特性？

2008/4/30 Eli <Eli...@gmail.com>:

[redsea(肖海彤)]

对于不是整天沉浸在模板, 模板匹配, traits 之类的东西的人来说, boost 甚至 STL 是很难读, 不人性.

 

我远离了 C++ 之后, 越发认为这些东西不自然.

 

在08-5-9，翁翊成 <wen...@gmail.com> 写道：

[redsea(肖海彤)]

std::pair 本身不算难读, 但是和这些东西混在一起, 被一棍子打死了.

在08-5-9，redsea(肖海彤) <red...@gmail.com> 写道：

[张鹏程]

我觉得pair还不错啊，怎么会造成难懂呢？

做作一种被发现而不是被发明出来的特性，不自然也是很正常的。但不能否认有时候它会带来方便。

我觉得C++的缺点主要是给了太多选择，在这些选择间用到治如其分，是比学习这些特性更难的过程。

 

在08-5-9，redsea(肖海彤) <red...@gmail.com> 写道：

[翁翊成]

呵呵，正如scott书中所说的。
C++是个语言的大集合，4大标准：兼容C/面向对象/泛型编程/STL。
确实造成了C++的极大的复杂性呀。
但是STL既然作为语言内置的标准，不应该因为使用这标准内的东西，而在程序员之间造成沟通障碍，不是么？
有沟通障碍的我认为还是恶补一下好：）

2008/5/9 张鹏程 <holme...@gmail.com>:

[red...@gmail.com]

一个很恐怖的恶魔城堡, 可以将人吓得不敢靠近, 怎么会去留意城墙下面有几朵花
开得还不错 ?

对于我们已经学过, 会用的人, 自然觉得 pair 不复杂, 问题是, 别人还在山的那
边呢.

张鹏程 wrote:
> 我觉得pair还不错啊，怎么会造成难懂呢？
> 做作一种被发现而不是被发明出来的特性，不自然也是很正常的。但不能否认有
> 时候它会带来方便。
> 我觉得C++的缺点主要是给了太多选择，在这些选择间用到治如其分，是比学习
> 这些特性更难的过程。
>
>

[lbaby]

恩，不自然地表达，确实是一种很大的缺陷

On May 9, 1:48 pm, "redsea(肖海彤)" <red...@gmail.com> wrote:
> std::pair 本身不算难读, 但是和这些东西混在一起, 被一棍子打死了.
>
> 在08-5-9，redsea(肖海彤) <red...@gmail.com> 写道：
>
> > 对于不是整天沉浸在模板, 模板匹配, traits 之类的东西的人来说, boost 甚至 STL 是很难读, 不人性.
>
> > 我远离了 C++ 之后, 越发认为这些东西不自然.
>

> > 在08-5-9，翁翊成 <weng...@gmail.com> 写道：

>
> >> 昨天因为使用std::pair被人鄙视了。原因是我的代码很难读。
> >> 难道我这也算使用了高级特性？
>
> >> 2008/4/30 Eli <Eli...@gmail.com>:
>

> >>> 呃， 说白了就是靠MCD上讲的那一套， 尤其是在.NET<http://%e5%b0%a4%e5%85%b6%e6%98%af%e5%9c%a8.net/>平台，

> >>> 果在.NET <http://%e6%9e%9c%e5%9c%a8.net/>下， 我可以设置一个随时可废弃的包装层，

> >>> 专门根据需要包装其它语言适用的接口， 在极端的情况下， 我拥有了两头： 获得所有静态语言
> >>> 的优势， 同时可以把那些确实不是运行前就知道的知识， 放到一个最动态的语言里。
>
> >>> 真正的让我觉得这种方式表达力更强更清晰的是， 除了具体的代码实现， 我组织一个系统时， 就完全是声明式的， 而且只要我的描述到位， 构建出来的
> >>> 系统， 可以在运行前就得到自我检查。 这个回复写的又长又乱， 主要是我也还在摸索阶段， 而且说实话， C++， 包括C++/CLI， 仍然很
> >>> 烂， 所以我这个摸索过程也是坑坑洼洼。 但是相比明天就开始自己实现一个预想中的语言， 凑合用C++， 总来的现实一些。
>
> >>> 多说一句， 关于0x， concept我觉得其实帮不了我太多， 更多的是帮助编译器作者， 但是auto等一些其它方面我现在有点等不及了。 当
> >>> 然， 如果还有其他语言或者其他做法和我这乱七八糟说的一堆是等价的， 也希望大家提醒我一下， 毕竟撞南墙墙撞半天， 回头一看万一有更好的东西，
> >>> 会死人的...
>
> >>> On Apr 29, 12:56 pm, pongba <pon...@gmail.com> wrote:
> >>> > 2008/4/29 Eli <Eli...@gmail.com>:
>
> >>> > > 大家都不鼓励使用高级特性， 问题是最近我发现， C++恰恰是唯一（这么说不确切， 因为似乎D也不错）提供了足够的表达方式，
> >>> 构建干净的正交的组
>

> >>> > > 成部分， 并利落的粘合起来的语言。 如果在.NET <http://%e5%a6%82%e6%9e%9c%e5%9c%a8.net/><http://
> >>> %E5%A6%82%E6%9E%9C%E5%9C%A8.NET <http://a8.net/>>下，
> >>> > > 甚至可以把基础组成部分交给相对容易写的其它语言， 然后用C++/CLI中的C++特性当
> >>> > > 作胶水去粘合。 只是这些做法限制比较多， 比如C++/CLI所在的.NET<http://%e6%89%80%e5%9c%a8%e7%9a%84.net/><http://
> >>> %E5%9C%A8%E7%9A%84.NET <http://84.net/>>环
> >>> > > 境容易发挥优势在于它可以和任何一种.NET<http://%e5%a2%83%e5%ae%b9%e6%98%93%e5%8f%91%e6%8c%a5%e4%bc%98%e5%8a%bf%e5%9c%a8%e4%ba%8e%e5%ae%83%e5%8f%af%e4%bb%a5%e5%92%8c%e4%bb%bb%e4%bd%95%e4%b8%80%e7%a7%8d.net/>
> >>> <http://%E5%A2%83%E5%AE%B9%E6%98%93%E5%8F%91%E6%8C%A5%
> >>> E4%BC%98%E5%8A%BF%E5%9C%A8%E4%BA%8E%E5%AE%83%E5%8F%AF%E4%BB%A5%E5%92%8C%E4%
> >>> BB%BB%E4%BD%95%E4%B8%80%E7%A7%8D.NET <http://8d.net/>>

[翁翊成]

如果连pair都觉得很难。。。。
那Tuple看一眼就会翻白眼了。。。
function一棒子就把他打晕了

2008/5/9 <red...@gmail.com>:

[red...@gmail.com]

我们公司, 现在开发语言的选择:

1. cpu bound, 代码量不是很大的程序, 用 C
C 语言简单, 即使你说宏丑陋, 类型 cast 丑陋, 那也是简单的丑陋, 简陋, 而不
是复杂得要死的丑陋

2. 不是 cpu bound, 而且不用担心反编译的程序, 用 python
不想尝试 ruby了, 因为 python 简单

3. cpu bound, 或者担心反编译的程序, 用D + Tango
D 语言和很多语言比, 不简单, 但是 Tango 简单.

4. Javascript 这个没有办法了, 非用不可, 这个东西简单用, browser 兼容性不
好, 用类库, 复杂度又提高了.

[张鹏程]

那到是，C++学起来真的不容易，有太多的潜知识。用还学C++本身的书就N厚了。一些概念，如模板的实例化，是非常不容易理解的。

 

redsea的形容还挺风趣的，不过，事实大概也就如此了。

 

我觉得其实大可不必把它完全的学完，学通，只学其中的一部分就够用在很多地方了。

 

我一开始并不题解为什么有很多人放弃了C++去用C，或用Java，现在想想，大致明白一点，那就是，他们只需要C++的一部分，而不是全部。

 

如果C++的template可以有一个单独的语言实现，可能又会挖走一票人吧。

 

在08-5-9，red...@gmail.com <red...@gmail.com> 写道：

[翁翊成]

宏不算丑陋了，主要是可能会有些小问题而已。
类型cast在C中应该不算丑陋，类型cast在C++中丑陋的一个主要原因是，C++是强类型且面向对象。
而类型cast反类型反对象，破坏了自有的面向对象系统。

不过,C++语言的复杂性,也似的这个社群越来越小,甚至很多人批评C++太学院派...

2008/5/9 <red...@gmail.com>:

[red...@gmail.com]

说老实话, 就算我自己用 C++ 特性很多的时候, 用 STL, 我都是抱着厌恶它的心
情用的, 怪异的格式, 奇怪的语义(例如remove 不删除), 要记忆的很多东西(例如
各种 iterator), 布满奇点, 离开了手册我根本没有办法保证用对, 也就是性能还
不错.

回过头来, 再看 C 的做法, 要写通用算法, 用 void * 指针, 效率或者可能低一
点, 但是, 至少不用学习一大堆前置知识, 才能使用不是 ? 类型安全? 针对业务
类型再封装一下就不就可以了 ? 程序也容易读得多.

用C做一个算法和数据结构, 想要追赶 STL 的效率, 直接 copy & paste 代码进行
修改好了(或者就 copy 自 STL), 代码冗余是罪恶 ? 反正类似 STL 里面的经典代
码, 都已经成熟了, 算法也没有什么改进余地了, 弄完了就当作 readonly 的东西
扔一边, 反正以后也用不着改.

现在我觉得 代码冗余的罪恶 < 代码难读的罪恶.

翁翊成 wrote:
> 如果连pair都觉得很难。。。。
> 那Tuple看一眼就会翻白眼了。。。
> function一棒子就把他打晕了
>

[翁翊成]

代码复用...个人感觉这一块C++的支持还是满多样的,基于模板或者基于面向对象,都可以打造出一个套路.
当建立好一个良好的套路之后,业务逻辑的表述就会很自然...业务逻辑的编写人,不需要关心底层结构提供者所编写的代码,使用它就好了.

2008/5/9 <red...@gmail.com>:

[张鹏程]

如果对C++的使用做一些限制，然后用这种限制后的方言做一种DSL，不知道是不是好用呢？

总比作一种新的语言要好吧？

 

在08-5-9，翁翊成 <wen...@gmail.com> 写道：

[pongba]

2008/5/9 翁翊成 <wen...@gmail.com>:

呵呵，正如scott书中所说的。
C++是个语言的大集合，4大标准：兼容C/面向对象/泛型编程/STL。
确实造成了C++的极大的复杂性呀。
但是STL既然作为语言内置的标准，不应该因为使用这标准内的东西，而在程序员之间造成沟通障碍，不是么？
有沟通障碍的我认为还是恶补一下好：）

我觉得问题不在于大杂烩。从高层面来说，四种范式也不是什么了不得的，都很直观。
关键是语言的实现不优雅，为了效率和兼容折衷了太多本可以直截了当的东西

[翁翊成]

恩恩，typedef+#define就可以干掉很多不直观了.

2008/5/9 pongba <pon...@gmail.com>:

[张鹏程]

与C++的效率想比，它是失去的太多了。现在看来，当初的一些折中已经没用，甚至是鸡肋了。

也许D更好吧，不过，现在的D还是个动荡的年代。

 

在08-5-9，翁翊成 <wen...@gmail.com> 写道：

[翁翊成]

D现在的版本变动还是很大的问题吧?

2008/5/9 张鹏程 <holme...@gmail.com>:

[张鹏程]

似乎有不能完全向后兼容的问题。

不过，在实现上还是不错的。只是GDC好像没有什么发展。不想总用什么DMC

 

在08-5-9，翁翊成 <wen...@gmail.com> 写道：

[王磊]

感觉讨论的东西好像以前就说过了。

一般来说如果主做业务那大多特性或第三方都可以让开，减少不必要的解释和麻烦

如果自己做产品那可以凭喜欢选择喜好

 

 

对于公司来说，把C++当C一样用

对于自己来说，把C当C++一样用   这么比喻不知道贴切么

仅供参考

2008/5/9 张鹏程 <holme...@gmail.com>:

[翁翊成]

对于公司来说，把C++当C一样用
===================================================
本人从业这几年一直在遭遇这样的情况...

2008/5/9 王磊 <wangle...@gmail.com>:

[张鹏程]

我觉得这样用没有什么不好。

当然很多人会觉得有点浪费。

不过，C的编译器可能要比C++的代码更优化吧？

 

在08-5-9，翁翊成 <wen...@gmail.com> 写道：

[wizard-神啊，赐我一本《银河系漫游指南》吧]

pair这东西经常写出来一长串，确实很影响阅读，
一般如果经常用的话，可以用typedef取个简洁点的名字。

2008/5/9 翁翊成 <wen...@gmail.com>:

[翁翊成]

那是必须的.
任何和容器有关的东东,肯定会有一堆的typedef,包括容器对应的iterator和const_iterator
否则代码看起来就是噩梦.

2008/5/9 wizard-神啊，赐我一本《银河系漫游指南》吧 <klin...@gmail.com>:

[张鹏程]

我觉得比起那些错误信息来，这些都挺好懂的。

在08-5-9，wizard-神啊，赐我一本《银河系漫游指南》吧 <klin...@gmail.com> 写道：

[翁翊成]

哈哈，错误信息经常飞到千里之外

2008/5/9 张鹏程 <holme...@gmail.com>:

[莫华枫]

这个问题根据不同的问法（语气和重音的不同），会有不同的答案。
比方说如果问：C++的高级特性到底有多少使用价值？那么答案肯定是"很多"。要不然，D也不会几乎通盘照搬这些东西，还不辞辛劳地加以扩展和完善。
如果问：C++的高级特性到底有多少使用价值？那么多半会得到千差万别的答案。我的答案是：有，但有代价。有时这些代价会超过所得的利益，有时则相反。这取决于目标和任务的特性。
真正的问题核心是我们如何认识和对待这些特性。根据我对很多程序员的观察，发现一个通病。多数程序员侧重于构造软件，但是往往忽视软件的修改和变化。而事实上修改和变化，往往占据绝大部分的工作量。另一方面，很多高级特性的引入对于消除错误的隐患有极大的帮助。最简单的例子就是容器。在仅具有oop特性的语言中，无法构建通用容器，程序员们被迫使用抽象基类和强制类型转换。这在早期的java和C#中非常典型。强制类型转换对于软件项目，特别是中等规模以上的软件项目，可以当成是一种很优良的酷刑。而随着模板/泛型的出现，我们可以在强类型的前提下，安全地构建和使用容器。这不能不看作是软件开发上的一次重要的进化。
至于那些"非常高级"的特性，比如元编程，完全取决于任务的特性。当我们在按照用户那崇高而不可侵犯的意愿构建业务流程的时候，高级特性是不会有任何作用的。在我看来，这种情况下，即便是动多态，甚至继承，也是多余的。这是脚本语言的天下。
但是，在某些基础系统的构建中，高级特性可以为我们带来很多有益的帮助。比如我们打算读取一个xml文件，然后按照其中节点的name，来构造对象。这是一个典型的抽象类工厂的任务。如果我们像《Modren C++ Design》中所做的那样，利用一个元编程容器，填充相应的类，然后运用元函数递归构造类创建函数的分派表。于是，如果所构造的对象有所变化，或者增加，我们所需做的，也仅仅是修改或构造相应的类，然后插入元编程容器中即可。传统实现中可能会因为这些变化引发的错误和工作量，都被消弭于无形。
阻碍高级特性应用的真正障碍还是程序员对他的理解和认识。限制高级特性（甚至是C++）应用的理由都出奇的一致：团队能力。记得g9老大也在这里（或是在blog）里抱怨过被限制使用fp，其理由也无非是"别人看不懂"或者"别人不会"。对于这种"现实问题"，除了培训和提高认识外，更重要的还是语言应用的分化，把高级技术应用在"高级"的应用场景里。在业务实现的层面使用元编程，明显是愚蠢的举动。即便在ruby里也不会这么做，但却无法抑制其在库和框架中的应用。
说到ruby的元编程应用，ruby在元编程方面比C++更激进，但似乎对于它的抱怨远远少于在C++中对模板的抱怨。这表明高级特性不是C++的问题，问题在于C++的那些并非高级的特性上，这些特性破坏的高级特性的应用性。D试图在保留C++高级特性的基础上，减少抱怨。目前看来做得还不错，只是语言特性的重点不明确，也尚未稳定，阻碍了推广，将来或许会好些。
总结起来一句话，如果项目是大中型的基础系统，那么高级特性可以带来决定性的好处。即便是培训团队，也是值得的。

2008/4/24 hunter <hunt...@gmail.com>:

我一直在努力的学习C++， 最近被GP给搞得快爽死了， 同时我工作也是在维护代码，我看我们这个小公司的代码结构极其混乱，什么多态，模板，stl
根本没人用， 加上今天我看论坛里面有人问有多少人用boost库，好多人在工作中都没用，难道C++的这些高级特性真的成了摆设吗？到头来最重要的还
是良好的编程风格，高效的算法，对业务的精确理解能力，C++的这些高级玩意对我们的时间工作有多少帮助? 似乎实际上我们大多数时间并不需要这些高级
的特性。
大家都有同感吗?  刘老大出来解释解释。

--
反者道之动，弱者道之用
m...@seaskysh.com
longsh...@gmail.com
http://blog.csdn.net/longshanks/

[张教主]

每个语言都有一些高级特性,python也有,也可以写得读起来很痛苦.

每一种高级特性都被引入的理由,
但是越多的高级特性会带来越陡的学习曲线以及相对越大的错误使用的概率.

一般来说,是人都有学习的惰性,偏向于用自己掌握并熟悉的技术去解决问题.
这也常常是技术代沟出现的原因.

此外,高级特性不一定导致难读.
比如stl的那些algorithm,我觉得反而比c的循环好理解的多

--
张沈鹏,在路上...
http://zsp.javaeye.com/

[red...@gmail.com]

张教主 wrote:
> 每个语言都有一些高级特性,python也有,也可以写得读起来很痛苦.
>
问题是, > 95% 的python 代码和库代码, 都是很容易读的, C++ (所谓
modern C++) 呢 ?

[张鹏程]

莫老师一语中的。

什么高级特性都要学习后才会用。所谓难读，看不懂，是不是因为没有相关的知识积累啊？

一个只会C程序员看到LISP程序时，总会感觉难以理解的。

 

在08-5-11，red...@gmail.com <red...@gmail.com> 写道：

[翁翊成]

精辟啊，受教了。

2008/5/10 莫华枫 <longsh...@gmail.com>:

[Eli]

同意归同意， 但是谁说Template C++的代码是让人读的了？ 我的方式是弄得懂就弄， 弄不懂就自己写，仅此而已。 MFC就真比Boost
好读？ 反正对我来说不是这样， 这只是会与不会的区别。 假设人人都是Template大师呢？所以你说的问题关键在于学习成本上， 每个人都搞好若
干个范式， 成本太高了。

但我们可以假设存在这样一个角色， 他不干别的， 就是用来翻译别人看不懂、 不会用的东西到需要使用者可以明白的形式。 问题是一般的组织不会有这么
个人， 但没有验证过， 你不能说这样就一定比Copy/Paste效率和成本低（暂且不老调重弹Copy/Paste的祸患）。 拿设计模式来说，
那么多搞不清状况就写文章写书的，足以证明其难于掌握， 是不是说设计模式也废掉呢？

我觉得这个问题就在于Template C++够丑， 大家本能的就不喜欢。 所以问题的核心在于三点：

1. 历史包袱。
2. 程序员的角色划分不够细致。
3. 太丑， 让人反感。

能克服第三点， 就可以尝试； 能驾驭第一点， 就可以用于实践； 满足了第二点， 合作就成为可能。 就是这样。

[张教主]

2008/5/11 <red...@gmail.com>:

> 张教主 wrote:
> > 每个语言都有一些高级特性,python也有,也可以写得读起来很痛苦.
> >
> 问题是, > 95% 的python 代码和库代码, 都是很容易读的, C++ (所谓
> modern C++) 呢 ?

感觉c++最大的问题是企图不改变语言本身而去用库解决一切.
这样导致了所谓的modern C++的各种奇技淫巧有了用武之地.

反观python,不断在语言本身上寻求改进,不断加入新的语法去取代原来的奇技淫巧
举一个简单的例子
python原来一直没有类似C的?:运算符
但是大家发明的 A and B or C的奇技淫巧来模拟这种运算,但是这样做也带来许多副作用,和C++中一样一不小心就会犯错.
到了python2.5加入了这样的语法
1 if 2>3 else 4
OK,一切都简单明了了.

同样,试想一想,如果C++语言本身提供了foreach,还需要去用非常hack的写一个Boost::foreach吗?
如果C++本身提供了lambda,还要挖空心思的写一个Boost::lambda干什么.

所以,个人认为,modern C++的奇技淫巧弊端的根源在于C++标准委员会的对语言本身变革/库选择保守(或曰谨慎).
而造成这种现象的原因又在于C++标准委员会和W3C一样,自己只负责指定标准,不提供实现.
从这种意义上说C++的弊端和Javascript兼容性的弊端是一样的.

此外,最近看<<Imperfect C++>>,上面提到了一个观点,因为需求的多变,所以不存在完美的封装.
而C++社区总有一种完美主义的DRY(Don't Repeat Yourself)的倾向.
从而导致抽象越来越高层,越来越难以理解.
反观python,从功能出发,不去执着于形式上的完美主义.这也是造成代码可读性区别的一个原因.

总结一下,

C++那些新潮的东西可以拿来用,不过千万不要去模仿他写代码,因为不是所有人有向你一样喜欢没事研究C++的角落特性:)

复制粘贴代码没有书本上说的那么可怕,过度抽象是罪恶的.

此外,把C++当脚本用也是罪恶的.

> > 每一种高级特性都被引入的理由,
> > 但是越多的高级特性会带来越陡的学习曲线以及相对越大的错误使用的概率.
> >
> > 一般来说,是人都有学习的惰性,偏向于用自己掌握并熟悉的技术去解决问题.
> > 这也常常是技术代沟出现的原因.
> >
> > 此外,高级特性不一定导致难读.
> > 比如stl的那些algorithm,我觉得反而比c的循环好理解的多
> >
>
>
>
>
>
> >
>

--
张沈鹏,在路上...
http://zsp.javaeye.com/