C++博客-IT菜鸟-随笔分类-读书http://www.cppblog.com/micwu/category/20334.html启航zh-cnSat, 09 Feb 2013 07:47:38 GMTSat, 09 Feb 2013 07:47:38 GMT60[转]一定有更容易的方法 - 戈尔迪斯结http://www.cppblog.com/micwu/archive/2013/02/05/197733.htmlmicwumicwuTue, 05 Feb 2013 04:22:00 GMThttp://www.cppblog.com/micwu/archive/2013/02/05/197733.htmlhttp://www.cppblog.com/micwu/comments/197733.htmlhttp://www.cppblog.com/micwu/archive/2013/02/05/197733.html#Feedback0http://www.cppblog.com/micwu/comments/commentRss/197733.htmlhttp://www.cppblog.com/micwu/services/trackbacks/197733.html   有时你会发现, 自己在处理的问题似乎比你以为的要难得多.感觉上好像是你走错了路--一定有比这更更容易的方法!
或许现在你已落在了进度边后面, 甚或失去了让系统工作起来的信心, 因为这个特定的问题是"不可能解决的".
   这正是你退回一步, 问问自己以下问题的时候:
   1. 有更容易的方法吗?
   2. 你是在设法解决真正的问题, 还是被外围的技术问题转移了注意力?
   3. 这件事情为什么是一个问题?
   4. 是什么使它如此难以解决?
   5. 它必须以这种方式完成吗?
   6. 它真的必须完成吗?
   很多时候 当你设法回答这些问题时,你会让自己惊讶的发现,很多时候,对需求的重新诠释能让整个问题全都消失-就像是戈尔迪斯结.

转自: 程序员修炼之道-解开不可能解开的迷题
  



micwu 2013-02-05 12:22 发表评论
]]>断言式编程Asserthttp://www.cppblog.com/micwu/archive/2013/01/21/197439.htmlmicwumicwuMon, 21 Jan 2013 09:08:00 GMThttp://www.cppblog.com/micwu/archive/2013/01/21/197439.htmlhttp://www.cppblog.com/micwu/comments/197439.htmlhttp://www.cppblog.com/micwu/archive/2013/01/21/197439.html#Feedback1http://www.cppblog.com/micwu/comments/commentRss/197439.htmlhttp://www.cppblog.com/micwu/services/trackbacks/197439.htmlIf it can't happen, use assertions to ensure taht it won't!

1. "这决不会发生...", 我们不要这样自我欺骗, 特别是在编码时.
2. 传给断言的条件不应该有副作用.
3. 不要用断言代替真正的错误处理.
4. 如果你需要释放资源, 就让断言失败生成异常, longjump到某个退出点, 或是调用错误处理器.
5. 让断言开着. 即使你确实有性能问题, 也只关闭那些真的有很大影响的断言.
6. "海森堡虫子", 调试改变了被调试系统的行为.  ASSERT(null != iter.nextElement());

下面是一些"不可能的事":
1. 一个月少于28天
2. stat(".",&sb) == -1
3. 在C++里: a=2; b=3;if (a+b!=5) exit(1);
4. 内角和不等于180的三角形
5. 没有60秒的一分钟
6. 在java 中: (a+1)<=a

PS: 刚开始看到, 真的很多都觉得是不可能的~~真当是知识面不够广~
     "这决不会发生...", 我们不要这样自我欺骗, 特别是在编码时. 

Michael.


   

micwu 2013-01-21 17:08 发表评论
]]>