CppExplore

顶！

#include <stdio.h>
int main()
{
getchar();
return 0;
}

兄弟，面对现实吧，你不适合上学，赶快找点能做出成绩的行业，开始起步吧。
比如利用你语言上的优势，在两国互通有无，或者复制一个国家的商机到另一个国家，或者为在国外的留学生小团体提供一些服务，常见的就是跨国话务之类的。

我的经历也是如此，也思考过原因：
（1）公司不重技术、重市场。而开发的直接领导也是同样的浮躁心态。
（2）开发团队没有技术积累、没有统一认可的基础架构。
（3）开发人员由于不同的开发经历，各自有自己的基础模块实现、对系统有自己的认知。

改善这个情况，开发人员的角度 也只能是多沟通、互相分享知识、定期分析已有系统的架构、争取能对同类型的应用应该使用的最佳设计达成共识。
根本解决还在领导层对技术的重视，重视基础模块积累、重视对系统框架的探讨分析，重视团队技术上的可持续成长。

博主好文采！
来搞技术，可惜了。

Ogre + C++吧 熟悉的话，可以直接进入实质的东西。时间都是浪费在实际的逻辑上，不是单纯的工具上，如果你对工具熟悉。

如果准备时间充足，也可以考虑XNA+.NET，事先增加技术预研阶段，写预研文档，扫平技术上的障碍，之后再进入实际的开发。

@yshuise
你确信你看懂它的实现了？

.............................
内存检测工具跑一遍就能发现的问题，你还真执着啊。

由于内存问题宕掉，堆栈什么的都是不可信的，一定要在初次出现问题的地方找（第一次写内存错误），都到后面了，什么意义都没了。

写完代码，需要用内存测试工具跑反复的跑，压力下跑，一遍没跑期望没有任何的内存问题 基本是不可能的。至少至今我开发的服务器，没有一个是写完编译过，就没有任何内存问题的。

@Chuck
发布到首页的 就是要给别人分享的。很多人订阅首页，让别人看不懂或者看了无所收获的文章，也是浪费别人的时间。
如果是给自己看的，不必选择发布到首页。

@陈梓瀚(vczh)
其实我移出首页的出发点,不是因为它没开源,根本原因是我认为不能共享到任何的思想, 没有看到可以分享的东西,当然可能是个人眼界的限制.

总上所述, 如果博主认为本文满足“分享知识给喜欢思考并研究的人”,请重新发布到首页吧. 我个人仍然坚持以前的看法.

@陈梓瀚(vczh)
1 luckyScript并未开源
2 本文展示了用luckyScript写的一个计算器,以及给出运行的结果贴图证明脚本的正确性.
3 博主并未明确说明,是来接受批评的 也未给出需要大家提出意见的方向
4 我的理解blog是分享知识的,尤其是首页精华,订阅首页文章的人 更多的是希望能获取到知识. 如果有疑惑需要大家解答,更好的选择是发布到论坛.

偶尔往首页发个解题报告也无不可 大量的发而又重复的没啥意义吧
是不是可以写的总结啊 算法基础 npc综述之类的发到首页啊

发首页 纯炫耀 鉴定完毕！ 移除

顶下！

已阅 移除

removed by cppexplore

已阅 删之

已阅 删之

无内容。移除

博主将文章 发往首页精华的 时候 稍微斟酌下 尤其是很多篇一起放上来的时候，没多少时间一篇一篇的审核，多谢。

博主放到sf上吧，配上英文说明、文档等。有时候99％和100％就是差那么一点额外的努力。

顶博主
多发写相关的东西啊
坐下来慢慢看

@OwnWaterloo
上班不能qq 呵呵 下班加你
A不能以指定消息值的方式向B发消息，通过调用B自身的ON_MSG方法发送。也就是除了B自己，谁也不知道它具体消息的枚举值。
64一下的也是调用B自身的方法发送，不过这些是B基类中的方法。

@OwnWaterloo
不是同一套，只有64以下的是相同。64以上的各个线程之间可以重复，因为对其他对象是不可见得，所以不存在冲突问题。可以定义USER_MSG_START=64.
项目越大，越需要表格，容易维护，容易扩展，容易找对应关系，也就是看一个文件就知道所有，而不是在几十个上百个文件里查找。当然要看你的虚函数实现成什么样子了。
我举的例子，对象B是管理类，同时也是线程类。里面管理了很多的对象，B拿到消息也是找到对应的对象去处理，貌似你一直谈的是后续。
而你在MFC里看到的是同一套，那是因为它们都在UI线程里，同属于一个线程，一个管理类。

