猪哥 的个人资料猪哥的Blog日志列表留言簿 工具 帮助
2008/2/26

猪哥的Megatops ProCoder 1.0字体新品发布

因为自己时不时也用用Ultraedit、EmEditor、EditPlus这样的编辑器,发现原来的ProCoder字体覆盖了128-255编码范围和中文字体冲突在这些不能正确计算宽度的编辑器里面确实还是挺麻烦的。所以简单裁剪了一个仅包含0-127范围的Lite版Megatops ProCoder字体。可以正常调用宋体显示全角引号、单引号、省略号等。当然,128及以上的西欧字符被裁掉了,所以这个版本无法正确显示德文和法文。如果你有这种需要就得使用没有裁过的完整版。所以我是建议你两个版本都安装,在类似于EmEditor这种能够为不同字符集指定字体的编辑器里面就可以无痛切换。

以下是在EditPlus中Lite版本的显示效果,因为已经完全裁掉了0x7F以上的字符,所以全角符号完全由中文宋体支持:



和原来的Full版可以共存,直接安装即可。点击这里下载

★ Megatops ProCoder正如其名:仅仅面向有长时间编码或屏幕代码阅读需求的专业程序员设计,不明白其设计目的的麻烦绕行~~
2008/2/24

最好的中文和英文TTS语言库

经过尝试后俺基本确定了现阶段最值得推荐的SAPI 5 TTS引擎:NeoSpeech的VW Paul和VW Lily!

NeoSpeech的VW Paul我前年写的一篇Blog里面有过介绍,不再多说。这里再贴一遍其朗读效果给大家复习:

“The United States, accused by Amnesty International of twice using Croatia as a stopover point for terrorism suspects, never informed the government about such landings, Croatia's president said on Saturday.”

上面这段话的VW Paul的朗读MP3下载:点此下载

至于中文的,原先以为应该只有个传说中的科大讯飞的那个才比较像样。不过讯飞的我一直没有发现有SAPI5的版本,总是只能在它的自有软件里面用很不爽所以我从来没兴趣在PC上装。很早以前装过NeoSpeech的VW Wang是中文男声的,可惜我兴冲冲地下来一听以后大倒胃口——VW Wang的质量也就只能和微软自己的那个中文TTS比较~~只不过是哪个更像机器人的问题~~不过这回弄到Lily以后,发现已经完全实用了!!虽然Lily的体积比Wang大了一倍(4xx多MB),但是质量好了几十倍啊相当超值!

反复地试验以后发现NeoSpeech Lily还是适合来阅读新闻内容。如果拿去阅读一些技术文章就会有点怪不过还是能听明白的,并且也没有听着MS那个傻TTS的感觉那么可怕。另外Lily的默认语速偏慢,我要把它调快两格才能得到比较正常的语速来。以前听鸟语老师说鬼佬听我们的鸟语听力考试的材料就和我们听鬼佬慢吞吞说中文的感觉差不多。比较一下NeoSpeech的英文Paul和中文Lily的默认语速~~俺才有了客观的认识(─.─||)。

不多说了,下面Show一下我录的Lily读中文的效果(语速已经调快):

“中国已经得出一个结论,即如果它继续走和平发展的道路,不尝试进入可发挥影响力的领域或挑战任何现有的强权如美国或西欧,而是与所有的人做朋友,包括日本、俄罗斯、印度及其他国家,按照它现在已是成员的世界贸易组织的游戏规则,它的实力将会越来越强,并在三四十年内将国民生产总值提升至同美国相当的水准。

中国的科技水准将达到美国的一半,再过三五十年,它的国民生产总值将超越美国,科技水准也可同美国相去不远,因为它仔细地研究了台湾、香港和新加坡的模式,并发现这些地方之所以先进,是因为它们同西方国家保持联系,可吸收科技、知识及资金,以开发出口市场,并培养一支受过教育的工作队伍。”


上面这两段话的VW Lily的朗读MP3下载:点此下载

现在的Babylon、金山词霸、Acrobat、Lingoes词霸等等都已经全面支持SAPI5,所以这两个TTS引擎能够在几乎所有的参见电子字典和阅读器软件里面使用。严重推荐!

★ 说到中文TTS,有必要补充一个科大讯飞的语音电子书手机版的效果。我平时上班的时候就听它读一些百家讲坛或者是读者合订本之类的闲书。虽然说是属于完全彻底没有任何语气讣告式的风格,但是倒是还吐字清晰分词比较正确,起码要比听清周杰伦的歌词容易得多,达到实用水平。值得一提的是整个软件(包括阅读器)仅有3.3MB,非常小巧。录音是用手机靠近笔记本的MIC录的,声音偏小但是音质和原来没有区别。因为手机版过小的音色库的缘故这个软件的发音就是给人感觉有些发糊码率很低,但是能在手机上做到这样已经非常不错啦。

