HIRAUCHI Hideyuki
hira****@verys*****
2004年 2月 20日 (金) 21:45:56 JST
おはようございます。平内です。
#まさか、昨日の夜中に投げたメールが今日の夕方に届くとは。。。
#会社から帰ってきてびっくり。このメールは今日中に届くのか？
CRLF,LF時のpeekで行数がカウントアップされるバグを修正しました。
#Scm_Getcの引数を増やしたかったのだけど、挫折しました。
#結局、こんな変テコリンな方法になってしまった（末尾のパッチ参照）。
いや、しかし、どうも、SAFE_PORT_OP関連のマクロが強敵なんですよね。
このマクロを眺めていると頭が真っ白になって、何も出来なくなっちゃう。
全く手が動きません。
ああ、このマクロを無しにして、関数にinlineつけるっていう風にしたい。
それにinline化すると、下の4つの関数が簡単に作れるんですよね。
1. getc ;mt-unsafe
2. line_counter(getc) ;mt-unsafe
3. lock(getc) ;mt-safe
4. lock(line_counter(getc)) ;mt-safe
現状、2+with-port-locking,4が提供されてますが、ポートを開くときのオプションで
1-4を選べる、なんてのもありかなと。
>Javaのポートは設計としては綺麗だと思いますが、
>コンパイラがインライン展開しまくらない限り、
>性能を出すのが難しそうだなと思いました。
そうなんですよね。
やっぱりコードサイズの肥大化を懸念してます？コンパイラ依存の問題とか？
でも、まあ、ちょっと試しに、全面的にinlineを採用したportapi_inline.cを
書いてみようかと思ってます。それでどう変わるのか比べてみようと。
いま、CR対応のためにScm_Getcの引数に再帰レベルみたいな物が欲しいんですけど、
現状のportapi.cをいじろうとすると、私の頭は真っ白になってしまうので。。。
以下、パッチ(泣)
--hira
--- portapi.c.org 2004-02-20 20:10:50.579500000 +0900
+++ portapi.c 2004-02-20 20:18:54.298250000 +0900
@@ -301,14 +301,17 @@
ScmChar Scm_PeekcUnsafe(ScmPort *p)
#endif
{
+ int line;
ScmChar ch;
VMDECL;
SHORTCUT(p, return Scm_PeekcUnsafe(p));
LOCK(p);
+ line = p->src.buf.line;
if ((ch = SCM_PORT_UNGOTTEN(p)) == SCM_CHAR_INVALID) {
ch = Scm_GetcUnsafe(p);
SCM_PORT_UNGOTTEN(p) = ch;
}
+ p->src.buf.line = line;
UNLOCK(p);
return ch;
}