程序的结构应当如何表示

zmsxhy

程序的结构应当如何表示 [复制链接]

 

现在接触的程序越来越大，所需要处理的任务及数据也越来越多，想请问大家是怎么画流程图的。我怎么感觉越画越乱。让整个思路变的都不清晰了？

Aragorn

关于较大型程序的编写，曾经碰到跟楼主一样的问题，我有很多话要说啊。

流程图未必是必须的，很有可能适得其反，使得既没起到应有的指导效果，还浪费了大把时间。所以这种东西因人而异，觉得有帮助就画，觉得没作用就不画，千万别觉得这是一种高大上的工作就强迫自己画。而且程序复杂度这种东西，跟画图之间没有必然的关系。正常的软件工程中，两种情况下画图是最多的。一种是在分析问题的过程中，画一些简单草图以帮助直观的理解问题，这种图生命很短，一旦理解问题后基本上都会被抹去；另一种就是项目完成后，用图来直观的表达程序的结构，以帮助后来的程序维护者理解程序，这种图基本上存在于程序的详细说明文档中，而且还得配有文字描述。至于用流程图面面俱到的画出程序的执行流程，基本上是新手为了追求高大上才干的活计。

看到上面有人提到用RTOS来简化程序设计，我不敢苟同，见过一些追求使用RTOS的人，写出来的代码跟没用RTOS时一样烂。也就是说，当一个人的程序水平本身很烂时，那么随便他使用什么RTOS、什么先进的模块，他写出的代码也还是烂的。水平不会因为使用的部分好代码而变得更好，反而可能因为使用了模块而变得更糟糕。

至于程序越来越大而变得复杂这个问题，其实要从两个方面入手予以解决。第一个方面就是一定要去掉陈旧的代码效率和执行效率至上的思维，要以封装为主；写MCU程序出身的很多工程师，思维比较古板，稍微多做一点封装、代码稍微多一点就跟个世界末日似的大喊大叫，这个代码太多了啊，会影响MCU执行速度的，而且几乎是条件反射似的反应。代码封装多一点，对现在的MCU来说，几乎就多了几US的时间，根本不会有影响，但是对程序结构来说，却会有莫大的助益。而且很多人没注意到，程序越大，所要使用的MCU也会越高级，资源也越多、执行速度也越快，这会抵消掉封装所带来的代码效率和执行效率问题。如再拘泥代码的效率和速度，就比较愚蠢了。

第二个方面，就是程序架构或者说是模块划分了，这一点至关重要，而且大多数的烂程序主要就烂在这方面。我曾经也是写烂程序的高手，也碰到很多写烂程序的高手。现在不说程序能写多好，但至少不烂了。这里给你的建议是，去学习面向对象的分析和设计方法，虽然这种方法出自于PC平台的软件工程中，但同样适合于嵌入式。以前觉得老是说面向过程和面向对象这些东西很玄乎，根本理解不了之间的差别，就骗人的玩意，就像马克斯的共产主义一样，都是虚妄。后来花了很长时间去学习和实践，还一个劲的学画UML图，终有些许所得。才发现，这的的确确是两种不同的思维方式。

现在基本上算是入道了，用C++写面向对象，封装做得妥妥的，用起来特别爽。最明显的好处有两个，第一个是需求发生变化时，的确更容易修改代码；第二个就是代码复用，现在面对新项目基本上直接把文件复制到工程中，效率要高很多，做好的代码基本上就等同于库了。不过也有一点不好，那就是总能碰到讨厌的同事和朋友，一听说用C++写MCU程序，两只眼瞪得大大的，一连串的问题发出来：有必要吗？那效率得多低啊？程序会不稳定的！容易出问题的！我现在已经懒得解释了，自己用得爽就行。

现在也基本上不用RTOS了，有自主行为的对象都做成内含线程的主动对象。面向对象刚入门那段时间着实兴奋了一把，还想着要出本书来着。后来想想，要出书得在理论上将自己的方法完善和阐述清楚，否则会误人子弟啊，所以还是写个博客吧，结果因为太懒，博客也没写成。看来，我终究是一事无成啊。

zmsxhy

