你好，请 登录 或 注册 · 九点指南

Fox的blog文章

　　When :  2008.8.8.20:00:00
　　Where : National Stadium, Beijing, China.
　　Who :    One World.
　　What :   One Dream.
　　All right, it is just a D-R-E-A-M...
　　____________________________
　　但是，我一定会看，从电视上。
　　就像看火炬一定要从电视上才和谐好些，开幕式也是。
　　网上猜测李宁......    (查看原文)

　　0. Introduction
　　接触设计模式有两年时间了，但一直没有系统整理过，为了不至于让自己的思维被繁琐的工作一点点禁锢，还是决定总结一下，为了能够真正做到有所收获，整个系列会按照GoF的Design Patterns: Elements of Reusable Object-Oriented Software的行文思路，但不会照本宣科就是了，Wikipedia上关于23种设计模式的介绍非常全面，CSDN上也可以下载中/英文电子档，因此很多套话、类图一概省去。
　　最早接触设计模式的时候，难免被各种模式的联系和区别所困扰，从教科书的分析可以得到模式之间形式上的不同。但这样对于领会设计模式意义不大，因为我们掌握模式的目的是为了融会贯通，灵活运用，以对开发有所帮助。
　　稍微成规模的OO程序，会有大量对象，其中很多实体对象之间存在着父子、兄弟关系，对象的创建提升为一种模式。其好处在于设计模式本身所宣称的reusable，这就像堆积木盖房子......    (查看原文)

　　一、Big-endian & Little-endian
　　还是Wikipedia好啊！可惜中文的国内看不了，愚昧啊！实在觉得中文有点难懂，看看日本语版本吧:D！
　　关于端（endianness）的介绍，Wikipedia上比较全了：http://en.wikipedia.org/wiki/Endianness
　　关于网络字节序（network byte order）和主机字节序（host byte order），说来挺无关紧要的一点东西，因为每次总是忘掉，所以每次都要好奇的看看大端（big-endian）和小端（little-endian）。
　　给定unsigned long型整数十六进制形式：0x0A0B0C0D，其big-endian和little-endian形式分别为：
......    (查看原文)

　　原文地址：Google C++ Style Guide
　　 * 规则之例外
　　前面说明的编码习惯基本是强制性的，但所有优秀的规则都允许例外。
　　1. 现有不统一代码（Existing Non-conformant Code）
　　对于现有不符合既定编程风格的代码可以网开一面。
　　当你修改使用其他风格的代码时，为了与代码原有风格保持一致可以不使用本指南约定。如果不放心可以与代码原作者或现在的负责人员商讨，记住，一致性包括原有的一致性。
　　1. Wind......    (查看原文)

　　原文地址：Google C++ Style Guide
　　 * 格式
　　代码风格和格式确实比较随意，但一个项目中所有人遵循同一风格是非常容易的，作为个人未必同意下述格式规则的每一处，但整个项目服从统一的编程风格是很重要的，这样做才能让所有人在阅读和理解代码时更加容易。
　　1. 行长度（Line Length）
　　每一行代码字符数不超过80。
　　我们也认识到这条规则是存有争议的，但如此多的代码都遵照这一规则，我们感觉一致性更重要。
　　优点：提倡该原则的人认为强迫他们调整编辑器窗口大小很野蛮。很多人同时并排开几个窗口，根本没有多余空间拓宽某个窗口，人们将窗口最大尺寸加以限定......    (查看原文)

　　原文地址：Google C++ Style Guide
　　 * 注释
　　注释虽然写起来很痛苦，但对保证代码可读性至为重要，下面的规则描述了应该注释什么、注释在哪儿。当然也要记住，注释的确很重要，但最好的代码本身就是文档（self-documenting），类型和变量命名意义明确要比通过注释解释模糊的命名好得多。
　　注释是为别人（下一个需要理解你的代码的人）而写的，认真点吧，那下一个人可能就是你！
　　1. 注释风格（Comment Style）
　　使用//或/* */，统一就好......    (查看原文)

　　原文地址：Google C++ Style Guide
　　 * 命名约定
　　最重要的一致性规则是命名管理，命名风格直接可以直接确定命名实体是：类型、变量、函数、常量、宏等等，无需查找实体声明，我们大脑中的模式匹配引擎依赖于这些命名规则。
　　命名规则具有一定随意性，但相比按个人喜好命名，一致性更重要，所以不管你怎么想，规则总归是规则。
　　1. 通用命名规则（General Naming Rules）
　　函数命名、变量命名、文件命名应具有描述性，不要过度缩写......    (查看原文)

