こんばんは、川合です。
test046とtest047をベータリリースしました。
test046はtest013（未公開）のマイナーチェンジ版で、XORでlineを
引いて、模様を描くだけです。これはあまり説明は要らないでしょう。
test047は、sprintf()（というかcprintf()になっていますが）のサ
ンプルです。サンプルのみならず、OSASKの今までのライブラリが再編
されています。strncmp()もGOを作るときにバグフィクスしたので、バ
グフィクス版が入っています。
今までは.libファイルがいくつもありましたが、これを2つに再編し
ました。OS（API）に依存するgg00libc.lib、そしてOSには依存しない
（コンパイラだけに依存する）golibc.libです。
さらにGOのときに作ったライブラリから、以下を持ってきました。
<stdio.h>
sprintf() %s と %d のみサポート
vsprintf()
<stdlib.h>
abs()
qsort()
strtol()
strtoul()
<stddef.h>
size_t
<stdarg.h>
va_start()
va_end
va_arg
va_copy()
va_list
<setjmp.h>
setjmp()
longjmp() valは1しか渡せません、たぶん
<math.h>
ldexp()
frexp()
<limits.h>
たぶんフルセット
<float.h>
たぶんフルセット
<errno.h>
errno
これらはOSに依存しない関数なので、簡単に持ってこられました。そ
れで、test047では、sprintf()を使って（というかvsprintf()を使って
）、cprintf()を作りました。
この新しいライブラリは、guigui00.rulの変更をしないと利用できま
せんが、しかしソースやMakefileを変更する必要はありません。完全上
位互換です。・・・この新ライブラリにバグがなければ、の話ですが。
さてこれがなぜ正式版ではなくtestのおまけなのかというと、作り直
したライブラリのテストをほとんどしていない上に、lib_putstringg0
などの書き加えるべき新関数を書き加えていないからです。テストをし
て書き加えたら、正式にリリースして、introaにもバンドルする予定で
す。
まあとにかく、cprintf()で遊ぶことはできます。
FORM-Akkie さんは 2003/09/24 11:42:53 の「[OSASK 6483] FORM: Re:
要望になってしまいますが」で書きました：
>お名前: ベイサイド
>... の部分さえ実装していただければあとは自分でなんとかします。
これはですね、<stdarg.h>を使えば（NASK等に手を染めなくても）OK
だったのですが、まあGOの<stdarg.h>がそのまま使えるというのはご存
じなかったかもしれませんね・・・。これからはintroaにバンドルされ
る予定なので、この問題は解決するでしょう。
（sprintf()を）
>乱用する人はいるでしょうね（笑）
>
>ライブラリーをどれだけ小さく作れるが腕の見せ所でしょうか。
いや、そうともいえません。僕は常々、ANSI-Cの標準ライブラリは駄
目なライブラリだと思っているので（確かにprintf族は便利です。問題
はfreadやfwriteなどで、標準ライブラリではメモリマップトファイル
を生かしにくい関数構成になっています。どんなOSでもメモリマップト
ファイルのほうが速いのに、です。だからこのライブラリを使う限り、
性能的には二流のプログラムしか書けません。移植性は高まりますが）
、OSASKではそもそもANSI-Cのライブラリを書きやすくするための配慮
をしていません。だからライブラリはあまり小さくならないでしょう。
僕は、標準ライブラリを積極的に使ったプログラムを「ダメプログラ
ム」だと思っていますから、そのダメプログラムのために良いライブラ
リを作る気はほとんどなくて、まあ動けばいいや、程度です。標準ライ
ブラリを使って作っている時点で「小さくする気はない＆速くする気は
ない」と言っているようなものかと。
標準ライブラリは、入出力がしょぼいだけで、そのほかのところはそ
れほど悪くないです（というかいいものもあります）。だから、その辺
は利用してもいいと思いますし、ライブラリを小さくする努力はやるつ
もりです。
>初心者がHello Worldを試すために使うなら許されるのではないかと。
>どっちみちグラフィックアプリを作るならguigui00.libに頼るしかないわけですから。
>それでも質のよいコンソールゲーム（RPG,ADV）が出てくる可能性はあります。
いやー、それでもprintf()を使わないほうが効率がいいんですけどね
え。printf()はただコンソールにだらだらと流すには悪くない関数です
が、表示位置やカラーを変更するにはエスケープシーケンスを使わなき
ゃいけないとか、そういう事があるわけです。
最初にprintf()でスタートすると、たいていはそれを引きずります。
画面を消去するには、'\n'を30個くらい表示すればいいやとか、そうい
う発想になります。カラーを変更するのはエスケープシーケンスで、カ
ーソル移動もエスケープシーケンス。こんなのを相手にするためにcput
s()はエスケープシーケンス対応になったりすると思いますが、これは
非常にばかばかしい状況です。
'\n'を30回表示するということは、全画面更新を30回もやることにな
ります。カーソルを左上に戻して、スペースで埋め尽くせば、負荷は
1/30で済みます。また、カーソル位置をエスケープシーケンスで表現す
るためにprintf()の%dを使って苦労して10進数文字列化し、それをcput
sのエスケープシーケンス読解ルーチンがせっせとバイナリに戻して、
しかるべき処理をするわけです。カラーコードも同じです。
・・・こんな無駄をやって楽しいでしょうか。ネットワークを通さな
きゃいけないとか、ファイルに保存しなきゃいけないというなら分かり
ますが、そんなのは通さなきゃいけないときにOSがやってあげればいい
ことです。アプリが常にやることではありません。僕はそう思います。
このせいでネットワーク越しでもないのにエディタの反応が悪かったり
するわけです。
printf()でプログラムの書き進めた後で、ああこれは愚かだと気が付
いても、たいていは書き直しません。めんどくさいですからね。それが
心配です。printf()がなまじっか便利なだけに、なおさらなんです。
だから僕の今の方針では、最初からlib_〜というAPI関数をいきなり
やるわけです。最初の障壁は確かにありますが、これしかないと言われ
れば、まあしぶしぶやるわけです。それで、そのまま着々と上達してゲ
ームを作ってくれたりするわけですが、それはみんな、小さくて速くて
無駄が少なくて、とてもOSASKらしいソフトウェアなわけです。
>そうなんです。デバッグのときに使いたいんです。
>現在でもコンソールなし版Wabaはコンソールあり版Wabaよりちょっと小さいですしね。
>
>int a = 10;
>char* b = "hoge";
>cputs("a = ", stdout);
>cputs(setdec(a));
>cputs(", b = ", stdout);
>cputs(b);
>cputs("\n");
>
>と書かなきゃいけないものが、
>
>printf("a = %d, b = %s\n, a, b);
>
>となると涙がでるほど嬉しいんですよ。
そんな僕でしたが、この説明には心打たれるものがあり、ああ、ベイ
サイドさんのためにGOに作ったやつを持ってこようかな、と思ってしま
いました。Wabaの場合、本当にデバッグにしか使わなそうですもんね・
・・。
ということで、test047に至るわけです。
僕の今後の方針としては、sprintf()などは提供するが、introaなど
最初のほうでは絶対に説明しない、という方針で行きたいと思います。
introeあたりで、ちょこっとでてくるとか、そんな感じで。デバッグに
使うと便利だねーってことで。
>Wabaのエンジンはできるだけ効率を重視したいと思っていますが、Wabaで動くアプリは
>できるだけ楽をしたいというのが本音です。そのために私は一生懸命Wabaを作ってます。
それは非常に理にかなっていると思います。
WabaのエンジンはOSASKアプリですから、効率を重視していただける
と非常に嬉しいです。そしてWabaアプリは、プラットフォームを選ばな
いで実行できることが最大の特徴なのですから（＝つまり、効率が特徴
ではないのですから）、それほど効率にこだわる必要はないでしょう。
効率が必要なら、Wabaアプリとしてではなく、OSASKアプリとして作れ
ばいいわけです。
それでは。
--
川合 秀実(KAWAI Hidemi)
OSASK計画代表 / システム設計開発担当
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/