楼上的各位啊 欢迎来讨论理论或者思想 具体到代码细节的东西就免了，文章已经很详细很详细了。

@sashion
不晓的啊，可以去看源代码 ：）

@OwnWaterloo
呵呵 你觉得你的想法来源于面向对象的纸上谈兵（没有贬义）以及基于win32的mfc框架程序设计。
我的实现不是为了模拟虚函数的实现，只是为了实现一个易维护的消息映射而已。
首先 对象A不能直接向对象B直接发送消息，需要调用对象B的ON_send_msg，由B自己的方法向自己发送消息，由B的DO_Msg方法处理消息，当然发送动作和处理动作在不同的线程内。任何对象向B发送消息都要调用B自己的方法。也就是说对象B的具体消息类型对其它对象是不可见的。
因此对象B中的消息类型是连续的，并且不存在自己不感兴趣的消息，既然不感兴趣，就不会存在这个消息类型，只要是存在的就是感兴趣的，就是要处理的。也不存在对多个消息，处理方式相同的问题，既然处理方式相同，它们就是同一个消息。
其次 你还是回避了大型程序开发中，使用虚函数方式，文件个数膨胀的问题。
最后 我讨论的是线程间的消息传递和映射，你的有偏向于 已经发送到UI线程的消息，对责任链模式上的 各个对象的后续处理。

@OwnWaterloo
呵呵，最后的问题归结为：哪种更容易理解和扩展。
超大工程当然是数组方式之上用宏展现最容易理解和扩展了，简洁直接。几十w行的代码，用虚函数，文件数量的迅速膨胀 找个东西都找不到在哪里，所有东西交织错乱在一起，最终维护程序的人都会想：要是有张表就好了，只看表就知道那个函数处理哪个消息，而宏的展现就是如此。 当然如果用宏包裹下虚函数的实现，结果就一样了。
并且数组表只是一个思路，不携带任何面向对象的语义，在这个业务系统里可用，在那个业务系统里也可用，虚函数有这么好的移植性吗？有这么简单化吗？

@OwnWaterloo
怎么不直接去我blog回复呢 呵呵
其实 时间消耗 之类并不是我最得意的东西，这种实现的细节 我并不太关注，所以质疑你以前说的 “虚函数占用较多资源而导致不得已采用消息路由”，如何实现并不重要，关键的是容易理解，容易扩展，容易维护，容易移植，容易简单化。
win32 你是指win32 的界面设计？ 业务系统里 基本不同的消息有不同的实现，我的本意其实都不在实现，而在于简单的思想，因此是查表实现 还是虚函数实现 也都无所谓，只要最后有统一的扩展方式。

@OwnWaterloo
欢迎来我blog讨论：http://www.cppblog.com/CppExplore 这篇http://www.cppblog.com/CppExplore/archive/2008/11/07/66216.html下。查表是本质，为什么要使用虚函数？更容易理解?MFC的消息映射展现方式很难理解吗？ 虚函数更容易扩展吗？ 说到虚函数占用较多资源而导致不得已采用消息路由，我不能认同，这个因素在整个系统中的开销你有没有量化过？比如 因为采用它导致并发数下降了多少多少之类？欢迎来我blog讨论。

1. 都为欠缺开发经验的应届毕业生
培训、沟通、讨论
2. 没有做完善的详细设计，需求分析完后立即开发，导致后期频繁改变系统架构，延迟开发时间
-->需求文档、review需求文档
开发文档、review开发文档
3. 没有模块做单元测试
-->培训
4. 没有 code review
-->问题不是很大，可以两两review 互相学习
5. 代码覆盖率 < 10%
-->一和代码架构有关 学习、总结、讨论
二和测试方式有关 培训
6. 开发小组提交到时测试小组前，没有做内部测试，导致很多产品被测试小组打回
-->写测试文档，培训测试流程、方式 评估bug个数 代码可读性 作为个人绩效考评依据