好吧，我从上班看到现在快半个小时仍然是有点糊涂。其实我现在的情况可能很多人都经历过，不像是点个LED灯，写两句回头看就知道了。我现的情况是虽然程序任务及数据的增多，既然是流程图我有时都要思考半天整个程序到底要干什么，任务与任务之间的关系，他们的数据是如何处理的。
总之很多大神可能已经渡过了这种境界，所以想讨教一下如何让自己的思路以及搭建的框架很清晰的展现出来，现在也在学习有结构体封装（我不知道这么说正不正确）数据行等方法。可是总有一种没有办法将脑子里的思路给展显出来，即使很多年以后我一看到这个东西，我就能明白当时的想法！
或者还有点表达模糊，但也只能这样！

Aragorn

辛昕 发表于 2015-3-4 17:11
额，老大，那个啥，其实我也一直很想好好学学面向对象，苦于几次无功而返。
不知道你是否能赐教一下

具体点，具体点。
当然不是要你跟我说很多具体的事情，只是，那个啥，大概是个什么学习思路和方法就可以了～～

当年上班的时候，公司也是用C的，我提议用C++，公司没批准。后来自己能作主了，就毫不犹豫的用上了。
至于怎么学习，我也说不清楚啊，而且我也不敢说现在就理解了面向对象和面向过程，甚至无法用语言描述出来。当年情况大概是这样的，因为碰到和楼主一样的问题，还有公司的一些代码需要维护、需要移植什么的，这些代码（包括我自己写的）都有一个非常明显的特点：烂。修改麻烦、移植麻烦，想动点手脚，你得烧香拜佛。


我就想，得把程序写好来。既然PC平台发明了那么多方法，我想一定可以用于嵌入式，面向对向吹得那么响，想必也有些门道吧。于是，学习开始了。各种书籍买，各种PDF下。什么大象—Thinking in UML啊、什么面向对象分析、设计、编程啊、什么OOAD、什么领域分析啊，出版的没出版的别人回复的写上博客的，忘记看了有多少了。很长一段时间之后，出结果了，结果是：一无所获。看过这么多，仍然不得要领，对面向对象还是迷迷糊糊的，根本不知道说的那些玩意有什么用。

既然没用，那就继续看吧。像头驴一样耷着脑袋往前走，只知道看资料和画UML图，忘记过了多久了，还是迷迷糊糊的。很多所学的东西根本不知道如何转化，比如什么边界对象、什么实体对象、什么控制对象，他们之间的交互啊，到底该如何实现？而有些问题中的对象到底算到哪种对象中？这个到底算不算用例？到底算两个用例还是归到一个用例中？想不明白的东西太多了。

在迷迷糊糊中，我尝试慢慢在项目中把这些东西用起来。写过几次代码后，感觉有些东西慢慢变得明了了。而且随着继续在项目中尝试，一些理解也慢慢成型，方法也慢慢成型。记得方法基本成型是我在公司所做的最后一个项目，那个项目由我一个人负责，虽然是用C写的，而且当时方法刚成型，还不完美，但证明了还算是比较成功的。因为离职之后我听说，新同事在维护我的代码后，在其他同事面前对我那个项目代码褒奖万分。有一次老同事聚会时他也去了，特地跑过来跟我一个人喝酒。说这些不是在夸自己有多少能耐，而只是证明方法确实是有优劣之分。

上面说那些看上去无关紧要的事情，只是想从事情的发展中总结一下我的看法：

1. 面向对象的分析设计和编程，有很多著作，每个人的理解不一样，有些步骤、说法也不一样。很多人把自己的理解总结出来，形成方法，并给这个方法命名。我自己也一样，看过很多资料，形成的方法也是在项目中慢慢理解和总结出来的。所以，当你学习的时候，没必要拘泥于一种方法的所有步骤、所有理解，每种方法出来的时候，或多或少的带有作者本身的习惯，这种习惯并不一定适合你，你可以学习他们，并总结自己的方法。面向对象只是一种思维方法，不是工具，我们要学的是如何按这种方法思考，所以没必要完全跟别人一样。当然了，所有的面向对象方法，整体框架上是相同的，这点可以放心；

2. 我们在写程序时，需要将整个程序分成若干元素或者说是模块，这些模块相互配合，使程序达到预期要求。这个过程分成两步，第一步是怎么通过分析来划分模块，第二步是怎么实现模块。模块划分跟语言无关，而是跟思维有关。不同思维主导下，分析得到的模块并不一样。模块划分完后，就是编码以实现模块。所以如上面所说，面向对象的方法又分为分析设计和编程实现。这就说明，无论我们用C、C++、JAVA抑或C#等，都可以用面向对象的方法来理解问题，划分模块。只不过如果用C++等面向对象的语言，那么还可以更进一步在编码实现层次使用面向对象的分析设计思维作出指导，并且更能有效的实现面向对象的特性。总之，面向对象是一种思维方法，跟所使用的语言关系不大。所以别说你C++和JAVA用得不多甚至根本就不用而只用C了；

