邱俊的空间

不错

如果定义两个list： List *list1 = (List*)ListConstruction(); List *list2 = (List*)ListConstruction(); 这样会不会有问题？因为List中的函数都是通过变量List *list来模拟this指针的，这样的话定义list2的时候就把变量list覆盖了，致使list1的函数调用变成是list2的函数调用？最近也在想怎么用c来模拟c++的this指针，

@abruzzi 我也下不下来啊,谁有源码?能不能发下我邮箱里,我正在学:ching5346@126.com

@我是一头驴子 不好意思，本啦是用dropbox的链接，我刚用迅雷试了下，好像真的不能下了，用这个链接吧：http://files.cnblogs.com/abruzzi/machine.zip

怎么下不下来呢？

攒一下楼主的写作风格，简洁而又调理。实在很难得

理想的编程语言 鞠文广 以下纯粹是个人观点, 不代表任何组织或社团. 现在流行的编程语言如Java和C#, 大多是面向对象的, 程序的各部分是通过方法调用连在一起, 其编程范式是命令编程, 即使支持其他范式也包装得很难理解和使用. 面向对象实际上只适合实现抽象数据类型, 让它去完成除此之外的任务确实是勉为其难, 即便能完成也给人不伦不类的感觉, 既不像面向对象编程, 也不像它的前任(过程编程). 这些语言中的对象与物质世界的物质(或对象)很不一致, 它使用方法调用的方式与其他对象进行相互作用, 而这与物质之间的(通过通信或媒介)相互作用是截然不同的, 因此用面向对象无法很确切地模拟现实世界(面向对象思想的初衷), 更不用说准确地为现实世界建立模型. 这几年流行的web服务和SOA虽使程序间交互更方便, 但它从本质上说还是使用”面向对象+命令编程+方法调用”的思路, 在编程方法论上并没有实质的进步. 用现在流行的语言实现的完成复杂功能的程序逻辑不清晰, 原因在于”命令编程+方法调用”的设计机制. 这使程序很难模块化, 副作用无所不在, 因此很难正确实现复杂功能. 现实世界的发展变化是通过事物间的相互作用实现的, 而这种相互作用用计算机科学的语言来说就是并发(concurrency). 软件的本质是什么? 我觉得:软件总是完成某种功能的,归根到底是对现实世界的事物间相互作用进行建模. 因此软件的组成部分间自然就是并发的关系, 而不是过程调用的关系. 用通信进程来对现实世界的事物间相互作用进行建模是比较合理的. 所以进程应该作为语言的基础成分, 是软件的基本组成部分, 而不是只为了提高效率才采用的. 为了使程序能准确地为现实世界建立模型, 从而正确性更高, 结构更合理, 模块化程度更高, 因此在几种编程思想或语言的基础上(见references), 我提出一种新的编程方法论: 面向进程+函数编程+进程间通信+逻辑编程+约束编程+其他合理的范式(命令编程除外)和一门编程语言ProcessLog (全称process logic). ProcessLog只支持一种并发:通信进程. 它就是计算机科学家在上世纪70年代为了克服现在的Java中仍采用的那种并发方式的缺点而提出的. 它是经过充分研究得到的一种理想并发方式, 看了并发理论(concurrency)和进程代数(Process algebra), 就会明白这种并发方式可解决实际中的各种并发问题, 用它足够了. 这里的进程是进程代数的进程,不是过程,也不是Java中的线程. 看看jcsp或Hoare的CSP(http://www.usingcsp.com/)就明白了.推荐网址: http://www.cs.kent.ac.uk/projects/ofa/jcsp/, 其中有两个ppt说得很明白: "Process Oriented Design for Java: Concurrency for All", "Communicating Processes, Components and Scaleable Systems". ProcessLog的语法概要如下: 1 运算符 (1) ? 输入; c ? x 从输入端口c或通道c上接收输入值放到变量x中 (2) ! 输出; c ! v 把v的值从输出端口或通道c上输出 (3) -> 顺序进行的事件的先后关系 (4) | b : s 分支 (5) || 进程并行 (6) // 附属进程 (7) and, or, not 逻辑运算符 (8) 算术运算符和关系运算符 与Java中相同 2 程序的组成成分 (1) Unit 程序单元 (2) Process 进程 (3) Function 函数 (4) Predicate 谓词 (5) Channel 通道, 有两个端口: in 输入端口, out 输出端口 (6) OutPort 输出端口 (7) InPort 输入端口 3 数据结构 (1) List (函数编程中的List类型, 对List的操作函数与函数编程中相同); (2) Tuple 元组, 同Clean. (3) Set 集合 没有数组 4 进程的定义 Process p1 (OutPort pt1, InPort pt2 ){ pt2?x -> pt1! compute(x) -> p1 } 5 进程间相互作用 (1) 进程并行 process1( c1.out, c2.in)|| process2(c1.in, c2.out) (2) 附属进程 (getE: getElements || getR: getReleasedVersion) // X.(in?method -> getE ! method ? elems -> getR ! em ? rem-> … ->X) 6 函数 [Function] compute(double x)= | x<=0: x*x+3 | x>0: compute(x-5)* compute(x-3) 函数只能以事件的方式在进程中使用或在其他函数中使用, 不能独立使用. 7 谓词 /* 建图 */ Predicate createGraph(t, graph):- addNode(t, null, ({},{}), graph1), getDS(t, graph1.ns, tlist), addList(tlist, t, graph1, graph). /* 加节点 */ Predicate addNode(t, null, (ns, es), (ns1, es):- merge(ns, {t}, ns1). Predicate addNode(t, upper, (ns, es), (ns1, es1)):- merge(ns, {t}, ns1), merge(es, {(upper, t)}, es1). 8 把谓词转换为函数 create(t)= graph where createGraph(t, graph) 谓词不能独立使用也不能在进程中直接使用, 要在进程中使用需要先转换为函数. 9 程序单元: 包含进程和数据类型 Unit PmethodDAO; interface Tuple Method; Process getLastVersion(OutPort pt1 , InPort pt2); … implementation Method=(String id, String name, String version); Process getLastVersion(OutPort pt1 , InPort pt2){ … } 指导原则: 程序是由通过通道通信的进程组成的. 数据处理和算法用函数编程实现, 如果函数编程不适用于要处理的问题, 就使用逻辑编程或约束编程. ProcessLog语言限制了编程的随意性, 要求只能用进程代数+函数编程+逻辑编程的方式编程, 不允许用Java或c#的命令方式编程. ProcessLog 现在还没有在机器上实现. 我用该语言重写了实际项目中的一些复杂代码(原是Java代码), 证实用它写的程序确实简单清晰, 有类似数学的简洁美. "7 谓词"就是其中一部分代码. 我的想法是: 应先在纸面上规定它的语法与语义, 再通过使用它编写一些应用程序来发现它的不足,再进而改进它, 再实践, 再改进, 直到它基本完善再在机器上实现. 另外, 大家不要把语言分为中国人提出的还是外国人提出的, 科学无国界, 这里不存在狭隘的爱国主义. 我不是那种技术高手, 但我自信我是一个能将理论很好地联系实践的研究者. 希望有识之士和我一起共同发展这种编程方法论和这门语言. juwenguang2000@yahoo.com.cn References 1. CSP http://www.usingcsp.com/ 2. JCSP http://www.cs.kent.ac.uk/projects/ofa/jcsp/ 3. Clean http://clean.cs.ru.nl/ 4. Prolog 5. Delphi 注: 转载时请注明作者.

