博文
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")
"finish
endif
let b:did_indent = 2
setlocal indentexpr=GetEiffelI......
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库就是在适配的接口上实现了映射风格......
波松分酒问题 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)
如果以瓶中酒的数量为节点, 通过一次以上运算可达到节点之间认为连通.
此题可转化为一个有向图的搜索问题.
即找出......
素数缓冲求法，可重用类 (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
{
&nbs......
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-wind......
蛇形方阵 (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&n......
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
&nbs......