3. 写一个程序，我们需要对程序进行模块划分，还需要分成不同的层次，哪个模块需要放到哪个层次中去，大模块中又有小模块，怎么封装底层，程序需要移植到哪些平台，怎么解决可移植性问题等等，这些总的加起来，就是软件架构了。而其中最为重要的，可能就属模块的划分了。所以用好的方法划分出模块的程序，会使得整个程序清爽舒适，如沐春风。而局部代码所造成的影响，则要减少很多，甚至被忽略。这就好像整个房子装饰美观、明亮整洁大气，就会使得一个小抽屉中的胡乱摆放也不会引起不舒适感是一样的道理；

4. 关于面向对象的理论，当然要学习。多看些这方面的资料，不要拘泥于只看大师的作品，别人的回复、博客中的点点滴滴都可以阅读。有时候这次阅读所不解的问题，可能在另一份资料中得到解答。但无论哪种资料，都不可陷入其中而不自拔。总之，思维方法这种东西，每个人都不一样，所以要多看多读多画图，而且别人说的也并不一定就是合适的，毕竟跟习惯也有所关系；

5. 无论理解有多深，学到有多少，记住一定要实践。不管是编码还是画图还是分析什么的，一定要尝试在项目中使用。可以先从简单的用例分析开始，然后再逐步深入，包括模块划分和编码。特别是编码，尤其重要。你可以给自己设计一个小项目，然后用所理解的方法去尝试，有公司项目尝试就更好了。不理解没关系，理解得模模糊糊也没关系，要硬着头皮去编码去实现，编码是联系理论和实践的桥梁，能够帮助理解，极有可能取到意想不到的效果。当年我就是在理解不完全的情况下硬着头皮编码的过程中，感觉自己“顿悟”的。

我比较笨，当年学习和实践、到方法成型，前后好像持续了两年左右，这时间已经很长了，但至少我坚持下来了。聪明的时间可以更短，更笨的则要花费更多时间。这里送你《佳访》中采访陈坤后所说的一句话：无论禅定还是行走，不管禁语还是清修，奥妙都是专注。

zmsxhy

是只有我自己这样吗？是只有我自己这样吗？是只有我自己这样吗？是只有我自己这样吗？是只有我自己这样吗？

dcexpert

每个人有自己的习惯和方法吧，也可以使用rtos来简化程序设计。

sjmzx

我也是，我也是，同等求解

freebsder

UML

zmsxhy

Aragorn 发表于 2015-3-3 19:01
关于较大型程序的编写，曾经碰到跟楼主一样的问题，我有很多话要说啊。

流程图未必是必须的，很有可能适得其反，使得既没起到应有的指导效果，还浪费了大把时间。所以这种东西因人而异，觉得有帮助就画，觉得没作用就不画，千万别觉得这是一种高大上的工作就强迫自己画。而且程序复杂度这种东西，跟画图之间没有必然的关系。正常的软件工程中，两种情况下画图是最多的。一种是在分析问题的过程中，画一些简单草图以帮助直观的理解问题，这种图生命很短，一旦理解问题后基本上都会被抹去；另一种就是项目完成后，用图来直观的表达程序的结构，以帮助后来的程序维护者理解程序，这种图基本上存在于程序的详细说明文档中，而且还得配有文字描述。至于用流程图面面俱到的画出程序的执行流程，基本上是新手为了追求高大上才干的活计。

看到上面有人提到用RTOS来简化程序设计，我不敢苟同，见过一些追求使用RTOS的人，写出来的代码跟没用RTOS时一样烂。也就是说，当一个人的程序水平本身很烂时，那么随便他使用什么RTOS、什么先进的模块，他写出的代码也还是烂的。水平不会因为使用的部分好代码而变得更好，反而可能因为使用了模块而变得更糟糕。