@jhtchina 总的来说，BBMS是一个轻量级的消息服务，还没有Pub/Sub机制，主要考虑到为GUI提供底层的消息机制，当然，可以进行扩展，使得其适应企业级的消息服务。当然，目前还有很多的问题，需要进一步完善。

主要是消息的定义 这个部分要做好 Bus 就是一个或者几个服务，按照SOA的思想来做 消息如果传递成功以后，你是否考虑过回传机制，消息是否成功发送到目的地

@Todd Wei 主要是概念上的问题，Queue是一个比较抽象的概念，可以用来实现BUS的内部容器，但是Queue跟BUS并不能等同起来。 比如，可以将一个listener“挂”在BUS上，但是不能说挂在Queue上，正如我一直的观点：名称在程序设计，特别是OO中，名称是特别重要的，可以使得代码的可读性和可维护性增强。

MessageBus和MessageQueue有什么区别？

@thinklose2
好的，明天有时间做个类图贴上，类稍微有点多，有图看着可能比较直观，呵呵

要是再多一张类图就好了

package listenerdemo.framework;

/**
* @author juntao.qiu
*/
public interface EventListener {
/**
* handle the event when it raise
* @param event
*/
public void handleEventListener(EventSource event);
}

不好意思，这个接口中的方法名字有问题，应该是
public void handleEvent(EventSource event);

up