“百年航空,群星灿烂。其中才华横溢的飞机设计师十分引人注目。他们中间的一些佼佼者,不但以自已的杰作-各种优秀的飞机著称于世,而且还对飞行情有独钟:或亲自试飞自己设计的航空器;或是飞行纪录的创造者;甚至驾机环球飞行……他们堪称“两栖”又“双赢”的航空奇才,为百年航空谱写了瑰丽的篇章。”

上面这段话的科大讯飞手机版Xiao Yan的朗读MP3下载:点此下载

2008/2/15

C语言的inline

转以前我用Docbook写的一篇关于C语言inline关键字使用的文章。唉,要是能用docbook直接写Blog就好了。用得越多发现Docbook这个东西真是越好用啊~~
 
本文介绍了GCC和C99标准中inline使用上的不同之处。inline属性在使用的时候,要注意以下两点:
  1. inline关键字在GCC参考文档中仅有对其使用在函数定义(Definition)上的描述,而没有提到其是否能用于函数声明(Declare)。

    从inline的作用来看,其放置于函数声明中应当也是毫无作用的:inline只会影响函数在translation unit(可以简单理解为C源码文件)内的编译行为,只要超出了这个范围inline属性就没有任何作用了。所以inline关键字不应该出现在函数声明中,没有任何作用不说,有时还可能造成编译错误(在包含了sys/compiler.h的情况下,声明中出现inline关键字的部分通常无法编译通过);

  2. inline关键字仅仅是建议编译器做内联展开处理,而不是强制。在gcc编译器中,如果编译优化设置为-O0,即使是inline函数也不会被内联展开,除非设置了强制内联(__attribute__((always_inline)))属性。

1. GCC的inline

gcc对C语言的inline做了自己的扩展,其行为与C99标准中的inline有较大的不同。

1.1. static inline

GCC的static inline定义很容易理解:你可以把它认为是一个static的函数,加上了inline的属性。这个函数大部分表现和普通的static函数一样,只不过在调用这种函数的时候,gcc会在其调用处将其汇编码展开编译而不为这个函数生成独立的汇编码。除了以下几种情况外:

  • 函数的地址被使用的时候。如通过函数指针对函数进行了间接调用。这种情况下就不得不为static inline函数生成独立的汇编码,否则它没有自己的地址。

  • 其他一些无法展开的情况,比如函数本身有递归调用自身的行为等。

static inline函数和static函数一样,其定义的范围是local的,即可以在程序内有多个同名的定义(只要不位于同一个文件内即可)。

注意

gcc的static inline的表现行为和C99标准的static inline是一致的。所以这种定义可以放心使用而没有兼容性问题。

要点:

  • gcc的static inline相对于static函数来说只是在调用时建议编译器进行内联展开;

  • gcc不会特意为static inline函数生成独立的汇编码,除非出现了必须生成不可的情况(如通过函数指针调用和递归调用);

  • gcc的static inline函数仅能作用于文件范围内。

1.2. inline

相对于C99的inline来说,GCC的inline更容易理解:可以认为它是一个普通全局函数加上了inline的属性。即在其定义所在文件内,它的表现和static inline一致:在能展开的时候会被内联展开编译。但是为了能够在文件外调用它,gcc一定会为它生成一份独立的汇编码,以便在外部进行调用。即从文件外部看来,它和一个普通的extern的函数无异。举个例子:

foo.c:

/* 这里定义了一个inline的函数foo() */
inline foo() {
    ...;   <- 编译器会像非inline函数一样为foo()生成独立的汇编码
}

void func1() {
    foo(); <- 同文件内foo()可能被编译器内联展开编译而不是直接call上面生成的汇编码
}

而在另一个文件里调用foo()的时候,则直接call的是上面文件内生成的汇编码:

bar.c:

extern foo(); <- 声明foo(),注意不能在声明内带inline关键字

void func2() {
    foo();    <- 这里就是直接call在foo.c内为foo()函数生成的汇编码了
}
重要

虽然gcc的inline函数的行为很好理解,但是它和C99的inline是有很大差别的。请注意看后面对C99 inline的描述(第 2.2 节 “inline”),以及如何以兼顾GCC和C99的方式使用inline函数。

要点:

  • gcc的inline函数相对于普通extern函数来说只是在同一个文件内调用时建议编译器进行内联展开;

  • gcc一定会为inline函数生成一份独立的汇编码,以便其在本文件之外被调用。在别的文件内看来,这个inline函数和普通的extern函数无异;

  • gcc的inline函数是全局性的:在文件内可以作为一个内联函数被内联展开,而在文件外可以调用它。

1.3. extern inline

