C++博客-路的尽头-文章分类-思索

C++博客-路的尽头-文章分类-思索http://www.cppblog.com/tangxinfa/category/5921.html开发者之旅zh-cnMon, 13 Aug 2012 21:45:08 GMTMon, 13 Aug 2012 21:45:08 GMT60新的个人博客http://www.cppblog.com/tangxinfa/articles/new_blog_home.html唐新发唐新发Wed, 08 Aug 2012 04:32:00 GMThttp://www.cppblog.com/tangxinfa/articles/new_blog_home.htmlhttp://www.cppblog.com/tangxinfa/comments/186645.htmlhttp://www.cppblog.com/tangxinfa/articles/new_blog_home.html#Feedback0http://www.cppblog.com/tangxinfa/comments/commentRss/186645.htmlhttp://www.cppblog.com/tangxinfa/services/trackbacks/186645.htmlhttp://blog.kankanan.com

唐新发 2012-08-08 12:32 发表评论

]]>多线程环境下的对象生命周期管理http://www.cppblog.com/tangxinfa/articles/object_meet_thread.html唐新发唐新发Sun, 26 Dec 2010 17:01:00 GMThttp://www.cppblog.com/tangxinfa/articles/object_meet_thread.htmlhttp://www.cppblog.com/tangxinfa/comments/137532.htmlhttp://www.cppblog.com/tangxinfa/articles/object_meet_thread.html#Feedback0http://www.cppblog.com/tangxinfa/comments/commentRss/137532.htmlhttp://www.cppblog.com/tangxinfa/services/trackbacks/137532.html　　常见的方案：
　　０）强引用
　　１）智能指针
　　２）弱引用
　　３）强弱组合引用
（待续）

唐新发 2010-12-27 01:01 发表评论

]]>为什么要用分布式版本控制系统http://www.cppblog.com/tangxinfa/articles/92792.html唐新发唐新发Mon, 10 Aug 2009 03:07:00 GMThttp://www.cppblog.com/tangxinfa/articles/92792.htmlhttp://www.cppblog.com/tangxinfa/comments/92792.htmlhttp://www.cppblog.com/tangxinfa/articles/92792.html#Feedback0http://www.cppblog.com/tangxinfa/comments/commentRss/92792.htmlhttp://www.cppblog.com/tangxinfa/services/trackbacks/92792.html　　首先来看看用subversion过程中遇到的一些闹心的事情：
　　一，我做为管理员（项目由我创建，我要负责提交的代码的检阅确保代码随时能够编译并进行新版本发布）时遇到的问题：
　　　*某个组员对subversion的使用一知并解，比较粗心，他会：提交一些不必要的文件内容（编辑器产生的临时文件、备份文件，对发布时所需的程序配置文件的一些本地修改，甚至用于成员间的临时文件传送），他会不写提交时的注释或很随便。做为一个开发组你无法阻止他们提交，即使技术上可行你也不可以或者说是无权这么做，相对于我这个管理员所需付出的额外维护精力，对开发组成员和积极性的伤害才是致命的。结果显而异见，做为管理员的我基本上每天都要修复提交的代码中的问题，并通知各个成员立即更新工作拷贝，并对犯事者进行又一次教育，svn不是这么用的。终于有一天svn仓库所占用的空间占光了分区空间，于是重建仓库，项目的历史没有了，程序开发中记录的一些真知灼见和经验教训也找不到了，程序旧版本的bug也因为检不出当时的源代码而未了未之。
　　二，我做为组员时遇到的问题：
　　版本控制就像是一付后悔药，一个月光宝盒，可以撤消/重做是多么惬意啊，还记得洗完澡后将干净衣服扔进桶里时的抓狂吗，反正这种情形下我是到处在找CTRL+Z键。毫无顾虑地使用版本控制让开发的日子更轻松，也更自信，可以大胆地尝试各种思路，不用担心自已偶然间天才的代码或者是想法在某个烦燥的中午被删掉。但是subversion也不是能够想用就用的，为什么呢：
　　通常来说，提交的东西一定是好的、完整的，它不会让整个项目处于一种不可用的状态（听说在某些公司，如果你捅了这个篓子，晚上你就得搬个席子半夜在机房里守着项目自动编译过程，直到遇到下一个像你一样的倒霉蛋），问题是在你搞定这个好的、完整的提交部分的过程中，你得不到subversion的庇佑，你的月光宝盒被紫霞给抢走了，你得小心地按delete键，你不敢删除代码中不洁的代码，如果你像我一样用惯了svn的话，在这段时间里你一定没有安全感。我真的需要自已的私有的版本控制，怎么办？svn给的标准答案是：１，创建分枝，可以解决问题，问题是必须提交代码到中心服务器，会占用服务器的资源（主要是硬盘空间），网络不可达时就不管用了，这很常见，如：公司比较小，svn仓库搞不好就在头儿的笔记本上，万一头儿不在就用不了了；你在家里做开发也可能暂时用不了；另外，你的私有版本可能有点不能见光，比如：你仅仅是想尝试一下新技术，你想搞个个人版，你不服气原有的设计想弄出个加强版过几天放出后一鸣惊人。２，在本地上建个仓库，导入原项目的内容，不过问题就更严重了，和原项目同步不容易。
　　而分布式版本控制系统则从根本上解决了上述问题，估且认为它和分枝是在本地上的Subversion吧，你可以方便地从源分枝创建自已的分枝，它有单独的历史，不依赖于某个中心服务器，在必要时你可以从某个外部分枝上更新内容，提交自已对源分枝的修改，发布自已的分枝以便别人在此基础上创建新的分枝。是的，这个时候为了让读者能够打心眼里认同我对分布式版本控制系统的推崇，我得恶补一下分布式版本控制系统的知识，至少得装出有过那么几年分布式版本控制系统的使用经验，最后来句“其实我也是经过了数十年的努力才取得了今天的成就”做为文章的结尾，闲话说多了，总结一下：Subversion解决了CVS的一些问题，DCVS解决了Subversion的一些问题，这只是版本控制的又一次发展，况且只要你愿意，DCVS也可以传统的集中式服务器模式运行，有理由相信DCVS会是对Subversion的一次完胜。
最后，做为一名写下本文章的DCVS菜鸟，当然免不了要推荐一些阅读资料：
分布式版本控制系统入门：http://www.ibm.com/developerworks/cn/aix/library/au-dist_ver_control/

