1.这不是Vim操作入门,其没有介绍Vim的基本知识,而是集中于编辑器的使用方法,这些方法也可在其它编辑器中使用。
2.要充分认识到编辑器的作用,既不能漠视编辑器的功能而用“蛮力”来完成工作,但也不要面面俱到地学习编辑器所有功能。对于Vim和Emacs这样的骨灰级编辑器来说,完全学习是"Mission Impossible"。
3.建立一个良好的习惯很重要,但更重要地发现问题,并能用智慧地方式进行解决的勇气与耐心。我们往往会有很多好的提高效率的想法,但在工作或学习的压力下,常不能坚守,而白白失去提升的机会。所以本文中非常强调发现的过程,即发现问题与发现解决方案。
4.方案不要一步完美,这样的方案往往不存在(或在我们头顶的三万公尺上)。要有踏出第一步的勇气,先建立一个力所能及但又有所提高的方案,这样即能增强信心,又为进一步完善提供基础。在不断地完善中学习编辑器,用好编辑器。
5.查找与修正是编辑中最常用的功能。用好编辑器的试金石是检查自己是否能自如地利用编辑器功能来快速查找定位与修正。而正则表达式的知识是非常关键的。在Windows下成长的一代似乎没有Unix/Linux人们与生俱来的模式观念,而模式在正则表达式中是最基本的。要努力锻炼这样的思维,虽然起步比较吃力,但终身收益。
6.编辑器好似兵器,而运用编辑器的方法则是每个人的内功。如果内功不强,即是神兵利器在手也发挥不了作用;而如果内功强劲,那么简单的编辑器也能发挥大作用。努力改变自己的思维,发现、创新、提升、再发现是每日必修的内功。
2007年9月2日星期日
2007年8月28日星期二
GNU Make学习(1)
1.Make是一个“古董级”的工具,其像橡树年轮,记录了近三十年计算机科学进步的痕迹。或许在学习Make中你会如考古般发现新奇的过往智慧,但更多的时候你将迷失于旧与新的迷雾之中,这也正是Make对于Windows平台下成长的一代程序员来说难懂的原因。但在每个IDE的F5或F9的背后,都能找到Make的身影。要进阶编程功力,当从了解Make开始。
2.Make是一个工具,它完成两个任务:一是建立一个多个文件的关系图,其用来描述文件间的依赖关系;二是检测文件的新旧,并按照关系图来进行命令执行以完成局部或整体的更新工作。所以在Make中存在两类语言,一为建立关系图,一为进行文本处理。
3.在学习Make前,应了解本机上的Make环境。在Windows系统中,由于安装BCB、VC2005等都会自带Make工具。而本文所用的Make是GNUMake 3.8,在Cygwin和DevCPP中都有。不同的Make对应不同的语法,故在BCB中由bpr文件导出的Make文件不能在GNUMake下编译。我就是犯了一次这样的错误。
4.Make中最简单的方式就是通过显性说明来建立关系图。对于小项目这还是很不错的方案,但对于大项目则不行。原因有三:一是重复声明过多,代码冗余,不利于维护;二是声明过细,移植性差;但最重要的是往往文件关系复杂到无法通过人脑来进行关系声明,这就必须用一种计算机辅助方式来进行关系推衍,这在Make中称为“Rule(规则)“。
5.Makefile难于阅读与调试的原因在于其自上而下的书写格式与”(关系图)自底而顶“的执行顺序往往是不一致的,也是人难于掌握的。所以Makefile采用Target(目标)与Rule(规则)这两种机制来分割问题。要注意的是这两种机制是双刃剑,其使用不当往往会造成Makefile的更晦涩难懂。
6.Phony Target用于结构化Makefile,将问题分割,并可优化用户界面。而其中的Empty Target则用来控制命令执行范围,避免非更新区域的反复执行。而对于大项目,制定一个Help Phony是常用技巧。但Phony Target也会破坏一些自然逻辑结构,从而给阅读带来一些障碍。要适当应用Phony Target,不要采用特殊技巧,在欺骗Make工具的同时也会欺骗阅读者,可能包含未来的你。
7.Rule则屏蔽了关系图的细节,让计算机来自动铺砌关键帧间的空隙。所以良好的Rule即能提高阅读性,又能提高执行效率。
8.Make诞生于Unix,其带有很强的*nix家族的色彩。比如其支持的通配符(WildCards)与Bourne Shell相同,包括~,*,?,[...]和[^...]。其有着古旧的键缩进惯例。
9.在Makefile中要注意变量展开、宏展开和函数展开的顺序。要充分理解Automatic Variables(自动变量)的作用;要用VPATH来指定被搜索文件的目录;要善于利用正则表达式来处理文本变量问题,特别是在gcc -M问题上。要小心地分割项目,善于利用eval函数来达到特定要求。
10.注意递归变量的声明与使用,这些变量与C中指针相似。
11.变量用$()来取值,摈弃过时的${}方式。
12.注意Command的Comment(前面有)与Makefile的Comment间的差异
13.正是有了简洁而强有力的函数支持,GnuMake具有很强的文本处理能力;而定义良好的自定义函数或宏,可提高Makefile的通用性和移植性。
14.inline函数是最常见的形式。
15.命令修改符 @-消音;- 消噪音(埋头工作) + 无论如何都要工作(即便是--just print模式)
2.Make是一个工具,它完成两个任务:一是建立一个多个文件的关系图,其用来描述文件间的依赖关系;二是检测文件的新旧,并按照关系图来进行命令执行以完成局部或整体的更新工作。所以在Make中存在两类语言,一为建立关系图,一为进行文本处理。
3.在学习Make前,应了解本机上的Make环境。在Windows系统中,由于安装BCB、VC2005等都会自带Make工具。而本文所用的Make是GNUMake 3.8,在Cygwin和DevCPP中都有。不同的Make对应不同的语法,故在BCB中由bpr文件导出的Make文件不能在GNUMake下编译。我就是犯了一次这样的错误。
4.Make中最简单的方式就是通过显性说明来建立关系图。对于小项目这还是很不错的方案,但对于大项目则不行。原因有三:一是重复声明过多,代码冗余,不利于维护;二是声明过细,移植性差;但最重要的是往往文件关系复杂到无法通过人脑来进行关系声明,这就必须用一种计算机辅助方式来进行关系推衍,这在Make中称为“Rule(规则)“。
5.Makefile难于阅读与调试的原因在于其自上而下的书写格式与”(关系图)自底而顶“的执行顺序往往是不一致的,也是人难于掌握的。所以Makefile采用Target(目标)与Rule(规则)这两种机制来分割问题。要注意的是这两种机制是双刃剑,其使用不当往往会造成Makefile的更晦涩难懂。
6.Phony Target用于结构化Makefile,将问题分割,并可优化用户界面。而其中的Empty Target则用来控制命令执行范围,避免非更新区域的反复执行。而对于大项目,制定一个Help Phony是常用技巧。但Phony Target也会破坏一些自然逻辑结构,从而给阅读带来一些障碍。要适当应用Phony Target,不要采用特殊技巧,在欺骗Make工具的同时也会欺骗阅读者,可能包含未来的你。
7.Rule则屏蔽了关系图的细节,让计算机来自动铺砌关键帧间的空隙。所以良好的Rule即能提高阅读性,又能提高执行效率。
8.Make诞生于Unix,其带有很强的*nix家族的色彩。比如其支持的通配符(WildCards)与Bourne Shell相同,包括~,*,?,[...]和[^...]。其有着古旧的
9.在Makefile中要注意变量展开、宏展开和函数展开的顺序。要充分理解Automatic Variables(自动变量)的作用;要用VPATH来指定被搜索文件的目录;要善于利用正则表达式来处理文本变量问题,特别是在gcc -M问题上。要小心地分割项目,善于利用eval函数来达到特定要求。
10.注意递归变量的声明与使用,这些变量与C中指针相似。
11.变量用$()来取值,摈弃过时的${}方式。
12.注意Command的Comment(前面有
13.正是有了简洁而强有力的函数支持,GnuMake具有很强的文本处理能力;而定义良好的自定义函数或宏,可提高Makefile的通用性和移植性。
14.inline函数是最常见的形式。
15.命令修改符 @-消音;- 消噪音(埋头工作) + 无论如何都要工作(即便是--just print模式)
2007年8月23日星期四
新读《C++Primer4》
虽然《C++Primer3》是我的枕边常读之书,但这次《C++Primer4》仍给我许多新的启发。该版进一步强调了C++作为一门工程语言的实用性。如在章节设置上,第一部与第二部都没有叙述Class的定义等内容,而是从使用者角度介绍STL中最常用库的介绍。这表明作者认为目前C++程序员更应该了解STL库,去用STL库,而不总是去设计“原始而拙劣”的Class。在第一部Basic中,作者将String、Vector等STL中最常用库介绍放在语句表达式之前介绍,并将Array与Pointer并入一章叙述,都体现了这一点。想现在大学中,许多学生学习完C++后,对于 Bind、Transform 等知之甚少,而 Class 也编写得很糟糕,就更感到《C++Primer》作者的真知灼见。“用比创建好”——这是《C++Primer4》给我的最深印象。
2007年8月20日星期一
网页上的代码高亮
在网络上发现一个源自Google的工具,可进行代码高亮。
1.下载并解压文件包,其中有两个文件:CSS和JS
2.在HTML文件头引用CSS与JS
< link href="prettify.css" type="text/css" rel="stylesheet">
< script type="text/javascript" src="prettify.js"></script>
3.在HTML正文中执行JavaScript命令,如 < body onload="prettyPrint()"> < /code >
4.需要高亮的代码用< code class="prettyprint" > ... < /code >包围即可。
原文地址:
http://google-code-prettify.googlecode.com/svn/trunk/README.html
1.下载并解压文件包,其中有两个文件:CSS和JS
2.在HTML文件头引用CSS与JS
< link href="prettify.css" type="text/css" rel="stylesheet">
< script type="text/javascript" src="prettify.js"></script>
3.在HTML正文中执行JavaScript命令,如 < body onload="prettyPrint()"> < /code >
4.需要高亮的代码用< code class="prettyprint" > ... < /code >包围即可。
原文地址:
http://google-code-prettify.googlecode.com/svn/trunk/README.html
2007年8月19日星期日
lstlisting的使用技巧
lstlisting中使用lstinputlisting命令导入外部源代码,不要全部导入,这样常会引起Latex解释错误。应定义起始/结束行号,这样即清楚,Latex编译也很快。
\lstinputlisting[language=Gnuplot,firstline=1,lastline=2]{sample01.plt}
2007年8月18日星期六
Firefox中的Gmail显示
最近Firefox中Gmail总是显示不正常,但在IE中却能正常显示,我原先以为是Firefox升级后的问题,今天Google得知原来是ADblock的缘故,故在ADblock中增加两条新的过滤条目后即可。
@@|http://*.google.com/
@@|https://*.google.com
@@|https://*.google.com
2007年8月3日星期五
《C++沉思录》阅读笔记(5)
1.在一个具有继承关系的类群中使用容器会遇到许多在使用内在类型(元类型)时所不会遇到的问题,因为机器是不了解它要处理的问题的规模是多大。它像一个满脸青春痘的少年面对制定一个跨国企业下年度财务预算报表时一样茫然无措。这并不是说少年不够聪明,而是他没有多少经验。即便对于一个经过多年磨炼的人来说,面对一个无法预测边界的工作时,他多少也会紧张。
2.将继承与容器共用,迫使我们要处理两个问题:控制内存分配和把不同类型的对象放入同一个容器中。这其实是一个RTTI问题。在C++中的语言层次,并没有提供一个完善的RTTI解决方案,但其确提供了解决该问题的工具。可惜地是,该问题是OOP中最常见也是最难于理解的问题,故后来的Delphi、Java、C#等都将RTTI作为语言级机制内化起来。这固然为新手入门带来很多好处,并能大幅提高软件工业的生产效率。但软件生产是一个如此特殊的产业,了解RTTI等底层技术的人的产能可能是一般新手的几百倍。或许其只是在产生了形式上的"效率提高"的繁华,而实际整体并没有太多增长。
3.在容器中应该使用代理对象而不是对象本身。
4.在编辑器中手工编写一下代码,有时不需要编译就可以理解作者意图,而单纯阅读总像"雾里看花"。
5.不应该接受对象,而应该接受对象指针或者引用。这虽然带来显而易见的效率优势,也带来棘手的问题,因为使用对象指针比直接使用对象要困难,未初始化的指针是非常危险而且没有什么简单办法可以防范。所以要在其间增加一个代理类,将指针管理封装起来,这样就有效隔绝了指针问题的蔓延。
6.Handle类的实现越看越和COM机制相似,或许COM的实现就是采用这样的技术。
7.Copy on write技术能有效提高效率,在编写完成代码后,应该用该技术优化既有代码。
2.将继承与容器共用,迫使我们要处理两个问题:控制内存分配和把不同类型的对象放入同一个容器中。这其实是一个RTTI问题。在C++中的语言层次,并没有提供一个完善的RTTI解决方案,但其确提供了解决该问题的工具。可惜地是,该问题是OOP中最常见也是最难于理解的问题,故后来的Delphi、Java、C#等都将RTTI作为语言级机制内化起来。这固然为新手入门带来很多好处,并能大幅提高软件工业的生产效率。但软件生产是一个如此特殊的产业,了解RTTI等底层技术的人的产能可能是一般新手的几百倍。或许其只是在产生了形式上的"效率提高"的繁华,而实际整体并没有太多增长。
3.在容器中应该使用代理对象而不是对象本身。
4.在编辑器中手工编写一下代码,有时不需要编译就可以理解作者意图,而单纯阅读总像"雾里看花"。
5.不应该接受对象,而应该接受对象指针或者引用。这虽然带来显而易见的效率优势,也带来棘手的问题,因为使用对象指针比直接使用对象要困难,未初始化的指针是非常危险而且没有什么简单办法可以防范。所以要在其间增加一个代理类,将指针管理封装起来,这样就有效隔绝了指针问题的蔓延。
6.Handle类的实现越看越和COM机制相似,或许COM的实现就是采用这样的技术。
7.Copy on write技术能有效提高效率,在编写完成代码后,应该用该技术优化既有代码。
订阅:
博文 (Atom)