博文
Vim indent file, another yet!(2006-12-29 15:34:00)
摘要：" Vim indent file, another yet!" Language: Eiffel" Maintainer: Huang Liang <huangl@tfol.net> " Ref Maintainer: Jocelyn Fiat <eiffel@djoce.net>" Previous-Maintainer: David Clarke <gadicath@dishevelled.net>" $Date: 2006/12/28 21:33:52 $" $Revision: 1.0 $" URL: http://www.djoce.net/page/vim/" Last Change: 2006 dec 28 : rewrite the indent rule" Only load this indent file when no other was loaded.if exists("b:did_indent") "finishendiflet b:did_indent = 2setlocal indentexpr=GetEiffelIndent()setlocal nolispsetlocal nosmartindentsetlocal&n......
linux和win32共存(2006-12-06 09:12:00)
摘要：这大概是我最早的一篇技术性文章了,大约是1999年.
看了十几个关于linux和win32共存的问题，总要有个答案吧！
以下的linux均指cosix linux 3.0亦适用于red hat 6.1以上（6.1以下的没试过）。
分区（适用于所有win32平台）
通常在第一分区安装最常用的操作系统，以得到最高的性能。
下面以第一分区为win32为例：
分区如下：
Partition NO. size File System Type Symbol
1 5000MB win32(Fat32) B
2 3000MB linux native(ext2) 82
3 Rest(>300MB) logic(Dos logic) (未知）
5 258MB linux swap(ext2) 83
6 Rest win32(FAT32/NTFS) B/(未知NTFS 5的代码）
这种分区表的好处是可扩展性好，保留了第四个主分区位置，可以自由增加第三个操作系统。
缺点是不太好做(fdisk或cfdisk（推荐）可以做，PQ Magic做不了)，并且PQ Magic不认.
（报错，并自动删去第二个扩展分区以后的所有分区。也可以不要交换分区，
这样PQ Magic就不会报错了）
Partition NO. size File System Type Symbol
1 5000MB win32(Fat32) B
2 192MB+ linux swap(ext2) 83
3 3000MB linux native(ext2) 82
4 Rest(>300MB) logic(Dos ......
C++关注方向(2006-12-06 09:07:00)
摘要：C++关注方向(本文的写作时间较早,其中有些言论已经不合时宜)1.C++扩展根据某位高人的解说，C++扩展似乎只有一条路了――类库。类库有几个方向：标准C++库的实现：基本上是各家一套，而最有希望的标准实现STLPort还在路上。不过我们最观心的还是如何用好它吧。通用C++类库：有很多很多，不过现在Boost已经博采众长，成长为最全面（未必最好）的一个通用类库。专门类库：很多专门类库已经并入通用类库，比如Serialization，Signal，Regexp等等，都已经是通用C++类的一部分，但还是有如WxWidgets，Bliz++，MFC，QT等专注于一个平台或一个方面。C++类库，主要有两个发展目标，一是跨平台，跨编译器，强调可移植性；二是泛型化，强调编译期，自适应；2.C++成例C++大概是最讲究“最佳实践”的语言了。有如此重多的书都是讲关于如何写一个类，如何写一个方法，如何设计一个方法。不过，随着编译器的发展，很多成例很快就过时了。比如说早期很讲究的一个成例NRV，已经成为编译器最重要的优化指标，基本上已经没有不支持这一优化的编译器了。做为一个C++程序员，知道多少成例，可以直接说明有多少经验。３.模式和架构很多类库其实就是因为某一个模式或架构在C++中实现而出现。甚至Loki完全就是一个的C++模式库。如何在C++语言中实现某中模式和架构，也是很重要的一个方向。４.应用平台这是C++永远的痛处了，很多类库就是为此奋斗，可惜“类库!=应用平台”。到现在为至，还没有一个完全为C++定制的应用平台。所有C++程序员都不得不在他人的平台上工作。因此，就有一个很奇怪的方向，在XXX平台上使用C++。......
语言之间的接口和适配层(2006-11-27 21:12:00)
摘要：语言之间并没有鸿沟，一种语言写成的东西并非不能被另一种语言调用，这是语言之间的接口和适配问题。1.语言之间的接口多是指动态语言和静态语言之间的接口。但是，从一般意义上来说只要是高级语言都有相应的低层接口。区别只在这个接口本身如何表达。例如，PASCAL语言它的低层接口只能表达为汇编，因为PASCAL本身就已经十分低层，它的内部结构，如函数，结构等，只能以汇编的方式访问。类似的语言还有C。又如，Python语言它的低层接口可以是高级语言--C语言。说明它的结构十分高级可以使用C语言来访问。静态语言很难以另一种静态语言来访问其结构，原因在于它的动态性很小，其静态结构就比较简单，同时也比较低层，很难找一种语言能访问它所有的设施。C++就是这样，虽然它大多数结构都可以被C语言访问，而且大多数时间C语言也是C++的低层接口语言。但是调用成员函数这样的设施还是需要汇编语言才能实现。2.两种语言之间有映射和适配两种接口方式。映射是指一种语言能直接访问另一种语言（用作接口）的基本结构。比如C++和C之间，C++能直接访问所有C的结构，所以C可以用作C++的接口语言，用于扩展C++。映射并不是包含。一般来说，只要高层语言能直接访问低层语言的大部分基本类型和调用机制即可。大多数语言和相应的虚拟机汇编都有如此关系，例如C#/VB#/J#等语言与IL的关系，Java和JVM bytecode的关系。编译语言中，D语言，haskell语言都有C的映射。这类语言扩展时常采用保留低层接口风格，高层语言看起来像是直接调用低层语言。最为著名的是Eclipse SWT库的Java-C接口，虽然Java-C的接口是适配关系，不是映射关系。适配关系的接口，正好与映射关系相反，是由低层语言来访问高层结构。比如前面提到的Java-C的接口，Java把对象结构公开出来，Jvm的调用公开出来，C语言只需要访问这些结构，就可以生成相应的Java对象。这种接口的特点是扩展后接口与低层接口风格有很大差异。映射和适配有区别也有统一，前面说到的SWT库就是在适配的接口上实现了映射风格的扩展。同样在映射接口上也可以实现适配风格的扩展。3.一般来说C语言是高级语言中最低层的语言。它的静态结构十分简单，基本上没有动态结构，结构体和共用体大概C语言中最动态的结构了。另一方面，几乎所有系统上都有标准C的实现。可以......
波松分酒问题 C++求最优解. (2006-10-24 15:25:00)
摘要：/*请设计程序解决“波松分酒问题”问题如下：某人有12品脱啤酒一瓶，想从中倒出6品脱，但他没有6品脱的容器，仅有一个8品脱和一个5品脱的容器，怎样才能将啤酒分为两个6品脱？抽象分析:b = 大容器,也表示容积s = 小容器,也表示容积(f),(h),(e) 状态f=满, e=空, h=数字,表示容量运算一: b(f) - s(e) => b(b - s), s(f)变例 b(h) - s(e) => b(h - s), s(f)运算二: b(e) + s(f) => b(s), s(e)变例 b(h) + s(f) => b(f), s(s - b + h)引出 b(f) - s(h) b(h) - s(h) b(e) + s(h) b(h) + s(h) 如果以瓶中酒的数量为节点, 通过一次以上运算可达到节点之间认为连通.此题可转化为一个有向图的搜索问题.即找出.指定节点(12, 0, 0) 和 (6, 6, 0)之间的最小路径. */#include <cstdio>#includ......
素数缓冲求法，可重用类 (2006-10-24 15:23:00)
摘要： #include <iostream> #include <algorithm> #include <vector> #include <iterator> template <typename T> class PrimerCache { typedef T ValueType; typedef std::vector<ValueType> IntArray; typedef typename IntArray::const_iterator IntPtr; static IntArray mCache; protected: bool Test(ValueType num) const { // make sure : half <......
Dev-cpp 小型指南(2006-10-24 15:21:00)
摘要：Dev-cpp是一个GCC在win32下的IDE程序,用Dephi 5编写,只有2M具有以下功能: 1.集成编译环境,支持工程模板. 2.支持语法加高,自动注释,对中文的支持也不错. 3.支持CVS集成 4.支持源码分析,可以形成类树图. 5.支持扩展包.Dev-cpp官方发布有集成MinGW32 gcc编译套件,最新支持GCC 3.3(2003-7-15)也可以支持MinGW其它版本和Cygwin gcc的各个版本.不过需要手动设置.Dev-cpp支持多语言环境,中文版界面由我的好友nyra(nyra@sohu.com)维护,如果大家发现中文版有翻释问题可以找她.如果有兴趣翻译帮助文件,也请联系.Dev-cpp有两个常用版本,一是开发中的5.0beta,最新一版是4.9.8.0另一个是4.01,是4.0的修正版(其中集成Gcc 2.9.5),前者功能较多,而后者较稳定.图形化环境我就不多说了,和VC的用法类似,其实大家问题多集中于Gcc本身.GCC, GCC和gcc不同的东西.前者是Gnu的编译环境,包括gcc, g++, gcj等多种语言的编译器和as(汇编), ar(库), ld(联接器)等一系统编译工具.gcc是GCC中C语言的编译器,g++是C++语言的编译器.GCC被移植到多种操作系统中,在Win32上最著名是MinGW和Cygwin两个版本,MinGW的全称是Minial GCC for Windows,如题,它是Win32上的一个小型GCC,只包括最少的GCC组件<10M而Cygwin就是一个Unix On Windows的大系统,全部下载有300多兆,Unix下的大多数软件在Cygwin中都有移植版,包括X-windows.还有一个for Dos-32 的GCC,名叫Djgpp,与Mingw的目标类似,不同的是它是一个以MZ为目标程序的可以在非Win32环境下运行(例如FreeDOS)它们都移值了GCC官方发......
蛇形方阵 (2006-10-24 15:20:00)
摘要：/* 题目按以下所示规律把1-N*N个数填入N*N的方阵中： 1 3 4 10 11 2 5 9 12 19 6 8 13 18 20 7 14 17 21 24 15 16 22 23 25 */#include <stdio.h>#include <assert.h>#include <string.h>/*解析： 上三角形 a(0)= 1 = 1 + 0 a(1)= 2 3 = a(0) + 1, a(0) + 1 + 1 a(2)= 4 5 6 = a(1) + 2, a(1) + 2 + 1, a(1) + 2 + 2 a(3)=7 8 9 10 = a(2) + 3, a(2) +&nb......
OOP已死(2006-10-09 18:01:00)
摘要：原文是英文，我这个不能算翻译只是笔记。http://kawagner.blogspot.com/2006/08/oop-is-dead.html文章的主要观点是：OOP已经达到它的顶点，并开始衰落。主要证据有1.函数式编程逐渐引人注意，许多老牌语言开始引入函数式编译的概念比如，closure, continuation, iterate等。2.多范式语言并不是解决之道:1)编程语言应该引导编程员解决问题，而不是面对多种范式无所选择。2)多种范式降低了代码重用的范围和效率.3.OOP语言不能解决以下问题1)多分派,双分派可以使用visiter模式,但要加入大量代码,也不灵活.而函数式语言可以轻易做到多分派.2)扩展工具类的能力.以java中String类为例,即使有一个ExtString类,也没有太大用处,因为除了你的程序以外没人用ExtString,你无论是从url中还是toString,得到的都是String,还要构造一次才能成为ExtString.但在函数式/过程式语言中,添加一个函数十分容易.3)扩展基本类操作,如果你需要添加一个能与Int/BigInt进行add的Complex类呵呵,你不得不为每一个基本类型添加相同的操作.4.OOP中最大的问题在于可变的状态,这正是函数式语言所没有的.它影响了OOP在程序结构,并型性,优化.函数式语言中无副作用的函数其实从根本上解决了这些问题.5.元编程也不是一个好主意.元编程被用于解决OOP语言中一些语义的问题但事实上,这完全是错误,Lisp这样自然的元编程语言中,语义是不能被修改的.这种使用原因完全是因为有些问题语言本身没有解决好.6.程序框架能解决一些问题,并非所有问题.总结一下OOP在两个方面已经很难满足要求:1.模块化.(原文是Dependencies,不过我认为模块化更准确)2.扩展性.详细内容还是看原文吧.......
Programming the SoundBlaster 16 DSP(2006-07-25 14:27:00)
摘要： ==================================== Programming the SoundBlaster 16 DSP Written by Ethan Brodsky (ericbrodsky@psl.wisc.edu) Version 3.1 ......