至于程序越来越大而变得复杂这个问题，其实要从两个方面入手予以解决。第一个方面就是一定要去掉陈旧的代码效率和执行效率至上的思维，要以封装为主；写MCU程序出身的很多工程师，思维比较古板，稍微多做一点封装、代码稍微多一点就跟个世界末日似的大喊大叫，这个代码太多了啊，会影响MCU执行速度的，而且几乎是条件反射似的反应。代码封装多一点，对现在的MCU来说，几乎就多了几US的时间，根本不会有影响，但是对程序结构来说，却会有莫大的助益。而且很多人没注意到，程序越大，所要使用的MCU也会越高级，资源也越多、执行速度也越快，这会抵消掉封装所带来的代码效率和执行效率问题。如再拘泥代码的效率和速度，就比较愚蠢了。

第二个方面，就是程序架构或者说是模块划分了，这一点至关重要，而且大多数的烂程序主要就烂在这方面。我曾经也是写烂程序的高手，也碰到很多写烂程序的高手。现在不说程序能写多好，但至少不烂了。这里给你的建议是，去学习面向对象的分析和设计方法，虽然这种方法出自于PC平台的软件工程中，但同样适合于嵌入式。以前觉得老是说面向过程和面向对象这些东西很玄乎，根本理解不了之间的差别，就骗人的玩意，就像马克斯的共产主义一样，都是虚妄。后来花了很长时间去学习和实践，还一个劲的学画UML图，终有些许所得。才发现，这的的确确是两种不同的思维方式。

现在基本上算是入道了，用C++写面向对象，封装做得妥妥的，用起来特别爽。最明显的好处有两个，第一个是需求发生变化时，的确更容易修改代码；第二个就是代码复用，现在面对新项目基本上直接把文件复制到工程中，效率要高很多，做好的代码基本上就等同于库了。不过也有一点不好，那就是总能碰到讨厌的同事和朋友，一听说用C++写MCU程序，两只眼瞪得大大的，一连串的问题发出来：有必要吗？那效率得多低啊？程序会不稳定的！容易出问题的！我现在已经懒得解释了，自己用得爽就行。

现在也基本上不用RTOS了，有自主行为的对象都做成内含线程的主动对象。面向对象刚入门那段时间着实兴奋了一把，还想着要出本书来着。后来想想，要出书得在理论上将自己的方法完善和阐述清楚，否则会误人子弟啊，所以还是写个博客吧，结果因为太懒，博客也没写成。看来，我终究是一事无成啊。

            听君一席话我是收获很多啊，不过这都是后绪的一个积累过程，现在手头上的事还是让人头大，看起来要了解一下C++了！另请问430用C++也可以编程？IAR怎么设置？

freebsder

c++慎用吧，这玩意一不小心就失控了，就算自己能把控，可不能希望团队里的人都能把控。各个厂实现的c++子集和行为的不一也会给移植带来不可预见性。编译器带来的额外复杂性给调试，性能，除错，等非设计编码过程也带来不少挑战。
从设计层面讲它确实能一定程度控制复杂度，可从语言层面讲它又会带来新的复杂度。c封装虽然不够语法层面的直接，好在简单，mcu里大量做这种设计。
没有一定规模的项目没有一定时间的项目没有一定高水平成员的项目，c++就太重了。

zmsxhy

那各位说一下以后C语言会不会向现在的汇编一下被淘汰啊，我到是觉得还真有可能，只是不知道时间要多久！

freebsder

做你这行c还淘汰不了的。

Aragorn

freebsder 发表于 2015-3-4 10:45
c++慎用吧，这玩意一不小心就失控了，就算自己能把控，可不能希望团队里的人都能把控。各个厂实现的c++子集和行为的不一也会给移植带来不可预见性。编译器带来的额外复杂性给调试，性能，除错，等非设计编码过程也带来不少挑战。
从设计层面讲它确实能一定程度控制复杂度，可从语言层面讲它又会带来新的复杂度。c封装虽然不够语法层面的直接，好在简单，mcu里大量做这种设计。
没有一定规模的项目没有一定时间的项目没有一定高水平成员的项目，c++就太重了。

又碰到一位，我已经麻木了。其实C++所带来的问题，放在C上一样适用。碰到大程序，即便用C，团队里也未必人人都能把控。至于给移植性带来问题，我笑了，见过太多用C写的，那移植性，可以把人逼得去跳楼。至于所说的额外的复杂性给调试、性能、除错等带来不少挑战，作为过来人，我只能说这种担心纯属多余，唯一的性能问题，我在上面的回复中也已经说过了，你没看见吗？另外再推荐你一篇关于C++写MCU的文章，是我以前看到的，觉得不错，保存成PDF文档，附件有下载。 低效的 C ,真的是这样吗？.pdf (374.15 KB, 下载次数: 9)