　　原文地址：Google C++ Style Guide
　　 * Google特有的风情
　　Google有很多自己实现的使C++代码更加健壮的技巧、功能，以及有异于别处的C++的使用方式。
　　1. 智能指针（Smart Pointers）
　　如果确实需要使用智能指针的话，scoped_ptr完全可以胜任。在非常特殊的情况下，例如对STL容器中对象，你应该只使用std::tr1::shared_ptr，任何情况下都不要使用auto_ptr。
　　“智能”指针看上去是指针，其实是附加了语义的对象。以scoped_ptr为例，scoped_ptr被销毁时，删除了它......    (查看原文)

　　一个好的日志系统，除了可以记录尽可能多的必要信息，方便trace bugs、提供data analysis source这些基本功能之外，其他的貌似不必太在意。但真正当bugs冒出来的时候，要命的是既没有dump，也没有有价值的日志，更要命的是日志居然已经记录了那么多，居然让你查了半天，居然都是没有价值的！
　　悲剧啊！
　　日志需要记录的信息大概分为两类：
　　1) 系统运行情况：启动、加载、读写、关闭、异常；
　　2) 用户使用情况：进入、操作、离开、异常。
　　我可以想到的关于日志系统的要求大致以下几......    (查看原文)

　　这一篇主要提到的是类，Lippman在《Inside The C++ Object Model》第二章中对构造函数作了详尽说明，本文中提到的几个单词基本仿该书中译本侯捷先生的翻译：
　　explicit：明确的
　　implicit：隐含的
　　trivial：没有意义的
　　non-trivial：有意义的
　　 
　　原文地址：Google C++ Style Guide
　　 * 类
　　类是C++中基本的代码单元，自然被广泛使用。本节列举了在写一个类时要......    (查看原文)

　　原文地址：Google C++ Style Guide
　　 * 作用域
　　1. 命名空间（Namespaces）
　　在.cc文件中，提倡使用不具名的命名空间（unnamed namespaces，译者注：不具名的命名空间就像不具名的类一样，似乎被介绍的很少:-(）。使用具名命名空间时，其名称可基于项目或路径名称，不要使用using指示符。
　　定义：命名空间将全局作用域细分为不同的、具名的作用域，可有效防止全局作用域的命名冲突。
　　优点：命名空间提供了（可嵌套）命名轴线（name ax......    (查看原文)

　　原文地址：Google C++ Style Guide
　　 * 背景
　　Google的开源项目大多使用C++开发。每一个C++程序员也都知道，C++具有很多强大的语言特性，但这种强大不可避免的导致它的复杂，这种复杂会使得代码更易于出现bug、难于阅读和维护。
　　本指南的目的是通过详细阐述在C++编码时要怎样写、不要怎样写来规避其复杂性。这些规则可在允许代码有效使用C++语言特性的同时使其易于管理。
　　风格，也被视为可读性，主要指称管理C++代码的习惯。使用术语风格有点用词不当，因为这些习惯远不止源代码文件格式这......    (查看原文)

　　sudo使普通用户具有root用户的权限，减少root登录，还有日志记录……，主要是为了安全，暂时没有体会@.@。
　　1. sudo
　　1) 安装sudo：apt-get install sudo
　　2) 添加sudo：
　　  a. chmod +w /etc/sudoers，允许写
　　  b. vim /etc/sudoers
　　  c. 添加：newsudo   ALL=(ALL) NOPASSWD: ALL
　　  d. chmod 0440 /etc/sudoers，更改sudoers文件权限，使之可......    (查看原文)