对了，代码可以在这里得到
http://dl.getdropbox.com/u/151884/Computer%20Science/machine.zip
有过有兴趣，可以下载下来自己测一测。

@随心所欲
模型比较简单，不需要考虑效率问题，主要重点在如何合理的建模上。这个机器目前还不适合做“真正”的动作，毕竟目前只有一个简单模型。

Mark。
有没有效率方面的考量？

@怪怪
哈哈，昨天去你的博客上看了看，才发现也是做这个部分的理论研究的。你的ORE也看了看，很不错。
我主要看的是《计算理论导引》这本书，很有意思。

最近也在看编译原理相关的内容。希望楼主可以多发类似的文章。:-)

@abruzzi
呃...，惭愧，我正好就是在做自动机方面的半理论研究工作...

我提到所谓regex，只是因为你提到正则表达式工具。如今大多数这种工具都可以接受比正则语言更广阔的语言类别，所以在学术上不再称它们为“正则表达式”而只称regex，他们本质上也不再能够对应于NFA了。

对于一些基础知识点的掌握，强烈推荐一下《自动机导论》。另外如果对于语言的成员性测试有更多的兴趣，一些编译原理的相关书籍也可以看一看～

如果对我所说的上述问题感兴趣（欢迎欢迎，同好太少了:），可以看看近期的论文～

@EricZhang(T2噬菌体)
词法分析上，肯定会用到状态机的理论，但是现在能看到的一些编译器的编译器如lex/yacc, javacc, anltr等都是基于正则表达式的（正如你所说，它们是等价的），可能状态机的模型没有正则表达式的模型成熟，所以没有大规模的使用起来。

@怪怪
嗯，可能你平时关注应用多一些，而我可能比较理论，学院派，呵呵。
DFA与NFA是等价的，但是，同样，NFA比DFA要简单，因为它在接受到N个不同的输入时可以定位到同一个状态，所以状态就比较少，同时，这样的机器在形式上比DFA要复杂些，所以我采用这个来说建模。
正则，Regular Expression和regex不知道有什么不同，关键是我不明确你这里的regex是什么，可能是正则表达式这个理论的一种实现，但是这里说的是抽象意义上的正则，可能我们没有说到一个点上。

有限自动机跟正则表达式的表达能力是等价的，一个正则语言总能找到一个能够识别它的有限自动机来。

@abruzzi
你这个概念介绍有一些不清晰的地方。

DFA与NFA在能力上是等价的，而如今的正则工具大多数没使用自动机模型。实际存在问题之一是sub-match extract，不过90年代后的论文和一些具体实现也解决了这个问题。

对于正则，分为Regular Expression和regex，前者综上所述使用DFA就可以；而后者是现在广泛应用的带back reference的Extended Regular Expression。

这种东东超出了正则语言的范围，实际上已经不应叫做正则表达式了。DPDA（相对于LR(k)文法）也不能完全覆盖它，更别提NFA了。现在基本所有的实现都使用的是基于回溯的算法。

在这个方面，基于自动机的理论模型和算法，还处于研究和发展的阶段。

说到文本解析，首先要确认的是落在乔姆斯基的四种文法哪个之内，然后再考虑相对应的机器模型。

但事实上，由于自动机理论和具体算法都还不成熟，超过DPDA的都很难找到一个合理的类自动机/图灵机实现。对于这些相对“复杂”的文本解析，根据具体需求设计算法或者使用回溯是一个可行之道。

@abruzzi
呵呵。感觉一提到FA，脑中自然想起一些东西，如正则文法，FA和正则文法的等价的证明。DFA、NFA的等价及相互转换之类的。。。另外就是一些应用，如词法分析等。

@eastcowboy
有限自动机(文中的为确定型)是一个计算机模型，比图灵机要简单的多，用以文本解析本无不可，不过如正则表达式的正则语言(本质上是一个非确定型有限自动机)等工具来做要好得多。
文章主要想说一说如何比较合理的建模，而个人对计算理论比较熟悉，所以举例子用的是有限自动机，如果要使用自动机，文中的例子就不够用了。需要学习一下更复杂的模型，如非确定型有限自动机，下推机等。
谢谢。

博主能否讲一些有限自动机在文本解析方面运用的内容

@EricZhang(T2噬菌体)
@剑在上海^^
不知道你们需要多深？这个方向我确实深入的学习过，可以讨论讨论，呵呵。

我很喜欢这种类型的文章，能不能系统深入的讲下？

不错。要是能深入一点就更好了。