2015-3-4 13:01 上传

点击文件名下载附件

其实我觉得只有研究过用过C++的人，才有评判的资格。否则，就是我所说的思维陈旧、固守刻板。接触过写代码水平不高的，随便用什么语言，写出来的都是烂代码。


写程序最主要在于作者的思维方法，好的思维方法能得到更好的程序，语言的作用没那么重要，但是好的语言能更好的实现方法。这就是为什么有了面向对象的思维方法后，新出了那么多的面向对象的编程语言，而不是都直接用C去模拟面向对象。另外，我当然承认C++较C更为复杂，更难掌握。所以想用C++的得注意两点，第一就是看是否掌握了面向对象的思维方法，没掌握就别用了；第二就是建议想用的人去看一下google的C++编码规范，里面的建议我非常喜欢，就是一些难处理的特性绝对不用，好用的、简单的才用，而且用这些容易懂的、简单的，已经足够强大了，没必须再为一些用得少的、难用的特性而对C++大加批判。

至于上面有人说C是否会淘汰，起码目前可见的未来不会淘汰。我虽然用C++写程序，但是绝对需要用到C。我的驱动就是用C做的，这样规避了不同编译器对C++访问硬件规范的不同而带来的移植性问题。而且一些小项目也是用C写的，碰到一些芯片不支持C++的也用C。

freebsder

Aragorn 发表于 2015-3-4 13:32
又碰到一位，我已经麻木了。其实C++所带来的问题，放在C上一样适用。碰到大程序，即便用C，团队里也未必人人都能把控。至于给移植性带来问题，我笑了，见过太多用C写的，那移植性，可以把人逼得去跳楼。至于所说的额外的复杂性给调试、性能、除错等带来不少挑战，作为过来人，我只能说这种担心纯属多余，唯一的性能问题，我在上面的回复中也已经说过了，你没看见吗？另外再推荐你一篇关于C++写MCU的文章，是我以前看到的，觉得不错，保存成PDF文档，附件有下载。

其实我觉得只有研究过用过C++的人，才有评判的资格。否则，就是我所说的思维陈旧、固守刻板。接触过写代码水平不高的，随便用什么语言，写出来的都是烂代码。


写程序最主要在于作者的思维方法，好的思维方法能得到更好的程序，语言的作用没那么重要，但是好的语言能更好的实现方法。这就是为什么有了面向对象的思维方法后，新出了那么多的面向对象的编程语言，而不是都直接用C去模拟面向对象。另外，我当然承认C++较C更为复杂，更难掌握。所以想用C++的得注意两点，第一就是看是否掌握了面向对象的思维方法，没掌握就别用了；第二就是建议想用的人去看一下google的C++编码规范，里面的建议我非常喜欢，就是一些难处理的特性绝对不用，好用的、简单的才用，而且用这些容易懂的、简单的，已经足够强大了，没必须再为一些用得少的、难用的特性而对C++大加批判。

至于上面有人说C是否会淘汰，起码目前可见的未来不会淘汰。我虽然用C++写程序，但是绝对需要用到C。我的驱动就是用C做的，这样规避了不同编译器对C++访问硬件规范的不同而带来的移植性问题。而且一些小项目也是用C写的，碰到一些芯片不支持C++的也用C。

你也别作为过来人，我C++从98年就在折腾，再有3年就20年了。
C++语言本身大多数编译器就支持的不完备，更不要说标准。C++的移植除了编译器自己被移植到很多平台，想靠代码和标准来做移植，基本是有多少坑你要填多少坑。就连C++、C与汇编的交互，各家C++的实现都有不一样的地方，当然标准也没定，有namemangling的，有下面加两个下划线的，有些类名是这种规矩翻译，有些类名是那种规矩翻译。这只是C++编译器之间的不一致。
再加上C++虚函数有基于查表的，有基于链表指针的实现，同样代码的class，sizeof出来的大小可能不同的编译器会不一样。C里面可以很方便的排列出struct的内存分布，所以container_of才能方便的使用，C++里面你得考虑编译器给你添加的东西会不会影响内存分布。
你要说“太多用C写的，那移植性，可以把人逼得去跳楼”，不否认有，但是C除了指针需要一点经验之外，C++有太多地方需要你对语言本身足够的把控。
我表达的意思是C++可以在一定程度控制复杂度，而如果你没有一个强力的团队能控制住它或者把它限制在某一个语法范围内，那么它自身的语言复杂度就完全抵消了可以带来的好处。