唐新发 2009-08-10 11:07 发表评论

]]>小话opensource licensehttp://www.cppblog.com/tangxinfa/articles/89862.html唐新发唐新发Sun, 12 Jul 2009 06:46:00 GMThttp://www.cppblog.com/tangxinfa/articles/89862.htmlhttp://www.cppblog.com/tangxinfa/comments/89862.htmlhttp://www.cppblog.com/tangxinfa/articles/89862.html#Feedback0http://www.cppblog.com/tangxinfa/comments/commentRss/89862.htmlhttp://www.cppblog.com/tangxinfa/services/trackbacks/89862.html　　BSD　　－　没有限制。
　　LGPL　－　在物理上保持独立(即不可以静态链接）。
　　GPL　　－　程序中用了GPL的东西，你的程序其它相关部分也要GPL。

　　其开源的共同点是：
　　尊重它的著作权及其完整性，你修改了它的话必须注明并指明它的原始版本所在，同时你所做的修改应该（不强制）回馈开源社区。
　　使用以上开源代码的程序只是自已（包括公司）用而不分发给第三方（用户）使用的话，可以不开源，一旦分发：
　　GPL要求你也必须按GPL协议发布你的产品，强迫你也GPL开源（GPL的传染性），另两者就没有这种要求了。

　　因此做为一个程序员，对于使用BSD协议的东西可以毫无顾忌地使用；
　　对于使用LGPL协议的东西则可放心使用，发布时多带几个dll不会死人。
　　而对于GPL，就要想一想了，这个协议比较复杂，有很多例外，就像税务制度，你可以缴税、逃税、避税，商用前好好研究一下它，
　　另外感觉上使用GPL协议的东西精品非常多，看源码的首选，可能是因为一些商用项目付lincense费的缘故，资金充足，
　　管理文档等比较正规，便宜没好货这句话还是有道理的。
　　

唐新发 2009-07-12 14:46 发表评论

]]>利用uml改进开发过程-（三）UMLhttp://www.cppblog.com/tangxinfa/articles/41130.html唐新发唐新发Mon, 14 Jan 2008 07:49:00 GMThttp://www.cppblog.com/tangxinfa/articles/41130.htmlhttp://www.cppblog.com/tangxinfa/comments/41130.htmlhttp://www.cppblog.com/tangxinfa/articles/41130.html#Feedback0http://www.cppblog.com/tangxinfa/comments/commentRss/41130.htmlhttp://www.cppblog.com/tangxinfa/services/trackbacks/41130.html得学点UML才行了，目前打算弄懂类图、顺序图和用例图就行了，不管怎么样边用边学。