内容很好，有限自动机的用处是大大的。

用 livewriter 阿.

呵呵，可能OO形式的代码更贴近人的思维方式。

沙发，很不错，数据结构很重要，希望楼主多写些这方面的文章！
你的C代码写的很漂亮:)

小例子，看不出析构函数的使用，大的话会复杂些。苹果操作系统可以用object-c开发，看过几篇文章，有讲内存管理之类的，不过单就上面的实现，未必做不出简单的多态和继承，重载等，重载可考虑多传一个函数指针参数来确定具体对应的函数，虽然有点兜圈子，但比用switch好点。

@Jake.NET
是的，前一向读了ucos-ii的源码，里边关于Task的execute()函数会接受一个void*参数，在运行时可以将其实例化成任何其他的数据类型比如字符串，另一个结构体等。具体应用时可以cast，类似于OO中的instanceof，这样就比较通用了，呵呵。

@taylor zhang
嗯，正是，void* 就相当于OO语言中的顶层对象Object，什么都不是，但是却可以变成任何其他的东西，呵呵。C在语言层面上不支持泛型，不过自己包装的话，我想还是可以实现的。

@abruzzi
其实c语言原生就支持封装，可以在struct里面封装属性，同事可以使用函数指针封装方法。不支持多态应该只能称为OB（Object-based）不算OO。但是我还是很是很欣赏你的设计，在Task场景，这是很不错的，因为这里的Task没有input，没有output。在实际应用下，我想场景会复杂些，run()会有input和output，当然在C里面可以用void*作为input和output的接口，在用的时候再cast。

用void*来实现部分重载。
呵呵
void func( void* arg_token, int size_token);

func( char* arg_real_char , 1);//
func( int * arg_real_int, 4);//

不错,很有帮助

学习了
我也转载了，怕以后被你删了，原文贴到我的首页去了~~

@Jake.NET
你所说的多态应该是OO中传统的意义了：类A和类B都实现了I接口，然后外部的逻辑仅与I接口有关，在运行时，会动态调用类A或者类B的相应方法。
这个并不是我要说的，我的意思是，Executor这个概念被抽取出来以后，就跟外部的使用者无关了，Task中包含任意的执行逻辑，将其set给Executor来执行，主要体现的思想是封装。而多态最少应该有"is a"的关系映射在里边，这个例子并不具备这种映射。

谢谢LZ演示了指针的用法，我觉得这种用法在表驱动的开发十分广泛。
从我的观点来看，这里你想表达的所谓OO应该是多态吧。就是Executor 的指针可以执行不同的函数。可是我不认为这是OO，因为在编译时，exe的执行逻辑已经决定了，不能在运行时变化。

牛人，8错

转载没有问题，而且是欢迎转载，不过我觉得应该注明出处吧？？呵呵

好文章,学习了,转载了:http://www.csdnit.com/showtopic-1510.html

@Jeffrey Zhao
哈哈，不是这个意思，昨天到你的blog上看了看，觉得很不错，特别是关于微软的那篇反思。
没说你没接触过FP，只是觉得你对FP的思想好像不是很赞同，所以讨论讨论而已。

--引用--------------------------------------------------
Jeffrey Zhao
主要是因为和人类的思维有些格格不入，人类思维往往是先做啥再做啥这种顺序型的，所以你看最符合这种方式的冯诺依曼的体系才是我们现在在用的，呵呵。
--------------------------------------------------------

我感觉写起来是没有问题的，关键在于读的时候可能跟人类的思维有些相悖之处，但是写的时候是很自然的。

@abruzzi
……兄弟你是不是没有看到这几天吵得最凶的话题是什么，我在那里和别人吵架支持C#中的lambda exp与FP，跑到你这里又被认为没有接触FP了，我好凄惨啊……

@Jeffrey Zhao
其实，可能只是你自己接触到的领域没有涉及到FP而已，并非FP真的没有在实际中的应用，.NET貌似已经支持lambda表达式了，著名的编辑器EMACS中的插件，linux中的photoshop(GIMP)中的插件，全部都是LISP方言写的，就是你上边提到的scheme.
FP的最重要的特性是动态性, 应用程序的模块可以动态添加而不需要重启。另不知Jeffey Zhao兄对python的研究深度如何，但是据我所知，python中的lambda表达式之强大也正是其流行的一个原因，呵呵。

对了，其实SICP已经不用了，已经用python而不是scheme教学了，就在最近，可以认为是一个时代的标志。