770781327

都是经验丰富的老前辈呀。。。。。

辛昕

我，我，，，，我表示我错了，居然木有看到这个讨论的如此激烈的题目
偶表示，偶也经常有这些苦逼的想法和困难，并且一路走来已经两三年。。。。。。当然仍为其所困扰。

但是为了避免一大段一大段的blablabla影响阅读，我要冷静，我要冷静！！

wo4fisher

几位分析的都挺有道理，本人C用的多，C++接触过，但没用过，所以不便发表什么意见，C、C++语法规范是一方面，再加上各种编译器细节上的不同处理...

辛昕

1.

额，首先偶想说的第一个观点是：

不管是c++,uml,面向对象神马的，我只想说，这些东西本身是很好，而且呢，也确实有可能给 单片机C 很多年的我们，很多启发。
但是，这些东西本身，并不是关键。
关键是你如何吸收其中的精华。

而同样一个东西，你能吸收多少，这完全取决于你的经验，能力和眼光。
而这些都有赖于你正确的，按部就班的学习，在实践中一点点真正的体验，是任何书或者工具无法替你完成的。
我的意思是，你现在去用 c++ uml 面向对象，最后你在一场看起来很美好的幻梦中醒来，你会发现所有问题还在，而更糟糕的是，现在你的脑子里多了一千匹一万匹野马在乱跑和咆哮，你完全无法平静下来。

比如说，面向对象与面向过程之争。

版主不敢说自己已经懂了一点面向对象的门道，版主甚至不敢说自己懂 面向过程。
但是，版主也曾经在过去的三四年里，在这些看起来很好很强大的东西里折腾，看书，发帖，口水多多，在代码里大刀阔斧的尝试.......

可是，版主最后发现，不管使用什么工具，其实，问题还是在那里——除非你真的了解自己遇到什么问题，并且找到一个真正有用的解决方法。

在这里，版主特别想温馨提示的是，往往你在折腾，学习的时候，你的注意力和精力已经被完全转移到和问题本身可能完全无关的事情上去了，最后你筋疲力尽却毫无所得，而更悲剧的事情是，你此时的能力和经验使得你无法真正发挥这些东西本该有的功能，于是你可能觉得这些东西没用，误解了它们，将来等到你能够理解他们的时候，你却会因为当年的偏见而拒绝。
这是非常糟糕的事情，我自己经历过，我也在多次看网上的一些帖子，内容时感受到相当多的人有这种情形。

而据版主的经验所得，很多时候，真正管用的解决方案往往更多的是思路方面的改变，而非来自工具。

PS：
最重要的一点。
有时候，你贸贸然去学习这个那个新东西，往往你需要时间去学习，掌握，沉淀 和 熟练使用 新技术。

从务实的角度来看，这些都是风险——版主本人试过很多次，花了大把时间去 折腾，尝试、却因没有再以开始的时候首先认真思索，问题的本质在哪里，而导致徒劳无功，甚至破坏了原来的情形，使问题变得越发严重。

我们都知道，花时间去学习，去磨刀，是为了更好地解决问题，这是对的，但是，我们也是活在现实工程中的人，做事情一定要斟酌。

事实上，在实际工作中，过多地使用新技术和过多地回避新技术，都是不对的。
而大多数时候，前者的危害更大。

总结之：
版主温馨提示：
你更应该关注的是你遇到的问题本身，而非这山望着那山高，希望像武侠片里的主人公，掉到什么坑里捡到一本九阳神功（当然有时也会是葵花宝典），学成就可以出来打遍天下无敌手。
软件行业有一句话叫 没有银弹，意思是，没有那种可以解决一切问题的东西，见招化招，才是关键。

辛昕

与前面相回应。

作为一个关心了很多年 代码架构啊，如何应对程序越来越大 啊什么的 人，版主非常渴望你 更多说说你实际遇到的问题和你的困惑。

如果没有这些，你，还有我们，都无法搞清楚你到底遇到了什么问题？

需知道，说同样一件事情，比如说 封装。

你所认为的事情，，和 我，freebsder 想到的可能完全是不同层次的问题。
所以我们的讨论对你没有一毛钱作用。

辛昕