GCC的static inline和inline都很好理解:看起来都像是对普通函数添加了可内联的属性。但是这个extern inline就千万不能想当然地理解成就是一个extern的函数+inline属性了。实际上gcc的extern inline十分古怪:一个extern inline的函数只会被内联进去,而绝对不会生成独立的汇编码!即使是通过指针应用或者是递归调用也不会让编译器为它生成汇编码,在这种时候对此函数的调用会被处理成一个外部引用。另外,extern inline的函数允许和外部函数重名,即在存在一个外部定义的全局库函数的情况下,再定义一个同名的extern inline函数也是合法的。以下用例子具体说明一下extern inline的特点:

foo.c:

extern inline
int foo(int a)
{
    return (-a);
}

void func1()
{
    ...;
    a = foo(a);   ①
    p_foo = foo;  ②
    b = p_foo(b); ③
}

在这个文件内,gcc不会生成foo函数的汇编码。在func1中的调用点①,编译器会将上面定义的foo函数在这里内联展开编译,其表现类似于普通inline函数。因为这样的调用是能够进行内联处理的。而在②处,引用了foo函数的地址。但是注意:编译器是绝对不会为extern inline函数生成独立汇编码的!所以在这种非要个函数地址不可的情况下,编译器不得不将其处理为外部引用,在链接的时候链接到外部的foo函数去(填写外部函数的地址)。这时如果外部没有再定义全局的foo函数的话就会在链接时产生foo函数未定义的错误。

假设在另一个文件里面也定义了一个全局函数foo:

foo2.c:

int foo(int a)
{
    return (a);
}

那么在上面那个例子里面,后面一个对foo函数地址的引用就会在链接时被指到这个foo2.c中定义的foo函数去。也就是说:①调用foo函数的结果是a=-a,因为其内联了foo.c内的foo函数;而③调用的结果则是b=b,因为其实际上调用的是foo2.c里面的foo函数!

extern inline的用法很奇怪也很少见,但是还是有其实用价值的。第一:它可以表现得像宏一样,可以在文件内用extern inline版本的定义取代外部定义的库函数(前提是文件内对其的调用不能出现无法内联的情况);第二:它可以让一个库函数在能够被内联的时候尽量被内联使用。举个例子:

在一个库函数的c文件内,定义一个普通版本的库函数libfunc:

lib.c:

void libfunc()
{
    ...;
}

然后再在其头文件内,定义(注意不是声明!)一个实现相同的exterin inline的版本:

lib.h:

extern inline libfunc()
{
    ...;
}

那么在别的文件要使用这个库函数的时候,只要include了lib.h,在能内联展开的地方,编译器都会使用头文件内extern inline的版本来展开。而在无法展开的时候(函数指针引用等情况),编译器就会引用lib.c中的那个独立编译的普通版本。即看起来似乎是个可以在外部被内联的函数一样,所以这应该是gcc的extern inline意义的由来。

但是注意这样的使用是有代价的:c文件中的全局函数的实现必须和头文件内extern inline版本的实现完全相同。否则就会出现前面所举例子中直接内联和间接调用时函数表现不一致的问题。

重要

gcc的extern inline函数的用法相当奇怪,使用的范围也非常狭窄:几乎没有什么情况会需要用它。

在C99中,也没有关于extern inline这样的描述,所以不建议大家使用extern inline,除非你明确理解了这种用法的意义并且有充足的理由使用它!

要点:

  • gcc绝对不会为extern inline的函数生成独立汇编码

  • extern inline函数允许和全局函数重名,可以在文件范围内替代外部定义的全局函数

  • extern inline函数的应用范围十分狭窄,而且行为比较奇怪,不建议使用

2. C99的inline

以下主要描述C99的inline与Gcc不同的部分。对于相同的部分请参考GCC inline的说明。

2.1. static inline

同GCC的static inline(第 1.1 节 “static inline”)。

2.2. inline

C99的inline的使用相当令人费解。当一个定义为inline的函数没有被声明为extern的时候,其表现有点类似于gcc中extern inline那样(C99里面这段描述有点晦涩,原文如下):

If all of the file scope declarations for a function in a translation unit include the inline function specifier without extern, then the definition in that translation unit is an inline definition. An inline definition does not provide an external definition for the function, and does not forbid an external definition in another translation unit. An inline definition provides an alternative to an external definition, which a translator may use to implement any call to the function in the same translation unit. It is unspecified whether a call to the function uses the inline definition or the external definition.

即如果一个inline函数在文件范围内没有被声明为extern的话,这个函数在文件内的表现就和gcc的extern inline相似:在本文件内调用时允许编译器使用本文件内定义的这个内联版本,但同时也允许外部存在同名的全局函数。只是比较奇怪的是C99居然没有指定编译器是否必须在本文件内使用这个inline的版本而是让编译器厂家自己来决定,相当模糊的定义。