7. 测试小组目前只做黑盒测试，很多BUG测不出或难以重现，导致产品在正式投入使用后出现很多问题

-->到测试组前，需要研发做白盒测试。测试小组拿到产品前，根据需求文档写测试项。愈是代码行数多的模块，所做的测试项愈多
8. 没有完善的版本管理，从客户那边拿回来产品经常找不到对应的源代码
-->指定项目经理，对项目负责，可以调度研发人员、测试人员等资源。另安排专门的人做it文档、版本等管理。

总之 应届生有激情，给予相应的指导培训、制度化、多鼓励、多总结，一切会好起来的。

楼主 要不要聘请一个兼职顾问，提供一下培训啊，呵呵。
另 removed

@LOGOS
呵呵。谁能想到答案在23种模式之外呢。不过理解mvc的关键是observer，不是那个browser。也难说你从另一个特别的角度同样了理解了mvc的关键所在。：）

多年不回顾专业课了。去《Design Patterns》里复制点原话出来：第五章 行为模式的observer模式中的Know Uses部分：
The first and perhaps best-known example of the Observer pattern appears in Smalltalk Model/View/Controller (MVC), the user interface framework in the Smalltalk environment [KP88]. MVC's Model class plays the role ofSubject, while View is the base class for observers.
当年专业课考试，题目是图形的场景，我答observer，标准答案mvc,老师给零分，郁闷。

@LOGOS
mvc并不是23种设计模式的任意一种。
它是设计图形交互系统的常用方式。它引入了庞大的应用场景，当然往大了说，可以说它是一种框架，往小了说，它接近哪个模式呢？

每个模式都是一种思想，而不是简单的固定实现。observer描述的是观察者 被观察者之间 的notify和update行为，如果用这个模式来实现ui交互，应该是什么样子呢？

先理解了observer模式，再理解mvc就容易了，mvc可以说是observer的特例

.................................
真的没人愿意看看RAII???????????????guard的实现、资源的自动管理、资源申请的原子操作？？？？这个题目也只是RAII的一个小小实践
class X{
public:
X(){}
~X(){printf("hello world!\n");}
};
int main()
{
X obj[n];
return 0;
}

汗，上个评论最后一句多写了一个“不”，博主见谅。

我想楼主想表达的意思并不在于该题本身，而是RAII
我随意搜索了一下，有兴趣可以继续看下：http://hi.baidu.com/joel%5Ftan/blog/item/8682fcd8ceefeb3032fa1c3b.html
相信大家不会认为博主的这点“简单”想法不是“nosense”。

不错，很好的思路。
楼上各位需要明白下 空杯心理。

@ssharry
其它线程快速调用putq两次，如果有2个线程在getq处阻塞，就会被同时激活，而完全有可能，其中一个被激活的线程获取到了cpu，快速处理了2个消息。

呵呵，有一句话说的很好：
心中有佛看到的便是佛,心中有屎看到的便是屎。
不要胡乱猜测别人是装逼犯哦。

@ssharry
可能是吧。这篇文章里东西都没实用的价值，就是理论上想象一下而已，呵呵。http://www.cppblog.com/CppExplore/archive/2008/03/20/44949.html这个里面的才是实际可用的。

熬夜很伤肝啊 还是早睡早起好习惯 呵呵

@田伯光
log4cplus是线程安全的。多进程共享内存的方式使用对象，和多线程的方式是一样的。你可以压力下测试下，呵呵。
另外，打印到syslogd和打印到socket也是多进程打印log的备选方案。
log系统用开源也不是因为它们功能强大，主要的好处是它们充分考虑了IO输出的效率（开辟内存池，延迟批量输出），第二个是系统宕掉时候，log打印的准确性。另外用宏隔离，也方便以后发现更好log系统时候替换。

@kacy16
：）

@田伯光
呵呵，多进程一定不能共享对象，除非这个对象在共享内存中，共享内存中的对象又要注意互斥问题。最好的办法还是各进程用自己的进程的log对象。运行期间动态改变log的级别，可以去代码中找答案，或者你等我有了这个需求，我改好告诉你，呵呵。

@dxzhan
非常高兴有人喜欢我的blog。
您的回帖是我继续的最大动力，呵呵。

一句话，多用组合，少用继承。