freebsder 发表于 2015-3-4 14:37
你也别作为过来人，我C++从98年就在折腾，再有3年就20年了。
C++语言本身大多数编译器就支持的不完备，更不要说标准。C++的移植除了编译器自己被移植到很多平台，想靠代码和标准来做移植，基本是有多少坑你要填多少坑。就连C++、C与汇编的交互，各家C++的实现都有不一样的地方，当然标准也没定，有namemangling的，有下面加两个下划线的，有些类名是这种规矩翻译，有些类名是那种规矩翻译。这只是C++编译器之间的不一致。
再加上C++虚函数有基于查表的，有基于链表指针的实现，同样代码的class，sizeof出来的大小可能不同的编译器会不一样。C里面可以很方便的排列出struct的内存分布，所以container_of才能方便的使用，C++里面你得考虑编译器给你添加的东西会不会影响内存分布。
你要说“太多用C写的，那移植性，可以把人逼得去跳楼”，不否认有，但是C除了指针需要一点经验之外，C++有太多地方需要你对语言本身足够的把控。
我表达的意思是C++可以在一定程度控制复杂度，而如果你没有一个强力的团队能控制住它或者把它限制在某一个语法范围内，那么它自身的语言复杂度就完全抵消了可以带来的好处。

我去～～freebsder，我错了，我一直以为你是比我大几岁的老大。
您到底是少年天才还是已经是功德圆满的老前辈啊～～

Aragorn

freebsder 发表于 2015-3-4 14:37
你也别作为过来人，我C++从98年就在折腾，再有3年就20年了。
C++语言本身大多数编译器就支持的不完备，更不要说标准。C++的移植除了编译器自己被移植到很多平台，想靠代码和标准来做移植，基本是有多少坑你要填多少坑。就连C++、C与汇编的交互，各家C++的实现都有不一样的地方，当然标准也没定，有namemangling的，有下面加两个下划线的，有些类名是这种规矩翻译，有些类名是那种规矩翻译。这只是C++编译器之间的不一致。
再加上C++虚函数有基于查表的，有基于链表指针的实现，同样代码的class，sizeof出来的大小可能不同的编译器会不一样。C里面可以很方便的排列出struct的内存分布，所以container_of才能方便的使用，C++里面你得考虑编译器给你添加的东西会不会影响内存分布。
你要说“太多用C写的，那移植性，可以把人逼得去跳楼”，不否认有，但是C除了指针需要一点经验之外，C++有太多地方需要你对语言本身足够的把控。
我表达的意思是C++可以在一定程度控制复杂度，而如果你没有一个强力的团队能控制住它或者把它限制在某一个语法范围内，那么它自身的语言复杂度就完全抵消了可以带来的好处。

“我表达的意思是C++可以在一定程度控制复杂度，而如果你没有一个强力的团队能控制住它或者把它限制在某一个语法范围内，那么它自身的语言复杂度就完全抵消了可以带来的好处”
如果只是这一句，其实我也是同意的，所以我说要参考google的C++编码规范，尽量用一些简单好用的特性，而其他一些难处理的特性别用。不过就你列出的论据部分，我倒觉得着实不是问题。不同的编译器对语言的处理并不完全一致，这对任何语言都有效。只是随着语言的越复杂，处理的不同越多而已。但是在程序没有BUG的情况下、以及编译器没有BUG的情况下，无论编译器有多不同，都会得到与源代码相预期的结果。契合点就是，程序员对语言的理解和编译器对语言的理解相一致。很多时候还不仅仅是对语言的理解，更需要对编译器和程序的运行环境作出理解，并根据这些理解编写代码。毕竟语言只是用来描述想法的，而编译器则是理解想法，运行环境更是实现想法的。

总之，我碰到的说C++有问题的人，他们很多其实在C中也碰到许多相类似的问题。

freebsder

Aragorn 发表于 2015-3-4 16:11
。。。。。。

不同的编译器对语言的处理并不完全一致，这对任何语言都有效。只是随着语言的越复杂，处理的不同越多而已。但是在程序没有BUG的情况下、以及编译器没有BUG的情况下，无论编译器有多不同，都会得到与源代码相预期的结果。

。。。。。。

兄弟你太可爱了，呵呵，别说C++，就是C里面你看看多少undefined，多少implementation defined的说明吧，C++几千页的标准里更多。“与源代码相预期的结果”这个理想是丰满的，可现实是骨感的。工具复杂就是复杂，这和是不是什么思维没关系，就算你面向党中央的编程，它还是那么复杂