唐新发 2008-01-14 15:49 发表评论

]]>利用uml改进开发过程-（二）工具的选择http://www.cppblog.com/tangxinfa/articles/41129.html唐新发唐新发Mon, 14 Jan 2008 07:44:00 GMThttp://www.cppblog.com/tangxinfa/articles/41129.htmlhttp://www.cppblog.com/tangxinfa/comments/41129.htmlhttp://www.cppblog.com/tangxinfa/articles/41129.html#Feedback0http://www.cppblog.com/tangxinfa/comments/commentRss/41129.htmlhttp://www.cppblog.com/tangxinfa/services/trackbacks/41129.html　　1，StarUML
2，Umbrello
3，BOUML
上面都是不收费，开源的，其中StarUML跑在windows下，Umbrello跑在linux下，BOUML跨平台，看相关评论，StarUML好用易用，Umbrello功能强大，BOUML看起来比较扑实，相关评论也还说它不错，并且因为个人会在windows及linux上进行开发，所以暂选BOUML。

唐新发 2008-01-14 15:44 发表评论

]]>代码命名风格的选择http://www.cppblog.com/tangxinfa/articles/41114.html唐新发唐新发Mon, 14 Jan 2008 03:28:00 GMThttp://www.cppblog.com/tangxinfa/articles/41114.htmlhttp://www.cppblog.com/tangxinfa/comments/41114.htmlhttp://www.cppblog.com/tangxinfa/articles/41114.html#Feedback0http://www.cppblog.com/tangxinfa/comments/commentRss/41114.htmlhttp://www.cppblog.com/tangxinfa/services/trackbacks/41114.html１，MFC风格
    class CClassName
    {
        public:
             void DoSomething();
        private:
             CString m_strName;
     };
2，linux风格
　　class class_name
    {
         public:
            void do_something();
         private:
            std::string name_;
    };
　　class class_name_t
    {
         public:
            void do_something();
         private:
            std::string name_;
    };
3，Java风格
    class ClassName
    {
         public:
              void doSomething();
         private:
              std::string name;
    };
这里关注的差异部分是：1，名称中是否使用类型前缀或后缀；2，怎样使用大小写。
　　风格1（MFC风格、匈牙利命名风格）带来的问题是：导致命名复杂化（m_lpszName？），每次写个变量名都要经过n道工序（中文->英文->类型提取->最后的名称），一个类型变化时（如：要用结构代替内置类型，typedef）是不是得发个重大更新重大升级啊，要不然怎么对得起程序中大范围的名称替换，要是用svn的版本比对一定可以看到状观的景像。
　　风格2（linux风格）问题是：带后缀总是显得不美观（看看stl的原代码），用户成了命名规范的二等公民（看看boost库），通用直观的好名字都认库占了。其实c++中成员变量带后缀是好理解的，它可以避免和参数名称冲突，如下所示：
　　class class_name
    {
       public:
           class_name(std::string name)
             :name_(name)
          {

         }
          void set_name(std::string name)
         {
             name_ = name;
          }
       private:
           std::string name_;
    };
    //当成员name_命名为name时，在set_name函数中name = name将是参数的自赋值。
成员变量带后缀可接受是因为我们认为没有人会引用它（看到它），但当序列化时，它的名称会被用户见到，另外成员变量也可能是公有的，如一个C结构带了一个辅助使用的构造函数时。那么参数名称加下划线怎么样？我这么干过，不过更不好，因为它会污染你IDE的智能提示以及用doxygen生成的文档。
类型名后加_t也是好理解的，除了表明这是一个类型外，可以避免与该类型的实例名称相冲突，有人会说实例名称用简写不就行了吗，问题是如果我的类名称已经足够简单了呢？加了_t会对用户代码的整洁性产生不必要的干扰。
　　风格3（Java风格）的问题：在c++中无法避免成员变量名称与参数名称冲突，java（或python）不存在这个问题是因为java中成员函数中引用成员变量时总是带个前缀this。但其实c++也可以这么干，只是出于习惯我们总是省略this前缀，这样的话就不存在什么问题了。
　　就我个人来说，目前倾向于采用java命名风格，原因是它最大程度地避免了命名冲突而又不会对代码带来太大的冲击，这或是就是为什么很多语言的命名风格会向它靠拢。