　　题记：哥（我）基本是Linux盲，刚开始接触，有点像对females的亢奋感。
　　心血来潮，再次装了VMware，两个机子分别装了简体中文和英文的Debian，只有base-system。
　　前前后后装了不下五、六遍，算是对Debian的安装过程熟悉一下，有点弱智:D。装好系统之后，只装了Vim：apt-get install vim
　　Vim是一个很好玩的东西，自从我在06年结束了TC 2.0的时代之后，已经很久没有在纯文本模式下做过任何操作了（偶尔的装过Debian，用过Vim都不算吧:D）。虽然我一向声称更喜欢命令操作而不是鼠标移动，但那毕竟是在用了六、七年的Windows下（虽然也不长:(），看来多少是有点叶公好......    (查看原文)

　　写的太杂，实在没法写题目，就用这一周的签名吧，很合现在的心境。
　　Kevin眼中的我，大概是个重视理论算法胜过编程实践的人，而我的算法和理论基础尚差的出奇（可能这就是知耻而后勇吧:D），可见我的编程实践又会多么的差了。Bugs更是对我整日沉浸于这些不着边际的“空中楼阁”颇有微词，甚至嗤之以鼻。今日若不是要把自己前段时间的豆腐渣粉饰一番，我依然不愿去考虑多线程的具体实现，或者说不是不愿，是不敢，总有一种临深履薄之感。
　　纵然如此，为了更好的完成工作，我还是拉来Kevin，劳他为我讲解一下多线程，可能是因为我从未仔细看过boost等C++开源库的原因吧，我对于结构封装本身并没有多......    (查看原文)

　　以前在学习非数值算法的时候，曾经了解过动态规划算法（Dynamic programming），以下是对Wikipedia上动态规划的翻译，图也是Wikipedia上的，仓促行文，不到之处，请方家指正。
　　这篇文章的术语实在是太多了，所以我在文中加入了少量注释，一律以粗斜体注明。
　　本文的不足之处将随时修正，MIT的《Introduction to Algorithms》第15章是专门讲动态规划的。
　　_____________________________________________________________
　　动态规划
　　在数学与计算机科学领域，动态规划用......    (查看原文)

　　Author: Fox
　　首先声明：本人没有解决掉这个问题。
　　相比第一道让CPU占用率曲线听你指挥对Windows系统中CPU占有率概念的考察和对API的使用，以及第二道中国象棋将帅问题对抽象建模的考察。这道题目才算是一道算法题吧？之前那两道尤其是中国象棋将帅问题总有点脑筋急转弯的味道。
　　题目：星期五的晚上，一帮同事在希格玛大厦附近的“硬盘酒吧”多喝了几杯。程序员多喝了几杯之后谈什么呢？自然是算法问题。有个同事说：
　　“我以前在餐馆打工，顾客经常点非常多的烙饼。店里的饼大小不......    (查看原文)

　　Author: Fox
　　晚上没有加班，打游戏打到9点过，后面就又看了一道《编程之美》的题目《中国象棋将帅问题》。
　　题目：下过中国象棋的朋友都知道，双方的“将”和“帅”相隔遥远，并且它们不能照面。在象棋残局中，许多高手能利用这一规则走出精妙的杀招。假设棋盘上只有“将”和“帅”二子（如图1-3所示）（为了下面叙述方便，我们约定用A表示“将”，B表示“帅”）：
　　A、B二子被限制在己方3×3的格子里运动。例如,在如上的表格里，A被正方形{d10, f10, d8, f8}包围，而B被正方形{d3, f3, d1, f1}包围。每一步，A、B分别可以横向或纵向移动一格，......    (查看原文)

　　Author: Fox
　　前两天在买《计算机程序设计艺术》中文版的时候，偶然发现《编程之美》这本书，当时翻了一下，看到“让CPU占用率曲线听你指挥”这样的题目确实让人为之一动。写一段代码，可以让CPU占有率曲线画出平滑的正弦曲线，有点意思:-)。
　　当然，最后没有买这本书，虽然我可以肯定这是本好书。
　　我从CSDN读书上找到几节，闲来读一读。今天来讨论一下《让CPU占用率曲线听你指挥》。
　　题目：写一个程序，让用户来决定Windows任务管理器（Task Manager）的CPU占用率。程序越精简越好......    (查看原文)

　　Author: Fox
　　本文写给满足以下条件的你（前面4点对应只读的你，后面4点对应只写的你)：
　　1) 经常阅读别人的Blog，所谓经常，平均每天阅读量在100篇左右；
　　2) 不希望花费大量时间在输入网址、鼠标点击和滚动上；
　　3) 有固定的阅读习惯，指专注于某一领域、某些特定的Blog；
　　4) 尚未使用或刚使用Google Reader并愿意使用Google Reader；
　　5) 经常更新自己的Blog，所谓经常，平均......    (查看原文)