如果在文件内把这个inline函数声明为extern,则这个inline函数的表现就和gcc的inline一致了:这个函数即成为一个“external definition”(可以简单理解为全局函数):可以在外部被调用,并且在程序内仅能存在一个这样名字的定义。

下面举例说明C99中inline的特性:

inline double fahr(double t)
{
    return (9.0 * t) / 5.0 + 32.0;
}

inline double cels(double t)
{
    return (5.0 * (t - 32.0)) / 9.0;
}

extern double fahr(double);   ①

double convert(int is_fahr, double temp)
{
    return is_fahr ? cels(temp) : fahr(temp);   ②
}

在上面这个例子里,函数fahr是个全局函数:因为在①处将fahr声明为extern,因此在②处调用fahr的时候使用的一定是这个文件内所定义的版本(只不过编译器可以将这里的调用进行内联展开)。在文件外部也可以调用这个函数(说明像gcc的inline一样,编译器在这种情况下会为fahr生成独立的汇编码)。

而cels函数因为没有在文件范围内被声明为extern,因此它就是前面所说的“inline definition”,这时候它实际上仅能作用于本文件范围(就像一个static的函数一样),外部也可能存在一个名字也为cels的同名全局函数。在②处调用cels的时候编译器可能选择用本文件内的inline版本,也有可能跑去调用外部定义的cels函数(C99没有规定此时的行为,不过编译器肯定都会尽量使用文件内定义的inline版本,要不然inline函数就没有存在的意义了)。从这里的表现上看C99中未被声明为extern的inline函数已经和gcc的extern inline十分相似了:本文件内的inline函数可以作为外部库函数的替代。

重要

C99标准中的inline函数行为定义的比较模糊,并且inline函数有没有在文件范围内被声明为extern的其表现有本质不同。如果和gcc的inline函数比较的话,一个被声明为extern的inline函数基本等价于GCC的普通inline函数;而一个没有被声明为extern的inline函数基本等价于GCC的extern inline函数

因为C99的inline函数如此古怪,所以在使用的时候,建议为所有的inline函数都在头文件中创建extern的声明:

foo.h:

extern foo();

而在定义inline函数的c文件内include这个头文件:

foo.c:

#include "foo.h"

inline void foo()
{
    ...;
}

这样无论是用gcc的inline规则还是C99的,都能得到完全相同的结果:foo函数会在foo.c文件内被内联使用,而在外部又可以像普通全局函数一样直接调用。

2.3. extern inline

C99没有见到extern inline的用法。

2008/2/14

猪哥修改版搜狗拼音3.2——支持华丽Cleartype!

下周一就要开始痛苦的上班了,趁着还有2天假,赶紧研究了一下我想改已久的搜狗拼音输入法。

这搜狗拼音和以前老版本的紫光一个德性:不支持Cleartype。搞得我根本没法用雅黑来做输入法的字体。而宋体在调大以后就不堪入眼,所以输入时只好一直忍受小小的16号宋体,即使是在我可怜的14寸1400×1050的显示器上也不得不这样忍受。

不过经过俺今晚天才、辉煌而又成功地修改,搜狗拼音不支持Cleartype已经成为了历史。修改方法是用IDA Pro反汇编( ̄口 ̄)!!,我反啊反,找到了搜狗设置输入栏字体的地方。看了看代码,前看后看,还是没明白为啥搜狗非要关掉Cleartype支持。既然没发现啥危险,我就打开他算了。另外发现实际上搜狗也能像拼音加加那样支持是否使用粗体斜体什么的显示的,只是搜狗很恶心地把英文字母硬编码用粗体,中文硬编码用正常体显示罢了~~难道是以前紫光遗留下来的历史问题?!(紫光是我唯一见到的字体配置和搜狗一样怪的输入法)。

修改的位置如下:

SogouPY.ime:
0x51C5D: 04 → 00
0x51EDD: 04 → 00
0x51DAD: 04 → 00

config.exe:
0x3A4bD: 04 → 00
0x3A60D: 04 → 00
0x3A73D: 04 → 00

不想自己改的,下载我改好的版本:点击下载

注意,上面修改只能用于搜狗拼音3.2正式版!!使用后搜狗拼音在系统打开Cleartype的情况下也会使用Cleartype渲染字体:



不只是可以用用雅黑之类的字体,在大字体显示的时候我的修改版本也有明显优势。以下是修改前官方原版的搜狗显示效果:



这是修改之后的效果:



明显,打开Cleartype支持以后的效果要好很多。奇怪的是搜狗不但不支持,更是在代码内费心故意关闭了Cleartype支持~~不清楚开发者是怎么想的啊(﹀_﹀")