唐新发 2008-01-14 11:28 发表评论

]]>利用uml改进开发过程-（一）问题http://www.cppblog.com/tangxinfa/articles/41108.html唐新发唐新发Mon, 14 Jan 2008 01:46:00 GMThttp://www.cppblog.com/tangxinfa/articles/41108.htmlhttp://www.cppblog.com/tangxinfa/comments/41108.htmlhttp://www.cppblog.com/tangxinfa/articles/41108.html#Feedback0http://www.cppblog.com/tangxinfa/comments/commentRss/41108.htmlhttp://www.cppblog.com/tangxinfa/services/trackbacks/41108.html　　我开发方式中的问题即使别人不提我也觉察到了：需求分析不足，过早进入实现阶段，习惯性地陷入细节的泥潭不可自拔。
　　当做一件事情有了不良习惯时，改正的办法不外乎不断地重复正确的方式，就像纠正你英语言中某个单词的发音错误，通过不断地朗读正确发音消除掉原有发音的记忆。不过这个方法对于解决我目前的问题似乎毫无帮助，因为我还不知道正确的发音是什么。
　　或许改变开发习惯会间接地解决上面的问题，在打开熟悉的IDE写代码之前用uml之类的高层语言打好结构、将关键的控制流程画出来，直到意识到可以将思路翻译成代码时才写代码。这样至少可以避免陷入细节的泥潭，因为一直以来当我发现局部的一个显而易见的解决方案时，总是忍不住立即动手，结果是捡了芝麻丢了西瓜。

唐新发 2008-01-14 09:46 发表评论

]]>c++开源开发库、开发工具个人选择列表http://www.cppblog.com/tangxinfa/articles/40341.html唐新发唐新发Thu, 03 Jan 2008 09:13:00 GMThttp://www.cppblog.com/tangxinfa/articles/40341.htmlhttp://www.cppblog.com/tangxinfa/comments/40341.htmlhttp://www.cppblog.com/tangxinfa/articles/40341.html#Feedback0http://www.cppblog.com/tangxinfa/comments/commentRss/40341.htmlhttp://www.cppblog.com/tangxinfa/services/trackbacks/40341.html　　1，emacs：
         不经细心配置的话用起来有点变态；通过细心配置、适当安装所需插件后，用起来很顺手，特别是写代
　　　码时有一种健步如飞的感觉，全键盘操作。对于完成工作似乎无所不能，有人说它就是操作系统不是开
　　　玩笑的。
　　　缺点是需要大量的配置工作，各种插件的集成度不是很高。
　　2， codeblocks：
　　　类似vc，devcpp杀手，建议下载每日构建版本，开发社区很活跃，不断更新中。
　　　特点是：跨平台，可以选择使用几乎所有类型c++编译器，界面基于wxwidgets库，包含常用的插件，对
　　　wxWidgets程序开发支持力度大。可视化的调试器，代码完成功能。
　　　可以认为是一个粗糙版的vc。
　　3，版本控制系统：subversion
　　4，登录工具：PieTTY
　　　支持utf-8，可方便地通过拖动文件进行ftp上传。
    5，错误追踪系统
    Mantis

二、库：
　　1，配置参数读取库：GetPot
　　　使用简单直观，就一个头文件。
　　2，xml解析类：Markup
　　　超轻量级，使用简单直观，就一个头文件和一个实现文件。用于解析简单的xml文件（如：xml配置文
　　　件，序列化）。用过之后忍不住感叹，原来解析xml也可以这么容易，不过用于商业开发是要收费的，
　　　有空我再找一个不收费的。
　　3，正则表达式库：boost::regex
　　　准标准库，使用简单直观，大胆地用吧。
　　4，界面开发：Qt
　　　c++库中少有的可称为艺术级的东西。
      5，日志库
          log4cxx log4j的c++版本，简单易用，配置能力强。
　　　log4j还有其它语言的版本（如：c, python, php, .net等），值得学习。

三、看好的库：
　　1，网络开发：asio
　　2，多线程开发：boost::thread，threadpool
                   ZThreads　对跨平台的多线程开发进行了完整的封装，易用．
    3，序列化：boost::serialization

唐新发 2008-01-03 17:13 发表评论

]]>