K.Maebashi's BBS

つよしさん、はじめまして。 >debian lenny でコンパイルエラーになります。 >何が足りないのでしょうか？ >gcc は、4.3 ヴァージョンをインストールしました。 >$ make … >make[1]: yacc: コマンドが見つかりませんでした 見てのとおり、yaccが入っていません。 Debianなら、bisonをパッケージインストールすれば、シンボリックリンクを 勝手に作って、「yacc」で実行できるようになったような気がします。 gccやyaccが標準で入っていない環境なら、おそらくlexも入っていないでしょうから、 flexも入れる必要がありそうです。 もし、bisonやflexは入れたけれど「yacc」や「lex」としては実行できない、 ということなら、compilerディレクトリ以下のMakefileを修正し、 yacc -dv diksam.y となっているところ(2箇所)を、 bison --yacc -dv diksam.y に、 lex diksam.l となっているところを flex diksam.l にしてください。 それはそれとして、 >（Linux版では、Ｕフォーは、ダメですか？：入門者） 残念ながらダメです……

前橋さま debian lenny でコンパイルエラーになります。 何が足りないのでしょうか？ gcc は、4.3 ヴァージョンをインストールしました。 （Linux版では、Ｕフォーは、ダメですか？：入門者） $ make cd ../compiler; make; make[1]: ディレクトリ `/home/tntn/Desktop/diksam_unix/compiler' に入ります yacc -dv diksam.y make[1]: yacc: コマンドが見つかりませんでした make[1]: *** [y.tab.h] エラー 127 make[1]: ディレクトリ `/home/tntn/Desktop/diksam_unix/compiler' から出ます make: *** [../compiler/compiler.o] エラー 2 $

前橋さま ウィンドウズ版Diksamの公開おめでとうございます。 Ｕフォーの絵　見ました。それが動いたりするのですか？すごい！！ Linuxから書き込んでいますが、Linuxでは、Ｕフォーは出来ないのかな？

こんにちは。 >前橋言語の作例は、ありませんか？ すみません、今のところサンプルプログラムとしては配布ディレクトリの compiler/test以下にあるものぐらいしかないです。 >パズルとか電卓とか？ >前橋さんの電卓ネタを前橋言語で書き換えるとか？ Diksam用のyaccはないので、再帰下降パーサを手書きすれば電卓ぐらいは 作れそうではありますが、文字列処理の手段がsubstr()しかなくて、 もちろんそれでもできますけれど効率が悪いので、"abc"[2]で'c'が取れるように したりとか、当然同時に文字リテラルも必要になって、とか、 いずれにしてもライブラリがこれではたいした物は作れないのでライブラリを 補強して、とか、やりたいことはいくつもありますし実現も難しくないのですが、 何をするにも時間が不足しております。 ライブラリの方は現在追加してまして、近々、何かしらちょっとは楽しいプログラムが 作れるようにしようとは思っているのですが。 すみません、Macユーザのたろうさんには大変申し訳ないのですが、今度追加される ライブラリ部分は当面Windows専用になります…

管理人（前橋）さま 前橋言語の作例は、ありませんか？ パズルとか電卓とか？ 前橋さんの電卓ネタを前橋言語で書き換えるとか？

>>$(CC) $(CFLAGS) -o $@ -I../../include builtin_conv.c $(CONV_OBJS) >> ↑ >> >>としてやればうまくいくのではないでしょうか。 > >前橋さん >コンパイル通りました。 情報ありがとうございます。次回リリースからは、Makefileを修正しておきます。 Macでも動いたということで、嬉しいです。

再帰も出来ますね！あたりまえ？ 何か使えそうな気配です！！ $ vi saiki int fact(int n) { if (n==0) { return 1; } else { return n*fact(n-1); } } println(fact(3)); println(fact(4)); println(fact(5)); println(fact(10)); $ diksam saiki 6 24 120 3628800 $

> >ここでこういうエラーが出ているということは、diksamの展開ディレクトリ以下の、 >compiler/builtinディレクトリのMakefileの20行目の > >$(CC) $(CFLAGS) -o$@ -I../../include builtin_conv.c $(CONV_OBJS) > >の「-o$@」の「-o」と「$@」の間に空白を入れ、 > >$(CC) $(CFLAGS) -o $@ -I../../include builtin_conv.c $(CONV_OBJS) > ↑ > >としてやればうまくいくのではないでしょうか。 前橋さん コンパイル通りました。 感謝、感激です。 ありがとうございます。 試してみました。 スキル不足でこんなのでいい？ ＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾ $ vi ppp.dk println("hello, たろう."); int s = 0; int i; for (i=1; i<=10; i=i+1) { s += i; print(i); println(" たろう"); } $ diksam ppp.dk hello, たろう. 1 たろう 2 たろう 3 たろう 4 たろう 5 たろう 6 たろう 7 たろう 8 たろう 9 たろう 10 たろう $ ＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾ 以上。

こんにちは。 >　マックosx で、コンパイルしたいのですが可能ですか？ >powerpc g3 インテルマックでは、ありません。 (略) >ld: unknown flag: -obuiltin_conv MacOS XのCコンパイラがどんなコンパイラなのか私は知らないのですが、 「-obuiltin_conv」というオプションはないよ、というエラーを出しています。 ここは、「-o」というフラグで実行形式の名前を指定しているところで、 私の知っているたいていのコンパイラでは、-oの後ろに空白を入れても入れなくても OKでした。 ここでこういうエラーが出ているということは、diksamの展開ディレクトリ以下の、 compiler/builtinディレクトリのMakefileの20行目の $(CC) $(CFLAGS) -o$@ -I../../include builtin_conv.c $(CONV_OBJS) の「-o$@」の「-o」と「$@」の間に空白を入れ、 $(CC) $(CFLAGS) -o $@ -I../../include builtin_conv.c $(CONV_OBJS) ↑ としてやればうまくいくのではないでしょうか。 確証はありませんが >ld -r -o mem.o memory.o storage.o このへんでは-oオプションがちゃんと効いているところからすると可能性は 高いと思います。 実際に試してくださった方がいらっしゃると励みになります。ありがとうございました。

diksam_0_4_unix.tgz 前橋さま 　マックosx で、コンパイルしたいのですが可能ですか？ powerpc g3 インテルマックでは、ありません。 makeの実行画面を示します。 ＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾ $ tar zxf diksam_0_4_unix.tgz $ ls diksam_0_4_unix.tgz diksam_unix/ $ cd diksam_unix/compiler/ $ make yacc -dv diksam.y lex diksam.l cc -c -g lex.yy.c -I/usr/local/include -I../include cc -c -g y.tab.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG main.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG interface.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG create.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG fix_tree.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG generate.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG string.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG wchar.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG util.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG error.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG error_message.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG builtin/builtin.c -I/usr/local/include -I../include cd ../dvm; make; cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include execute.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include load.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include heap.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include native.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include nativeif.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include wchar.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include util.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include error.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include error_message.c ld -r -o dvm.o execute.o load.o heap.o native.o nativeif.o wchar.o util.o error.o error_message.o cd ../share; make; cc -c -g -I../include -DDEBUG -Wall -ansi -Wswitch-enum -I../include dispose.c cc -c -g -I../include -DDEBUG -Wall -ansi -Wswitch-enum -I../include opcode.c cc -c -g -I../include -DDEBUG -Wall -ansi -Wswitch-enum -I../include disassemble.c cc -c -g -I../include -DDEBUG -Wall -ansi -Wswitch-enum -I../include wchar.c cc -c -g -I../include -DDEBUG -Wall -ansi -Wswitch-enum -I../include util.c ld -r -o share.o dispose.o opcode.o disassemble.o wchar.o util.o cd ../memory; make; cc -c -g -DDEBUG -Wall -I../include memory.c cc -c -g -DDEBUG -Wall -I../include storage.c ld -r -o mem.o memory.o storage.o cd ../debug; make; cc -c -g -Wall -DDBG_NO_DEBUG -I../include debug.c ld -r -o dbg.o debug.o cd ./builtin; make; cc -g -DDEBUG -Wall -ansi -Wswitch-enum -obuiltin_conv -I../../include builtin_conv.c ../../memory/memory.o ../../debug/debug.o ld: unknown flag: -obuiltin_conv make[1]: *** [builtin_conv] Error 1 make: *** [diksam] Error 2 $ ＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾

ローカルにPHP5の環境を作ったのですが、デフォルトのphp.iniの設定が違いすぎていて、まだ一部動かせていません。 magic_quotes_gpcはOffだわ(これは正しいのですが)、asp_tagsはOffだわ、short_open_tagもOffだわで、これではサーバがPHP5に移行した際、どんな設定になっているかが問題のように思います。 ……と思っていたら、どうもPHPの移行には混在期間があって、当面は今のままで動くようです(PHP5にしたければ拡張子を変えろと)。なので今日はもう寝ます。

この掲示板(を含むうちのWebページ一式)をホスティングしてくれている会社から、 以下の通知が来ました。 >この度、Zend社のPHP4サポート終了の告知を受けまして、サーバーシステムの >保全のため、PHP5へのアップデートを行います。全共用サーバーにおきまして、 >PHP4のご利用ができなくなります。至急設置スクリプトの対応状況をご確認、 >更新をお願いいたします。 この通知が来たのはだいぶ前のことなのですが、いろいろあって放置しているうちに、 変更の期日が10/29に迫ってしまいました。 この掲示板を作った時点の環境は当時のPCが壊れた時点で失われていて、 今現状のLet's Noteの環境にPHPとApacheを入れてみたのですが、まだPHPが 動かせていないようです。 もうちょっといじってみるつもりですが、10/29の時点でこの掲示板が動かなく なっていたら、それが原因とお考えくださいませ。

>（ぱ）さんが、賞金１万円出して >（ぱ）さんが作ったOSで、プログラミングコンテストをする。 OSを作った覚えはないので、プログラミング言語ですかね。 1万円というと、いにしえのBASICマガジンの原稿料がそれぐらいだったと思います。 ベーマガ相当のプログラムが集まるのなら、最優秀賞に1万円くらい出すのは 惜しくないですが、結局ほとんど集まらず、hello, worldに1万円出すハメに なったりして。

（ぱ）さんが、賞金１万円出して （ぱ）さんが作ったOSで、プログラミングコンテストをする。 無責任な書き込みでした。本気！

今回実行していた「app.exe」が処理が成功しているにもかかわらず、 '1'を返していたため、makeが その戻り値を検出し、処理を停止してしまって いたようです。 ('-'を付加することにより逃げました。） 774RRさんありがとうございました。

返信、ありがとうございます。 >なので app.exe target.dat 0<source.dat は本質的に正しい入力であって、 なるほど、そうなんですか。 >なので 0< となるのは「実行できない」の原因ではないと思われまっする。 >「実行できない」の詳細について記載がないのでこれ以上の判断は出来ません。 >本体プログラム側のバグを疑ってください。 今回実行したい「app.exe」が特にエラーメッセージを表示せず、 何故実行できないのかわからなかったため、この'0'が付加することによるのかな と想像してしまいました。 仰るとおり、本体プログラム側を疑って調査してみます。 ありがとうございました。

標準入力のリダイレクトは < で行うのですがこれは本来 0< の略記なのです。 http://itpro.nikkeibp.co.jp/article/COLUMN/20060228/231093/ たとえば un*x のコンソール上では $ cat hoge.txt Hoge! $ cat 0<hoge.txt Hoge! $ // と、このように同じ動作をするのが正常な動きでありんす。 んで XP/2000 のコマンドプロンプトである cmd.exe もこの表記を受け付けます。 D:\MYWORK>cat 0<hoge.txt Hoge! D:\MYWORK> なので app.exe target.dat 0<source.dat は本質的に正しい入力であって、 期待したとおりに動くはずです。実際俺のところでは cmd.exe bash.exe の両方で このように0<と手入力しても期待通りの正しい動きをします。 さてここまで納得していただけたでしょうか。この例の場合、バッチファイル中には < としか書いていないリダイレクト記号を、誰かが勝手に (make がやっているのか cmd.exe がやっているのか、他の誰かかは不明) 0< と置換しているわけです（実害ないけど妙なことをやってるよね・・・） 0< となっていても俺んとこでは期待通り動作しています。 なので 0< となるのは「実行できない」の原因ではないと思われまっする。 「実行できない」の詳細について記載がないのでこれ以上の判断は出来ません。 本体プログラム側のバグを疑ってください。

cygwin をインストールして確認しましたが、 やはり、Borlandのmakeと同じ結果でした。 確認方法は、下記のようなmakefile及び バッチファイルを用意して、 (ダミーの"source.dat"と"app.exe"も用意して) --- makefile -------------------- target.dat : source.dat test.bat --------------------------------- --- test.bat -------------------- app.exe target.dat < source.dat --------------------------------- cygwin上？でmakeを実行しました。 すると、やはり'<'の前に'0'が付加されます。 --------------------------------- $ make test.bat app.exe target.dat 0<source.dat ~ --------------------------------- 何故でしょうか? 環境は、下記です。 GNU make 3.81 Windows XP Professional Version 2002 Service Pack 2

>file1.hoge ではなく hoge1.txt みたいに８文字ドット３文字以下の >過去互換性重視なファイル名に変えてみると良いかもしれん、ということぢゃ >直るかもしれんし、直らんかもしれん。どっとはらい。 理解できました。ありがとうございました。 引き続き試してみます。

ちなみに GNU make はソースコード提供なので開発環境がないと作れない make 自体は開発環境の一部であり、これがうまく動かないのではコンパイルできない という自己矛盾の状況に陥るわけだ。 cygwin 開発環境一式持ってくるほうが結局面倒が無いかも知れんっす。 そーすると gcc コンパイラ自体も入手できちゃうので某の出番は無い可能性が・・・ 掲示板のスペースで cygwin の解説など不可能っぽいので http://journal.mycom.co.jp/special/2002/cygwin/index.html

むかしむかし、あるところに MS-DOS というものがあってのぉ MS-DOS ではファイル名に「８文字以下 ドット ３文字以下」しか使えなかったのぢゃ その関係でなぁ、 Win95 以後のソフトでも８文字ドット３文字のファイル名しか 扱えないような、そーいう過去互換性重視なモノもあったのぢゃよ # 某の make がそういう過去互換重視なものかどうかは知らんがのぉ hoge.exe は４文字ドット３文字だから問題ない file1.txt は５文字ドット３文字だから問題ない のぢゃが file1.hoge や file2.piyo は５文字ドット４文字なのでな、 過去互換性重視なソフトに取っては非互換なファイル名なのぢゃよ file1.hoge ではなく hoge1.txt みたいに８文字ドット３文字以下の 過去互換性重視なファイル名に変えてみると良いかもしれん、ということぢゃ 直るかもしれんし、直らんかもしれん。どっとはらい。

返信ありがとうございます。 GNU makeで試してみます。 ただ、 >俺の Makefile のように 8.3 コンパチなファイル名で試してみること推奨 この意味がわかりませんので、よろしければ教えてください。

cat > Makefile <<EOF file1.txt: file2.txt hoge <tab>./hoge file1.txt < file2.txt hoge: hoge.c EOF ということで GNU make で試したけど無問題っす (HPUX11.11 と cygwin) borland の make ではなく GNU make で試してみませう 某の make がどうしてもいい、ってことなら 俺の Makefile のように 8.3 コンパチなファイル名で試してみること推奨

皆さんこんにちは、tosです。 makeファイル中で以下のように リダイレクトを要求するexeを実行したいのですが、 正常に実行できません。 ------------------------------------------- FILE1.HOGE : FILE2.PIYO Hoge.exe FILE1.HOGE < FILE2.PIYO ------------------------------------------- 「正常に実行できません」の内容は、最初エラー メッセージのみでわからなかったんですが、 ためしに、上記の2行目をBAT呼び出しにしたところ、 下記のように何故かリダイレクト起動に前に'0'が 付加されていました。 ------------------------------------------- Hoge.exe FILE1.HOGE 0<FILE2.PIYO ------------------------------------------- この'0'は何故付加されるのでしょうか? ちなみに、makeは「BorlandのVersion 5.2」 を使用しています。

どうもです。遅くなりましてすみません。 774RRさん： >テストＢＢＳが広告だらけですが、どうせテストだし管理しない方針でしょうか？ >ほげほげ認証だけでもつければまた違いそうですが すみません、面倒なので放置しています。 表掲示板とテスト掲示板は同じプログラムで、GETパラメタで動きを変えている だけなので、ほげほげ認証はテスト掲示板にも付いています。 ほげほげ認証導入以後、日本語以外のspamはまったくないようなので、 人力で書いているんですかね。 yuyaさん： >というわけでテスト板見ようとしたんですが、Firefoxでは >>「テスト書き込みの類はテスト用掲示板にどうぞ。」 >のリンクが効いておらず見に行けませんでした。 このメッセージははD/Bに入っていて、掲示板作成用のWeb画面は作ったものの 更新画面がなくて、放置してしまっていました。すみません。 今、手でSQLを書いて更新したのですが… センタリングを忘れました。 これから出かけるのですみませんがひとまずこの状態で。

>テストＢＢＳが広告だらけですが、どうせテストだし管理しない方針でしょうか？ >ほげほげ認証だけでもつければまた違いそうですが というわけでテスト板見ようとしたんですが、Firefoxでは >「テスト書き込みの類はテスト用掲示板にどうぞ。」 のリンクが効いておらず見に行けませんでした。 ソース見ると、<a>タグに文法ミスがありますね。 IEだと善意に解釈されてリンクしてるんですが。

テストＢＢＳが広告だらけですが、どうせテストだし管理しない方針でしょうか？ ほげほげ認証だけでもつければまた違いそうですが

前橋さま コンパイル通りました。 $ ./mycalc >9; >>9 >1+2+3+4+5+6+7+8+9+10; >>55 > mycalc も実行できます。行編集もできます。 ありがとうございます。感謝感謝！！です。 言われますように次ぎの通り修正しました。 $ cat -n Makefile ＜略＞ 14 INCLUDES = -I/opt/local/include 15 16 $(TARGET):$(OBJS) 17 $(CC) $(OBJS) -o $@ -L/opt/local/lib -lreadline -lfl -lm ＜略＞

>13: CFLAGS = -c -g -Wall -I/opt/local/include >14: INCLUDES = \ >15: >16: $(TARGET):$(OBJS) >17: $(CC) $(OBJS) -o -L/opt/local/include $@ -lreadline -lfl -lm まず、-Lの指定は間違っています。 ・-oオプションはできあがる実行形式の名前を指定するオプションですし、 　makeでは、$@がターゲットの名前を指します。よって「-o $@」で組なので 　その間に-Lを入れてはいけません。 ・/opt/local/includeは、その名のとおり#includeするファイルを置くところだと 　思うので、ライブラリは別のところにあるはずです。 　MacOSのディレクトリ構造は知りませんが、おそらく/opt/local/libあたりに、 　libreadline.aとかlibreadline.soなんとかというファイルがありませんか? 　だとすれば、 >17: $(CC) $(OBJS) -o $@ -L/opt/local/lib -lreadline -lfl -lm でいいと思います。 ただ、エラーメッセージが今でも >cc -c -g lex.yy.c >calc.l:6:31: readline/readline.h: No such file or directory こうだというのなら、-Iも失敗しているようです。 …そう思ってMakefileを見直して気付きました。 CFLAGSはlex.yy.cの規則のところでは使っていませんでした。すみませんこちらのミスです (_o_) 14行目の INCLUDES = \ を、 INCLUDES = -I/opt/local/include としてみてください。

すいません 忙しく今bbsを見ました。 積極的にアプローチしてませんが、 電卓を勉強したい人が、スムーズに電卓に入っていけるようになったらなーとも思います。 >とのことなので、もうreadlineを動かしたいとは強くは思っていないように思いますし、 >それなら外野がとやかく言うこともないかな、とも思いますし。 13: CFLAGS = -c -g -Wall -I/opt/local/include 14: INCLUDES = \ 15: 16: $(TARGET):$(OBJS) 17: $(CC) $(OBJS) -o -L/opt/local/include $@ -lreadline -lfl -lm 13: と 17: を変更しました。 ./memory/　と　./debug/ で make は成功します。 mycalc/ で make すると $ make bison --yacc -dv calc.y flex calc.l cc -c -g lex.yy.c calc.l:6:31: readline/readline.h: No such file or directory calc.l: In function `tty_input': calc.l:87: warning: assignment makes pointer from integer without a cast make: *** [lex.yy.o] Error 1 $ お願いします。-Ldir の記述例もお教えください。僕の-Ldirは的を外していると思います。

>まず、どういう指定をしたか、具体的に書きましょう。 一般的にはそうですけど、今回について言えば、つんつんさんは >readline 使っていない方のサイトで　勉強したいと思います。 とのことなので、もうreadlineを動かしたいとは強くは思っていないように思いますし、 それなら外野がとやかく言うこともないかな、とも思いますし。

>現状：： >readline.h は　　/opt/local/include/readline/readline.h　です。 >-L も指定したつもりですが、あっているか分かりません。 まず、どういう指定をしたか、具体的に書きましょう。 エスパーじゃないんですから、「-L も指定したつもり」とだけ書かれても、 実際に何をどう指定したのか、つんつんさん以外にはさっぱり分かりません。

前橋さま まだエラーになります。 現状：： readline.h は　　/opt/local/include/readline/readline.h　です。 -L も指定したつもりですが、あっているか分かりません。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー EasyPackage　というパーケージ管理でreafline をインストールすると 標準　/usr/local にインストールされます。 その状態では、mycalcのコンパイル成功します。 しかし、複数のパッケージ管理を使いたくないので EasyPackage　の readline は、アンインストールしました。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー パッケージ管理 MacPorts で　/opt/local/include/readline/readline.h　に インストールした状態で、mycalcをコンパイルすることは、難しいです。

>readline は、/opt/local/include/readline/　にインストールされていました。 … >「コンパイラの-Iオプション」に加えるということが分かりませんので >readline 使っていない方のサイトで　勉強したいと思います。 了解です。 まあ一応書いておくと、今回の例ならトップディレクトリのMakefileに CFLAGS = -c -g -Wall という行がありますが(13行目)、ここに CFLAGS = -c -g -Wall -I/opt/local/include のように-Iを追加すればコンパイルは通るようになると思います。 インクルードのパスが通ってない以上、リンクのパスも通っていない可能性が ありますが、その場合は17行目の $(CC) $(OBJS) -o $@ -lreadline -lfl -lm ここに-Lオプションを加えるとかします。 詳細はこのへんを参照してください。 http://www.asahi-net.or.jp/~wg5k-ickw/html/online/gcc-2.95.2/gcc_2.html#SEC14

>「C言語 体当たり学習徹底入門」正誤表に載っている「ほげを考えるページ」へのリンクがniftyのURLのままです。 ご指摘ありがとうございます。 ポインタ完全制覇、体当たり学習、Java謎+落とし穴すべてについて 新URLへのリンクを付けておきました。 どの本も移転前だったんだなあ… (遠い目)

＞もし入っているのであれば、コンパイラの-Iオプションにそこを加えれば ＞よいですし、入っていないのであれば拾ってきて入れることになります。 前橋さま ありがとうございます。 readline は、/opt/local/include/readline/　にインストールされていました。 MacOSX では、readline : いろいろなインストール方法により /opt/local や /sw/local ? や /usr/local にインストールされるみたいです。 「コンパイラの-Iオプション」に加えるということが分かりませんので readline 使っていない方のサイトで　勉強したいと思います。

「C言語 体当たり学習徹底入門」正誤表に載っている「ほげを考えるページ」へのリンクがniftyのURLのままです。

こんにちは。 >MacOSX で電卓使いたいとコンパイルしたのですが、エラーになります。 … >cc -c -g lex.yy.c >calc.l:6:31: readline/readline.h: No such file or directory このエラーメッセージは、readline.hというファイルが見つからないと言っている わけですから、GNU readlineがインストールされていないのでしょう。 MacOSはよく知りませんが、デフォルトでは入ってなくても無理ない気がします。 実は入っていて、#includeのパスが通ってないだけかもしれませんが。 もし入っているのであれば、コンパイラの-Iオプションにそこを加えれば よいですし、入っていないのであれば拾ってきて入れることになります。 このページからダウンロードできるようです。 http://tiswww.case.edu/php/chet/readline/rltop.html インストールの方法はここにありました。 http://tiswww.case.edu/php/chet/readline/INSTALL GNUのソフトらしく、 ./configure make make install でインストールできるようです。 ただ、電卓を作るための勉強用なら、こちらの方が簡単でよいかと思います。 GNU readlineも使っていませんし。 http://kmaebashi.com/programmer/devlang/yacclex.html

その4 「電卓を作ってみよう」 MacOSX で電卓使いたいとコンパイルしたのですが、エラーになります。 前橋さまの電卓試したいのですが、ご教授よろしくお願いします。 $ tar zxvf mycalc.tgz $ cd mycalc $ cd memory/ $ make cc -c -g -Wall memory.c cc -c -g -Wall storage.c ld -r -o mem.o memory.o storage.o $ cd ../debug/ $ make cc -c -g -Wall -I../ debug.c ld -r -o dbg.o debug.o $ cd .. ーーーーーーーーーーーーーーーーここまでは、エラーでませんが $ make bison --yacc -dv calc.y flex calc.l cc -c -g lex.yy.c calc.l:6:31: readline/readline.h: No such file or directory calc.l: In function `tty_input': calc.l:87: warning: assignment makes pointer from integer without a cast make: *** [lex.yy.o] Error 1 $ ーーーーーーーーーーーーーーーーここで、エラーになりました。どうして？？？

>以前から告知されていましたが、niftyのメンバーズホームページはリンクのサービスも停止してしまいましたね。 ありがとうございます。まったく気付いていませんでした。変更しておきました。 ずいぶん長いこと転送してくれていましたから、まあ文句は言えませんね。

トップページ > kmaebashi.comに直接飛ぶように設定できるようになっていたことが判明。今はそのように設定しています。 以前から告知されていましたが、niftyのメンバーズホームページはリンクのサービスも停止してしまいましたね。 トップページの口上が現状と合致しなくなったので、(おせっかいながら)指摘しておきます。

もいちど駄レスしておくと オブジェクト指向な設計、というものはあっても 非オブジェクト指向な設計の元にオブジェクト指向なプログラム、ってのはありえない わけで、「基礎設計したことがないプログラマ」ではＯＯがわからなくて当然。 メタ度が違うっちぅことで。 俺も、基礎設計が気に入らなくなったという理由で、５０％くらい作ったプログラムを 全部捨てて最初から再設計したなんて経験が何度もある。 ただ「実装するだけ」のＯＯでは意味が無いと思うのココロ そーいう人に限って「スーパークラスがごみ置き場」になるわけだ。

>リスコフというと「え、ええと置換原則の人?」程度の私はまだまだ勉強が >必要のようです。 リスコフは「抽象データ型」とか「カプセル化」を考えた（言い出した）人です。 >新しいほうの3系統 >http://d.hatena.ne.jp/sumim/20080415/p1 > >は大変腑に落ちます。 それはよかった。ご紹介痛み入ります。

>新人はさしたる仕事もなく、昨日もオブジェクト指向のサイトを転々としておりました。 ああ、それはうらやましい。 戦力として配置されるとだんだん勉強の時間も削られてくるものですし、 さらに年を食うとろくにコードも書かせてもらえなくなるのがこの業界ですので。 >　継承：共通処理（親）をベースとして差分を子に付け加える。ライブラリを > includeするのと逆の発想。 うーん、これはまさに(最近評判があまりよろしくない)実装継承ですよね。 以前、この辺のスレッドで議論したことがあります。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&thread=270 この中で出ているoo-squareのリンクは、現在切れていますがこっちです。 http://www.ogis-ri.co.jp/otc/hiroba/oosquare-ml/Archive/200501.month/thread.html よく使うメソッドをスーパークラスに置いて、なんてことをやっていると、 http://www.ogis-ri.co.jp/otc/hiroba/oosquare-ml/Archive/200501.month/4468.html | 継承は確たる「設計思想」が無い場合、スーパークラスが単なる「ごみ置き場」 | と化していることが多いようです。 なんてことになってしまう。それよりはむしろ、 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=276&range=1 | 「ほらほら、『使うほう』はその実体が具体的に何であるか気にしなくていいんだよ」 のほうが実際の使いどころに合っていると思いますが、こうなるとインタフェースと 一緒になっちゃうんですよね。実際、「継承なんかどうでもよくてインタフェースこそが 本質なのだ」と言う人もいますし。 じゃあ継承なんかなくていいのかというとそうでもなくて、実際私も使うというのが ややこしいところ。「継承とインタフェースのどっちを使えばいいんですか?」というのは FAQですが、私はこれはもう単純に ・データメンバがメインの構造体的なクラスにフィールドを追加するなら継承を、 ・それ以外はインタフェース でいいんじゃないかな、と思っています。 >　隠蔽：見せたくない処理はlocal変数、local関数にて実装する。 これは実態としてまさにそうだと思います。 よく「その『オブジェクト』だけが知っていればよいことはprivateにするんだ」と オブジェクトごとに丸を描いたりして「カプセル化」としている説明がありますが、 言いたいことはよくわかるものの、C++でもJavaでも実はprivateは 「別のクラスから見えない」だけで「別のオブジェクトから見えない」のでは ないんですよね。 これを、単にC++(およびその派生言語)が腐っているとか実用上の妥協だとか 言うことも可能ですが、私はこれを「privateというのは他の『プログラマ』に 対する隠蔽なのだ」と考えてしまってよいと思っています。 >　多態性：引数に基づき、サブルーチン側でif～elseで処理分岐する。 > またはincludeを変える。 「またはincludeを変える」のほうは良くわかりませんが、1行目は、用途としては そのとおりです。よくある図形(Shape)の描画ルーチンの例のように、 ポリモルフィズムを使うことで、プログラムからswitch caseを排除できます。 Cにはそれがないばかりに巨大なswitch caseを書いてる例： http://kmaebashi.com/programmer/devlang/diksam_src_0_2/S/7.html#693 ポリモルフィズムにおいて、一見単なる実装詳細に見えるけど実は結構重要なのは、 サブクラスを追加しても、呼び出し素(switch caseに相当する部分)再コンパイルの 必要がない、ということですね。だからAppletを継承したクラスを作れば すぐにブラウザで実行できるわけで。 >　マルチプルインスタンス：サブルーチンをメインの実行状況によって任意に > （動的に）増やせる。 うーん、これはどうなんでしょう。オセロの例で言えば、Boardをいくつnewしても、 put()というルーチンは増えないと思うのですが… 「メソッドはインスタンスに付属している」というイメージからすると、 一緒に増えると考えることもできるのかもしれませんが。

こんにちは、sumimさん。(いろいろなところで)いつもお世話になってます。 >すみません（汗）。 いえそんな(大恐縮) >当時はまだリスコフの抽象データ型（カプセル化）について理解があさく、 >ユーザー定義型に手続きを含むか、含まないかで、それぞれを OOP（あるいは、 >手続きによる抽象化。PDA）とするか、ADT（クック独自定義の抽象データ型） >とするかという分類はとてもクールに思えて必要以上に持ち上げてしまいました。 リスコフというと「え、ええと置換原則の人?」程度の私はまだまだ勉強が 必要のようです。 新しいほうの3系統 http://d.hatena.ne.jp/sumim/20080415/p1 は大変腑に落ちます。

返信下さった皆さん、ありがとうございます。興味深く読ませて頂きました。 新人はさしたる仕事もなく、昨日もオブジェクト指向のサイトを転々としておりました。 やはり「猫」の例はヘンですよね。現実世界を模しているならば「鳴けとメッセージを送ると 鳴く」というよりは「腹が減ると鳴く」の方がピッタリでしょう。つまり完全自律型、プログラムで いったら暴走に近いかも・・・。 プログラミングは少々かじったことがあるのですが（学校の実習レベルです）、無理矢理 現実世界に例えるよりはこんな感じの説明の方がイメージに合っていると思います。 　継承：共通処理（親）をベースとして差分を子に付け加える。ライブラリをincludeするのと逆の発想。 　隠蔽：見せたくない処理はlocal変数、local関数にて実装する。 　多態性：引数に基づき、サブルーチン側でif～elseで処理分岐する。またはincludeを変える。 　マルチプルインスタンス：サブルーチンをメインの実行状況によって任意に（動的に）増やせる。 　オブジェクト指向：これら個々の処理を分離して薄皮でくるみ、モノとして捉える。 わかってないとお叱りを受けそうですが、「犬・猫」よりはそれっぽい（笑）気がします。

># 以前何度か読んで、そのたびに「手続きによる抽象化」について調べようと思いつつ ># 忘れていたらいつの間にか追記がついていた。あれ? すみません（汗）。 当時はまだリスコフの抽象データ型（カプセル化）について理解があさく、 ユーザー定義型に手続きを含むか、含まないかで、それぞれを OOP（あるいは、 手続きによる抽象化。PDA）とするか、ADT（クック独自定義の抽象データ型） とするかという分類はとてもクールに思えて必要以上に持ち上げてしまいました。 その後、リスコフは、手続きを型に含むか含まないかは抽象データ型の実現方法の バリエーションにすぎない（それぞれにメリット・デメリットがある…）と書いてある のを見つけて、追記にように認識を改めた次第です。

>オブジェクト指向のごちゃごちゃが気になったら、とりあえずこのページを見ておくと良いと思います。 >http://d.hatena.ne.jp/sumim/20040525/p1 ページの紹介ありがとうございます。 # 以前何度か読んで、そのたびに「手続きによる抽象化」について調べようと思いつつ # 忘れていたらいつの間にか追記がついていた。あれ? というわけで、Javaの勉強をするのなら、「メッセージ」という言葉を多用している 入門書はひとまず避けておけ、と(ぉぃ 逆に言えばうちのページ http://kmaebashi.com/programmer/object/index.html はC++/Java流OO限定ですね。そういうわけで当時の掲示板でのバトルの末 「言語としてはJavaを使用します。」という文言を先頭のページに持ってきた、 という経緯はあるんですが、もうちょっとでかでかと書いてもよかったかも。 まあ当時は依怙地になっていたかと思います。

>新人君 (大学では情報技術をやってなかった君) を見ていると >やはり[マルチプルインスタンス]にてつまづいているようだ。 >http://kmaebashi.com/programmer/object/othello.html この「マルチプルインスタンス」という言葉は別に私の造語ではなく、 http://kmaebashi.com/programmer/object/intro.html にも書いたようにC++ FAQにあった言葉を使ったのですが、上のページを私が書いた 時点では、「マルチプルインスタンス オブジェクト指向」でGoogleしても 0件でした。 それが今では258件だか出ます(私のページやそれに対する言及も多いですが)。 うちのページの影響だと思っても、自意識過剰じゃないですよね。きっと。たぶん。 プロトタイプベースまで含めるとまた話がややこしくなりますが、 クラスベースのOOに関する限り、複数のインスタンスが作れるという概念は 基本だと思うんですよね。あまりに基本すぎるせいか、入門書とかでは 飛ばされてしまっていたわけですが。 新人君がなにもかもstaticなプログラムを書いたら「オブジェクト指向的じゃない!」 と怒るくせに。 >マルチプルインスタンスが理解できても static という罠が待ち構えている。 しかもJavaの場合実行がすべてpublic static void main()から始まるために、 本当の入門者がいきなり罠にはまるという…

Gloryさん、こんにちは。 >例題は「車」・・・このサイトの予想通り。ご多分に漏れずなかなか >理解できずにいます。 車ですか…これもよく使われる例かと思いますが、やっぱりたとえ話はよくないと 思います。 >そのうえ更に「よくある○○という説明は間違い、誤解をうむ、 >オブジェクト指向ではない」などと説明されると、卓袱台を引っくり返された >ような感覚すら。 >結局どれが”正”なんだ？と。お互いに自分の説明こそが正しいという立場で主張する >わけですから（当たり前ですが）、初心者は余計に混乱し、根気がないと挫折します。 すみません、一部加担しています。(_o_) >オブジェクト指向に対する根本的なモノの考え方は同じなのかもしれませんが、 >投稿・掲示板でも意見が分かれるように、統一見解がないことこそが >”なぜわからなくなってしまうのか？”の一番の原因なのかもしれません。 [1111]でこくぼさんが挙げておられるページのように、また、 http://practical-scheme.net/trans/reesoo-j.html こちらでも「オブジェクト指向というものが動く標的であるため、オブジェクト指向の 熱心な支持者はこのメニューのうちの適当なサブセットを気まぐれに選んで、 それを以って他の言語はオブジェクト指向ではないと説得しようとする。 」 と言われているように、定義がちゃんと定まったものではないとは思います。 >本当は誰もが認めるバイブル的な教本があるとよいのですがねぇ・・・。 たとえばBertrand MeyerさんのOOSC(Object-Oriented Software Construction)は かなり多くの人がバイブルと認めると思いますが(少なくとも静的型OO支持者であれば)、 それでも「あの本の継承の使い方は…」という留保をつける人が多いんじゃないかと 思います。

昨晩はちょっと早めに帰宅して、 　　↓ 掲示板を確認し、ゴミ投稿を消して、 　　↓ どうお返事しようかなあ、と考えながらベッドにごろんと 　　↓ 気付いたら朝　←いまここ というわけで、今しばらくお待ちくださいませ。

オブジェクト指向のごちゃごちゃが気になったら、とりあえずこのページを見ておくと良いと思います。 http://d.hatena.ne.jp/sumim/20040525/p1

新人君 (大学では情報技術をやってなかった君) を見ていると やはり[マルチプルインスタンス]にてつまづいているようだ。 http://kmaebashi.com/programmer/object/othello.html 同じ種類のモノが、複数個！という概念が理解できた後でないと 同じ性質だけど、違う種類！ (基底クラス→派生クラス) の理解は危うい。 と思うのであった。 マルチプルインスタンスが理解できても static という罠が待ち構えている。 Java の Double クラスの public static Double valueOf(String s) が ああ、そういうことねーと納得できるかどうか こりゃいったいなにがいいたいんぢゃろと困るか その辺にわかるわからないの境目がありそうな気がする俺ちゃんであった

管理人さん＆読者の皆さん、こんにちは。 この前、会社の新人研修でオブジェクト指向（Java）を学びました。 例題は「車」・・・このサイトの予想通り。ご多分に漏れずなかなか理解できずにいます。 いろいろなオブジェクト指向関連のサイトや本を読みあさって勉強していると、筆者それぞれに 思い入れがあって、解説の仕方や考え方が異なることに気付きます。「実は簡単」とか「これだけ 覚えればOK」という内容をよく目にしますが、私のような初心者にとっては、それでさえ 理解できなかったりします。そのうえ更に「よくある○○という説明は間違い、誤解をうむ、 オブジェクト指向ではない」などと説明されると、卓袱台を引っくり返されたような感覚すら。 結局どれが”正”なんだ？と。お互いに自分の説明こそが正しいという立場で主張するわけですから （当たり前ですが）、初心者は余計に混乱し、根気がないと挫折します。 オブジェクト指向に対する根本的なモノの考え方は同じなのかもしれませんが、投稿・掲示板でも 意見が分かれるように、統一見解がないことこそが”なぜわからなくなってしまうのか？”の一番の 原因なのかもしれません。研修の講師の方も仰っていました。「わからないときは先輩に 訊いた方がよい、ただしその相手を間違えるとヘンな設計になる（笑）」。なんとなく分かるような 気がします。どうもベテランのJava開発者＝オブジェクト指向を理解している人ではないようです。 本当は誰もが認めるバイブル的な教本があるとよいのですがねぇ・・・。

>まあ、仕事のプロジェクトについてここであんまり書くわけにもいきませんから >このへんにしときます。 ですよね。 失礼しましたm(_ _)m

>自分も何の因果か、巡り巡って今はGのつくプロジェクトにどっぶり漬かっています。 >＃お客さんとコネのあるベンダーなので面倒がないというか、大変というか…＾＾； >＃(前会社で働いてたときよりも待遇も給料も良いので全然良いんですけどね) あの会社にGのつくプロジェクトはいくつかありますが、あのGであれば、 お会いする機会は今後もあるかもしれません。 まあ、仕事のプロジェクトについてここであんまり書くわけにもいきませんから このへんにしときます。

>ええと、それならおそらく私です。 やっぱりそうでしたか。お会いできるチャンスを逃してしまって残念です＾＾； >ただ、現在私は1階にコーヒー屋があるビルの向かいのビルにはいません。 ># 会社自体変わったような変わってないような。 そうなんですか…! >超巨大企業の子会社の、Gのつくプロジェクトの人たちも現在はコーヒー屋がある >ビルではないビルに移っているはずです(全員ではないはずですが)。 今年末くらいに駅近くの新しくできるビルに移るって話は聞いてますが、今はまだ大部分はそこのビルにあると思います。 >月日は過ぎ人は去り状況は刻々と変わっているようです。諸行無常といいますか。 自分も何の因果か、巡り巡って今はGのつくプロジェクトにどっぶり漬かっています。 ＃お客さんとコネのあるベンダーなので面倒がないというか、大変というか…＾＾； ＃(前会社で働いてたときよりも待遇も給料も良いので全然良いんですけどね)

こんにちは。 >自分は名古屋の伏見にある某企業で働いてるのですが、２年ほど前(2006年の3月末) >にとある会社(超巨大企業の子会社)の名簿みたいなやつに前橋さんのお名前を見かけ >ました。 ええと、それならおそらく私です。 >おそらく前橋さんの会社からすぐ近くの1階にコーヒー屋があるビルなのですが、 ただ、現在私は1階にコーヒー屋があるビルの向かいのビルにはいません。 # 会社自体変わったような変わってないような。 超巨大企業の子会社の、Gのつくプロジェクトの人たちも現在はコーヒー屋がある ビルではないビルに移っているはずです(全員ではないはずですが)。 月日は過ぎ人は去り状況は刻々と変わっているようです。諸行無常といいますか。

はじめまして、こんにちは。 ポインタ本を６年くらい前(？)に読んでから、前橋さんのファンです。 自分は名古屋の伏見にある某企業で働いてるのですが、２年ほど前(2006年の3月末)にとある会社(超巨大企業の子会社)の名簿みたいなやつに前橋さんのお名前を見かけました。 (ちょうど自分が3月末までその会社に派遣されてまして) おそらく前橋さんの会社からすぐ近くの1階にコーヒー屋があるビルなのですが、あのとき見た名前が本当に前橋さんなのか今でも気になっています。 迷惑でなければ、教えてくださいm(_ _)m

はじめまして。おほめいただきありがとうございます。 >よくわからない宣言は避けて、使わないようにしていたのですが >それが理解できると途端に使えるものが増えて、世界が広がったような気がしました 本にも書いたとおり、あまり複雑な宣言を使うのはおすすめできませんが、読むときには読めないと困りますし、わからないからとvoid*に逃げるのもよろしくないですから、宣言の読み方はわかっているほうがよいですよね。 お役に立てたようで何よりです。

C言語ポインタ完全制覇の本を読ませていただきました 細部まで説明してくれるこういう本は本当にありがたかったです よくわからない宣言は避けて、使わないようにしていたのですが それが理解できると途端に使えるものが増えて、世界が広がったような気がしました 良い本を出してくれて感謝致します

はじめまして。書き込みありがとうございます。 >で、今回は、面白いページがありましたので、ご紹介致します。（既に知っていらっしゃるかもしれませんが・・・） >http://builder.japan.zdnet.com/sp/c-programming-language/story/0,3800083430,20370255-2,00.htm?p=3&mode=all#block_comment 某筋から聞いて知っていました。4/1にかこつけてこんなのを書いちゃったくらいで (^^; http://d.hatena.ne.jp/kmaebashi/20080401 >しかし、簡単なポインタが分からない人は、表舞台（雑誌とか、本とか）から絶滅したと思っていましたが、まだまだ現役なんですね :-p C自体、うちの会社では使っている部署はどんどん減っているのですが、まだCの記事に需要があるようですね(この記事の出来はさておき)。 「C言語 ポインタ完全制覇」は今度第11刷が出ます(奥付は5月11日)。皆様のおかげです。

前橋さんのファンです。一度は書き込んでみたいと思っておりました。(^^;) で、今回は、面白いページがありましたので、ご紹介致します。（既に知っていらっしゃるかもしれませんが・・・） http://builder.japan.zdnet.com/sp/c-programming-language/story/0,3800083430,20370255-2,00.htm?p=3&mode=all#block_comment 最初は単純ミスかとも思いましたが、直せば直すほど馬脚を現していく有様を見ていると、これは「真性」だと思います。 しかし、簡単なポインタが分からない人は、表舞台（雑誌とか、本とか）から絶滅したと思っていましたが、まだまだ現役なんですね :-p

>JAVAを使っていてわざわざ１クラスのなかに全プログラムを記述するような >ことをせず、クラスに分割していけば自動的にオブジェクト指向になっていく >のではないでしょうか。 Javaで1クラスの中に全プログラムを記述するようなことをする人はめったに いないと思いますが、Cで、関数を複数の.cファイルに分類して書いていった ところで、「オブジェクト指向になっている」とは言わないでしょう。普通は。 そういうことを下記ページに書きました。 http://kmaebashi.com/programmer/object/othello.html、 | しかし、現状では、カプセル化は実現できていても、オブジェクト指向に | はなっていません。なぜならここにはオブジェクトがいないからです。 >そこで、JAVAのプログラマーであるのに、オブジェクト指向でない >プログラミングの例を示して解説していただければうれしいです。 >ただし初心者や技術不足が原因のしょうもない例ではなくお願いします。 いまどきJavaといえばWebアプリケーションの開発に使うことが多いと思いますが、 たとえばStrutsとJDBCを使うとして、UIの階層はStrutsが提供するクラスを 継承したりして作るかもしれませんが、そこから呼び出されるビジネスロジックの 階層を「staticメソッドの集合体」にするケースは結構あると思いますよ。 それでもJDBCが提供するinterfaceを使っているからオブジェクト指向だ、とか、 UI層ではActionを継承して作っているからオブジェクト指向だ、と主張する のであれば別に止めませんが。 いわゆる業務アプリケーションの開発において、継承やらインタフェースやらを 多用したクラス階層を自分で設計してプログラムを書いていく場面は実はかなり 少ないです。 以前この掲示板ではこんな議論がありました。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&thread=693 この中で紹介されているhappieさんの意見に、私は大筋で賛成です。 http://happiese.exblog.jp/3127241/

オブジェクト指向について分かりやすい説明ありがとうございました。CとJAVAの違いで説明されているところで感じたのですが、もともとJAVAでプログラミングしていれば自然にオブジェクト指向になるのではないでしょうか。JAVAを使っていてわざわざ１クラスのなかに全プログラムを記述するようなことをせず、クラスに分割していけば自動的にオブジェクト指向になっていくのではないでしょうか。私の疑問は、JAVAのプログラマーでありながら、オブジェクト指向でないプログラミングをするということの方が難しいのではないかということです。 そこで、JAVAのプログラマーであるのに、オブジェクト指向でないプログラミングの例を示して解説していただければうれしいです。ただし初心者や技術不足が原因のしょうもない例ではなくお願いします。しょうもない例というのは、Newのタイミングを間違えるとかそういう例です。

>結果として、このプログラムは一見正常に動きますが、 >再入力の場合に限り字数チェックが行なわれない、という奇妙な仕様になっています。 ご指摘ありがとうございます。コーディングの方針とかスタイルとか そういう話ではなく、再入力のときBOOK_NAME_LEN等より長い文字列を 入力すると領域破壊を起こしますから、これは致命的ですね。 こういうバグが入った経緯はさすがに思い出せませんが、正誤表に追加しておきました。 えー、他にもまだあるようでしたら(と書くのも怖いのですが、間違いは間違いとして 正誤表に載せておきたいと思いますので)

ご確認ありがとうございました。 > (まだあるようでしたらぜひお願いします)。 というお言葉に甘えて、連投ヒンシュク覚悟で……。 【7】 蔵書管理プログラム配列版(p243～のList5-12)において、 「再入力機能」のコード(reinput系統の関数)に納得しかねる点があります。 input_string() と input_number() とは、文字列と数値の違いこそあれ、 ともに「新規入力処理」として並立した存在です。 両者の冒頭には共通の一行入力処理(+α)が fgets() を使って書かれており、 これらはのちに input_line() として切り出されることになります。 そして、この2者に再入力機能(つまり改行だけが入力された場合の処理)を付け加えたものが それぞれ reinput_string() と reinput_number() であるはずですよね。 しかし、再入力に際して input_line() 相当の処理を書くべきところには、ともに input_string(buf, 1024, stdin); と書かれています。これは不合理ではないでしょうか？ 配列版での文字列入力は字数制限を伴うため、 新規入力では input_data() が input_string() に上限を渡してチェックさせています。 一方、再入力では reinput_data() がいったん reinput_string() を呼び出し、 その中で上限を1024にして input_string() を呼び出しており、不可解です。 そもそも reinput_string() 自体が上限を引数にとらないので、 reinput_data() から渡せなくなっていますね。 結果として、このプログラムは一見正常に動きますが、 再入力の場合に限り字数チェックが行なわれない、という奇妙な仕様になっています。 全くの憶測ですが、以下のような経緯は考えられないでしょうか？ | 配列版を執筆している段階では、まだ再入力機能は無かった。 | 動的メモリ確保版に入り、再入力機能を持たせた。 | この機能を配列版でも使えるように、List5-12(p243～)にさかのぼって、 | reinput_string() 、reinput_number() 、および reinput_data() を付け加えた。 | このとき、配列版特有の字数制限への対応を行なわなかった。 | また、reinput_string() 、reinput_number() では input_line() を呼び出す必要があるが、 | 配列版ではこの関数をまだ切り出していなかったので、関数名だけ reinput_string() に置き換えた。 見当はずれだったら赤っ恥ですが(^^;)

お返事が大変遅くなりまして申し訳ありません。 >【6】 >3-3の detab.c についてなのですが、p141に (中略) >do{ > putchar(' '); > char_count++; >} while(char_count % TABSTOP != 0); > >で済ませてしまうと思います。 う。これは確かにこれで動きますし、こちらの方がシンプルですね。 「体当たり学習」のサンプルソースがなぜああなっているかについてですが、単純に思いつかなかったのかもしれません。ひょっとすると「出力すべきスペースの数を算出する」→「その数のスペースを出力する」と段階を追って考えたほうがわかりやすいのでは、と思った、という可能性はありますが… いずれにせよすでに記憶の彼方です。すみません。 なお、限りなく手抜きな対応ですみませんが、ここでのやり取りを、下記補足ページに転記させていただきました。 http://kmaebashi.com/taiatari/hosoku.html いろいろとご指摘いただきありがとうございました(まだあるようでしたらぜひお願いします)。

丁寧にお返事いただき、ありがとうございます。 【2】 > 私は、習慣的にマクロで値を定義するときは括弧で囲んでいます。 > 演算子等を含むと括弧が必要だったりしますから常に入れているというだけで、 > この場合は実用的な意味はあまりないですが。 了解しました。ただ、括弧のない箇所もたくさんあったので(p111など)、 統一性の観点から指摘させていただきました。 【4】 > たしかに対象読者を考えると厳しい気がします。 私自身、初心者に毛が生えた程度なわけですが、 率直に言って、この部分を見たとき、頭がこんがらかっちゃったんですよね。 「何をやっているか」は分かったものの、 「これで万事うまくいく」という確信がすぐには持てませんでした。 なんでスッと頭に入らなかったのか考えてみると、 (ア) ファイルを開く→書き込む→閉じるという順番でしかモノが考えられない(私が) (イ) 「初め」の処理だけ特別扱いされている の2点が原因になっているように思います。 (ア)な初心者としては、下のような手順が素朴に思い浮かびます。 ------------------------------------------------------------------ while(){ 書きかけの出力ファイルがなければ、新しいファイルを開く 文字を書き込む 出力ファイルが一杯になったら、ファイルを閉じる } 最後の出力ファイルが中途半端なサイズで終わっていたら、それを閉じる ------------------------------------------------------------------ つまり、 FILE *out_fp = NULL; while((ch = getc(in_fp)) != EOF){ if(out_fp == NULL){ out_fp = fopen(......); ...... } putc(ch, out_fp); total_size++; if(total_size % OUT_FILE_SIZE == 0){ fclose(out_fp); out_fp = NULL; } } if(out_fp != NULL){ /* ここでは入力ファイルが空の場合だけでなく、 出力ファイルのキリのいいところで終わったときも NULLになる */ fclose(out_fp); } てな構成にすれば、(イ)も自然に解消されるのではないでしょうか。 ……と思って上のソースを見直すと、whileループの末尾と(次の回の)先頭で、 ほとんど同じ条件判断を行っていて非効率ですね(^^;) ほかにも私の気づいていない問題点があるかもしれません。 【5】 > 動くか動かないかという点では動きますし、出力用のファイルポインタと > 読み込み用のファイルポインタを比べると、読み込み用の方がfclose()しなくても > 害が少ないわけですが(書きかけで異常終了すると変なファイルができる可能性が > 高いですが、読み込みならまず大丈夫)行儀としては閉じた方がよいかと思います。 > # ただ、このレベルなら、やっぱり実用上「どっちでもいい」と言ってしまいそうです。 > # 私の場合。 こちらもよく理解できました。ありがとうございます。 風邪をひかれているのに申し訳ないのですが、もう一点、よろしいでしょうか。 【6】 3-3の detab.c についてなのですが、p141に > タブストップが8の時、タブは、「その行の出力文字の総数が8の倍数になるまで」空白を出力します。 とあり、まさにタブの動作はこれで言い尽くされていると思います。 私の場合、単純にこれをそっくりそのままコードに翻訳することを考えてしまうわけですが、 そうすると例えば do{ putchar(' '); char_count++; } while(char_count % TABSTOP != 0); で済ませてしまうと思います。 これも素人ゆえの感想かもしれませんが、「出力すべきスペースの数を算出する」という方法は、 なんだか必要以上に事を複雑にしているように映ってしまうのですが、いかがでしょうか。 どうも勝手なことばかり長々と書き散らしてすみません。

どうもです。いろいろご指摘ありがとうございます。 >【1】第1章の本文に「BMI指数」という表現がありますが、 >body mass indexの「index」は「指数」なので、 >単に「BMI」でいいのではないでしょうか？ そうですね。「IT技術」的なことをやってしまっています。 >【2】p105・List2-8(my_sort5.c)・4行目および >p180・List4-2(my_sort6.c)・4行目が > >#define SCORE_ARRAY_SIZE (100) > >となっていますが、この「100」を囲む括弧は意図されたものでしょうか？ 私は、習慣的にマクロで値を定義するときは括弧で囲んでいます。 演算子等を含むと括弧が必要だったりしますから常に入れているというだけで、 この場合は実用的な意味はあまりないですが。 >【3】正誤表 >http://kmaebashi.com/taiatari/seigo.html >のp102およびp103に言及している箇所で、ともに >「1手順ごとに『ソートずみの範囲』はひとつづつ増えていきます。」 >という、全く同じ注釈が付いています。 >これは本来p102のほうだけに付けることを意図していた、 という可能性はないでしょうか？ これはp102の方のHTMLを書いてから、それをコピペしてp103の方を作って、 消し忘れたようです。 >| 最後に開いた出力ファイルを閉じる。 >| ただし入力ファイルが空で、いきなりEOFに出くわして >| whileループを一度も回さずに脱出したときだけは、閉じるべき出力ファイルがない。 >| このときはout_fpが(10行目の定義によって)NULLに初期化されたままのはず。 >| よって、out_fp != NULL のときのみ、クローズ処理を行う。 > >という解釈でよいのでしょうか？ >コメントがないと対象読者には分かりにくいような気もしますが……。 37行の「さっきまでオープンしていたファイルを閉じる」というコメントから、 while () { さっきまでオープンしていたファイルを閉じて、 　次のファイルを開く } 最後に開いたファイルを閉じる という構造になっているのはわかってほしいと…あとは、どういう場合に out_fpがNULLでループを抜けるかですが、ループの中(しかもif文の中)で 閉じて開いている以上、NULLでここに落ちてくる可能性には直感で気づいてほしい… という気はしますが、たしかに対象読者を考えると厳しい気がします。 >【5】p148の本文で、「使い終わったファイルはクローズしておいたほうがよい」とあります。 >p158～p159・List3-7(my_split.c)やp168・List3-10(textdump.c)などでは >読み込み用に開いたファイルのクローズ処理が書かれていませんが、別に構わないでしょうか？ 動くか動かないかという点では動きますし、出力用のファイルポインタと 読み込み用のファイルポインタを比べると、読み込み用の方がfclose()しなくても 害が少ないわけですが(書きかけで異常終了すると変なファイルができる可能性が 高いですが、読み込みならまず大丈夫)行儀としては閉じた方がよいかと思います。 # ただ、このレベルなら、やっぱり実用上「どっちでもいい」と言ってしまいそうです。 # 私の場合。 今日は遅いですし私は現在風邪ひきですのでアレですが、後日何らかの形で Web上で対応させていただきます。 いろいろご指摘ありがとうございました。

こんにちは。 「C言語体当たり学習徹底入門」を読み返しています。 お手数ですが、いくつか確認させてください。 【1】第1章の本文に「BMI指数」という表現がありますが、 body mass indexの「index」は「指数」なので、 単に「BMI」でいいのではないでしょうか？ 【2】p105・List2-8(my_sort5.c)・4行目および p180・List4-2(my_sort6.c)・4行目が #define SCORE_ARRAY_SIZE (100) となっていますが、この「100」を囲む括弧は意図されたものでしょうか？ 【3】正誤表 http://kmaebashi.com/taiatari/seigo.html のp102およびp103に言及している箇所で、ともに 「1手順ごとに『ソートずみの範囲』はひとつづつ増えていきます。」 という、全く同じ注釈が付いています。 これは本来p102のほうだけに付けることを意図していた、 という可能性はないでしょうか？ 【4】p159・List3-7(my_split.c)・55～57行目の if(out_fp != NULL){ fclose(out_fp); } は、 | 最後に開いた出力ファイルを閉じる。 | ただし入力ファイルが空で、いきなりEOFに出くわして | whileループを一度も回さずに脱出したときだけは、閉じるべき出力ファイルがない。 | このときはout_fpが(10行目の定義によって)NULLに初期化されたままのはず。 | よって、out_fp != NULL のときのみ、クローズ処理を行う。 という解釈でよいのでしょうか？ コメントがないと対象読者には分かりにくいような気もしますが……。 【5】p148の本文で、「使い終わったファイルはクローズしておいたほうがよい」とあります。 p158～p159・List3-7(my_split.c)やp168・List3-10(textdump.c)などでは 読み込み用に開いたファイルのクローズ処理が書かれていませんが、別に構わないでしょうか？

検索から来ました。参考になります！

>http://www.atmarkit.co.jp/fjava/rensai2/javaent04/javaent04.html >などを読むと、意識すると理解がより深まるのかなぁ、なんて最近思っています。 おおっ、これはっ! 前後を見ると、「制御構造」もやらないうちからいきなりメモリの話かよ、と思うわけで、説明の方法としては(私の感覚では)同意しかねますが、継承を説明するのにメモリ上の配置から入るのは合理的なんじゃないかと私は思っています。私が継承を理解したのは、Cで無理やり継承を実現したXtがきっかけでしたから。 http://kmaebashi.com/programmer/c_yota/inherit.html yuyaさんもおっしゃるように、具体的な方から攻めていかないと理解できないことは多いと思います。私も「人間、誰だって、低レベルな概念の方が理解が早い」とあちこちに書いています。 と思って今Googleしてみたら http://d.hatena.ne.jp/yaneurao/20060511 | 私はもともとコンパイラやそういう低レベルの実装の話が好きだから | そういう勉強の仕方をするのだが、このへんはあまり共感が得られないかも知れない。 あれ? いやまあコンパイラは置いといて、メモリモデルについては、ちょっとプログラミングをかじった人はなんとなく頭にあって、だからこそ、仮想メモリとかを教えるとびっくりする、という認識があったのですが…

>大学生に教える機会が多いのですが、何をどの程度教えればよいか、 >こんなことを気に留めながら、試行錯誤しています。 イマサラな意見で恐縮ですが……。 抽象的なことを理解するには、やっぱり具体的なものを ほんの一部でもいいので徹底的に解剖してみて、 そのあとで再び抽象化する、という過程を踏まないと、 きちんと理解できない(少なくとも私は理解した気になれない)と思います。 「木を見て森を見ず」は確かに良くないけれど、 一本も木を見たことのない人がそれを言っても説得力がないなぁ、というところでしょうか。 具体例を経験した後は、こんどはその経験が足枷にならないように 抽象化(文字通り、対象のエッセンスを抽出する)しないといけないのが難しいところですが。 前橋さんの[1085]の解説は、 Cの規格上は必ずしもそのように実装しなければならないわけではない、ということを承知の上で、 あえて一般的な実装(具体例)の詳細にまで踏み込んでいらっしゃる、 という点に、ひげおやじさんは留意しておかれるとよいと思います。 # あ、今年もよろしくお願いします。 > 皆様

たいへん丁寧なご説明ありがとうございます。感謝しております。 未だ「処理系の実装」を想像できるほど物を知っているわけでは ないのですが、理解を深めるのに意識しながら今後勉強して行きたいと 思います。 ちなみに、メモリを意識せずにプログラミングを自力で作成できるように なるのが良いのかもしれませんが、Javaでの継承がメモリモデルを使って 解説してある記事 http://www.atmarkit.co.jp/fjava/rensai2/javaent04/javaent04.html などを読むと、意識すると理解がより深まるのかなぁ、なんて最近思っています。 大学生に教える機会が多いのですが、何をどの程度教えればよいか、 こんなことを気に留めながら、試行錯誤しています。

>>このへんから、 >>・静的型言語 >>・実行時に型を持つ言語 >>・アセンブラみたいな、本当に型のない言語 >>あたりの対比につながると面白いのかな、と思いつつ、 ええと、すみません、そんなたいした話ではないのですが。 たとえばCで、 int a; という(定義を兼ねた)宣言があったとき、これは >（１）変数xの内容を読んだり書いたりするときには、型Tに合った メモリの使い方に従います。 >（２）（１）、かつ、変数xのメモリ領域を型Tに対応するサイズだけ確保する。 この(1), (2)の両方を意味しますが、(1)の意味で効いてくるのはコンパイル時であり、(2)は実行時なんですよね(細かく言えば、staticでないローカル変数なら関数突入時、グローバル変数なら実行開始時)。 もちろんCではintとdoubleとでは普通はサイズが違いますから、「型Tに対応するサイズだけ確保する」ためには型を知らなければならないように思いますが、実際には「intのローカル変数ふたつ」であっても「doubleのローカル変数ひとつ」であっても、実行時の機械語コードは「スタックに領域を8バイト分確保する」となっている(※1)だけで、細かい型までは意識していません。 構造体定義にしても、 typedef struct { double x; double y; } Point; と書いたとして、Cでは、この型定義の情報はコンパイルされた機械語コードには残っていません。Point型の変数pがあったとき、p.yという記述は、「pの先頭アドレスから8バイト(※1)ずれたところを参照する」という機械語コードに変換されるのであって、「メンバyを参照する」ということは実行時には意識していません。 Javaあたりだと微妙に話が違って、リフレクション用にクラスの情報を保持しておく必要はありますし、バイトコード中に「メンバy」という情報は残っていますが、「メンバy」という情報はロード時にオフセット参照に変換されるはずです(JITがなかったとしても)。 静的型言語だとこんな感じですが、型なし言語であるRubyとかcrowbarでは、 a = 10; で変数が宣言されます。JavaScriptなら var a; でしょうか。これはひげおやじさんのおっしゃるところの(2)を、実行時に行っています(※2)。ただし「a = 10;」の実行のあとで「a = "abc";」と書くのも許されます。これは、整数型も文字列型も(変数aのレベルでは)同じサイズで表現されるためです。また、オブジェクトのメンバを参照するためa.yと書いてあったとき、aの型は実行時までわかりません(aにyというメンバがあるかどうかさえも)。よってひげおやじさんがおっしゃるところの(1)は、aという変数が宣言されたさらに後、まさにその変数を使うときに判定されるわけです。 「アセンブラみたいな、本当に型のない言語」は、例としてはたとえば(Cの前身である)Bなんかがそうでしょう。Bでは auto a; で変数が宣言できるようですが(※3)、なにしろBには型がないというか、intとポインタ(アドレス)は同じ型でそれ以外の型はなかったわけですから、「auto a;」は(2)の意味しか持ち得ません。 ……ええと、なんというかあまり面白い話にはならなかった気がしますが、ひげおやじさんもおそらく哲学論議がしたいわけではないと思いますから、ここはひとつ「言語を作ってみる」…とまではいかなくても処理系の実装を想像してみる、というのはいかがでしょうか(と、「プログラミング言語を作る」の宣伝につなげてみる)。 とか言いつつ、静的言語であるDiksamは、いまだにクラス部分が公開できてないわけですが。秋ごろから一応クラスやポリモルフィズムは動いていて、ただいろいろな意味で中身がぐちゃぐちゃで、作業時間が全然(本当に全然)取れないので進んでいないのですが。 ※1)intが4バイト、doubleが8バイトの処理系を想定しています。 ※2)Rubyの変数の宣言は厳密には「代入文が実行されたとき」ではないのですが、ここでは置いておきます。 ※3) http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html

ご返答ありがとうございます。 >なんというか、ご質問は、その指すところが曖昧で、(失礼ながら)初心者がワケわかんなくなった上での質問のように一見すると見えて、「774RRさんいきなりそんな話をされても」とか書くべきかと酔っ払った頭で一瞬思ったのですが。 まさにその初心者で、自分で頭の整理ができなくて質問してしまったようなところです。 結局は、変数の「宣言」と「定義」の違いをきちんと認識するのが不足していた と自分では省みています。（質問にもその認識不足がにじみでていたな、とも。） それだけではないのかもしれませんが･･･。 >ヒントになるかもしれないこととしては、 > >typedef struct { > double x; > double y; >} Point; > >と書いたとき、これだけでは単なる型宣言なのでメモリはまったく確保しませんが、上記(1)で言うところの型Tを定義する意味は持っているわけですよね。 これって、Javaのabstract class や interfaceなどでも同じことが当てはまるんでしょうか。浅はかな知識だけで、この質問も曖昧かもしれなく、すいません。 >このへんから、 >・静的型言語 >・実行時に型を持つ言語 >・アセンブラみたいな、本当に型のない言語 >あたりの対比につながると面白いのかな、と思いつつ、 可能ならば、この続きを教えていただければと存じます、触りだけでも。 宜しくお願い致します。

どうもです。 >プログラムで、変数を宣言する文は、プログラムを実行した >ときのパソコンのどんな動作に対応するのでしょうか。 なんというか、ご質問は、その指すところが曖昧で、(失礼ながら)初心者がワケわかんなくなった上での質問のように一見すると見えて、「774RRさんいきなりそんな話をされても」とか書くべきかと酔っ払った頭で一瞬思ったのですが。 >（１）変数xの内容を読んだり書いたりするときには、型Tに合った >メモリの使い方に従います。 >（２）（１）、かつ、変数xのメモリ領域を型Tに対応するサイズだけ確保する。 この(1)と(2)は、変数の宣言の二面性をかなり明確に意識しているように思います(だからこそ774RRさんのご回答がこの区分にきっちり一致しているわけで)。 今は酔っ払っているので頭回ってませんが、ヒントになるかもしれないこととしては、 typedef struct { double x; double y; } Point; と書いたとき、これだけでは単なる型宣言なのでメモリはまったく確保しませんが、上記(1)で言うところの型Tを定義する意味は持っているわけですよね。 このへんから、 ・静的型言語 ・実行時に型を持つ言語 ・アセンブラみたいな、本当に型のない言語 あたりの対比につながると面白いのかな、と思いつつ、すみませんもう寝ますおやすみなさい。

>また、言語によって違ったりするんでしょうか。 世の中にはプログラミング言語など星の数ほどあるので、違ったりするだろうな それだと答えに困るので、とりあえず C C++ の類に限定すると メモリ　という言葉をより広義の「記憶域」と読み替えて （１） Yes （２） 宣言が同時に定義となる場合には Yes 変数は狭義の「メモリ」つまり、俗に言う RAM に置かれるとは限らなくて もっと高速にアクセスできる「レジスタ」に置かれる場合もあるわけだ。 レジスタとメモリ（とその他変数に使えそうなもの）を称して記憶域という （１）（２）のあわせ技から以下のようなバグが発生することがあるので注意だな 「定義にならない宣言」と「定義になる宣言」が矛盾する場合におかしなことになる ---a.c--- extern int wrong_declared_variable; // declaration without definition ... wrong_declared_variable=0; // may destroy other variables ---b.c--- char wrong_declared_variable; // declaration with definition

お世話になります。 プログラムで、変数を宣言する文は、プログラムを実行した ときのパソコンのどんな動作に対応するのでしょうか。 変数xをある型Tで宣言するのは、次のいずれかなんじゃないかなぁ、 なんて自分では推測しているのですが。 （１）変数xの内容を読んだり書いたりするときには、型Tに合った メモリの使い方に従います。 （２）（１）、かつ、変数xのメモリ領域を型Tに対応するサイズだけ確保する。 （３）（１）、（２）以外。 どれが正解なんでしょう。それとも正解はないんですかね(^_^; また、言語によって違ったりするんでしょうか。 どなたかご教授いただければ幸いです。

>本日は晴天なり すみません、純粋なテスト投稿であればできるだけテスト用掲示板 http://kmaebashi.com/bbs/list.php?boardid=testbbs の方にお願いします。テスト用掲示板にもほげほげ認証は付いています。 …が、今見てみたら、テスト用掲示板にはspamが来てるじゃないですか! 人間がアルバイトで投稿しているのかなあ。

本日は晴天なり

>では早速テスト投稿などしてみませう どうも、おひさしぶりです。 # おひさしぶりになってしまったのは掲示板が壊れていたためですね…すみません。 >はたして cgi 君はうまくうごくのであろうか PHPだからcgiではないです、というツッコミはありでしょうか。 ところで、昨日は一晩で14通のspamが来たことを考えると、「ほげほげ認証」は それなりに効果があると思ってよさそうです。もうちょっと続けてみないと なんとも言えませんが。

では早速テスト投稿などしてみませう はたして cgi 君はうまくうごくのであろうか

掲示板を直したところspamがひどいので、 以下のページで紹介されている「ほげほげ認証」を導入しました。 http://diary.noasobi.net/2006/07/diary_060728a.html お手数をおかけしますが、今後投稿する際は、投稿欄の下のテキストボックスに 「ほげほげ」と入力してください。 こんなのは固定パスワードですし、画面に堂々と出るわけですし、 本来であればCAPTCHAか何かを導入すべきかもしれませんが、 ロボット相手ならそれなりに効果があるんじゃないかなあ、ということで 手抜き実装です。 投稿される方にはひと手間増えて申し訳ありませんが、よろしくお願いいたします。

>max(serialid)に置き換えて修復しました。 > >どうりで長いこと投稿がなかったわけだ… で、直したとたんスパム14連発かよ。

今年もよろしくお願いいたします。 ……と投稿しようと思ったら、SQLがエラーを吐きました。 スクリプトを見直したら、掲示板ごとの連番を取得するところでcount(*)を使っており、 少し前の広告削除で空き番ができるような物理削除をしていたのでcount(*)で取得した 連番が重複エラーを出していました。センスの悪いSQLを書いてましたね。 max(serialid)に置き換えて修復しました。 どうりで長いこと投稿がなかったわけだ…

>以下のような文章が出てきます。 >（下2行はいらないでしょうが、一応載せておきますね。） >----- >i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367) >Copyright (C) 2005 Free Software Foundation, Inc. >This is free software; see the source for copying conditions. There is NO >warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 情報ありがとうございます。 うちのUbuntu Linuxの gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) とやらではこの警告は出ないので、4.x系なら出るのかというとそういうわけでも なさそうですね。

>gcc --versionで表示されるgccのバージョンは何でしょうか? 以下のような文章が出てきます。 （下2行はいらないでしょうが、一応載せておきますね。） ----- i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -----

>----- >mycalc.y:64: warning: incompatible implicit declaration of built-in function 'exit' >----- >と警告が出てしまいます。 「of built-in function 'exit'」つまりexit()を組み込み関数とした上で 警告を出してくれるわけですね。 すみません、よろしければ教えていただきたいのですが、 gcc --versionで表示されるgccのバージョンは何でしょうか? うちのMinGW(gcc (GCC) 3.4.2 (mingw-special))ではこの警告は 出ないようです。

はじめまして。 前回の投稿で挨拶をしていなくて、すみませんでした。 >>8行目 >>"}" → "};" >>"union" の宣言の終わりのセミコロンが無い。 > >これですが、ここはもともとセミコロンは不要ではないでしょうか >(bisonで試したところあってもなくても通りましたが)。 はい、自分のところで試してみたところ、セミコロン無しでも通りました。 エラーメッセージを読み間違えたのだと思います。 >>64行目 >>"exit()" を使用しているのに、"stdlib.h" が include されていない。 > >こちらは修正いたしました。 >gccだとexit()は組み込み関数になっていて、-Wallを付けても、stdlib.hをinclude >していない状態でコンパイルエラーにならなくて… というのは言い訳ですね。 私の環境（MacOSX v10.4.10 Darwin 8.10.1?）で gcc -o mycalc y.tab.c lex.yy.c を実行すると ----- mycalc.y:64: warning: incompatible implicit declaration of built-in function 'exit' ----- と警告が出てしまいます。 なので、一応神経質になって include してみた次第です。 # こういう仔細な状況を書き忘れないようにしようとは思うのですが、 # 忘れてしまいます。すみません。 お早い返信ありがとうございました。

はじめまして。ご報告ありがとうございます。 >8行目 >"}" → "};" >"union" の宣言の終わりのセミコロンが無い。 これですが、ここはもともとセミコロンは不要ではないでしょうか (bisonで試したところあってもなくても通りましたが)。 NUTSHELLの本でも、以下のサンプルでもセミコロンは付いていませんし。 http://www.linux.or.jp/JF/JFdocs/Lex-YACC-HOWTO-6.html#ss6.3 >64行目 >"exit()" を使用しているのに、"stdlib.h" が include されていない。 こちらは修正いたしました。 gccだとexit()は組み込み関数になっていて、-Wallを付けても、stdlib.hをinclude していない状態でコンパイルエラーにならなくて… というのは言い訳ですね。 実は現在公開しているcrowbarやDikamでも同様の問題があり、最近ようやく -ansiオプションを付けました。次バージョンから修正します。 >私は2行目と3行目の間に "#include <stdlib.h>" という行を挿入したのですが、 >これでいいのでしょうか? それでOKです。 ご報告いただきありがとうございました。

リンクされているページのソースコード"mycalc.y"に誤りがありましたので、報告いたします。 8行目 "}" → "};" "union" の宣言の終わりのセミコロンが無い。 64行目 "exit()" を使用しているのに、"stdlib.h" が include されていない。 私は2行目と3行目の間に "#include <stdlib.h>" という行を挿入したのですが、これでいいのでしょうか?

> Rationaleを見ても、このへんに関する記述は以下の箇所くらいのようです。 > http://www.lysator.liu.se/c/rat/c1.html#3-1-2-2 rationaleにこんな記述があったのですね。ありがとうございます。 > extern int i3 = 3; > これも不可解ですが、これはcommonモデルの方を引き継いだのでしょうかね。 該当箇所をよく読んでみると、列挙されたモデルの4つ目にinitializionモデルというのがあり、 「定義になるかどうか」を初期化子の有無だけで判断するものがあったようですね。 さらにその後には、 (訳) >規格で採用されたモデルは、strict ref/defモデルとinitializationモデルの特徴を組み合わせたものとなっている。 >(略) >しかし、外部定義として働くのは、「初期化」あるいは「記憶域クラス指定子のない特定の宣言」のいずれでもよい。 >このような混合アプローチが選択されたのは、さまざまな環境と既存の実装に可能な限り広範囲に適応するためである。 とあります。これを読む限り、 extern int i3 = 3; の挙動はinitializationモデルを引き継いだ可能性もありそうです。 同モデルの説明のところにはexternの扱いは明記されていないので、少し話がずれているかもしれませんが。 有用な資料の箇所を指し示してくださってありがとうございました。

C/C++ の予約語に関しては D&E で Stroustrup も書いているんだけど 「新しいキーワードを増やすことは激論を招く」pp.191 C/C++ では同じ予約語を文脈によって異なる意味に使うことで、増やさない選択をした。 違和感の原因はこの辺にありそう。 > 特に「紹介状」は使わせてもらっていいでしょうか。 どーぞご自由に。 <前橋様>すんません、勝手に盛り上がってしまっております。 本来こー言う[俺はこう思う]論は自分で blog 等立てるのが筋なんですが 小心者ですので web は「使う側」に回らせてもらっております。 もう少し掲示板スペースをお貸しください</前橋様>

▼ > 要するに言語仕様上の extern と、英語の単語 external の不一致に違和感がある > っつーことでっか そうです。すでに決まっちゃったものに文句を言っても仕方ないですが、 「説明するときに名前との関連を前面に出すか、抑えるか」という選択肢は残されています。 そもそも結合は定義サマが決めるのが筋なのであって、 定義でない宣言がいくら結合を声高に主張しても、 「定義との食い違いを処理系に見つけてもらおう」というのでない限り無意味ですよね。 int hoge = 1; static int hoge; でエラーを出してくれるならまだしも、未定義動作ですし。 それならば、「参照に(ほぼ)特化した、結合に関してはオールマイティな」 externのようなキーワードが用意されているのは合理的だと思いますが、 なにもそんな名前じゃなくても良かろう、と思うわけです。 # externは実は外部宣言(external declaration)から来ているのかも、というオチは……。 ▼ > プログラム言語のキーワードをいちいち英語とつき合わせていると違和感ありですな。 > 俺的に一番違和感があるのは const であります。 > const ではなく readonly にしてくれると **俺的には** 解消です。 私もまったく同じように思います。というか、 「文字通りではないことに気付いているかどうか」によって、 理解度が測れてしまうこと自体(Cはこんなのばっかり)、なんて不健全な状況なんだ(^^;) #define INTERN static #define READONLY const ... ▼レベル別教授法はとても参考になりました。 特に「紹介状」は使わせてもらっていいでしょうか。 「エキスパートCプログラミング」には「(定義でない宣言は)税関の申告のようなものだ」とあり、 初めて読んだときは？？？でしたが。

ふむー 要するに言語仕様上の extern と、英語の単語 external の不一致に違和感がある っつーことでっか プログラム言語のキーワードをいちいち英語とつき合わせていると違和感ありですな。 俺的に一番違和感があるのは const であります。 const ではなく readonly にしてくれると **俺的には** 解消です。 言語規格書は古い非推奨な書き方してる既存のコードが invalid にならないように 過去との互換性維持のためだけの文言・機能も含んでいるので、そーいうところは 初心者・中級者むけクラスでは一切教えない。教える必要も無い。隠しておくべし。 たとえばいまさら「関数原型宣言にならない関数宣言」など教える必要は一切無い。 「extern があると先行する宣言に従う」はまさにこの黒歴史の部分。初心者に教えるな！ # 知っておいて隠しておくのと知らないままでいるのとでは大きく違うのだがね。 extern に関して俺が後輩諸氏に説明するならばレベルに応じ 初心者向け（厳密に宣言を必ず先行させる新しいスタイルのみ教える） ・ヘッダファイル中において変数を宣言する場合には必ず extern を書くべし 　→宣言とは他人/自分が [その名前] を使えるようにするものである 　→他人の作った未知の関数や変数は使いたくないだろ。だから最低限素性がわからないと困るんだ 　　だから、ヘッダファイル中には[名前]と「紹介状」を書くべし（＝これが宣言） ・他人/自分がその変数を使えるようにするために、定義を１つ .c 中に書くべし 　→定義とは [その名前] の変数や関数を作って提供することである 　→「紹介状」と実際の人物像が異なると困るだろ、だから紹介状を書く側には責任がある 　　人間の目でなくコンパイラでチェックできるよう、自作ヘッダは自作ソース中で #include しろ 　　そーすれば機械が不一致を検出してくれる 　→紹介状は複数人で回覧することができる (宣言は複数回あっていい) が、 　　実際の人物は１人しかいないわけだから定義は１つ。 宣言と定義の簡易解説は必要。詳細解説までは不要。 結合や記憶域期間や可視性、等の詳細については説明不要 (消化不良になるだけ) 中級者向け（旧式の非推奨な書き方してるソースコードには触らせない） ・宣言と定義の詳細解説 ・内部結合と外部結合と無結合の違い 　→「原則として」と前置きして extern は外部結合・定義にならない宣言となると解説 　(変数宣言に extern があっても定義になりうると話しても混乱を招くだけなので説明しない) 　→「原則以外は？」と問われたら上級者向け解説を実施 関数の場合の話を問われたら ・関数宣言と関数定義はソースコード上の記述形式が明確に異なるので区別できるから 　extern/static は結合の決定にのみ使われるとフォローし ・static が明記されていない場合は extern が省略されていると解説 (X3010:1993 に準拠) ・これは変数の場合と挙動が異なるぞ、ともフォロー 上級者向け（既存のソースコードのダークサイドまで全部面倒見る人向け） ・言語規格書の章番号＋解説 ・相手に興味がありそうで時間もあれば既に書いた俺妄想による Rationale をフォロー

774RRさん、(ぱ)さん、ありがとうございます。 たくさんコメントをいただいたので、[1045]～[1050]へのリプライは こちらにまとめさせていただきます。 [1048]774RRさん; > ながながと書いたけど結局のところ yuya さんの疑問点は > extern 記憶域指定子はなぜに (6.2.2) のようなヘンな振る舞いをするのか、その根拠やいかに > ということでよろしいのだろうか？ [1049](ぱ)さん; >>static int i2 = 2; // 定義，内部結合 >>extern int i2 ; // 内部結合をもつ前の定義を参照する > > この「extern int i2;」の挙動が不可解だということですよね。 > 私にも不可解に見えます。そもそもキーワードの名前が「extern(al)」なのに! 6.2.2のexternの振る舞いが奇妙に映るのは、(ぱ)さんのおっしゃるとおり、 `extern'という、外部結合(external linkage)を想起させる名前によるところが大きいと思います。 いったん名前のことを忘れて、単に 「(翻訳単位内外にかかわらず)どこかで定義されている(かもしれない)変数・関数を参照する」 という機能が主眼だと考えれば、6.2.2の結合の定まり方は、 「可能な限り状況に合わせて結合を決定する」という、ある意味ではきわめて合理的な、 悪く言えば御都合主義的な仕様になっています。 その背景には[1048]・[1050]で774RRさんが書いてくださったような事情があった可能性が高いと思います。 現在の目から見て、初心者に「結局のところexternって何をするんですか？」と聞かれたとき、 最も正しい答えは[1046]でまとめていただいたように規格書の該当箇所を指し示すことだと思いますし、 最終的には本人にそこまで行き着いてもらわないといけないわけですが、 やはり(自分自身の頭を整理するためにも)「何が原則で、何が例外か」という観点で整理したくなり、 できるだけ普遍的な原則・少ない例外で理解できる方法はないだろうか、と思ってしまうわけです。 その過程の中で、歴史的経緯を知ることが原則を抽出する助けになることも多いと思います。 もちろん規格書には「これが原則、これが例外」などということは書かれていませんから、 注意しないと私が陥ったように勝手な行間解釈や俺俺用語を生んでしまうわけですが……。 で、実際にexternに対してそのような整理を試みたとき、ポイントとなる切り口は [1047]でご指摘のとおり「結合は何か」「定義になるかどうか」です。 ここでexternという名前を尊重して、「結合指定」を原則に据えると、 内部結合になるケースを例外と捉え、「定義になるかどうか」は別途論じることになります。 これに対して、「定義にならない」ことを原則に据えると、 (a); 結合は上記のように状況に合わせて定まる。 (b); 何も付けなくても初めから外部結合のブロック外定義になっているもの (関数定義や初期化子つきのブロック外変数定義)だけは、externをつけても定義とみなされる。 extern int hoge = 1; /* 外部結合のブロック外定義 */ と整理することができ、(b)が昔はコンパイルエラーになっていたとなれば、 例外として扱うことへの抵抗が小さくなります。 結局のところ、Cの振る舞いを統一的に理解することなど追求すべきでないのかも知れず、 [1045]774RRさんの > なんか難しく考えすぎなのではないかと思ってきた・・・ が最も正しいような気がしてきました。自覚はあるんですけど(^^;)

>最初期のCではexternはあってもなくても同じだったらしい 「最初期」をどのくらいまで遡るか次第、だけど 俺妄想だと Kerningham/Ritchie が作った直後のCには、たぶん extern はまったく無かったのだろうと思う。 なおかつリンカーが bss combine を勝手に行ってしまう都合上 ODR は実装したくても実装するすべが無かった。 ----aaa.c---- static int i1; // internal linkage, definition int i2; // external linkage, definition ----bbb.c---- static int i1; // internal linkage, definition, another instance of aaa.c!i1 double i2; // external linkage, definition, different decl of aaa.c!i2 ----bss in a.out--- aaa.c!i1; bbb.c!i1; common!i2; // combined together, uses maximum size bss combine 機能が無いリンカーをもつ処理系に移植する際に困ったので 後付で extern を追加したが、そのときにはすでに extern を持たないCで書かれた ソースコードがたくさんあったので、互換性を維持するには？と考えた結果が今の仕様 あと初期化子の有無で挙動が異なるのも、リンカーの都合 (非0の)初期化子がある＝bss に置けない＝bss combine が効かない って、これも妄想 歴史家なら、黒歴史を追及するのもまあお仕事ですし、実際面白そうだけど １ユーザとしては今ある仕様を理解するほうが建設的かなーって思うのであった

えー、一応管理人としては何か言うべきところなんでしょうが、正直、 私にはわかりません。 >6.9.2 外部オブジェクト定義 例1(抜粋) > >static int i2 = 2; // 定義，内部結合 > int i2 ; // 前に内部結合をもつ定義があるため、 > // 結合の不一致が生じ、6.2.2によって > // 動作は未定義となる >extern int i2 ; // 内部結合をもつ前の定義を参照する この「extern int i2;」の挙動が不可解だということですよね。 私にも不可解に見えます。そもそもキーワードの名前が「extern(al)」なのに! Rationaleを見ても、このへんに関する記述は以下の箇所くらいのようです。 http://www.lysator.liu.se/c/rat/c1.html#3-1-2-2 これはこれで興味深いのですが(最初期のCではexternはあってもなくても同じだった らしい)、yuyaさんの疑問の回答にはならないように思います。 Relaxed Ref/Defモデルのところには、 | The appearance of the keyword extern (whether it is used outside of the | scope of a function or not) in a declaration indicates a pure reference | (ref), which does not define storage. (超訳) >externはどっかの定義の参照を意味し、記憶領域の定義ではない。 とあるので、そのモデル(UNIX Cのモデル)を引き継ぐとそういう考え方になるのかなあ、 と思いましたが… UNIX Cにおいてexternが内部結合の定義を参照するような 実装があったのでしょうか。 externは定義にはならない、と考えると extern int i3 = 3; これも不可解ですが、これはcommonモデルの方を引き継いだのでしょうかね。

ながながと書いたけど結局のところ yuya さんの疑問点は extern 記憶域指定子はなぜに (6.2.2) のようなヘンな振る舞いをするのか、その根拠やいかに ということでよろしいのだろうか？ 根拠 (Rationale) は規格書採択の際の委員会議事録などをさがせば出てくるんだろう。 でも俺は規格策定委員でもなんでもないただの１ユーザなのですだ。 そういう議事録みたいなのが公開されていれば誰か探してみてほしい。 まずは検証可能な事実を指摘： この「結合」の振る舞いは JIS X3010:1993 (ISO/IEC 9899:1990) の時点から ほとんど変わっていない。(一部些細な変更があるが今の議論には関係ないところ) 言語規格書ってのは、理想を追求するあまりに今あるユーザー・処理系を無視する わけにはいかない代物なわけだ。 したがって当時1990年頃に書かれていた「一般的なソースコードがすべて不適合」に なるような文言てのは採用するわけには行かない。理想と現実の落としどころが重要になる。 以下は俺の妄想： ヘッダファイルを多重に #include していて include-guard がうまく効いていない、 あるいは、同一大域変数の宣言を複数の別ヘッダファイルが行っている、 そんなソースコードでできたプログラムがあるとして。 #include の結果として、 翻訳単位中に extern の無い大域変数宣言 (要するに外部定義) が先に現れ、 後から extern のある大域変数宣言 (いわゆる変数宣言) が現れる、ような場合であっても うまいことコンパイル＆リンクができるようにする必要があった。 すなわち extern 記憶域指定子の振る舞いは JIS X3010:1993 なら 6.1.2.2 JIS X3010:2003 なら 6.2.2 のように定めると都合がよかった。 そーいう話だと思って勝手にコメントしてみたけど、 いや、ずれてる！ということならまたよろしく。

> そもそもリンケージが翻訳単位外に及ぶ(つまり外部結合)、というのと、 > 宣言が定義を探しに行く範囲が翻訳単位外に及ぶ(extern宣言)、というのは > 分けて考えるべきだと思うのですが、皆様のご意見はいかがでしょうか？ この文章の意味が俺には解釈が難しいんだけど、つまるところ規格書が主張してるのは ・extern があれば外部結合になる (6.2.2) ・extern があっても外部結合であるとは限らない(6.2.2) ・extern があれば外部定義にならない(6.7+6.9.2) ・extern があっても外部定義になりうる場合がある(6.9.2) ・プログラム全体の中で現れる、外部結合をもつ同一識別子は、 　そのすべての宣言において、同じものを表す (6.2.2) ということ。それ以上でも以下でもなくて、勝手に行間を読んではいけない。 extern 宣言なんて用語は言語規格書には無いわけで、あえて言うなら 「宣言に extern 指定子がある場合」と呼ぶべき。そして、解釈すべきは 「その宣言が同時に定義になるか否か」「その宣言の持つ結合は何か」 だけ。余計なことを考えずに素直に規格書通りにプログラムを読むだけでいい。 俺俺用語を勝手に作ってはいかん。

このコメントは yuya さんむけというわけではなくて、第三者読者様の参考分として <結合の規則> 6.2.2 識別子の結合 オブジェクトの宣言の場合 (関数には適用されない) ・記憶域クラス指定なし＝外部結合 ・static 指定あり＝内部結合 ・extern 指定あり 　「すでに宣言があって、その宣言で外部結合または内部結合が指定されている」 　　→その既存の宣言と同じ結合をもつ 　「すでに宣言があって、その宣言で無結合が指定されている」または「宣言が無い」 　　→外部結合 </結合の規則> <宣言> ・無結合の識別子の宣言が同一スコープ内に２つ以上あってはならない </宣言> ということは、外部結合の宣言が２つあってもよいということ。 6.9.2 の例 int i4; // 宣言、外部結合の仮定義 int i4; // 宣言、外部結合の仮定義 extern int i4; // 宣言、既出の結合を採用、この場合は外部結合 static int i5; // 宣言、内部結合の仮定義 extern int i5; // 宣言、既出の結合を採用、この場合は内部結合 6.9.2 に出てない例 (外部定義にならないのでわざと出していない) extern int i6; // 宣言、既出の宣言が無いので外部結合、外部定義にならない (*136) 脚注のとおり、識別子を使わなければ定義は無くてよい

なんか難しく考えすぎなのではないかと思ってきた・・・ 言語規格書は書いてあるとおりに読めばよくて、勝手に行間を解釈しては誤るよ。 <[外部定義かそうでないか]の解釈> JISX3010:2003 6.9.2 外部オブジェクト定義、で述べられている内容は要約すると ・オブジェクトの外部定義＝ファイル有効範囲と初期化子をもつ場合 ・初期化子がなく、記憶域クラスなしか static があるとき＝仮定義 ・仮定義が１つ以上あって外部定義が無い場合は、翻訳単位の終了時点で 　仮定義を =0 という初期化子を持つ外部定義と読み替える。 以上。 よってここに書いてないものは外部定義ではないっつーことだ。 記憶域クラス指定 extern をもつ宣言についてはここ 6.9.2 では記載が無いので、 外部オブジェクト定義ではない。 > 私は定義ではなく、ただの宣言である。 ここまでは正しい。というか「外部定義にならない宣言である」というべきかな。 > 定義はほかにある そんな勝手な行間を読んではいけない。これに関しては別に規定がきっちりある。 6.9 外部定義、において ・外部結合で宣言した識別子を使用している場合、プログラム全体の中でその識別子に 　対する外部定義がちょうど１つなければならない。 ・使用していない場合、１つ以下でなければならない (*136) (*136) 外部結合で宣言した識別子を使用しない場合、その外部定義は必要ない </[外部定義かそうでないか]の解釈>

774RRさん、ありがとうございます。 0. C限定の話です。 1. はい、ご紹介くださったものと同じものを入手しています(保存も……)。 2. 変数のextern宣言について[1043]で成り立つことは、 関数原型宣言(externをつけてもつけなくても同じですが)についても成り立つと思うので、関数も含む話です。 3. 処理系準拠限定の話です。[1043]の末尾の非準拠の話は、歴史的経緯の手がかりになるかも、と思って付け加えました。 で、この議論に関係する条項は JISX3010:2003 6.2.2 識別子の結合 6.9 外部定義(とくに 6.9.2 外部オブジェクト定義) になると思います。 [1043]の投稿は、[1025]に774RRさんが書かれた > extern の意味するところは[1020]で書いたとおり、結合指定 > (略) > 厳密なところは自分で JIS 言語規格書を参照してもらうとして、簡単に言うなら > extern:外部結合を指定、static:内部結合を指定 というところを読んで、その意味を考えたのがきっかけです。 確かに6.2.2にはextern宣言された識別子の結合が場合分けされて書かれていますが、 よく読むと回りの定義状況に合わせた定まり方になっており、私には(ごく自然な) *結果* と映ります。 だとすると、extern宣言はどんな「結合指定」を担っているのだろう？と疑問に思ったのです。 特に、初期化子のない外部(ブロック外)変数定義・宣言の場合、 externをつけないほうがむしろ積極的に「外部結合」を指定しているように思います。 内容は前回の繰り返しになりますが、規格書で言えば 6.9.2 外部オブジェクト定義 例1(抜粋) static int i2 = 2; // 定義，内部結合 int i2 ; // 前に内部結合をもつ定義があるため、 // 結合の不一致が生じ、6.2.2によって // 動作は未定義となる extern int i2 ; // 内部結合をもつ前の定義を参照する が該当します。

詳しい議論（重箱の隅ともいう）に入る前に確認事項をいくつか 0.この話は C 限定か？それとも C++ 限定か？ 1.言語規格書は読みましたか？今手元にありますか？ (C89 なら JIS X3010:1993 ないし ISO/IEC 9899:1990) (C99 なら JIS X3010:2003 ないし ISO/IEC 9899:1999) (C++ なら JIS X3014:2003 ないし ISO/IEC 14882:2003) 2.変数の話限定か？それとも関数も含むか？ 3.規格非準拠の処理系の話も含むか？規格書採択前を含むか？ 規格非準拠の処理系の話ならパスします（きりがないので） C/C++ 言語規格書が無いのであればお話にならないです。げっちゅしてください。 http://www.jisc.go.jp/ から*閲覧*が可能です (小細工すれば保存もゲフゲフ) 検索が効かないので役に立ちませんが、無いよりは無限大にマシです。 んで、疑問に思われる/わからないところを具体的に条項番号を挙げて話してください。

別スレッドを立てました。 externと「外部結合」については以前から私の悩みの種で、 現時点で以下のように理解しているのですが、問題がないかどうか、よろしければご意見をお聞かせください。 以下、すべてブロック外の話で、「宣言」とは「定義でない宣言」を指すとします。 extern宣言は、同一翻訳単位内にすでに定義があれば、その結合に従った宣言となります。 定義がなければ他の翻訳単位に定義があるだろうと仮定して、 それに対応する宣言になろうとします(この場合には、状況から外部結合しかあり得ません)。 このようにextern宣言の振る舞いを見ると、externは 「近いところから順に定義を探し、状況に合わせて(きわめて自然に)結合が定まる」 宣言であると考えられます。 もちろん、実際にはほとんどのケースで外部結合になり、 内部結合になるのは同一翻訳単位内にstatic定義がある場合だけですが、 これを「例外」と捉えるよりも、上記のように結合が定まると考えたほうが良いように思います。 初期化子のない変数定義・宣言を考えたとき、記憶クラス指定子をつけなければ外部結合の仮定義になりますが、 これが(他に定義があるために)宣言に成り下がった場合でも、外部結合であることは動きません。 したがって、 static int hoge = 1; /* 定義(内部結合) */ int hoge; /* 仮定義(外部結合)、ここでは宣言になるが、結合指定が定義と矛盾する */ は未定義動作になります。これに対し、2行目にexternをつけた static int hoge = 1; /* 定義(内部結合) */ extern int hoge; /* 宣言(結合は状況に応じる)、ここでは定義に従い内部結合となる */ は問題ありません(ソースを比較すると、後者のほうが「問題あり」に見えてしまいますが)。 これを「結合」という観点から見ると、「絶対に外部結合」だったものが、 externを付けることで「結合は状況に合わせる」に変わっています。 ではexternの実際の機能は何かというと、 「私は定義ではなく、ただの宣言である。定義はほかにある」ことを明示することにあります。 [1024]ひげおやじさんの > 「別のところにあるのを宣言する」ってのはexternの本質を表していないのですね。 において、「別のところ」というのが「翻訳単位外」を指しているならば、確かに誤りです。 しかし、その「誤りである理由」は、「外部結合が『翻訳単位内も含む』概念だから」ではなく、 「externが(結合とは無関係に)翻訳単位内外両方に定義を探しに行くから」ではないでしょうか。 そもそもリンケージが翻訳単位外に及ぶ(つまり外部結合)、というのと、 宣言が定義を探しに行く範囲が翻訳単位外に及ぶ(extern宣言)、というのは 分けて考えるべきだと思うのですが、皆様のご意見はいかがでしょうか？ なお、ブロック外において明らかに定義と分かるもの(関数定義や、初期化子の付いた変数定義)に externが付いた場合、外部結合になりますね(付けなくても同じですが)。 この場合はexternが文字通り「外部結合」を意味していると考えられますが、 ANSI以前はコンパイルエラーになっていたと聞いたことがあります。

>この小細工を施したヘッダを『すでに定義を書いてあるファイル』に >インクルードしているようなソースが世の中に(けっこう)存在する > >という大前提がありますよね。 えっ? …と読み返したら、yuyaさんの[1034]には確かにそう書いてありました。 (すみません、よく読んでませんでした) この小細工を使うときには、.cにはそもそも定義を書かないと思います。 .cに定義を書いたらメリットがまったくありませんので。 >>・この小細工は、(1)の問題の解決には役に立たない >えーと、これは「小細工を施してもコンパイラはチェックしてくれない」と >いう意味ではなく、「チェックしてくれるのは小細工のおかげではない」と >いう意味ですよね？ そうです。 小細工を行わないとき、方法はふたつあって、[1037]で言うところの a)defvar.cに定義を書き、extern.hに宣言を書く。 　defvar.cではextern.hを#includeする。 b)defvar.cに定義を書き、extern.hに宣言を書く。 　defvar.cではextern.hを#includeしない。 a)なら型チェックが効きますが、b)では効きません。 774RRさんがおっしゃるような、 >この小細工はexternとは同一翻訳単位外のものを取り扱うものだと >「誤解したプログラマ なら、a)はそもそも書けないと思い込んでいるから、型チェックのため 小細工を行った、というのが、私が書いた 「(1)を問題視したプログラマがこの小細工を使った」 の意図です。

どうも自分が議論について行っているつもりで 実は勘違いしているような気がしてきて不安なのですが……。 まず、この議論には この小細工を施したヘッダを『すでに定義を書いてあるファイル』に インクルードしているようなソースが世の中に(けっこう)存在する という大前提がありますよね。その上での話ですが、 > 774RRさんの説は、(1)を問題視したプログラマがこの小細工を使った、 > というものですよね。(2)はいずれにせよ問題になるんですから。 確かに宣言自体を削らずにわざわざexternだけ削っているということは コンパイラのチェックを気にしているとも考えられますが、 単に「ここではまずいから、externを削っとこう」くらいの人もいるような気がします。 誰かが(2)の目的で書いたものを見て、 主旨を誤解して使っている(で、同じことをばっちり2回書いている)というのは あり得そうですね。 >・この小細工は、(1)の問題の解決には役に立たない えーと、これは「小細工を施してもコンパイラはチェックしてくれない」という意味ではなく、 「チェックしてくれるのは小細工のおかげではない」という意味ですよね？

山奥に旅に出ているうちに掲示板が進んでました。 >この小細工はexternとは同一翻訳単位外のものを取り扱うものだと >「誤解したプログラマが」書いてたもので >言語仕様を理解していたプログラマなら書かない代物。 どうでしょうか。私が最初にコレ↓を書いた時点では、 http://kmaebashi.com/programmer/pointer.html 細かい仕様を理解していたかどうかはともかく、extern付きのとそうでないのを 同一コンパイル単位に書いてよい、ということは経験から知っていたと思いますよ (昔のことですし、証拠を出せといわれても困りますが)。 ていうか、変数定義を入れたdefvar.cとextern宣言を入れたextern.hがあったとして、 defvar.cだけextern.hを#includeしないことは容易です。 その場合嬉しくないこととしては以下の2点があって、 (1)defvar.cとextern.hの間でコンパイラのチェックが働かなくなる。 (2)似たようなことを2箇所に書かなければならない。 774RRさんの説は、(1)を問題視したプログラマがこの小細工を使った、 というものですよね。(2)はいずれにせよ問題になるんですから。 (1)の問題は、int hoge[100];とint *hoge;みたいな問題を起こすので 確かに恐ろしいんですが、(2)の問題も存在するわけですから、 (1)の問題のため「だけ」にこの小細工が使われた、というのは無理があるように 思います。 ・この小細工は、(1)の問題の解決には役に立たない(役に立つと思っている 　人がいるとしたら、Cの仕様を知らないだけ)。 ・(2)の問題の解決にはなるが、初期化子が書けなくなるしパーサ通らなくなる 　マクロの使い方なのであまり薦められたもんではない。 ということであれば同意します。

> [結合]を理解していないプログラマが[仮定義]を理解していて、 > 意識してこういうコードを書いたかという点については、俺はきわめて疑問に思う。 > たまたま実害が無かったとしても「間違っているが結果オーライ」なだけだろう。 全面的に同意します。前回もそういうつもりで書きました。 実害が出てくれりゃ勉強する機会も生まれただろうに、と。 > [1020]と[1033]のサンプルは変えてあるのだけど、ちゃんと見てるよね。 はい、ちゃんと見てますです(コメントしておらず失敬しました)。 複数のヘッダファイルをインクルードする状況では、 [1020]だと#undefしとかないと重複定義になっちゃいますね。 でもって、[1035]のようにEXTERNの名前を使い分けるなら、 わざわざHOGE_DEFINITIONだのPIYO_DEFINITIONだのを別に用意する必要はないわけですね。

[結合]を理解していないプログラマが[仮定義]を理解していて、 意識してこういうコードを書いたかという点については、俺はきわめて疑問に思う。 たまたま実害が無かったとしても「間違っているが結果オーライ」なだけだろう。 繰り返すが C++ には[仮定義]は無いのでこーいう書き方はダメ。 [1020]と[1033]のサンプルは変えてあるのだけど、ちゃんと見てるよね。 [1020]は実際には一行抜けてて #undef EXTERN が #ifdef の前に必要 [1033]は EXTERNHOGE と EXTERNPIYO と使い分けて名前がかぶらない 両者ともいちおう正しく使えば[仮定義]も重複しないようになってるつもり。

774RRさん、ありがとうございます。 「現代 C/C++ では不要」とあったので、 古い処理系でも通るようにするための小細工なのかな、 と思ったんですが、「誤解の産物」だったんですね。 誤解されたままで、このヘッダが 外部定義か仮定義のあるファイルにインクルードされてEXTERNが消えても、 それに続く部分は仮定義になるので (つまり、外部定義 + 仮定義になるか、仮定義 + 仮定義になり、 どちらにしても「外部定義がただひとつ」と等価になる) 実害はなかった、ということになるのでしょうか。

>かつてはexternが「同一翻訳単位外のみ」を意味していたのでしょうか？ かつてというのがどのくらい昔の話を意図してるのかわからないけど、 少なくともC89 (ISO/IEC 9899:1990) の文書には今と同じ[結合]の記述がある。 規格採択前の独自仕様の処理系については、もう知る必要も無いと思う。 俺は採択前の処理系も複数個実用してたけど、「外のみ」は無かったと追記しとく。 この小細工はexternとは同一翻訳単位外のものを取り扱うものだと 「誤解したプログラマが」書いてたもので 言語仕様を理解していたプログラマなら書かない代物。 あるいは[1022]前橋さんのコメントのように 宣言部と定義部で類似の記述を分散させるのを嫌ったプログラマが行っていたかもしれない。 ----hoge.h---- extern int hoge; ----hoge.c---- #include "hoge.h" int hoge; // これならここに初期値を書ける -------------- hoge の記述がヘッダとソースで２回出てくるのはミスの元という人がいる 以下のように書いておけば記述が２回必要ないというわけで ----piyo.h---- #ifndef EXTERNPIYO #define EXTERNPIYO extern #endif EXTERNPIYO int piyo; ----piyo.c---- #define EXTERNPIYO #include "piyo.h" // piyo の初期値を与える手段が無い -------------- んで [1022] に既述のごとく初期化子がうまく書けないとか問題があるんで俺はやらない。 ちなみにC++ではODRがあるので「定義にならない宣言」と「定義」は分離するのが定石。 類似の既述が２回でてくるのは仕方ない。類似は同一ではないのだから。

ご回答ありがとうございますm(_ _)m >returnで変数の値を返すときは、それがポインタかどうかに関わらず、別の場所へ中身がコピーされます。 この「returnの動作」の理解が足りませんでした。おかげさまでモヤモヤが取れました。

>以下のような小細工コードをいまだに見るけど、現代 C/C++ であれば不要 >#ifdef HOGE_DEFINITION >#define EXTERN >#else >#define EXTERN extern >#endif 昔のCを知らないので、教えていただきたいのですが、 かつてはexternが「同一翻訳単位外のみ」を意味していたのでしょうか？

日本語がまずかったので訂正。 >呼び出し側で返されたポインタを使って、自動変数（のあった所）にアクセスしているからまずいのです。 呼び出した関数から返されたポインタを使って、自動変数（のあった所）にアクセスしているからまずいのです。

はじめまして。 >そこに載っている関数int_to_strではポインタを返しているからまずいの >でしょうか？それとも、ポインタでなく整数値を返す場合でも、関数の >中で宣言した自動変数の値を返すことはやめた方がよいのでしょうか。 呼び出し側で返されたポインタを使って、自動変数（のあった所）にアクセスしているからまずいのです。 >たとえば、次のような関数は（int_to_strと同じ観点から見て）まずいのでしょうか。 > >int keep(int int_value) >{ > int i; > i = int_value * int_value; > return i; >} この場合は問題ありません。 returnで変数の値を返すときは、それがポインタかどうかに関わらず、別の場所へ中身がコピーされます。 自動変数のポインタを返すとまずいのは、そのポインタが指す領域がなくなってしまうからです。 int *f(void) { int a = 0; return &a; } と言う関数があったとき、 int *p = f(); printf("%p", p); /* pの値を表示する */ のようにすることは何の問題もありません。しかし、ポインタが指している領域はすでに開放されているので、 int *p = f(); printf("%d", *p); /* pが指している領域の値を表示する */ のような事はできない、と言うことです。 こんな感じでしょうか？

お世話になっております。 「C言語ポインタ完全制覇」の９７ページの補足「自動変数の領域は、 関数を抜けたら開放される！」のつながりで質問させてください。 そこに載っている関数int_to_strではポインタを返しているからまずいの でしょうか？それとも、ポインタでなく整数値を返す場合でも、関数の 中で宣言した自動変数の値を返すことはやめた方がよいのでしょうか。 たとえば、次のような関数は（int_to_strと同じ観点から見て）まずいのでしょうか。 int keep(int int_value) { int i; i = int_value * int_value; return i; } ご返答いただけると幸いです。 （なにぶん継ぎ接ぎの知識なもんで、この質問自体がまずいかもしれませんが・・・）

＞トルさん、(ぱ)さん 返信遅くなってすみません。 大変分かりやすく説明していただき、ありがとうございました！ よくわかりました。 「なぜこの関数から？？」 →まさにこの疑問でした・・・。 本当にありがとうございました！！

>「別のところにあるのを宣言する」ってのはexternの本質を表していないのですね。 こういう疑問が出てくるということは、言語規格書を読んでみていいレベルということだ 初心者向け解説書は厳密さよりもわかりやすさを優先せざるを得ないので びみょーに不正確だったりすることがある extern の意味するところは[1020]で書いたとおり、結合指定 C なら JIS X 3010:2003 6.2.2 C++ なら JIS X 3014:2003 3.5 厳密なところは自分で JIS 言語規格書を参照してもらうとして、簡単に言うなら extern:外部結合を指定、static:内部結合を指定 外部結合＝その名前が表す実体は、他の翻訳単位または同じ翻訳単位で使うことができる 内部結合＝その名前が示す実体は、同じ翻訳単位で使うことができる ということだ。

ご回答ありがとうございますm(_ _)m 変数と関数の宣言・定義の違いでの説明がしっくり来ました。 >初心者向け解説として「 extern は別のところにあるものを使う宣言」と書いてある書籍を見かけるけど >言語規格書的には大きく間違い (同一翻訳単位中にあってもかまわないので) まさにこれがもう一つ質問したかったことでした。 「別のところにあるのを宣言する」ってのはexternの本質を表していないのですね。

>グローバル変数の名前が偶然かち合ってしまう可能性があります。 (snip) >と書いてもエラーにならないと困ってしまいます。 C++ においては ODR (One Definition Rule) により、これは必ずエラーになる C ではエラーにならない (仮定義の重複を認める) という違いがあるですな。 初心者向け解説として「 extern は別のところにあるものを使う宣言」と書いてある書籍を見かけるけど 言語規格書的には大きく間違い (同一翻訳単位中にあってもかまわないので) 俺も後輩君にそういう説明したことあるし反省っすな。

>ヘッダ中で宣言＋ソースファイル中で定義することは完璧に正しい これはもちろんそうなのですが、 >以下のような小細工コードをいまだに見るけど、現代 C/C++ であれば不要 >#ifdef HOGE_DEFINITION >#define EXTERN >#else >#define EXTERN extern >#endif この小細工は、ヘッダとソースファイルに似たようなものを分散させたくないという面からは有効だと思いますよ。初期化子がうまく書けないとか、文法的にCのパーサを通らんようなマクロを作るなとか、そもそもそんなにグローバル変数使うなよとか、批判があるのはわかりますが。

>分割コンパイルなどで、外部で定義している変数を参照するにはexternを使う、と >よく本に書いてあると思いますが、外部の関数を参照するにはexternを >付ける必要がないように見受けられるのです。これはなぜなんでしょうか。 774RRさんのおっしゃるようにそういう約束だから…なのですが(X3010の6.1.2.2)それを言ってしまうとつまらないので、理由を考えますと。 大規模なプログラムを何人もの人で書いている場合、グローバル変数の名前が偶然かち合ってしまう可能性があります。たとえば a.c: int hoge; b.c: int hoge; と書いてもエラーにならないと困ってしまいます。この場合、それぞれの担当プログラマには、「グローバル変数の値がいつの間にか変わっている」という得体の知れないバグとして見えるはずです。 その点、「externなしで定義できるのは必ず1箇所のみ、それ以外の箇所では必ずexternを書け」という規則にしておけば、リンク時にエラーになるのでこの問題を回避することができます。 では関数の場合はどうかというと、関数名が偶然かち合ったとして、 a.c: int hoge(void) {...} b.c: int hoge(void) {...} とか書いたらどうせエラーです。 つまり、関数の場合、関数の処理を書くブロックの有無で定義と宣言の区別がつくため、わざわざexternをつける必要はない、というのが私の理解です。

そういう約束だから 関数(原型)宣言に extern も static もない場合は extern が補われると考えよう void myfunc(int); // これには extern も static も明示されてないので extern void myfunc(int); // と解釈される規則 この規則は関数の場合にのみ適用されるので、変数宣言には適用されない 以下は、言語規格書の厳密解釈なので、一読してわからなかったらスキップしてね ・関数宣言で指定できる linkage は static か extern かどちらかだけ (無指定も OK) ・ static が明示されている関数宣言は internal linkage ・ internal linkage でない関数宣言は external linkage ヘッダ中で宣言＋ソースファイル中で定義することは完璧に正しい ----hoge.h---- void hogefunc(double); // This declaration has external linkage ----hoge.c---- #include "hoge.h" void hogefunc(double d) { ... } // This definition also has external linkage 以下のような小細工コードをいまだに見るけど、現代 C/C++ であれば不要 #ifdef HOGE_DEFINITION #define EXTERN #else #define EXTERN extern #endif

「C言語ポインタ完全制覇」を読ませてもらっております。 その本の本筋とは外れるのかしれませんが、第５章のヘッダファイルの作成と関連 してexternでわからない点がいくつかあるので質問させてください。 ご回答いただけると幸いです。 とりあえず、ひとつお聞きします。 分割コンパイルなどで、外部で定義している変数を参照するにはexternを使う、と よく本に書いてあると思いますが、外部の関数を参照するにはexternを 付ける必要がないように見受けられるのです。これはなぜなんでしょうか。

ちょいちさん、はじめまして。 >fgets(buf, 1024, stdin) >と書いていたのを、なぜ急に >fget(buf, 1024, fp) >と変えたのですか？？ もちろんこれはトルさんから回答があったように入力元を変えるためなのですが、 「なぜこのプログラムから?」というのが疑問であるわけですよね。 確かに説明不足だったかもしれません。 理由は、ここで作っている関数input_string()は、汎用の関数を目指している ためです。 このinput_string()は、扱える行の最大長に制限があるとはいえおおむね現実的な 入力においては、長さチェックを行って長すぎる場合にはエラーまで出してくれる、 という便利な関数です。実際、蔵書管理プログラムの中でもあちこちで使われて いますし、今後別のプログラムで使うこともあるかもしれません。 今後別のプログラムで使うことがあるのなら、入力元をstdinに限定して しまったのでは汎用性が薄れます。そこで、input_string()に引数として 入力元を渡せるようにしているわけです。 これで回答になっていますでしょうか?

はじめまして。私は『C言語 体当たり学習徹底入門』はもってないんですが･･･ちょっとだけ。 fgetsの第三引数の型はFILE *で、入力先を指定します。 stdinは標準入力と結びついていますので、stdinを渡せば標準入力から入力します。 fpの方は、どこぞのファイルに結びついていますので、fpを渡せばそのファイルから入力します。 要するに、stdinをfpに変えたのは、読み込み先を変えたという事です。

すいません。 自分の文章が自分でも理解できなかったので 何が分からないかを言い直しますｗ えぇと、「FILE *fpを引数に渡しているのはなぜか」というよりも、 fgets(buf, 1024, stdin) と書いていたのを、なぜ急に fget(buf, 1024, fp) と変えたのですか？？ ってことがわからないってことです・・・。 すんません。

はじめまして。ちょいちというＣ言語初心者です。 C言語体当たり学習徹底入門で勉強しています。 お世話になってます。 で、早速質問を・・・。 既出でしたら大変申し訳ないのですが、 p225のlist5-6やp227のlist5-8において、関数の引数に 『FILE *fp』があるのはなぜですか？ よろしくお願いします。

>お父さんには今夜じゅうにでも謝っておこうかと思います。 それはよかった… ですが。 >後、気になることがあるのですが、以前、掲示板を覗かせてもらったときに、 >前橋さんが僕に対して「前言撤回。こういう馬鹿は一度死ななきゃわからないのかも >しれない。」とおっしゃっていたのを記憶しております。 a) まず、私はそのような発言をした覚えはありません。念のため「前言撤回」や 　「馬鹿」でkmaebashi.comをGoogleサイト内検索してみましたがみつかりません。 b) それ以前の問題として、そもそも吉田さんは、この掲示板に書き込んだのは 　2007年8月1日の[1008]が最初ではないのですか? 「初めまして」と書いてあるし。 　ほんの1～2日前にこの掲示板に登場した人に、過去罵声を浴びせることが 　できるはずがありません。 c) 仮に、吉田さんがかつては別のハンドルネームでうちの掲示板に書き込んでいて 　私から何らかの罵声を浴びせられたとして、だったらその過去のハンドルネームなりを 　教えてもらわなければ、私には、何の話だかわかるはずもありません。　 >これは何に対する憤怒なのでしょうか。 >僕はずっとbrainfuckインタプリタを自分の物として父親に発表されたことによる >憤怒かと思っておりました。 d) 「brainfuckインタプリタを自分の物として父親に発表された」ということを 　吉田さんがこの掲示板に報告したのは、これもつい1～2日前の[1008]の投稿です。 　吉田さんがお父さんに何を発表しようと、その内容を私が知ることは不可能です。 　よって、それによって私が憤怒するなどということがあるはずもありません。 a)だけなら、別の掲示板と勘違いしてたとか、前橋の方が過去に罵声を浴びせた ことを忘れてる、ということもあり得るでしょうが、b), c), d)は、そういうことでは 説明がつきません。 煽りでもなんでもなく思うのですが、吉田さん、統合失調かなにかのケがありませんか。 もちろん私のような素人が勝手に診断を下してよいはずはないわけで、だからこそ、 (現在未受診であれば)精神科の診察を受けられたほうがよいのではないでしょうか。

前橋さん、ご返信ありがとうございます。 brainfuckインタプリタの件に関して前橋さんが「問題ない」とおっしゃってくれてホッとしております（NYSLの簡単な概要に関しては理解しました)。 お父さんには今夜じゅうにでも謝っておこうかと思います。 後、気になることがあるのですが、以前、掲示板を覗かせてもらったときに、前橋さんが僕に対して「前言撤回。こういう馬鹿は一度死ななきゃわからないのかもしれない。」とおっしゃっていたのを記憶しております。これは何に対する憤怒なのでしょうか。僕はずっとbrainfuckインタプリタを自分の物として父親に発表されたことによる憤怒かと思っておりました。もし、違う理由があるのであれば、その理由を教えていただけないでしょうか。よろしくお願いいたします。

>僕が前橋和弥さんの作った宝であるbrainfuckインタプリタをさも自分が >作ったかのように自分の父親に発表してしまったことです。これは >ソースファイルの盗用にあたるかと思います。 Brainfuck自体は、私が考えた言語ではないですし、実装もそこかしこに 転がっていますがそれはさておき。 BF-BASIC'nのソースについて言えば、ライセンスはNYSLであり、これは http://www.kmonos.net/nysl/ | ご自分の作ったものを扱うのと同じように、自由に利用することが出来ます。 と明記してあるとおり、BF-BASIC'nのソースを「さも自分が作ったかのように」 扱うことはまったく問題がありません。 よって、私からすればまったく問題ないわけですが、吉田さんが謝罪すべき 相手はお父様の方ではないでしょうか。嘘をついたわけですから。

初めまして。吉田祥彰という者です。今回は前橋和弥さんへ謝罪いたしたく投稿させていただきました。謝りたい件というのは、僕が前橋和弥さんの作った宝であるbrainfuckインタプリタをさも自分が作ったかのように自分の父親に発表してしまったことです。これはソースファイルの盗用にあたるかと思います。ここで前橋さんにお願いがあります。どうか前橋さんの寛大な心で、僕の愚行を許していただけないでしょうか？今後、このようなことはしないように最大限の注意を払って努力していくつもりです。どうかよろしくお願いいたします。

>BF-BASIC…前フリで「逆にいま BASIC 回帰もありなんだな」とか妙に納得しちゃったんですがすぽぽーんでコーヒー吹きました どうもです。ウケたようで何よりです。 いまさらですが、BF-BASIC'nは日付を見ればわかるように2006年のエイプリルフールに書いたものです。 ところで、前フリ部分は、私にとってはあれはあれで一面の本音ではあります(ぼそっ)。

BF-BASIC…前フリで「逆にいま BASIC 回帰もありなんだな」とか妙に納得しちゃったんですがすぽぽーんでコーヒー吹きましたBF で気づくべきだったのだな

>>コードが美しく、短く、分かりやすいです。 > >うーん、ざっと見ただけですが、なんか効率悪いパーサのような… > 許容範囲のコードかなぁー

>つんつんが時々 訪れている「紫藤さんのページ」のPython関数電卓です。 >http://www.shido.info/py/python_calc.html 情報ありがとうございます。 「Perl, Python, Rubyの比較」 http://www.shido.info/py/python1.html は以前に読んだことがあるのですが、その方のページだったんですね。 >コードが美しく、短く、分かりやすいです。 うーん、ざっと見ただけですが、なんか効率悪いパーサのような…

つんつんが時々 訪れている「紫藤さんのページ」のPython関数電卓です。 http://www.shido.info/py/python_calc.html コードが美しく、短く、分かりやすいです。 （つんつんの関数電卓は、引退しました。） 「紫藤さんのページ」には、scheme の関数電卓もあります。 http://www.shido.info/lisp/scheme_calc.html

>>あ、それすごく面白そうです。何度か書いてますが、私自身車輪の再発明が趣味ですし。 > >私も全く同様なのですが、どうも肩身が狭いですね。 >サイトが稼動し始めたらお知らせします。 や、よろしくお願いします。 エディタとかメーラとか、普段使っているツールは、プログラマにとってもっとも自作 したくなる道具であるはずで、だったらプログラミング言語は最優先のはずではないか、 とも思うのですが。 前提からして間違っているのかなあ… # かくいう私自身、クライアントアプリとしてのメーラを書いたことはないですが # (Webメーラなら書いたことある) >解説とか研修を行なうときは「無駄を省いた自作コース」を提供するのが強力であることが多いと思います。 その意味で、以前書いたように「本当の基礎からのWebアプリケーション入門―― Webサーバを作ってみよう」というのを考えてはいるのですが、Diksamができるまでは お預けです。ていうか私自身読みたいネタなので、誰か書いてくれないかしらん。

>>「車輪の再発明工場(仮称)」なんていうサイトを立ち上げようとしている私としては、 > >あ、それすごく面白そうです。何度か書いてますが、私自身車輪の再発明が趣味ですし。 私も全く同様なのですが、どうも肩身が狭いですね。 サイトが稼動し始めたらお知らせします。 > 言語処理系だけでなく、普段使っている何かを自作するというのは、それを理解する > 一番の方法でもありますし(時間はかかるので効率は悪いですが…)。 そうですよね。何にもない状態から発明した人よりははるかに短時間で作れるわけですから、 解説とか研修を行なうときは「無駄を省いた自作コース」を提供するのが強力であることが多いと思います。 # 「何でも自作してみないと本当に分かった気がしないのは、損なのか得なのか？？」と悩んじゃうことはありますが(^^;)

>「車輪の再発明工場(仮称)」なんていうサイトを立ち上げようとしている私としては、 あ、それすごく面白そうです。何度か書いてますが、私自身車輪の再発明が趣味ですし。 言語処理系だけでなく、普段使っている何かを自作するというのは、それを理解する 一番の方法でもありますし(時間はかかるので効率は悪いですが…)。 >素朴な疑問なんですが、(ぱ)さん自身はCrowbarやDiksamを普段どれくらい使われているのでしょうか？ これはもう正直なところを言ってしまうと、ほぼまったく使っていません。 Diksamなんか現状でprint()しか組み込み関数がないので実用になりませんし、 crowbarならAWK程度の役には立ちそうですが、そもそもAWKとかPerlとかRubyとかの 言語でさくっとテキスト処理、という機会も、今の私にはあまりないですし。

久々にお邪魔します。 >まあ、あの文章が面白いのだとすればそれは別に私の手柄ではなく、 >「プログラミング言語を作る」という行為自体が非常に面白いためなんだろうと >思いますが。 ># でも、同意してくれる人はあまり多くない気がします。残念ながら。 「(ぱ)さんの手柄ではない」という点は同意しませんが、 「言語を作るという行為自体が面白い」という点は同意します(そんなに少数なんですかね？)。 「車輪の再発明工場(仮称)」なんていうサイトを立ち上げようとしている私としては、 「面白そうだからやってみる。それだけ」というノリに共感を覚えてしまうんですが(^^;) 素朴な疑問なんですが、(ぱ)さん自身はCrowbarやDiksamを普段どれくらい使われているのでしょうか？

はじめまして。おほめいただきありがとうございます。 まあ、あの文章が面白いのだとすればそれは別に私の手柄ではなく、 「プログラミング言語を作る」という行為自体が非常に面白いためなんだろうと 思いますが。 # でも、同意してくれる人はあまり多くない気がします。残念ながら。 >「プログラミング言語を作る」を体裁を整えて本にしてください。 >５０００円未満なら買います。 えー、どうなるかはわかりませんが、精進いたします。

>あれ、Cにはありますよ。少なくともC89では既にありました。 ありゃ、本当だ。Cの構文規則は何度も見ているしパーサを書いたことも複数回あるし、 知らなかったはずはないのですがなぜか「ない」と思い込んでいたようです。 >Java は知りません。:) ありました。 http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.15.3 毎度のことながらご指摘ありがとうございます。 嘘を書きましてすみませんでした。

「プログラミング言語を作る」を体裁を整えて本にしてください。 ５０００円未満なら買います。

> CでもJavaでも単項の+演算子は用意されていませんよね あれ、Cにはありますよ。少なくともC89では既にありました。 Java は知りません。:)

　再投稿ありがとうございます。 　電卓の大親分であるはずのPCが目の前にあるのに電卓叩いてたり、あろうことか電卓内蔵のマウスパッドなんかが普通に商品の1ジャンルを占めていたりする現状を見るにつけ、こういう(bcのような)電卓には価値があると思います。 　私はすぐにyaccを使ってしまいますが、つんつんさんのは手書きの再帰下降パーサですね。RubyならRaccという手もあるかと思いますが。 >bc では、+1+1+1 がエラーで、-1-1-1 が成功します。 >動作が変です。 　これは実際そのとおりだと思いますが、CでもJavaでも(ついでに言うとcrowbarでもDiksamでも)単項の+演算子は用意されていませんよね(Rubyにはあるようですが)。 　単項+演算子を付けるのは容易なはずなのに付けてないのは、crowbarやDiksamについて言えば単にCをまねたからなのですが、冗長な表現を嫌ったという理由もあるのかもしれません。

bc では、+1+1+1 がエラーで、-1-1-1 が成功します。 動作が変です。 ruby　スクリプト：正規表現が厳密に合っていないのですが 電卓として機能します。 'q' で終了です。 試してください。 　 http://www.otc.ne.jp/~mugenkai/keisan.rb tntn@otc.ne.jp

>ASTや中間表現は共通で、コード複製はコード生成部で行うことになるのだと >思いますけれども、それをいつやるか、という問題がありますよね。 >Javaのような実行形態を考えると、Listクラスはきっと事前にコンパイルされて >いるはずですし、List<int>を使うクラスがあっちにもこっちにもあるとすると、 >コンパイルの時点で複製すると悲惨なことに。 分割コンパイルを行うときの問題ですか。基本型を対象とするなら個数が あらかじめ決まっているので、Listクラスのコンパイル時に List_int.class, List_long.class, ... を生成しておけば済みそうですが、実体型をユーザが宣言できる言語だと、 同じ手は使えないわけで、考えどころですね。

>PCは新しいのを買ったんでしょうか？ >いまどきなら Core 2 Duo とか？ はてなの方に書いてますが、こんな感じです。 http://d.hatena.ne.jp/kmaebashi/20070620#p1 http://d.hatena.ne.jp/kmaebashi/20070627 ブツ自体はこれです。Core 2 Duoです。 http://panasonic.jp/pc/products/w5a/index.html 久々にはりこみました。

>はい。ただ、それは全ての型について同一のバイトコードで扱えなければならないという方針の場合の話であって、例えば、基本型は型ごとにコード複製、参照型はErasureによって同一のバイトコードに変換するなどの方針であればコンパイラだけでごまかせると思います。 それはそうです。実際C#だと、値型はコード複製、参照型は同一コードということに なっているようですし。 http://ja.wikipedia.org/wiki/C_Sharp%E3%81%A8Java%E3%81%AE%E6%AF%94%E8%BC%83 >確かに。ただ、ASTや中間表現の段階で実体型ごとにコードを複製しておけば、 >「何バイトコピーするか」などの詳細はコード生成部に任せられるのでは？ ASTや中間表現は共通で、コード複製はコード生成部で行うことになるのだと 思いますけれども、それをいつやるか、という問題がありますよね。 Javaのような実行形態を考えると、Listクラスはきっと事前にコンパイルされて いるはずですし、List<int>を使うクラスがあっちにもこっちにもあるとすると、 コンパイルの時点で複製すると悲惨なことに。

> 現在のDiksamについてであれば、実体に対する代入等の操作ができるように > するつもりはありません。 なるほど。 > それがどれぐらい仕様上も実装上も難しいものであるか、 たぶんユーザにも優しくないですよねえ。 > ＠自宅環境復活 PCは新しいのを買ったんでしょうか？ いまどきなら Core 2 Duo とか？

>どこまでVMに実行時情報を持たせるかにもよりますが、たとえばJVMでは、 >T型の変数 a, b があるとき、 >Tがintのときの a = b; と、Tがdoubleのときの a = b;を同一のバイトコードでは >表現できないのでは? >Javaはクラスに関する限りポインタ(参照)しかない言語ですし、 >Genericsで対象にできるのは結局Objectだけなので、コンパイラだけで >ごまかしきれてますけれども。 はい。ただ、それは全ての型について同一のバイトコードで扱えなければならないという方針の場合の話であって、例えば、基本型は型ごとにコード複製、参照型はErasureによって同一のバイトコードに変換するなどの方針であればコンパイラだけでごまかせると思います。 >基本型は対象にしないとしても、クラスの(ポインタでなく)実体を扱えるように >した場合、C++のように機械語を吐くコンパイラでは、「何バイトコピーするか」が >型ごとに違ってきます。このへんVMだと工夫のしようはありそうですが。 確かに。ただ、ASTや中間表現の段階で実体型ごとにコードを複製しておけば、「何バイトコピーするか」などの詳細はコード生成部に任せられるのでは？

>あれ、インスタンスに対して参照だけではなく、実体に対する代入等の操作ができる >ようにするんでしょうか? それはやめた方が良いような。 ええと、みずしまさんの独自言語についてはわかりませんが、 現在のDiksamについてであれば、実体に対する代入等の操作ができるように するつもりはありません。 [975]で >当時は、Javaのような「ポインタしかない言語」が嫌で、クラスは実体でも >宣言できるようにしようとしていましたし、 と書いたように、(ふたつめくらいのDiksamを作っていた)「当時は」、そういう 仕様を考えていた、ということです。 それがどれぐらい仕様上も実装上も難しいものであるか、ということを 知らなかっただけですはい。

> クラスの(ポインタでなく)実体を扱えるようにした場合 あれ、インスタンスに対して参照だけではなく、実体に対する代入等の操作ができる ようにするんでしょうか? それはやめた方が良いような。 継承のあるクラスのインスタンスではなく、単なる構造体のようなものに対してのみ 許すなら問題ないかもしれませんけど...

>普段使っていないと、久しぶりに使ってみたときに、つい括弧つけちゃった >という経験があります。結局、自分が普段使っている言語に合わせるのが一番 >なのかなとも思います。 それもひとつの手ですし、なまじ似てるから混乱するというのなら、 いっそ中括弧でなくendで終わる構文にするとか、根本的に変えてしまう というのもありかもしれませんね。 >>当時は、Javaのような「ポインタしかない言語」が嫌で、クラスは実体でも >>宣言できるようにしようとしていましたし、そうなるとtemplateも、Javaのように >>コンパイラだけでごまかしきることはできなくなります。 > >(C++風の)templateなら、コンパイラだけでなんとかなるのではと思ったのですが、 >何か見落としがあるんでしょうか？あるいは、 どこまでVMに実行時情報を持たせるかにもよりますが、たとえばJVMでは、 T型の変数 a, b があるとき、 Tがintのときの a = b; と、Tがdoubleのときの a = b;を同一のバイトコードでは 表現できないのでは? Javaはクラスに関する限りポインタ(参照)しかない言語ですし、 Genericsで対象にできるのは結局Objectだけなので、コンパイラだけで ごまかしきれてますけれども。 基本型は対象にしないとしても、クラスの(ポインタでなく)実体を扱えるように した場合、C++のように機械語を吐くコンパイラでは、「何バイトコピーするか」が 型ごとに違ってきます。このへんVMだと工夫のしようはありそうですが。

みずしまです。返事が遅くなりましてすみません。 >どうもcrowbar ver.0.1で「ifの後ろの()をなくす」という文法にしたものの >(これも以前のDiksamではすべてそうなっていました)、自分自身すら慣れることが >できなかった、というのがトラウマになっている気もします。 >本当にバリバリに使えば、すぐ慣れることなのかもしれませんけれども。 私の作った言語でも、if、whileなどの後ろの()が無い文法になっているのですが、 普段使っていないと、久しぶりに使ってみたときに、つい括弧つけちゃった という経験があります。結局、自分が普段使っている言語に合わせるのが一番 なのかなとも思います。 >以前の3つくらいのバージョンのDiksamのふたつめくらいまではtemplateを >付けようとしていました。が、結局そのあたりを作っている間に(複雑に >なりすぎて)挫折してしまったわけでして。 >私は今でもgeneric programmingの知識や経験が豊富なわけではありませんが、 >当時はもっと知らなかったにも関わらずそんなところに手を出したら >挫折するのも当然です。 templateの実装は結構複雑そうですね。かく言う自分も、Java generics相当の 機能(JVMで動作するので、仕様はJavaと互換にしたい)を俺言語に搭載しようと 思いつつ、Java genericsの型システムがかなり複雑なので、なかなか 挑めないでいます。 >当時は、Javaのような「ポインタしかない言語」が嫌で、クラスは実体でも >宣言できるようにしようとしていましたし、そうなるとtemplateも、Javaのように >コンパイラだけでごまかしきることはできなくなります。 >型ごとにコード複製やむなし、という考えで作っていたように思いますが、 >結局、その部分の実装まですら行き着けなかったような。 (C++風の)templateなら、コンパイラだけでなんとかなるのではと思ったのですが、 何か見落としがあるんでしょうか？あるいは、 > 型ごとにコード複製やむなし というのが、型ごとにコード複製すれば、コンパイラだけでなんとかなるという 意図でしょうか？

>C言語ポインタ完全制覇の記述などを見ても、後置の型宣言の方がお好みなのかな >と思っていたので、ちょっと意外な気がしました。 私自身も「後置の型宣言の方が好み」と思っています。 現在のDiksamは「4つ目くらいの作り直し中」で、以前のバージョンでは すべて後置にしていました。 どうもcrowbar ver.0.1で「ifの後ろの()をなくす」という文法にしたものの (これも以前のDiksamではすべてそうなっていました)、自分自身すら慣れることが できなかった、というのがトラウマになっている気もします。 本当にバリバリに使えば、すぐ慣れることなのかもしれませんけれども。 >あと、質問なんですが、将来的にDiksamを拡張して、多相型(JavaのGenerics >相当の機能)を付け加える予定はあるでしょうか？多相型のセマンティクスは >言語によってかなりバリエーションがあり、一応俺言語を作っている者として、 >前橋さんがどのようなセマンティクスが良いと考えておられるかについて興味が >あります。 以前の3つくらいのバージョンのDiksamのふたつめくらいまではtemplateを 付けようとしていました。が、結局そのあたりを作っている間に(複雑に なりすぎて)挫折してしまったわけでして。 私は今でもgeneric programmingの知識や経験が豊富なわけではありませんが、 当時はもっと知らなかったにも関わらずそんなところに手を出したら 挫折するのも当然です。 当時は、Javaのような「ポインタしかない言語」が嫌で、クラスは実体でも 宣言できるようにしようとしていましたし、そうなるとtemplateも、Javaのように コンパイラだけでごまかしきることはできなくなります。 型ごとにコード複製やむなし、という考えで作っていたように思いますが、 結局、その部分の実装まですら行き着けなかったような。

>>案としてJava 7風に >> B foo(A); > >Java 7で関数を代入できる変数の宣言は > >B(A) foo; > >では? >http://journal.mycom.co.jp/articles/2006/08/23/java7closuer/002.html あ、そうですね。うろ覚えで書いたので間違ってしまったようです。 >>というわけで、静的型付け関数型言語(MLとかHaskellなど)でよくあるように、 >> foo : int -> int; >>と書くのはいかがでしょう？ > >ご提案ありがとうございます。ちょっと調べてみます。 >ただDiksamは、 >「floatなんか付けるつもりもないくせに浮動小数点数はdouble」 >というくらいC/Javaにひよった言語ですので、Java 7風かなあ、とは思っています。 >と言いつつ、「なぜかBだけ先頭」という規則が美しくないとは思っているんですけどねえ。 C言語ポインタ完全制覇の記述などを見ても、後置の型宣言の方がお好みなのかな と思っていたので、ちょっと意外な気がしました。とはいえ、この程度の細かい シンタックスの違いはある意味どうでもいい話なので、C/Javaにひよるのも一つ なのかもしれません。 あと、質問なんですが、将来的にDiksamを拡張して、多相型(JavaのGenerics 相当の機能)を付け加える予定はあるでしょうか？多相型のセマンティクスは 言語によってかなりバリエーションがあり、一応俺言語を作っている者として、 前橋さんがどのようなセマンティクスが良いと考えておられるかについて興味が あります。

>こんにちは。みずしまです。 こんにちは。 はてなの方でちょっと書いたのですが、自宅PCが不調で、昨夜からついに起動もできなくなりました。今は昼飯がてらネットカフェで書いています。 というわけでしばらく反応が遅くなると思います。ご了承ください。 >案としてJava 7風に > B foo(A); Java 7で関数を代入できる変数の宣言は B(A) foo; では? http://journal.mycom.co.jp/articles/2006/08/23/java7closuer/002.html つまり、 > var foo:(A) B; この形式から、末尾のBを先頭に持ってきて、それ以外の部分をBの後ろにつないだ形式になります(と、私は解釈しています)。 > B foo(A); Diksamには関数のプロトタイプ宣言があるので、この構文はバッティングしますね。 >というわけで、静的型付け関数型言語(MLとかHaskellなど)でよくあるように、 > foo : int -> int; >と書くのはいかがでしょう？ ご提案ありがとうございます。ちょっと調べてみます。 ただDiksamは、 「floatなんか付けるつもりもないくせに浮動小数点数はdouble」 というくらいC/Javaにひよった言語ですので、Java 7風かなあ、とは思っています。 と言いつつ、「なぜかBだけ先頭」という規則が美しくないとは思っているんですけどねえ。

こんにちは。みずしまです。 以前から前橋さんのページの特にプログラミング言語関係のネタをwatchして いましたが、今年になってから「プログラミング言語を作る」の 「静的型・バイトコード実行型言語を作る」編を開始されたということで、 静的型言語好きな自分としては、Diksamがどんな言語になっていくのか 楽しみにしております。 さて、本題なのですが、Diksamでは将来的に関数型の変数を扱う機能の実装を 予定されているようですが、構文に関してはまだ決定されていないようです。 案としてJava 7風に B foo(A); と書く方法と var foo:(A) B; と書く方法の2つを考えておられるようですが、どちらも関数を返す関数などの 複雑な型を書く場合にイマイチな気がします。 C(B) foo(A); //Aを受け取り、「Bを受け取りCを返す関数」を返す関数 var foo:(A) (B) C; //引数と返り値の型が区切られて無いせいで、読みにくい気がする というわけで、静的型付け関数型言語(MLとかHaskellなど)でよくあるように、 foo : int -> int; と書くのはいかがでしょう？

えー、補足で一応書いておくと、 これが私の書いたものに対する正当な批判のつもりなら、 ・そもそもどの文章についてなのか。 ・そこで使われている「バカ」の具体例 くらい出さなきゃ話にならんでしょう。 まあ、こんな書き捨て野郎には何も期待してませんけど。

なんなんすかね、これ。 匿名書き捨て野郎の相手をするほどヒマではないので放置しときますが。

何かアレだな 文章に頻繁に出てくる「バカ」ってのがウザい 人をバカにする文章を書くことで優越感に浸れるのかもしれないけど 読んでる方は不快なだけだから。

ページ直すのが面倒なので今年はこっちでやります。 3/22より例によって断酒しています。 今回の期間はゴールデンウイーク開始まで。 ・飲み会では飲んでもいい。 ・それ以外でどうしても飲んじゃった場合には、その旨をここで報告する。 というふたつの例外条件はいつものとおり。 年度の変わり目は飲み会が多いので、そのへんを狙うのがコツ(ぉぃ)

昨年のBF-BASIC'nに続き、今年も何かエイプリルフールネタをやろうとして、「S式を箇条書きで表現するLispもどき言語」というのを考えてたんですが時間切れでした… あーあ。

　広告が連投されていて、この掲示板では管理者削除で消しても形跡が残るので、鬱陶しいので物理削除しました。 　spam向けの削除機能とspamよけの何らかの機能を考えないといかんかなあ。

はじめまして。お役に立てたのなら幸いです。 >仕事に、「構文解析」の needsが出て、 目的のアプリケーションがCで、yacc/lexが使える状況であれば、 うちのサイトの記述が役に立つかと思います。なお、yaccのコンフリクト 解消については、「プログラミング言語を作る」よりも 「電卓を作ってみよう」 http://kmaebashi.com/programmer/c_yota/calc.html の方に記述がありますのでよろしければそちらもどうぞ(今見返すと、 我ながらアレな文章書いてますが…)。 目的のアプリケーションがC++なら、(yacc/lexも使えますが)Boostの spiritの方がよいかもしれません。 外部ツールやライブラリを使うのが難しいなら、再帰下降で手書きの パーサを書くという方法もありますよね。

仕事に、「構文解析」の needsが出て、 困っているところに、 前橋さんのこのサイトを見つけました。 「あっ！これで、なんとなく、助かるじゃん！」という感じなんです。 本当に、感謝します。 (まったく私の勝手ですが。。。)これから、よろしくお願いします。^_^ さって、「電卓作成」の勉強に入ります。。。

レンタルサーバ業者さんから下記の通りサービス停止の連絡が来ています。 サーバ停止中は、kmaebashi.comの閲覧や掲示板の使用ができません。 ただしメールは届きます。 > メンテナンス作業実施のお知らせ > ネットワーク機器のメンテナンス作業を実施いたします。 > 作業日時：3/5(月)午前1時～ > 作業対象：国内全サーバー > 作業内容：ネットワーク機器のメンテナンス > 作業時間は4時間程度を予定しております。 > 作業中、数回程度断続的にネットワークが遮断されます。 > 一回の遮断は30秒から3分程度となっております。

>http://kmaebashi.com/bbs/ 　なるほど… 報告ありがとうございます。掲示板のスクリプトがhttp://kmaebashi.com/bbs/以下においてあるくせに、Niftyの過去ログがhttp://kmaebashi.com/bbs/index.htmlである、ということがまずいように思えます。 　Niftyの過去ログは、Niftyでは500件で投稿が流れてしまうという制限があったため、せっかくの投稿が消えてしまわないように作ったものです。当時はレンタルサーバ借りて自分で掲示板を設置するとは思いもよらず/bbs/直下にしたわけですが、その後、いざ掲示板を作るにあたっても、別に悪いこともないだろうと/bbs/直下に置いたのが仇になったようです。 　どっちかのURLを変えればよいわけですが、既にNifty掲示板の過去ログも現行掲示板も結構Google等に拾われているようなので、当面このままにしようかと思います。あしからずご了承くださいませ。 　この現象のせいですごく困っている、という方はご報告ください。私は携帯は使わないので、状況を把握していない可能性があります。

> お気になさらず。 ありがとうございます。 テスト板の方で勝手に実験させてもらったのですが、再現しませんでした。 [952]で「Niftyの過去ログに飛んだ」と書きながら OTDの過去ログのURLを書いてしまっていましたが、正しくは http://kmaebashi.com/bbs/index.html でした。おそらく携帯ブラウザの制限から、本来のURLが破棄されて、 /../ すなわち http://kmaebashi.com/bbs/ として解釈されてしまい、index.html が表示されたのだろうと推測しています。 もちろんこのファイル名は「Niftyの過去ログのインデックス」という意味でしょうけれど、 デフォルトインデックスとして扱われてしまったのでしょうね。 # お騒がせしました。

>ありゃ、お役に立とうと思ったら裏目に出てしまった。 >すみませんです。 や、これはもう完璧に私のポカですからお気になさらず。 # SQLの文法の問題だと言い張りたい気はなきにしもあらずですが。

>ありゃ、お役に立とうと思ったら裏目に出てしまった。 >すみませんです。 や、これはもう完璧に私のポカですからお気になさらず。 # SQLの文法の問題だと言い張りたい気はなきにしもあらずですが。

ありゃ、お役に立とうと思ったら裏目に出てしまった。 すみませんです。 前橋さんのサイトは携帯電話のブラウザでも ほとんど問題なく読めるので、よく携帯(au)からアクセスするのですが そのときに起きた現象だったので、 キャッシュは残ってましたがソースが見られない。 うー、気持ち悪い。

>このspammerの書いていたリンク先を、削除される前にクリックしちゃったんですが、 >なぜか旧掲示板(Nifty)の過去ログのページに飛んだんですよ。 >たぶんここに↓↓ >http://kmaebashi.com/bbs/otdindex.html うーん、D/Bをいじってフラグを戻し、投稿を復活させてクリックしてみたのですが、 再現しないようです。 それはさておきその時update文にwhereを付け忘れてしまい… 広告が全部復活してしまいました (;_;) 途中までは消したのですが、今日はもう眠いので後日ぼちぼち消していきます。 とほほ。

このspammerの書いていたリンク先を、削除される前にクリックしちゃったんですが、 なぜか旧掲示板(Nifty)の過去ログのページに飛んだんですよ。 たぶんここに↓↓ http://kmaebashi.com/bbs/otdindex.html 再現されるかどうか分かりませんけど、 何かバグがあるなら修正の機会になるかと思い、一応指摘させていただきました。

>「プログラミング言語を作る」の『サンプル言語「Diksam」』 >http://kmaebashi.com/programmer/devlang/index.html > >の一番下の注釈を消し忘れているみたいです。 ご指摘ありがとうございます。修正しました。

「プログラミング言語を作る」の『サンプル言語「Diksam」』 http://kmaebashi.com/programmer/devlang/index.html の一番下の注釈を消し忘れているみたいです。

>毎度こまかな指摘で恐縮ですが、掲示板のヘルプのページのOTD関係の記述って、 >もう要らないんではないでしょうか？ ご指摘ありがとうございます。気にはしていたのですが、放置したままn年過ぎてしまいました。 ひとまず直しました。不備等ありましたらまた明日以降直します。

毎度こまかな指摘で恐縮ですが、掲示板のヘルプのページのOTD関係の記述って、 もう要らないんではないでしょうか？

「trackback.php」を「aaa.php」に変えるという対策は功を奏さなかったので、トラックバックURLをJavaScriptで生成するようにしてみました。 さてどうなるか。

>> その場でエラーにならなければ参照しているだけですから、通常その後にはクラッシュしません。 > >例えばbufが関数へのポインタの配列だったりすると、 >誤って取得しちゃったbuf[10]の値に従って関数を呼び出すかもしれないわけですよね。 そうですね。 初期化していないデータをポインタとして参照したら、不正なアドレスですから、いつクラッシュしてもおかしくないですね(^_^) # 無謀なキャストも同様ですね。 書き方が少し変でした。 「(参照しているだけですから)その場でエラーにならなければ、通常その後にはクラッシュしません。」 というつもりでした(_ _)

>例えばbufが関数へのポインタの配列だったりすると、 >誤って取得しちゃったbuf[10]の値に従って関数を呼び出すかもしれないわけですよね。 他にもポインタの配列だったり、intの配列でもそれが別の配列の添字になっていたりとか。 >たけさんが初めに出した例(要素の値を表示するだけ)であれば たけさんの最初の例だと、ひとつだけ超えたところですからたぶん書き込んでも死なないんですよね。 この辺の「不定」さがCの難しさではありますが、たとえばJavaでもマルチスレッドなら結果が予測できないことはいくらでもあるので、「ダメなコードは何をしでかすかわからない」ことは結局理解しなければいけないことだよなあ、と思ったり。

>弾いても良いと思いますが (そもそもそういうトラックバックってあります?)、 のまネコ関連でひとつリンクなしが来てますね。この人は正直あまり友達になりたくないタイプではありますが、この手のトラックバックの使い方は全面的に否定はできないような気がします。 もっとも、私はこういうことはしませんし、自分のページは自分のポリシーで運営すればよいので、言及なしトラックバックを禁じてもよいとは思うのですが、「技術的に面倒くさい」というのが結局のところ最大の理由です。 >まあでも今や spam 対策なしのサイト運営は厳しい時代なんじゃないかと。 そう思います。 で、「トラックバックスパム対策」とかでGoogleすると、言及なしリンクをはじいたりフィルタをかけたりする(面倒な)方法ばかりなんですよね。spammerがトラックバックURLを検出する方法を推測すればもっと手軽にいけないかなあ、と思ったのですが、外したようです。そりゃまあ簡単に対策できるならみんなそうするわけで、この結果は必然だったのかもしれませんが、自分で失敗して見えてくるものもありますし。 だから、 >この推測が合っているかどうかは知りませんし、知っている人は知っていることのような気もしますが、ひとまずこの方法で対策します。 と書いたわけです。 spammerが「trackback.php」に反応していたわけではないらしい(少なくとも一部のspammerは)ということがわかっただけでもそこそこ面白かったです。

ああ、確かにちょっと不正確な書き方でしたね。 >>Cでは、配列の範囲を超えたところをアクセスしても、普通はエラー等にはならず、ずっと離れたところでプログラムがクラッシュしたりします。 Cでは、配列の範囲をちょっと越えたところに書き込んでも、普通はエラー等にはならず、ずっと離れたところでプログラムがクラッシュしたりします。 と訂正します。 >無関係なところを参照してアドレスエラーや境界チェックエラーなどになれば、その場でクラッシュするでしょう。 >その場でエラーにならなければ参照しているだけですから、通常その後にはクラッシュしません。 わかって書いておられるとは思いますが、「その場でエラーにならなければ参照しているだけ」とは限りませんよね。

> その場でエラーにならなければ参照しているだけですから、通常その後にはクラッシュしません。 例えばbufが関数へのポインタの配列だったりすると、 誤って取得しちゃったbuf[10]の値に従って関数を呼び出すかもしれないわけですよね。 こういう場合、 「参照だけして、ずっと先でクラッシュしてしまう(or してくれる)」という事態は、 そんなに珍しいことではないように思うのですが。 そういう話をしているのではない!?ならゴメンナサイ。 たけさんが初めに出した例(要素の値を表示するだけ)であれば きっとクラッシュしないでしょうけど。

>Cでは、配列の範囲を超えたところをアクセスしても、普通はエラー等にはならず、ずっと離れたところでプログラムがクラッシュしたりします。 この記述の「アクセス」というのは書き換えを意図しているんだと思います。 コンパイラ、ランタイム、参照アドレスによっても違うでしょうが、 無関係なところを参照してアドレスエラーや境界チェックエラーなどになれば、その場でクラッシュするでしょう。 その場でエラーにならなければ参照しているだけですから、通常その後にはクラッシュしません。 buf[10]を参照することに意味があるとは思いませんが(^^;

> いつものkitさんですよね? あ、そうです。すいません。 > ここ↓で言われている関連仲間文化圏的なものをすべて弾いて良いか、 > という点で迷うところもあるのですけど、 弾いても良いと思いますが (そもそもそういうトラックバックってあります?)、 気になるなら、承認制にして、一度承認したサイトはホワイトリストに登録とか ですかね。 > これを実現するにはトラックバックのURLを見て相手側のページを取得し、URL > が含まれているかどうかをチェックする必要がありますよね。そこまでやらな > きゃいかんのかなあ… こっちの方が面倒そうですよね。 まあでも今や spam 対策なしのサイト運営は厳しい時代なんじゃないかと。

ええと、ハンドル名が「kit1」になっているのは、 [715] http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=715&range=1 の時に間違って入力してしまったものがcookieに残っていたとかで、いつものkitさんですよね? >よくある、先方のページから逆リンクがない限りトラックバックを >認めないor要承認にするって奴はどうでしょうか？ ひとつには、ここ↓で言われている関連仲間文化圏的なものをすべて弾いて良いか、という点で迷うところもあるのですけど、 http://www.kotono8.com/2006/01/06trackback.html それよりも、トラックバックで飛んでくるPOSTには、先方のページの要約しか含まれないので、これを実現するにはトラックバックのURLを見て相手側のページを取得し、URLが含まれているかどうかをチェックする必要がありますよね。そこまでやらなきゃいかんのかなあ… と思いつつ、もうふたつspamが届いている。うへぇ。

ええと、ハンドル名が「kit1」になっているのは、 [715] http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=715&range=1 の時に間違って入力してしまったものがcookieに残っていたとかで、いつものkitさんですよね? >よくある、先方のページから逆リンクがない限りトラックバックを >認めないor要承認にするって奴はどうでしょうか？ ひとつには、ここ↓で言われている関連仲間文化圏的なものをすべて弾いて良いか、という点で迷うところもあるのですけど、 http://www.kotono8.com/2006/01/06trackback.html それよりも、トラックバックで飛んでくるPOSTには、先方のページの要約しか含まれないので、これを実現するにはトラックバックのURLを見て相手側のページを取得し、URLが含まれているかどうかをチェックする必要がありますよね。そこまでやらなきゃいかんのかなあ… と思いつつ、もうふたつspamが届いている。うへぇ。

よくある、先方のページから逆リンクがない限りトラックバックを 認めないor要承認にするって奴はどうでしょうか？

　うちの雑記帳にはトラックバック機能があるのですが、トラックバックspamが毎日数十来ます。 　削除の際は、そのトラックバックのURLのドメインを禁止ドメインに登録し、以後そのドメインのURLのトラックバックはすべてはじく、というフィルタを仕込んでなおこの有様です。 　こんな僻地の自作トラックバックをspammerはどうやって見つけるんだろう、と考えたのですが、 ・うちの雑記帳には自動トラックバック用のRDFは入ってない。 ・「この記事のトラックバックURL」という文言を見つけて、その近辺のURLを… 　とも思ったけれどこんな日本語文言を見つけて英文spamを打ってくるのも変では。 ・トラックバック受信スクリプトが「trackback.php」という名前なのが 　まずいのかなあ。 と考えて、phpの名前を変更しました。 　この推測が合っているかどうかは知りませんし、知っている人は知っていることのような気もしますが、ひとまずこの方法で対策します。 　これでしばらくたってまたspamが来るようになったら、「この記事のトラックバックURL」という文言を画像にしてみるとか、それでも来るようならトラックバックURLの一部(http://kmaebashi.comまで、とか)を画像にしてみるとか、いろいろ試してみようと思います。

御意。およそ何がしたいのか意図がつかめないので、あの程度のコメントとなった次第。 あえてもっと詳しくコメントしてみるテスト char buf[10]; は char が 10 個の配列、の意味。１０個の内訳は buf[0] .. buf[9] の１０個 // ０から開始するので ということは buf[10] は存在しないので、その中身を使ってはならない。 もちろん buf[-1] や buf[-2] や buf[11] や buf[498914] 等も全部ダメ。 char *cp=buf; は char *cp=&buf[0]; の短縮形であるため cp は buf[0] を指す。 んでそもそも buf[1] ってのは *(&buf[0]+1) のこと。 cp[1] も *(cp+1) のこと。 だからこの場合 cp[1] と buf[1] は同じところを意味する。 cp=&buf[1]; とか cp=buf+1; とかすれば cp は１つずれるわけだ。 なのでこうすると、 cp がずれてる分 cp[2] と buf[3] が同じところを意味する。 当然 cp[9] は buf[10] に相当するので前述のごとくこれも使っちゃダメ。 あと配列外をアクセスするとダメってことの解説。 多くの場合配列外に相当するメモリ/アドレス表現は存在していたりする。 存在するけど、そこは他の変数だったり、他の重要な情報だったりする。 ということで配列外をアクセスすると他の変数を壊す＝遠くでクラッシュしたりする。 エラーを OS/CPU が検出してくれる場合もあるが、多くは検出なしにメモリを壊すだけ。 OS/CPU が検出をサボってよい代わりにプログラマが細心の注意を払え、ってのが C/C++ その分、正常に動いている限りにおいては他言語より高速なプログラムが書けたりする。 これとは別に 配列外のオブジェクトの中身を見てはならない (buf[10] はダメ) んだけど 配列直後に限りアドレスを計算しても良い (&buf[10] はＯＫ) という決まりがある。 for (i=0; i<10; ++i) buf[i]=0; と書いてよいごとくに for (cp=&buf[0]; cp<&buf[10]; ++cp) *cp=0; と書いてよいということ。 直後以外はダメ。なので &buf[11] や &buf[-1] は計算しちゃダメ。 計算したらエラーになるかもしれないし、 エラーにならずにおかしな値が得られるかもしれない。 C/C++ は「やっちゃだめ」なことをしたときに「何が起こるかわからない」のだ。 これを「鼻から悪魔が飛び出してもかまわない」と表現したりする。 何が起こるかわからない＝エラー発生、ならまだ良かったりする。 何が起こるかわからない＝一見、プログラマの期待通りに動いたりする、こともある。 後者は怖いよー。

昨晩は「寒いから暖房が効くまで布団の中で本でも読んでよう」と思いつつ気が付いたら朝でした。こんなのばっか。 >>buf[10] で、無いオブジェクトの中を見に行っている時点で許されない。 >>*(cp+10) も同様。 >>ただし &buf[10] や cp+10 は許されるというあたりが微妙なところであったりする。 > >明日試してみます。 ええと、試してみたところで「動いてしまう」可能性がそれなりにあります。 Cでは、配列の範囲を超えたところをアクセスしても、普通はエラー等にはならず、ずっと離れたところでプログラムがクラッシュしたりします。 それはさておき、「たけ」さんのサンプルプログラムでは、代入もしていない「buf[10]」の中身をいきなり参照していますが、それで「'1'」が入っていることを期待しているわけではないですよね? そもそも本当は何を聞きたかったのかが疑問です。 774RRさんのご指摘どおり、char buf[10];で宣言した配列のbuf[10]は参照できませんが、 char buf[10]; char *cp; cp = buf; として、*(cp + 3)とかを参照するのは合法です。buf[3]と同じものが見えます。 ただし、「*(cp + 3)」のようなわかりにくい書き方をするよりは、cp[3]と書いたほうがよいでしょう。これもbuf[3]と同じものが見えます。

>buf[10] で、無いオブジェクトの中を見に行っている時点で許されない。 >*(cp+10) も同様。 >ただし &buf[10] や cp+10 は許されるというあたりが微妙なところであったりする。 明日試してみます。 私は去年の４月から、プログラマーとして、仕事をしています。 配列やポインタの勉強は大変ですが、Ｃ言語が面白くなってきたところです。 たまには、酒でも飲みたいのですが、みんな忙しくて、機嫌が悪いです。

buf[10] で、無いオブジェクトの中を見に行っている時点で許されない。 *(cp+10) も同様。 ただし &buf[10] や cp+10 は許されるというあたりが微妙なところであったりする。

初心者で変な質問をしているかもしれませんが、 教えていただけると助かります。 以下のコードはＣ言語で許されますか？ char buf[10]; char *cp; if (buf[10] != '1'){ printf("array[10]=%c",buf[10]); } cp = buf; if (*(cp + 10) != '1'){ printf("pointer[10]=%c",*(cp + 10)); }

　掲示板で人生相談されても困るんですが。 >お金のため（生きるため）に働くのはいやです。 >６０のしらが親父になってから世界旅行して何が楽しいのかわからないです。 >生きてるか分かりませんが、６０になって自分の残りの人生を考えるたときに >愕然としそうなのがこわい。死ぬまでに悟りたいことがあるんです。 >そんなひまがなく日々の仕事におわれて、いつのまにか年をとっているのが >こわいんです。 　ということは「ゆう」さん的には、35過ぎてもまだあくせく働いている私なんぞは、悟りとやらも一生得られない人生の敗北者なのでしょうから、成功者のところで教えを乞うほうがよいのでは? 　うちの両親は60過ぎてからあちこち旅行行ってますが、そこそこ楽しそうですけども。 　「OB」さんは私の大学の先輩なのですが、一緒に酒を飲んだりすると時々、 「学生の頃は、『世間はそんなに甘くない』ということをよく聞くけれど、 　いざ社会人になってみると結構甘いもんだな」 　という話をしてます。 　世間はもちろん甘くないところもありますが、まっとうにやっていればそうそう理不尽な目に遭うことは少ないし、何となれば転職の自由だってある。努力が常に報われるとは限らないけれども常に報われないわけでもない。特にサラリーマンなんてのは今でも何だかんだで手厚く守られているのであって、サラリーマンが勤まらないような人に起業ができるはずもない。 　就職が決まっているのなら、まずはそこでがんばってみることでしょうに。何もしないうちからいったい何を言っているのかと。

>>技術者として前橋さんのように会社でコツコツがんばっても35歳くらいまでに、 >>金持ちになるのは不可能ですか？前橋さんの経験でよいので話してくれませんか？ >>金持ちの定義は難しいですが、一生働かなくてもよいくらいお金を持っている人の >>こととします。 一生働かなくてもよいくらいのお金がいったい幾らなのかも問題ですが、 一般的にはどんな大きな会社でも、サラリーマンをしていて、そうなれることは まず無いと思います。 ３５歳と言わず、４０歳でも５０歳でもそこまでの稼ぎでリタイアできるだけの 金持ちになるためには自分で会社をやる側（経営陣、でなく会社オーナー）に ならないと無理でしょう。 また一般に会社を自分で興すとそれが楽しくて、金が問題では無くなる様に見えます。 人間の欲望は簡単にインフレーションします。今のあなたの金銭感覚でリタイヤ できるだけのお金を稼ぐ頃には、あなたの金銭感覚もインフレーションしていて その金額では満足出来なるなってることでしょう。 世間でたまに居る若くしてリタイヤするＩＴ長者は金銭感覚のインフレーション よりも、所得の伸びが上回った大変珍しい例だと思います。

>技術者として前橋さんのように会社でコツコツがんばっても35歳くらいまでに、 >金持ちになるのは不可能ですか？前橋さんの経験でよいので話してくれませんか？ >金持ちの定義は難しいですが、一生働かなくてもよいくらいお金を持っている人の >こととします。 　私は35は超えているわけですが、結論から言えば、「一生働かなくてもよいくらいお金を持って」はいませんねえ。持ってたら私だって仕事してません。サラリーマンやってる限りどの会社に行ってもそうじゃないでしょうか。 　ただし、この業界は、仕事がどんどん下請け孫受けに回されて、(仕事内容に関わらず)この階層が下がるほど収入が下がっていくので、腐っても大企業に入っておけ、というのはあります。「一生働かなくてよい」というのは土台無理としても、生活のゆとりに大きく差が出ます。 　本を出したら何もしなくても印税で儲かるのでは、実のところ周りからもよく言われるのですが、それなりに売れる本を出したとしても、出した年だけのことです。私の著書の中では、「ポインタ完全制覇」などはこの業界では結構なロングセラーだと思いますが、今年に関して言えば、飲み代が賄えているかどうか、というところです。 # おまえの飲み代は月にいくらなのか? というツッコミは却下。

はじめまして、私は22歳学生です。前橋さんの本は、わかりやすくて、新たな発見がたくさんありました。私は、情報学部の生徒で、来年の春からシステム系の企業に就職します。プログラムは苦手で、不安で、最近本を読みまくっています…。独習C　柴田望洋さん　ポインタが理解できない理由などなど…。前橋さんの本は、他にはない説明の仕方でとてもわかりやすいです。センスオブプログラミングも途中ですけど、読んでます。わかりやすくて、ためになる知識がつきます。例えば、変数の名前の付け方などです。あげたらキリないのでやめます。ところで、前橋さんは、本を書くくらいですから、かなりの技術力をもち収入もかなりありそうですが…HPなどを拝見してると、そんなことはないみたいな感じがします。私は、金持ちになりたいです。働きたくないからです。技術者として前橋さんのように会社でコツコツがんばっても35歳くらいまでに、金持ちになるのは不可能ですか？前橋さんの経験でよいので話してくれませんか？金持ちの定義は難しいですが、一生働かなくてもよいくらいお金を持っている人のこととします。変な質問をしてすみません。答えるのがめんどければ、答えてくれなくて結構です。忙しそうなので…。

>　掲示板での宣伝行為については、私はよその掲示板管理人より多少は寛大なつもりです。うちの趣旨に合っていて、話題投下としての書き込みであれば、たとえ宣伝が含まれていてもとやかく言うつもりはありません。ただ、アクセスログを見てみると、阿部さんの場合、 > >(1)Googleで「プログラミング言語」を検索 >(2)「プログラミング言語を作る」のトップページを参照 >(3)そこから直接掲示板に来る >(4)リスト表示から一度だけスレッド表示に切り替えた後、 >(5)いきなり投稿フォームへ > >という遷移で来ているようなので、これはかなり「無差別宣伝書き込み」に近いものだと思いますが。 > すばらしい解析能力ですね。うちに財力があれば、来ていただきたいぐらいです。 しかし、考えてみてください。僕がどうしてこのサイトを始めて訪れたとわかるのでしょうか（実際、僕は以前にもここを訪れています）。 そして、この掲示板がプログラミング言語と無縁の掲示板だったら、書き込みをしなかったでしょう。実際、僕がこのような形で書き込んだのは、ここ以外、ありませんから。それは、僕が書いたことの内容を見れば、判断できることだと思います。 さらに言えば、みなをサイトにひっぱてきて、直接の経済活動に結びつけようというものではありません。ただただ、プログラミング言語を作っている人であれば、また、そのサイトを訪れる人であれば、KI言語にも興味を持たれるかもしれない、そう思っただけなのです。何しろ、今の僕には、何の財力もなく、こうした方法で、少しでも、人に関心を持ってもらうことぐらいしか、やれることがないのです。 結局、無差別宣伝かどうかというのは、内容で判断するしかないのではありませんか？ 前橋さんが無差別的書き込みに対して怒る気持ちは、よく分かります。無差別宣伝や嫌がらせに近い書き込みのために、議論やコミュニケーションの場であるはずの掲示板が機能しない。だからこそ、最近は、MIXIがはやるのでしょう（僕も、MIXIなら、まともな議論ができるのかなと思い、少し試してみましたが、残念ながら、あそこは社交の場でしかないようですね）。 ---------------------- カテナスのホームページもリニューアルして、まだ、2ヶ月足らずで、ご指摘の通り、まだまだ不十分です。ただ、少しずつ、更新していますから、「興味があれば」、見にきてください。 最後に、KI言語が何なのかよく分からないというご指摘に関して、こう答えればいいでしょうか。ページを分割して得られる領域（領域に置かれる文字列や図を含む）、自由に配置できる領域、線や曲線などの図形、スタイル情報、プログラム文、データ、メタ情報をすべてキーという名のインスタンスとしてキー構造に配置し、かつ、動的に扱える（生成、挿入、削除ができる）言語。う～む、よけいにわかりにくなったかしら。

>>　SaLAというのがKI言語の実行系のようですが、SaLAはHTMLの代わりにKI言語を解釈するWebブラウザのいとこようなものなのでしょうか。そして、それを使うと「KSCS Labo」に接続できて、お絵かきコンテストに参加できる? > >その通りです。 それを読みとるのに、少なくとも私はえらく苦労したんですけど。 >SaLAは、Vectorにも登録していますが、あなたの言うことに従えば、 >Vectorにある無名の人たちのソフトウェアは、インストールできないと >いうことでしょうか。 　Vectorに登録しているということ自体初耳なわけですが、Vectorの場合、 ・Vector側で最低限の動作確認はしているだろう。 ・もし悪さをするようなソフトなら、ダウンロードしたユーザからVectorに 　通報が行き、しかるべき処置がなされるだろう。 　という期待があるから、そのへんの無名のページからダウンロードするよりは安心感が多少増すでしょうね。もちろんそれはVectorという会社の実績と知名度によるものです。 　まあ実際には、Vectorも「分類目的で内容をチェックすること」しか行ってないようですし、考えてみればMan-in-the-middle攻撃くらってファイルを途中で差し替えられる可能性もゼロとは言えなさそうですが(でも一度でもそれが表面化すれば、Vectorは何らかの対策をしてくれるだろうという期待はあります)。 　このへんの線引きは人によっていろいろあるでしょうが、少なくとも私は、「掲示板への宣伝書き込みからリンクされてるページ」にあるものをうかうかとダウンロードして実行することはできません。これは普通の感覚ではないでしょうか。 　掲示板での宣伝行為については、私はよその掲示板管理人より多少は寛大なつもりです。うちの趣旨に合っていて、話題投下としての書き込みであれば、たとえ宣伝が含まれていてもとやかく言うつもりはありません。ただ、アクセスログを見てみると、阿部さんの場合、 (1)Googleで「プログラミング言語」を検索 (2)「プログラミング言語を作る」のトップページを参照 (3)そこから直接掲示板に来る (4)リスト表示から一度だけスレッド表示に切り替えた後、 (5)いきなり投稿フォームへ という遷移で来ているようなので、これはかなり「無差別宣伝書き込み」に近いものだと思いますが。

>ソフトウェアが使われるのは、ユーザが望む機能がそこにあるからだと思います。知名度が高くても、使ってみようと思わない限りは使われません。 僕が書いたのは、「知名度ないと、ユーザの望む機能があったとしても、使われない」ということです。

>会社名でソフトウェアの信用性が決まるとしたら、悲しいことですね。 >正直のところ、私は、今、肩書きや知名度で判断されるこの社会の中で、それっとどうなの？と叫んではみるものの、いやと言うほどその厳しさを感じています。 ソフトウェアが使われるのは、ユーザが望む機能がそこにあるからだと思います。知名度が高くても、使ってみようと思わない限りは使われません。

>　SaLAというのがKI言語の実行系のようですが、SaLAはHTMLの代わりにKI言語を解釈するWebブラウザのいとこようなものなのでしょうか。そして、それを使うと「KSCS Labo」に接続できて、お絵かきコンテストに参加できる? その通りです。お絵かきコンテストは、少しでも実際に試してもらえればと、考えた企画です。KI言語では、ドロー系の描画を描画命令を順次実行するのではなく、一種のオブジェクトとして、定義しているため、描画ツールの作成が簡単に行えます。 >　それはそれで面白そうではありますが、失礼ながら私は「有限会社カテナス」という会社を存じ上げているわけではないですから、「出処不明のソフトウェア」をそうそう軽々しくインストールするわけにも行きませんし。 SaLAの開発にようやく終わりが見えてきた今、多くの人に使ってもらって、反応を知りたいと考えています。それで、こちらにも投稿したのですが、もし、会社名でソフトウェアの信用性が決まるとしたら、悲しいことですね。SaLAは、Vectorにも登録していますが、あなたの言うことに従えば、Vectorにある無名の人たちのソフトウェアは、インストールできないということでしょうか。 正直のところ、私は、今、肩書きや知名度で判断されるこの社会の中で、それっとどうなの？と叫んではみるものの、いやと言うほどその厳しさを感じています。

丁寧な解説ありがとうございます。 確かに、前橋さんのおっしゃるとおり、 >・sorted_countは「ソートされた要素の数」である。 >・すべての要素がソートされた要素になればよいのだから、sorted_countが 　score_countになるまで回せばよい。 と考えるのは直感的で分かりやすいと思います。 >　単純選択ソートにおいて、未ソート範囲から最小値を選ぶとき、たまたま未ソート範囲内の左端が最小値であれば、事実上交換は発生しません(同じ変数同士の交換になる)。、「sorted_count < score_count」としたとき最後に起きる無駄な交換も、現象としてはこれと同じです。 確かに、言われてみればそのとおりですね。 なんだか重箱の隅をつつくような質問ですいませんでした。

>もう一つ質問なのですが、36行目から始まる外側のforループの判定条件を >「i < score_count - 1」としなかったのは何か訳があってのことでしょうか？ >もし何か訳があれば補足をお願い致します。 特に理由があるわけではないですし、こっちがよいとか主張したいわけでもないですが。 ・sorted_countは「ソートされた要素の数」である。 ・すべての要素がソートされた要素になればよいのだから、sorted_countが 　score_countになるまで回せばよい。 ということで、直感的であるかとは思います。 　107ページの図(Fig.2-7)に、「ソートずみの範囲」と「未ソートの範囲」を色分けし、間に線を引いた図がありますが、ソートが進むにつれ、この境界線がだんだん右に移動し、ついに右端に至ったときがソートの終了と考えれば、「sorted_count < score_count」になるように思います。境界線の右から左に、ぽいぽい要素を放り込んでいくイメージです。 　単純選択ソートにおいて、未ソート範囲から最小値を選ぶとき、たまたま未ソート範囲内の左端が最小値であれば、事実上交換は発生しません(同じ変数同士の交換になる)。、「sorted_count < score_count」としたとき最後に起きる無駄な交換も、現象としてはこれと同じです。単純選択ソートであれば、確かに言われてみれば最後に残った要素は最大値に決まってますから「境界線の右から左に放り込む」必要はないわけなのですが、コメントでも書いておかないと、私の場合「あれっ」とか思ってしまいそうです。 　挿入ソート(List 4-6)でも、「境界線の右から左に、ぽいぽい要素を放り込んでいく」操作を行いますが、こちらでは、最後に残るのが最大値とは限りません。単純選択ソートにおいて最後に最大値が残るのは、あくまでこのソート方法の特性なので、そこを理解して効率のよいコードを書くのもよいですが、必ずしもそこまでやらなくてもバチはあたらないのではないでしょうか。 # とか言いつつ挿入ソートのサンプルソースでは、sorted_countを1から始めてるな…(^^;

> 36行目から始まる外側のforループの判定条件を > 「i < score_count - 1」としなかったのは何か訳があってのことでしょうか？ > もし何か訳があれば補足をお願い致します。 C言語のfor文の判定条件は毎回評価されるので、年寄りとしては ループ内で不変な値を条件式に書くのは躊躇しちゃいますね。 たいてい lim = score_count - 1; for (sorted_count = 0; sorted_count < lim; sorted_count++) { としちゃいます。 まあ score_count が auto 変数でかつアドレス参照されてなければ、 あるいはループ内に関数呼びだしがなければ、いまどきのコンパイラは 自動的に同等な機械語に変換してくれるんでしょうけど。

面白い話題ですね。 私だったら、実行時の無駄を承知の上で判定条件を sorted_count < score_count; /* (-1)は付けない */ とします。 最小値を表す記号を min{x, y, z, ...} と書いたとき、 min{5, 3, 8} = 3 min{2, 2} = 2 min{6} = 6 などとなりますが、このminを定義(あるいは実装)するときに、 ・要素数が2個以上のとき……最小の要素を選ぶ ・要素数が1個　　のとき……その要素そのもの と場合分けするのが良いと考える人は少ないと思います。 そんな話はこの判定条件の問題とは違うのかもしれませんが、 大局的には同じようなセンスの問題をはらんでいると私には感じられます。 経験上は(って、アマチュアですけど)、このようなスタンスで臨むほうが 仕様変更や拡張に強いコーディングになるような気がします。

>my_sort5.cは挿入ソートではなく、単純選択ソートですね。 間違えました。 >(1)条件は「<」なのですから、sorted_countのループ内での最大値は >　score_count-1です。よって、score[sorted_count]で参照する限り、 >　範囲外を参照することはありません。 >(2)38行目からのループは、 >　for (i = sorted_count + 1; i < score_count; i++) { >　で始まっています。iがsorted_count + 1から始まりますが、 >　sorted_countが最大のとき、このループは1回も回らないので、score[i]で >　範囲外が参照されることもありません。 こちらから指摘しておいてすいません。その通りのようです。私が勘違いしていました。 もう一つ質問なのですが、36行目から始まる外側のforループの判定条件を 「i < score_count - 1」としなかったのは何か訳があってのことでしょうか？もし何か訳があれば補足をお願い致します。

>p106のmy_sort5.cのソースコード36行目から始まる単純挿入ソートなのですが、 >誤：for(sorted_count = 0; sorted_count < score_count; sorted_count++) { >正：for(sorted_count = 0; sorted_count < score_count - 1; sorted_count++) { >ではないでしょうか（判定条件の-1が抜けてる）。 >誤りと思われるコードでは、配列の範囲外を（配列の要素数より1つ分多く） >参照してしまうと思います。 my_sort5.cは挿入ソートではなく、単純選択ソートですね。 ソースを確認しましたが、 (1)条件は「<」なのですから、sorted_countのループ内での最大値は 　score_count-1です。よって、score[sorted_count]で参照する限り、 　範囲外を参照することはありません。 (2)38行目からのループは、 　for (i = sorted_count + 1; i < score_count; i++) { 　で始まっています。iがsorted_count + 1から始まりますが、 　sorted_countが最大のとき、このループは1回も回らないので、score[i]で 　範囲外が参照されることもありません。 ただ、単純選択ソートの原理は「未ソート部分から最小値を探してきて左端に持ってくる」というものですから、最後にひとつ残された未ソートの要素は最大値に決まっているので、無駄といえば無駄ではあります。現状のソースだと43～45行目のスワップで、必ず同じ変数をひっくり返します。 これはバグとは思いませんが、補足かなにかで書いておいた方がよいかもしれませんね(今日は時間が時間なのでアレですが)。 ご意見ありがとうございました。

前橋さんの「C言語体当たり学習」の読者です。 正誤表に反映されてない誤りと思われる記述を見つけたので報告させていただきます。 p106のmy_sort5.cのソースコード36行目から始まる単純挿入ソートなのですが、 誤：for(sorted_count = 0; sorted_count < score_count; sorted_count++) { 正：for(sorted_count = 0; sorted_count < score_count - 1; sorted_count++) { ではないでしょうか（判定条件の-1が抜けてる）。 誤りと思われるコードでは、配列の範囲外を（配列の要素数より1つ分多く）参照してしまうと思います。

>僕も新しいプログラミング言語を開発しました。言語名はKIです。 … >ぜひ、試してみてください。できる限り、オープンな形で今後も >開発を進めたいと思っていますので。 　すみません、ページを拝見したのですが、どういうソフトでどういう言語なのか、よくわかりませんでした。 　SaLAというのがKI言語の実行系のようですが、SaLAはHTMLの代わりにKI言語を解釈するWebブラウザのいとこようなものなのでしょうか。そして、それを使うと「KSCS Labo」に接続できて、お絵かきコンテストに参加できる? 　それはそれで面白そうではありますが、失礼ながら私は「有限会社カテナス」という会社を存じ上げているわけではないですから、「出処不明のソフトウェア」をそうそう軽々しくインストールするわけにも行きませんし。

>オブジェクト指向初心者です。 こんにちは。 >最終行の"こちら"の部分がリンク切れのようですが、どこへのリンクでしょうか？ 　すみません、以前にも指摘があって、掲示板には書いたのですが、HTMLの方は直していませんでした。 　書いたのはずいぶん前なので記憶が曖昧なところはありますが、ここのリンク先は↓です。 　http://kmaebashi.com/programmer/object/shigoto.html 　strtok()のように同時に2箇所で使えない「関数」では再利用性が高いとはいえないが、StringTokenizerのようにオブジェクトにすることで、より広く、どこでも自由に使えるようになった、という意図で書いています。

オブジェクト指向初心者です。 「疑り深いあなたのためのオブジェクト指向再入門」を拝見しましたが、 一部リンク切れがあり、内容が非常に気になりますので教えていただければ幸いです。 2. なぜわからなくなってしまうのか? オブジェクト指向で再利用性は高まるか? ～この点についてはこちらで後述します。 最終行の"こちら"の部分がリンク切れのようですが、どこへのリンクでしょうか？

僕も新しいプログラミング言語を開発しました。言語名はKIです。 いわゆる手続き型のプログラミング言語ではありません。 HTMLにJavaSctiptとCSSを加えたようなものと言えばいいでしょうか。 僕は、レイアウト言語と呼んでいます。HTMLは、巻物のようなもの、 つまり、終わりのない文書を整形するための言語ですが、KI言語は ページ内に文字列や図をレイアウトするための言語になっています。 僕自身も、プログラミング言語に関しては、全くの素人ですが、 いつの間にか、結構、大規模なものになりました。 ぜひ、試してみてください。できる限り、オープンな形で今後も 開発を進めたいと思っていますので。 http://www.kathenas.com/

>…と思ったら、 >http://b.hatena.ne.jp/HiromitsuTakagi/ 　高木さんのブックマークに取り上げられたおかげか、はてなでずいぶんブックマークされているようです。 http://b.hatena.ne.jp/entry/http://kmaebashi.com/zakki/zakki0042.html 　「反論」というほどではないにせよ「異論」的なものはあるようですのでコメントしたいのですが、いまちょっと時間が…

>高木さんによるサニタイズに関する記事に対する解釈は、僕も全く同じです。 …と思ったら、 http://b.hatena.ne.jp/HiromitsuTakagi/ で、高木さんご本人からお墨つきがあったんですね。 まあ当然ですなあ。

お、mmasudaさんのリンクをたどると見なれたページが… :-) 高木さんによるサニタイズに関する記事に対する解釈は、僕も全く同じです。 普段読んでる日記だと、 http://www.coins.tsukuba.ac.jp/~hdk/diary/d200602b.html#10-4 でも、本質的には同じ解釈がされてたし(日記の著者は筑波の院生さん)、 そう解釈している人はたくさんいるのではないかと思います。 ただし、それが多数派かどうかは断言できないかもしれないところが、 ちょっと怖い…

>８行目の >>違いが分かるようになりました。 >という書き込みは、本を全て読んだのではなく、まだまだ読むところがあるので >>違いが分かるようになってきました。 >に訂正です。 >小さなことで悪いですが・・・気になって夜も眠れないので訂正させてもらいます。 　や、190ページとのことなので3章の終盤程度ですか。 　3章のラストが「頭に叩き込んでおくべきこと――配列とポインタは別物だ!」なので、配列とポインタの違いに関して言えば、そこでひとまず終了、のつもりです。もちろん4章以降も読んでいただきたいですけれど。

>[895]のComroさんの誤植指摘を見て、なんとなく該当ページを久々に覗いてみたら…… >なんかSPAMトラックバックがえらいことになっていますね。 　ご指摘ありがとうございます。 　実はトラックバックSPAMは定期的に消しています(消すためのページを作りました。1件ずつチェックボックスで選んで削除するUIにしてしまったので数が多いと大変です)。 　ここ数日、出張してたりとかいろいろあって溜め込んでしまいました。放っておくと1日数十とかのオーダーでSPAMが来ます。 　あんまりひどいので、トラックバックのリンク先URLをドメイン単位ではじく機能を追加し、削除する際そのテーブルにドメインを追加しているのですが、それでもこの有様です。 　ちなみに現在禁止ドメインは1315件あります。はじいたトラックバックについては現在特に記録を残していないのですが、そのうち修正して、どれくらいの比率でSPAMをはじいているのかを見てみようと思っています。 　それにしてもなんでまたこんなWebの片隅にある手作りトラックバックにまでSPAMがやってくるのやら… 　「Brainfuckのせいか?」と思ったこともあるのですが、SPAMが来るのはあそこばかりでもないですし。

>前橋さんの書いた本(C言語ポインタ完全制覇)を入門書の次の次に読み、 お読みいただきありがとうございます。 >僕はPerlしか知りませんが、Perlはelsifです。 こちらもご指摘ありがとうございます。 elseifがふたつありましたね… typoでした。

８行目の >違いが分かるようになりました。 という書き込みは、本を全て読んだのではなく、まだまだ読むところがあるので >違いが分かるようになってきました。 に訂正です。 小さなことで悪いですが・・・気になって夜も眠れないので訂正させてもらいます。

[895]のComroさんの誤植指摘を見て、なんとなく該当ページを久々に覗いてみたら…… なんかSPAMトラックバックがえらいことになっていますね。 雑記帳のインデックスのページでは一番下の過去記事リンクにたどり着くまで ぐぉぉぉーっとスクロールしなきゃいけなくなってます。 http://kmaebashi.com/zakki/index.html 余計なお世話かと思いましたが、もし前橋さんがご存知でなければと思い、 指摘させていただきました。 個人的には閲覧の妨げとして無視できない量になりつつあるので、 できれば削除して欲しいなぁ、と思います。

前橋さんの書いた本(C言語ポインタ完全制覇)を入門書の次の次に読み、 分かりやすいし、補足も面白くて、良い本だと思い、作者をＹＡＨＯＯで検索したら、このページに着きました。 ちなみに、入門書の次に読んだ本は、よく分からず途中で止めて、C言語ポインタ完全制覇を読みはじめました。 今までに僕の買ったＣ言語関係の本にはこんなこと書いてなく、 この本を読むまでいつも、配列とポインタの違いが分からず混乱していましたが、 違いが分かるようになりました。 まだ、１９０Ｐぐらいまでしか読んでいませんが、早くこの本を全部読んで、 途中で読むのを止めていた入門書の次の本を読破したいです。 この本と早めに出合えて本当に良かったです。 そして、訂正ですが、 「プログラミング言語を作る」の「見た目の問題(2005/6/25)」の Perl, Ruby, MODULA-2, Ada, Eiffel elseifについて、 僕はPerlしか知りませんが、Perlはelsifです。 それでは。

>うーん、私が想定していたのは、内部形式をふたつ作るのではなく、 >「読み込んで内部形式に変換するところ」でまとめて変換する、というものでした。 >内部形式をふたつ作ってもよいでしょうが、ストロークを少なくするという >code golfの趣旨に反するような気がします。 ここでおっしゃっている内部形式が私の考えているものとずれているかもしれないですが、例えば、入力(文字列)を内部形式(メモリ上の変数)、例えば、リストなどに変換するのは、Pythonでは、sが入力文字列だとすると、list(s)とするだけですし、forなどに文字列(シーケンス)を直接渡しても、1文字ずつ処理してくれるので文字列が内部形式としても良いですし、どのタイミングで変換するかは問題ではないように思えますがどうでしょう？ 文字列を1文字ずつ処理するのは、例えば、以下のような感じ。 >>> s = 'test' >>> for c in s: ... print c, ... t e s t >Perlはたまに使いますがたまにしか使わないので身に付かず、 >PHPはここの掲示板を作った程度、 >Rubyはちょこちょこ見ては試しにプログラムを動かしたりはしてますが、 >Rubyのソースを書くのに費やした時間よりRubyの実装のソースを読んだ時間の方が >長いくらい、 >PythonはRubyについてよりも浅学ですねえ。 なるほどです。しかし、crowbarみたいなスクリプト言語を作れるというのはすごいと思います。PythonがRubyよりも浅学というのはPythonファンの私としては残念です。 >「Rubyソースコード完全解説」をWebで読んじゃって本を購入しなかったので、 >罪滅ぼしに「ふつうのHaskellプログラミング」を読んでたり。 私も「ふつける」は購入しましたが、最近、MYCOMから出た「入門Common Lisp」という本も買ってしまいました。最近、(ぱ)さんが本を出さないのは残念です。何か書く予定があったら教えてください。

>>それをすべきタイミングは >>Brainfuckソースを読み込んで内部形式に変換するところでしょうから、 >>「文字列変換」ではないですよね。 > >リスト(内部形式)に変換してから別のリスト(内部形式)に変換しても >良いかもしれません。 うーん、私が想定していたのは、内部形式をふたつ作るのではなく、 「読み込んで内部形式に変換するところ」でまとめて変換する、というものでした。 内部形式をふたつ作ってもよいでしょうが、ストロークを少なくするという code golfの趣旨に反するような気がします。 >Perl、PHP、Ruby、Pythonなどを想定していました。 Perlはたまに使いますがたまにしか使わないので身に付かず、 PHPはここの掲示板を作った程度、 Rubyはちょこちょこ見ては試しにプログラムを動かしたりはしてますが、 Rubyのソースを書くのに費やした時間よりRubyの実装のソースを読んだ時間の方が 長いくらい、 PythonはRubyについてよりも浅学ですねえ。 「Rubyソースコード完全解説」をWebで読んじゃって本を購入しなかったので、 罪滅ぼしに「ふつうのHaskellプログラミング」を読んでたり。

すいません(汗)。先ほどの返信で、 >さすがに(ぱ)も手を出しているのかなと思いました。 「(ぱ)さんも」と書こうとして、「(ぱ)も」と書いてしまいました…。大変失礼致しました…<_O_>

ご回答ありがとうございます。 >Code Golf自体は以前「Matzにっき」からリンクを辿って、ページの構成が >わかりにくいのもあってちょっと眺めただけでしたが。 ルールがどこに明記されているのか分かりにくいのは私も感じました。 >ええと、Brainfuck問題というのは > > ... > >で、課題は、 >・マスタングさんがPythonで書いたBrainfuckの処理系に、 >・課題のページで与えられているBrainfuckのコードを食わせて、 >・正しい解答が、4秒以内に得られること > >ですよね? (「4秒以内」という制限がどこに書いてあるのか、見つけられていませんが) その通りです。４秒以内というのは問題によってたまに書いてるのですが、Code Golfでのルールみたいです。 >うちの処理系をベースにしたのであれば、実行部分は、アルゴリズム的に小手先で >最適化できる余地はあんまりないのではないでしょうか(Brainfuck処理系には、 >「]」が来たとき実行時に「[」を検索しているようなものもありますが、うちの >処理系はそのへんは読み込み時に済ませていますし)。 >Pythonの実装に依存するチューニングの余地はあるかもしれません。読み込んだ >Brainfuckプログラムをどのような内部形式で保持するか、とか。 Pythonの実装に依存するチューニングは確かにありそうですが、残念ながら思いつきません。内部形式もリストを使用しているのですが、dict(辞書)も値として式しか書けないので使えなさそうですし他には分かっていません。 >5秒を4秒にする程度のことであれば、「++++」を「+4」のようなひとつのコードに >するというアイディアで十分かとは思いますが、それをすべきタイミングは >Brainfuckソースを読み込んで内部形式に変換するところでしょうから、 >「文字列変換」ではないですよね。 6秒を4秒かもしれません。文字列変換というのは、例えば、'>+++++[<+++]<.'という入力(文字列)が与えられたときに、'>+5[<+3]<.'という文字列に変換してからリスト(内部形式)に変換することを想定していました。リスト(内部形式)に変換してから別のリスト(内部形式)に変換しても良いかもしれません。 文字列変換を考えていたのは、正規表現で簡単にできないかなと考えていました。 >(「スクリプト」が何なのかが不明ですが)いろいろな言語の本やら解説ページやら >読んではいますが、簡単なチュートリアルの例題とかではなく、実際に日頃から >自分の問題を解くために使っていないと、「身に付く」ことにはならないようですね。 スクリプトは、最近、LL言語と言われているもの、例えば、Perl、PHP、Ruby、Pythonなどを想定していました。普段使ってないと身に付くことにならないというのは同感です。私もC++やJavaは本読んでいただけなので全く身についていません。 Ruby、Pythonは世間で今流行っているというイメージがあったので、さすがに(ぱ)も手を出しているのかなと思いました。Haskellとか関数型言語などを勉強しているのかなとか。 悩んでいても進まないのでとりあえず、Brainfuck問題はPendingしておくことにしました。ありがとうございます。

Code Golf自体は以前「Matzにっき」からリンクを辿って、ページの構成が わかりにくいのもあってちょっと眺めただけでしたが。 >最近Pythonを覚えて、Code Golf(http://codegolf.com/) >というコンペにはまっているのですが、Brainfuck問題というのがあり、(ぱ)さんのソースを参考にさせて頂いたのですが、最後の問題が４秒以内という制限にTime outでパスしません。恐らくあと1秒くらい短縮しないとダメみたいです。 ええと、Brainfuck問題というのは http://codegolf.com/brainfuck ここのことで、「最後の問題」というのは、このページの一番下のところにある Rot-13の問題のことですか? WikipediaのRot-13のページ： http://ja.wikipedia.org/wiki/ROT13 で、課題は、 ・マスタングさんがPythonで書いたBrainfuckの処理系に、 ・課題のページで与えられているBrainfuckのコードを食わせて、 ・正しい解答が、4秒以内に得られること ですよね? (「4秒以内」という制限がどこに書いてあるのか、見つけられていませんが) >ネックは、入力の1文字1文字をループで回しているところだと思うのですが、3百万回のループが問題になっていそうです。スクリプトはループに弱いので。 うちの処理系をベースにしたのであれば、実行部分は、アルゴリズム的に小手先で 最適化できる余地はあんまりないのではないでしょうか(Brainfuck処理系には、 「]」が来たとき実行時に「[」を検索しているようなものもありますが、うちの 処理系はそのへんは読み込み時に済ませていますし)。 Pythonの実装に依存するチューニングの余地はあるかもしれません。読み込んだ Brainfuckプログラムをどのような内部形式で保持するか、とか。 >何か一般的に早くアウトプットを得る方法はあるのですか？とりあえず、'++++'などを'+4'のようにすればループ回数が劇的に減るかなと思っているのですが、まだ試していません。うまい文字列変換が思いつかないので。 5秒を4秒にする程度のことであれば、「++++」を「+4」のようなひとつのコードに するというアイディアで十分かとは思いますが、それをすべきタイミングは Brainfuckソースを読み込んで内部形式に変換するところでしょうから、 「文字列変換」ではないですよね。 >あと(ぱ)さんはスクリプトは勉強とかされていますか？ (「スクリプト」が何なのかが不明ですが)いろいろな言語の本やら解説ページやら 読んではいますが、簡単なチュートリアルの例題とかではなく、実際に日頃から 自分の問題を解くために使っていないと、「身に付く」ことにはならないようですね。

お久しぶりです、マスタングです。もし分かれば教えて欲しいです。 最近Pythonを覚えて、Code Golf(http://codegolf.com/) というコンペにはまっているのですが、Brainfuck問題というのがあり、(ぱ)さんのソースを参考にさせて頂いたのですが、最後の問題が４秒以内という制限にTime outでパスしません。恐らくあと1秒くらい短縮しないとダメみたいです。 ネックは、入力の1文字1文字をループで回しているところだと思うのですが、3百万回のループが問題になっていそうです。スクリプトはループに弱いので。 何か一般的に早くアウトプットを得る方法はあるのですか？とりあえず、'++++'などを'+4'のようにすればループ回数が劇的に減るかなと思っているのですが、まだ試していません。うまい文字列変換が思いつかないので。他に何かうまい方法ありますか？ あと(ぱ)さんはスクリプトは勉強とかされていますか？

>プログラミング（超）初心者です。 はじめまして。ほめていただきありがとうございます。 最近仕事に追われておりまして、Webページの更新もすっかり滞り、 この掲示板も放置状態でしたが、久々に投稿いただきその点でもありがとうございます。 >前橋先生の他の本を購入しようと思っています。 それはもう是非(商魂モード)

プログラミング（超）初心者です。 「C言語体当たり学習　徹底入門」を図書館で借りました。 あまりのわかりやすさに大感激です。　(^o^)/ 前橋先生の他の本を購入しようと思っています。

>そういえばLGPLはスタティックリンクはだめでしたっけ。すっかり忘れてました。 必ずしもスタティックリンクが駄目というわけじゃないですが、 スタティックリンクすると、 LGPL http://www.gnu.org/licenses/lgpl.html の第6項 a) みたいな制約を満たさないといけなくなります。 すなわち、LGPL なライブラリを再リンクできるようにするため、 アプリケーションの側のオブジェクトコードか、ソースコードを 提供する必要が生じます。 それよりはダイナミックリンクして、第6項 b) の適用を選んだ方が 楽なことが多いんじゃないかと思います。

Subject変えました。 >>「本当の基礎からのWebアプリケーション入門 ―Webサーバを作ってみよう―」 > >　ネットワークに関してはほとんど無知なので何とも言えませんが、Webサーバの >作成は原点に戻りすぎではありませんか？随分と役に立つとは思いますけど。 昔、「インターネットを256倍使うための本」というのがあって、その中に、 「シェルによるhttpdの実装」というのがありました。 …今探したらソースが公開されていました。こちらです。 http://www.ascii.co.jp/books/support/4-7561-1663-9/supplement/0001/shttpd こちらによれば、 http://www.ascii.co.jp/books/support/4-7561-1663-9/supplement/ 「筆者が偉いんではなく、shが偉いんでもなく、ズバリinetdが偉い」そうですが、 その部分をJavaかなんかでちょろっと書いてしまえば、Webサーバとしての機能は すぐに実装できそうですし、それをベースにいろいろ拡張すれば勉強になるんじゃ ないかなあ、と思うわけです。ブラウザが何を送ってきてるのか目で見えますし、 どう対応すればいいかもわかるので。

>SDL は LGPL なので、スタティックリンクするよりは、Windows の場合なら >実行ファイルと同じディレクトリに展開されるようにアーカイブを作る方が >いいでしょうね。 そういえばLGPLはスタティックリンクはだめでしたっけ。すっかり忘れてました。 >LGPL よりライセンスの緩いライブラリとしては Allegro というのがあるよう >です。http://www.talula.demon.co.uk/allegro/ こちらも情報ありがとうございます。 >行数については、大学時代には、1日1000行、6日で6000行書いちゃう先輩が >いました。まあ、この人は特別で、絶対真似できんと当時から言ってましたが。 現在なら、1日1000行はやれないこともないのですが…あくまで「非常時」だけですね。 後で読みたくないコードになることが多いので。

>Cで掲示板というのは別の意味ですごいというか、ずいぶん手間がかかったのでは >ないでしょうか。PHPを覚えるほうが手っ取り早いような。 　PHPの$_POSTの代わりの物をせっせと作っていたりした辺りを手間と言えば確かにPHPより はずいぶん手間がかかりました。 　一番時間がかかったのはデータベースを使わなかったので、保存や読み込みの辺りです。 ちょうどその頃「プログラミング言語を作る」でyaccとlexが使われていたので、興味本位で 使ってみたりしました。楽ができたかと聞かれますと微妙ですが。 >「本当の基礎からのWebアプリケーション入門 ―Webサーバを作ってみよう―」 　ネットワークに関してはほとんど無知なので何とも言えませんが、Webサーバの作成は原点に 戻りすぎではありませんか？随分と役に立つとは思いますけど。 >掲示板のプログラムを公開することは、Webページのひとつも立てれば可能では >ないでしょうか。お金もかかりませんし。 　それは可能ですが、見てくれる相手が未だにいないのが悩みの種です。メーリングリストなどに 参加してみたいとは思うのですが、今は色々とありますのでまだ先の事になると思いますし。

>P.198 L.3 (4-6-1) >Line polyline_array[LINE_MAX]; 確認しました。ご指摘ありがとうございました。正誤表に入れておきます。 >　話が変わりますが、「PHPとMySQLで掲示板を作る」を前に読ませていただき、 >私も作ってみたいな～、と思い、前橋さんの掲示板を参考にして作ってみました。 >まともに使える言語がCしかなく、練習の意味合いも込めてCで作ったのですが、 >あまり上手くは作れませんでした。 Cで掲示板というのは別の意味ですごいというか、ずいぶん手間がかかったのでは ないでしょうか。PHPを覚えるほうが手っ取り早いような。 とはいえ、CGIはWebアプリケーションの基本ですから、(Perlでもよいので)一度は 作っておくべきものかとは思います。最近は、PHPやらJSPやらStrutsやら、果ては ASP.NET等いろいろ便利な道具があって、もちろんそれはそれでよいのですが、 結局下回りを知らないと困ることもありますから。 「本当の基礎からのWebアプリケーション入門 ―Webサーバを作ってみよう―」 なんての、誰か書いてくれませんかね… >　独学で、周りにプログラミングのできる知り合いがおらず、評価したりして >もらえないので寂しいです。 掲示板のプログラムを公開することは、Webページのひとつも立てれば可能では ないでしょうか。お金もかかりませんし。 >　あと、「プログラミング言語を作る」も楽しく読ませていただいています。 ありがとうございます。停滞しておりましてすみません。

SDL は LGPL なので、スタティックリンクするよりは、Windows の場合なら 実行ファイルと同じディレクトリに展開されるようにアーカイブを作る方が いいでしょうね。 Linux の場合は、ディストリビューションに最初からついてきて、デフォルト でインストールされることが多いので、特に考慮の必要はないと思います。 LGPL よりライセンスの緩いライブラリとしては Allegro というのがあるよう です。http://www.talula.demon.co.uk/allegro/ 行数については、大学時代には、1日1000行、6日で6000行書いちゃう先輩が いました。まあ、この人は特別で、絶対真似できんと当時から言ってましたが。 大学祭の展示が素晴らしいってのは同感です。

正誤表に載っていませんでしたので、お知らせします。（初版第一刷） P.198 L.3 (4-6-1) Line polyline_array[LINE_MAX]; とありますが、 PolyLine polyline_array[LINE_MAX]; ではないでしょうか？ 　話が変わりますが、「PHPとMySQLで掲示板を作る」を前に読ませていただき、 私も作ってみたいな～、と思い、前橋さんの掲示板を参考にして作ってみました。 まともに使える言語がCしかなく、練習の意味合いも込めてCで作ったのですが、 あまり上手くは作れませんでした。 　独学で、周りにプログラミングのできる知り合いがおらず、評価したりしてもらえないの で寂しいです。 　あと、「プログラミング言語を作る」も楽しく読ませていただいています。

どうもです。返答が遅くなりましてすみません。 >> そろそろWindowsに特化してもいいんじゃないかと思っていたり(謎)。 >これって昔聞いたあの話の関連ですかね。 　この文言はcrowbar 0.4の時のToDoリストに入ってまして、この時は そういうこともそれなりに考えていたのですが、今はちょっと別方面に 手を出しつつあって、どうしようかなあ、という状態です。 >だとすると、SDL をライブラリとして使えば、Windows に特化しなくても >いいのではないかって気もします。 　毎度アドバイスありがとうございます。 　ちょっと調べてみましたが、このへんを見る限り、使い方はそんなに 難しくなさそうです。 http://lazyfooproductions.com/SDL_tutorials/index.php 　ただ、あっち方面を目指す場合、「.EXEファイル単体で動く」というのは それなりに重要な用件であるように思います。crowbarもそっち方面を目指すなら、 HSPやひまわりがそうであるように、インタプリタとスクリプトをひとつの .EXEにまとめられなきゃな、と思っていました。そこに別のDLLが必要に なるというのはちょっと…(Windows限定なら、staticに固めてしまえばよいのかも しれませんが) >大学祭で見たアレも SDL で作ってた >そうです。たかだか千数百行であれくらいできてしまうってのも驚き >でしたが。 　そう思います。 　でも、自分が大学生だった頃のことを考えると、「千数百行」は「たかだか」では なかったわけで、その意味でもびっくりです。今の現役生はがんばってるなあ、と。 　

> そろそろWindowsに特化してもいいんじゃないかと思っていたり(謎)。 これって昔聞いたあの話の関連ですかね。 だとすると、SDL をライブラリとして使えば、Windows に特化しなくても いいのではないかって気もします。大学祭で見たアレも SDL で作ってた そうです。たかだか千数百行であれくらいできてしまうってのも驚き でしたが。

>　たとえ話は好きじゃないですが、材木屋さんになったと想像してください。 >材木がコンベアーに(縦方向に)乗って流れてくるのですが、材木の長さはまちまちです。 >あなたはそれを箱詰めして発送しなければなりません。 1点補足します。 あなたが立っている場所からはコンベアーの端しか見えず、材木はとても長いので、 材木が最後まで流れてこないと材木の長さがわからない、と思ってください。 …やっぱり、このたとえ話もはずしたかな?

>お世話になります。プログラミング初心者です。 > >「ポインタ完全制覇」のp218のList 4-6のプログラムで質問させてください。 > >76--79行目でmallocを使っているのは何故なのでしょうか。 > >代わりに、 > >return st_line_buffer; > >では駄目なのでしょうか。 　マスタングさんが書いておられるように、この書き方では、2行目が読み込まれたときに1行目の領域が上書きされてしまいます。st_line_bufferが指す先の領域はひとつしかないからです。 　ただし、たとえば以下のように書けば、 temp = st_line_buffer; st_line_buffer = NULL; st_current_buffer_size = NULL; return temp; 　次のread_line()の呼び出しでは新たな領域が割り当てられますから、正しく動作することでしょう。ただし、st_line_bufferはALLOC_SIZE(256バイト)ずつまとめて伸びていきますから、行の長さによってはメモリが無駄になります。 　256バイトずつではなく、1バイトずつrealloc()していけばこの無駄はなくせますが、p.221で説明しているようにrealloc()はそれなりに重い関数なので、あまり頻繁にrealloc()しないため、こうしているわけです。 　List 4-6では、以下の戦略をとっています。 (1)ファイルから文字を1文字ずつ読み込み、いったん「一時置き場」に蓄える。 (2)「一時置き場」はひとつしかない。 (3)行が「一時置き場」に入りきらない場合、「一時置き場」は256バイトを単位に 　まとめて拡張される。一時置き場が縮むことはない。 (4)行を最後まで読み終わり、行の長さが確定した時点で、その行の長さに 　ぴったり合わせたサイズの領域を新たに確保し、そこにコピーして、 　利用者に返す。 　たとえ話は好きじゃないですが、材木屋さんになったと想像してください。材木がコンベアーに(縦方向に)乗って流れてくるのですが、材木の長さはまちまちです。あなたはそれを箱詰めして発送しなければなりません。 　コンベアーの端に広めの作業領域を作り、いったん材木をそこに置いて、正確な長さを測ってから、ぴったりの大きさの箱を作るという方法が無駄がないと思いませんか? このプログラムではそういう方針をとっているわけです。 　

>僕が混乱したのは、きっと、１次式の定義に「式」という１次式を含む未定義の >クラスが登場したと受け止めたからだと思います。 その受け止め方は正解です。そして再帰的定義というのはそういうものです。 ちょうどうちのページにこんな文書がありまして、簡易的な電卓の構文規則を載せています。 http://kmaebashi.com/programmer/devlang/yacclex.html 7: expression /* 「式」とは… */ 8: : term /* 「項」、 */ 9: | expression ADD term /* または、「式」 + 「項」 */ 10: | expression SUB term /* または、「式」 - 「項」 */ 11: ; 12: term /* 「項」とは、 */ 13: : primary_expression /* 「一次式」、 */ 14: | term MUL primary_expression /* または、「項」 * 「一次式」 */ 15: | term DIV primary_expression /* または、「項」 / 「一次式」 */ 16: ; 17: primary_expression /* 「一次式」とは… */ 18: : DOUBLE_LITERAL /* 実数のリテラル */ 19: ; この電卓は括弧が使えないのでprimary_expressionの定義は異なりますが、 この電卓でも、式の定義にはやっぱり式が登場します。 K&Rをお持ちであれば、巻末の構文規則(p.298あたり)でCの式の構文が定義されています。 >式は１次式から構成されるものなのでしょうが、どのように構成されるものをそう言うのか、 >そこでの記述では不明だと思います。定義になっていないのでは。 ポインタ完全制覇における式の定義に関する説明は、 ・「式には1次式と呼ばれるものがあります」 ・「式に対して演算子を適用したり、演算子でもって式と式をつなぎ合わせたもののことも、 　　また式と呼びます」 　となっています。 　Cには関数呼び出し等を含めたくさんの演算子がありますし、sizeof(型)はどうなるのか等、この定義では曖昧すぎるというご意見はあるかと思いますが、この場所でそれを延々と書くのもよろしくないと判断した、のだと思います。ずいぶん前の話なので記憶が曖昧ですが。 　

一部、間違えました。 (誤) >char s1, s2; (正) char *s1, *s2;

>「ポインタ完全制覇」のp218のList 4-6のプログラムで質問させてください。 > >76--79行目でmallocを使っているのは何故なのでしょうか。 > >代わりに、 > >return st_line_buffer; > >では駄目なのでしょうか。違いがわからないのですが。 これは、オブジェクト指向の防御的コピーに近いですが、 read_line()が、st_line_bufferを素直に返している訳ではないので ちょっと違うかもしれません。 read_line.cファイルが1つのオブジェクト、st_line_bufferがprivateな メンバと考えると、実装詳細を直接戻すと、カプセル化が崩れるという 考え方も可能だと思います。 違いは以下です。 // もし、read_line()で、st_line_bufferを返す場合 char s1, s2; s1 = read_line(fp); // 例えば、s1が、"abc" s2 = read_line(fp); // 例えば、s2が、"def" // ここで、s1もs2も、"def"となる! // もし、read_line()で、コピーを返せば、 // s1は"abc"、s2は"def"となる。

お世話になります。プログラミング初心者です。 「ポインタ完全制覇」のp218のList 4-6のプログラムで質問させてください。 76--79行目でmallocを使っているのは何故なのでしょうか。 代わりに、 return st_line_buffer; では駄目なのでしょうか。違いがわからないのですが。 ご教授いただけると幸いです。

ご回答ありがとうございました。 >　説明不足でしたでしょうか。 >　「定義するもの自身をその定義で書いた」もののことを「再帰的定義」と言いまして、プログラミングの世界ではさほど珍しいものではありません。 僕が混乱したのは、きっと、１次式の定義に「式」という１次式を含む未定義のクラスが登場したと受け止めたからだと思います。 式は１次式から構成されるものなのでしょうが、どのように構成されるものをそう言うのか、そこでの記述では不明だと思います。定義になっていないのでは。

>そのため 「部分式 1+2*3 」に括弧をつけて (1+2*3) と書くと、これが部分式になるという規則が必要なのです。 typo これぢゃ意味判らん orz 部分式 1+2*3 に括弧をつけて (1+2*3) と書くと、これが一次式になる ですな。

もっとあえて蛇足するなら (1+2*3)+4*5 とかを考えるといいかもしれません この例では括弧内を先に、括弧外の + を後に評価してもらわなければなりません。 もっというなら + より先に 4*5 を評価してもらわなければなりません。 そのため 「部分式 1+2*3 」に括弧をつけて (1+2*3) と書くと、これが部分式になるという規則が必要なのです。 実際のプログラムも再帰を使います。

>１次式の定義の中で、「式を（）で囲んだもの．」とあるのですが、 >定義するもの自身をその定義で書いたらいけないと思うのですが。 　説明不足でしたでしょうか。 　「定義するもの自身をその定義で書いた」もののことを「再帰的定義」と言いまして、プログラミングの世界ではさほど珍しいものではありません。 「再帰的定義」でGoogle: http://www.google.co.jp/search?hl=ja&q=%E5%86%8D%E5%B8%B0%E7%9A%84%E5%AE%9A%E7%BE%A9&lr= >きっと、その上３つを指しているんだと思うのですが・・・。 ポインタ完全制覇p.165より引用します。 | 1次式とは以下のものを指します。 | ・識別子(変数名、関数名のこと) | ・定数(整数定数と浮動小数点定数を含む) | ・文字列リテラル(""で囲まれた文字列) | ・式を()で囲んだもの 　「その上３つ」と解釈すると、「(hoge)」とか「(0.5)」とか「("abc")」とかになりますが、「(hoge + 5)」と書いても1次式なので、その解釈ではまずいです。「その上3つ」は「1次式」の定義ですが、4つ目では「『式』を()で囲んだもの」と書いています。

「C言語ポインタ完全制覇」の165ページなのですが。１次式の定義の中で、「式を（）で囲んだもの．」とあるのですが、定義するもの自身をその定義で書いたらいけないと思うのですが。きっと、その上３つを指しているんだと思うのですが・・・。僕には精神衛生上きついっす。

>これは、オブジェクト指向とは言わないのではないでしょうか？ >あえて言うなら、オブジェクト指向の特徴の一つである『データ抽象化』でしか >ないと思います。オブジェクト指向というには、『継承』の概念が実装されている >必要もあると思います。 　まあそうなのかもしれませんけど、「どこまでやってるとオブジェクト指向であるか」といった用語の定義的な議論は、既にずいぶん曖昧な定義で使われている「オブジェクト指向」という言葉については、不毛だと思います。 前にもあげたページだと思いますが http://www.shiro.dreamhost.com/scheme/trans/reesoo-j.html | オブジェクト指向というものが動く標的であるため、オブジェクト指向の熱心な | 支持者はこのメニューのうちの適当なサブセットを気まぐれに選んで、それを以って | 他の言語はオブジェクト指向ではないと説得しようとする。 私も以下のように書きました。 http://kmaebashi.com/programmer/object/intro.html | ※2 「それは抽象データ型だ」という意見もあるかもしれませんが、抽象データ型は | オブジェクト指向に至るためには必須の概念です。 Matzにっきより。 http://www.rubyist.net/~matz/20030729.html#p01 |「オブジェクト指向」のもっとも重要な概念は通常のプログラミングにも登場して | いる。たとえば、Cで | FILE *f = fopen(path, "r"); | という呼び出しは「pathにあるファイルをオープンして、ファイルオブジェクトを | 得る」という処理そのものだ。別にオブジェクト指向は必要ない。CのFILE*には | fprintf()やfclose()などのいくつかの「メソッド」がある。 >（ただし、Xtも単なる抽象データ型だったかも。継承を実装していたか記憶が > 定かではありません。 継承は実現していましたね。たとえばMotifのRowColumnはManagerのサブクラスです。 # んで、JavaのレイアウトマネージャがComponentクラス階層の中になく、 # プラグイン的に突っ込むようになっているのを見て衝撃を受けましたとも。

>オブジェクト指向の標準関数がありますね。FILE * を介して行なうファイル入出力です これは、オブジェクト指向とは言わないのではないでしょうか？ あえて言うなら、オブジェクト指向の特徴の一つである『データ抽象化』でしかないと思います。オブジェクト指向というには、『継承』の概念が実装されている必要もあると思います。 >その他、X Window System の Xlib やそのツールキットもオブジェクト指向です。 私は、学生の頃、Xtのソースを読んで、『なんだこのコーデイングは？なんで構造体に関数のポインタぶち込んでるんや？』『おお！そういうことか！すげー！』と凄い衝撃を覚えました。 このころは、まだオブジェクト指向という言葉を知らなかったのですが、あとからC++を勉強したときには、C言語のテクニックを駆使して無理やりオブジェクト指向に仕上げたXtはやっぱり凄かったんだと再認識しましたね。（ただし、Xtも単なる抽象データ型だったかも。継承を実装していたか記憶が定かではありません。でも、構造体に関数をぶち込んでいる時点でFILEとfopen等よりも高度ですね。関数のポインタを書き換えて振る舞いを変えさせることもできましたしね。）

>本屋でJAVA謎+落とし穴徹底解明を見つけました。 >あまりにも難しい内容ですが今困っていますので教えてください。 >WIN　XPSP2で証券会社のHPにアクセスすると下記ERRで強制終了します。 >またSUN JAVAコンソールをクイックしても同じERRになります。 > > ># ># An unexpected error has been detected by HotSpot Virtual Machine: ># ># EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d6c20e6, pid=1228, tid=2324 ># ># Java VM: Java HotSpot(TM) Client VM (1.5.0_02-b09 mixed mode) ># Problematic frame: ># V [jvm.dll+0x820e6] ># > >--------------- T H R E A D --------------- > >Current thread (0x0562a6a8): JavaThread "main" [_thread_in_vm, id=2324] > >siginfo: ExceptionCode=0xc0000005, reading address 0x00000008 > >Registers: >EAX=0x00000000, EBX=0x00000000, ECX=0x00000008, EDX=0x00000000 >ESP=0x069f5f74, EBP=0x069f5fac, ESI=0x0562a6a8, EDI=0x00000000 >EIP=0x6d6c20e6, EFLAGS=0x00010246 > >Top of Stack: (sp=0x069f5f74) >0x069f5f74: 6d6c494b 00000000 00000000 0562a764 >0x069f5f84: 6d317763 0000000c 09352923 00000000 >0x069f5f94: 100f38a0 00000000 00000000 056cf3a8 >0x069f5fa4: 0562a6a8 00000000 069f5fd0 6d304c3a >0x069f5fb4: 0562a764 6d317774 00000000 0562a764 >0x069f5fc4: 00000000 00000000 0562a764 069f5ff8 >0x069f5fd4: 6d30543a 0562a764 069f6003 6d317774 >0x069f5fe4: 6d317768 6d317750 055f5684 0562a764 > >Instructions: (pc=0x6d6c20e6) >0x6d6c20d6: e8 0c 2a ff ff c3 8b 44 24 04 8b 0d b0 64 7a 6d >0x6d6c20e6: 8b 04 01 c3 8b 44 24 04 8b 0d ac 64 7a 6d 8b 04 > > >Stack: [0x06900000,0x06a00000), sp=0x069f5f74, free space=983k >Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >V [jvm.dll+0x820e6] >C [java.dll+0x4c3a] >C [java.dll+0x543a] >C [java.dll+0x54d3] >C [java.dll+0x18ba] >j java.lang.ClassLoader$NativeLibrary.load(Ljava/lang/String;)V+0 >j java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+300 >j java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+48 >j java.lang.Runtime.load0(Ljava/lang/Class;Ljava/lang/String;)V+57 >j java.lang.System.load(Ljava/lang/String;)V+7 >v ~StubRoutines::call_stub >V [jvm.dll+0x818e8] >V [jvm.dll+0xd4989] >V [jvm.dll+0x817b9] >V [jvm.dll+0x887ae] >C [jpishare.dll+0x4380] >C [jpishare.dll+0x1eb2] >C [jpiexp32.dll+0x5744] >C [npjpi150_02.dll+0x1abf] >C [ole32.dll+0x2206a] >C [ole32.dll+0x40a03] >C [ole32.dll+0x4071d] >C [ole32.dll+0x27b76] >C [ole32.dll+0x27a62] >C [ole32.dll+0x27c48] >C [ole32.dll+0x27bf4] >C [ole32.dll+0x4112b] >C [ole32.dll+0x410e2] >C [ole32.dll+0x27c9b] >C [ole32.dll+0x27a62] >C [ole32.dll+0x27a7c] >C [ole32.dll+0x27a62] >C [ole32.dll+0x278f6] >C [ole32.dll+0x277af] >C [ole32.dll+0x27731] >C [urlmon.dll+0x3c5c7] >C [urlmon.dll+0x3cb1e] >C [urlmon.dll+0x3ce5a] >C [mshtml.dll+0x273785] >C [mshtml.dll+0x273afa] >C [mshtml.dll+0x26e889] >C [mshtml.dll+0x275cfe] > >Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >j java.lang.ClassLoader$NativeLibrary.load(Ljava/lang/String;)V+0 >j java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+300 >j java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+48 >j java.lang.Runtime.load0(Ljava/lang/Class;Ljava/lang/String;)V+57 >j java.lang.System.load(Ljava/lang/String;)V+7 >v ~StubRoutines::call_stub > >--------------- P R O C E S S --------------- > >Java Threads: ( => current thread ) > 0x066f0878 JavaThread "traceMsgQueueThread" daemon [_thread_blocked, id=2540] > 0x066decc0 JavaThread "AWT-Windows" daemon [_thread_in_native, id=560] > 0x066de8d8 JavaThread "AWT-Shutdown" [_thread_blocked, id=460] > 0x066dab40 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=1336] > 0x06657588 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=2148] > 0x0659d750 JavaThread "CompilerThread0" daemon [_thread_blocked, id=292] > 0x06554df8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2536] > 0x06592a50 JavaThread "Finalizer" daemon [_thread_blocked, id=2532] > 0x0563a580 JavaThread "Reference Handler" daemon [_thread_blocked, id=2528] >=>0x0562a6a8 JavaThread "main" [_thread_in_vm, id=2324] > >Other Threads: > 0x06581580 VMThread [id=2496] > 0x05659768 WatcherThread [id=744] > >VM state:not at safepoint (normal execution) > >VM Mutex/Monitor currently owned by a thread: None > >Heap > def new generation total 576K, used 334K [0x100b0000, 0x10150000, 0x10810000) > eden space 512K, 52% used [0x100b0000, 0x100f3a80, 0x10130000) > from space 64K, 100% used [0x10140000, 0x10150000, 0x10150000) > to space 64K, 0% used [0x10130000, 0x10130000, 0x10140000) > tenured generation total 1408K, used 201K [0x10810000, 0x10970000, 0x160b0000) > the space 1408K, 14% used [0x10810000, 0x10842500, 0x10842600, 0x10970000) > compacting perm gen total 8192K, used 3930K [0x160b0000, 0x168b0000, 0x1a0b0000) > the space 8192K, 47% used [0x160b0000, 0x16486a20, 0x16486c00, 0x168b0000) >No shared spaces configured. > >Dynamic libraries: >0x00400000 - 0x00419000 C:\Program Files\Internet Explorer\iexplore.exe >0x7c940000 - 0x7c9dd000 C:\WINDOWS\system32\ntdll.dll >0x7c800000 - 0x7c931000 C:\WINDOWS\system32\kernel32.dll >0x77bc0000 - 0x77c18000 C:\WINDOWS\system32\msvcrt.dll >0x77cf0000 - 0x77d7f000 C:\WINDOWS\system32\USER32.dll >0x77ed0000 - 0x77f16000 C:\WINDOWS\system32\GDI32.dll >0x77f20000 - 0x77f96000 C:\WINDOWS\system32\SHLWAPI.dll >0x77d80000 - 0x77e29000 C:\WINDOWS\system32\ADVAPI32.dll >0x77e30000 - 0x77ec1000 C:\WINDOWS\system32\RPCRT4.dll >0x76350000 - 0x764bc000 C:\WINDOWS\system32\SHDOCVW.dll >0x765c0000 - 0x76653000 C:\WINDOWS\system32\CRYPT32.dll >0x77c40000 - 0x77c52000 C:\WINDOWS\system32\MSASN1.dll >0x75410000 - 0x75485000 C:\WINDOWS\system32\CRYPTUI.dll >0x76be0000 - 0x76c0e000 C:\WINDOWS\system32\WINTRUST.dll >0x76c40000 - 0x76c68000 C:\WINDOWS\system32\IMAGEHLP.dll >0x770d0000 - 0x7715c000 C:\WINDOWS\system32\OLEAUT32.dll >0x76970000 - 0x76aad000 C:\WINDOWS\system32\ole32.dll >0x59250000 - 0x592a4000 C:\WINDOWS\system32\NETAPI32.dll >0x76660000 - 0x76704000 C:\WINDOWS\system32\WININET.dll >0x76f10000 - 0x76f3c000 C:\WINDOWS\system32\WLDAP32.dll >0x77bb0000 - 0x77bb8000 C:\WINDOWS\system32\VERSION.dll >0x762e0000 - 0x762fd000 C:\WINDOWS\system32\IMM32.DLL >0x60740000 - 0x60749000 C:\WINDOWS\system32\LPK.DLL >0x73f80000 - 0x73feb000 C:\WINDOWS\system32\USP10.dll >0x77160000 - 0x77262000 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll >0x7d5b0000 - 0x7ddad000 C:\WINDOWS\system32\SHELL32.dll >0x5ab60000 - 0x5abf7000 C:\WINDOWS\system32\comctl32.dll >0x58730000 - 0x58768000 C:\WINDOWS\system32\uxtheme.dll >0x74660000 - 0x746ab000 C:\WINDOWS\system32\MSCTF.dll >0x75ed0000 - 0x75fcd000 C:\WINDOWS\system32\BROWSEUI.dll >0x20000000 - 0x20010000 C:\WINDOWS\system32\browselc.dll >0x76d90000 - 0x76db2000 C:\WINDOWS\system32\appHelp.dll >0x76f80000 - 0x76fff000 C:\WINDOWS\system32\CLBCATQ.DLL >0x77000000 - 0x770ab000 C:\WINDOWS\system32\COMRes.dll >0x73620000 - 0x7364e000 C:\WINDOWS\system32\msctfime.ime >0x4edc0000 - 0x4ee16000 C:\WINDOWS\system32\imjp81.ime >0x648f0000 - 0x649c0000 C:\WINDOWS\system32\imjp81k.dll >0x3b100000 - 0x3b11b000 C:\WINDOWS\IME\IMJP8_1\Dicts\IMJPCD.DIC >0x75c40000 - 0x75cdc000 C:\WINDOWS\system32\urlmon.dll >0x77fa0000 - 0x77fb1000 C:\WINDOWS\system32\Secur32.dll >0x76570000 - 0x765c0000 C:\WINDOWS\System32\cscui.dll >0x76550000 - 0x7656c000 C:\WINDOWS\System32\CSCDLL.dll >0x76040000 - 0x76199000 C:\WINDOWS\system32\SETUPAPI.dll >0x10000000 - 0x100af000 c:\program files\google\googletoolbar1.dll >0x71a00000 - 0x71a0b000 C:\WINDOWS\system32\WSOCK32.dll >0x719e0000 - 0x719f7000 C:\WINDOWS\system32\WS2_32.dll >0x719d0000 - 0x719d8000 C:\WINDOWS\system32\WS2HELP.dll >0x76af0000 - 0x76b1b000 C:\WINDOWS\system32\WINMM.dll >0x5a820000 - 0x5a827000 C:\WINDOWS\system32\serwvdrv.dll >0x58a60000 - 0x58a67000 C:\WINDOWS\system32\umdmxfrm.dll >0x74cd0000 - 0x74d61000 C:\WINDOWS\system32\MLANG.dll >0x76940000 - 0x76964000 C:\WINDOWS\system32\ntshrui.dll >0x76ad0000 - 0x76ae1000 C:\WINDOWS\system32\ATL.DLL >0x759b0000 - 0x75a60000 C:\WINDOWS\system32\USERENV.dll >0x71a50000 - 0x71a62000 C:\WINDOWS\system32\MPR.dll >0x75eb0000 - 0x75eb7000 C:\WINDOWS\System32\drprov.dll >0x71b60000 - 0x71b6e000 C:\WINDOWS\System32\ntlanman.dll >0x71c20000 - 0x71c35000 C:\WINDOWS\System32\NETUI0.dll >0x71be0000 - 0x71c20000 C:\WINDOWS\System32\NETUI1.dll >0x71bd0000 - 0x71bd7000 C:\WINDOWS\System32\NETRAP.dll >0x71b40000 - 0x71b53000 C:\WINDOWS\System32\SAMLIB.dll >0x75ec0000 - 0x75ec9000 C:\WINDOWS\System32\davclnt.dll >0x73cc0000 - 0x73cd3000 C:\WINDOWS\system32\shgina.dll >0x758b0000 - 0x759a3000 C:\WINDOWS\system32\MSGINA.dll >0x762b0000 - 0x762c0000 C:\WINDOWS\system32\WINSTA.dll >0x73520000 - 0x7355d000 C:\WINDOWS\system32\ODBC32.dll >0x76300000 - 0x76348000 C:\WINDOWS\system32\comdlg32.dll >0x03aa0000 - 0x03ab7000 C:\WINDOWS\system32\odbcint.dll >0x092d0000 - 0x09349000 C:\WINDOWS\system32\Audiodev.dll >0x086c0000 - 0x08904000 C:\WINDOWS\system32\WMVCore.DLL >0x070d0000 - 0x0710b000 C:\WINDOWS\system32\WMASF.DLL >0x67930000 - 0x679d1000 C:\WINDOWS\system32\DBGHELP.DLL >0x76e90000 - 0x76ecc000 C:\WINDOWS\system32\RASAPI32.DLL >0x76e40000 - 0x76e52000 C:\WINDOWS\system32\rasman.dll >0x76e60000 - 0x76e8f000 C:\WINDOWS\system32\TAPI32.dll >0x76e30000 - 0x76e3e000 C:\WINDOWS\system32\rtutils.dll >0x72220000 - 0x72225000 C:\WINDOWS\system32\sensapi.dll >0x03dd0000 - 0x03e52000 C:\WINDOWS\system32\shdoclc.dll >0x04060000 - 0x0406e000 C:\Program Files\Adobe\Acrobat 7.0\ActiveX\AcroIEHelper.dll >0x7c340000 - 0x7c396000 C:\WINDOWS\system32\MSVCR71.dll >0x75de0000 - 0x75e8f000 C:\WINDOWS\system32\SXS.DLL >0x040c0000 - 0x04620000 C:\WINDOWS\system32\xpsp2res.dll >0x71980000 - 0x719bf000 C:\WINDOWS\system32\mswsock.dll >0x607c0000 - 0x60816000 C:\WINDOWS\system32\hnetcfg.dll >0x719c0000 - 0x719c8000 C:\WINDOWS\System32\wshtcpip.dll >0x04b20000 - 0x04b3c000 c:\progra~1\mcafee.com\vso\McVSSkt.dll >0x76ed0000 - 0x76ef7000 C:\WINDOWS\system32\DNSAPI.dll >0x76930000 - 0x76938000 C:\WINDOWS\system32\LINKINFO.dll >0x76f70000 - 0x76f76000 C:\WINDOWS\system32\rasadhlp.dll >0x03d80000 - 0x03d9c000 C:\Program Files\Adobe\Acrobat 7.0\ActiveX\PDFShell.dll >0x7cca0000 - 0x7cf85000 C:\WINDOWS\system32\mshtml.dll >0x74600000 - 0x74627000 C:\WINDOWS\system32\msls31.dll >0x74630000 - 0x7465a000 C:\WINDOWS\system32\msimtf.dll >0x64890000 - 0x648eb000 C:\WINDOWS\IME\imjp8_1\IMJPCIC.DLL >0x75ba0000 - 0x75c0e000 C:\WINDOWS\system32\jscript.dll >0x75390000 - 0x75401000 C:\WINDOWS\system32\mshtmled.dll >0x72c70000 - 0x72c79000 C:\WINDOWS\system32\wdmaud.drv >0x72c60000 - 0x72c68000 C:\WINDOWS\system32\msacm32.drv >0x77b90000 - 0x77ba5000 C:\WINDOWS\system32\MSACM32.dll >0x77b80000 - 0x77b87000 C:\WINDOWS\system32\midimap.dll >0x71c90000 - 0x71cac000 C:\WINDOWS\system32\ACTXPRXY.DLL >0x6bf50000 - 0x6bf85000 C:\WINDOWS\system32\dxtrans.dll >0x6d5d0000 - 0x6d5da000 C:\WINDOWS\system32\ddrawex.dll >0x736b0000 - 0x736f9000 C:\WINDOWS\system32\DDRAW.dll >0x73b10000 - 0x73b16000 C:\WINDOWS\system32\DCIMAN32.dll >0x6bf90000 - 0x6bfea000 C:\WINDOWS\system32\dxtmsft.dll >0x1c000000 - 0x1c006000 C:\WINDOWS\HKNTDLL.dll >0x5ec50000 - 0x5ec89000 C:\WINDOWS\ime\mscandui.dll >0x6d590000 - 0x6d5a1000 C:\Program Files\Java\jre1.5.0_02\bin\npjpi150_02.dll >0x5c9a0000 - 0x5c9b7000 C:\WINDOWS\system32\OLEPRO32.DLL >0x6d400000 - 0x6d417000 C:\Program Files\Java\jre1.5.0_02\bin\jpiexp32.dll >0x76f60000 - 0x76f68000 C:\WINDOWS\System32\winrnr.dll >0x6d450000 - 0x6d468000 C:\Program Files\Java\jre1.5.0_02\bin\jpishare.dll >0x6d640000 - 0x6d7c5000 C:\PROGRA~1\Java\JRE15~1.0_0\bin\client\jvm.dll >0x6d280000 - 0x6d288000 C:\PROGRA~1\Java\JRE15~1.0_0\bin\hpi.dll >0x76ba0000 - 0x76bab000 C:\WINDOWS\system32\PSAPI.DLL >0x6d610000 - 0x6d61c000 C:\PROGRA~1\Java\JRE15~1.0_0\bin\verify.dll >0x6d300000 - 0x6d31d000 C:\PROGRA~1\Java\JRE15~1.0_0\bin\java.dll >0x6d630000 - 0x6d63f000 C:\PROGRA~1\Java\JRE15~1.0_0\bin\zip.dll >0x6d000000 - 0x6d166000 C:\Program Files\Java\jre1.5.0_02\bin\awt.dll >0x72f50000 - 0x72f76000 C:\WINDOWS\system32\WINSPOOL.DRV >0x73890000 - 0x73960000 C:\WINDOWS\system32\D3DIM700.DLL >0x6d240000 - 0x6d27d000 C:\Program Files\Java\jre1.5.0_02\bin\fontmanager.dll >0x6d1f0000 - 0x6d203000 C:\Program Files\Java\jre1.5.0_02\bin\deploy.dll >0x049c0000 - 0x049dd000 C:\Program Files\Java\jre1.5.0_02\bin\RegUtils.dll >0x08910000 - 0x08bd6000 C:\WINDOWS\system32\msi.dll > >VM Arguments: >jvm_args: -Xbootclasspath/a:C:\PROGRA~1\Java\JRE15~1.0_0\lib\deploy.jar;C:\PROGRA~1\Java\JRE15~1.0_0\lib\plugin.jar -Xmx96m -Djavaplugin.maxHeapSize=96m -Xverify:remote -Djavaplugin.version=1.5.0_02 -Djavaplugin.nodotversion=150_02 -Dbrowser=sun.plugin -DtrustProxy=true -Dapplication.home=C:\PROGRA~1\Java\JRE15~1.0_0 -Djava.protocol.handler.pkgs=sun.plugin.net.protocol -Djavaplugin.vm.options=-Djava.class.path=C:\PROGRA~1\Java\JRE15~1.0_0\classes -Xbootclasspath/a:C:\PROGRA~1\Java\JRE15~1.0_0\lib\deploy.jar;C:\PROGRA~1\Java\JRE15~1.0_0\lib\plugin.jar -Xmx96m -Djavaplugin.maxHeapSize=96m -Xverify:remote -Djavaplugin.version=1.5.0_02 -Djavaplugin.nodotversion=150_02 -Dbrowser=sun.plugin -DtrustProxy=true -Dapplication.home=C:\PROGRA~1\Java\JRE15~1.0_0 -Djava.protocol.handler.pkgs=sun.plugin.net.protocol vfprintf >java_command: <unknown> > >Environment Variables: >PATH=C:\PROGRA~1\Java\JRE15~1.0_0\bin;C:\Program Files\Internet Explorer;;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;. >USERNAME=管理人室 >OS=Windows_NT >PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel > > >--------------- S Y S T E M --------------- > >OS: Windows XP Build 2600 Service Pack 2 > >CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht > >Memory: 4k page, physical 244464k(55328k free), swap 598668k(323724k free) > >vm_info: Java HotSpot(TM) Client VM (1.5.0_02-b09) for windows-x86, built on Mar 4 2005 01:53:53 by "java_re" with MS VC++ 6.0 > >

>えーっと、GPLかNYSLを適用しておいてもらえますでしょうか？ そうでした。ライセンスの規定を忘れていました。ご指摘ありがとうございます。 NYSLにさせていただきました。

こんな言語を探してました。 えーっと、GPLかNYSLを適用しておいてもらえますでしょうか？

>なるほど。めったにプリントアウトしないため気づきませんでした。 私も今はプリントアウトはしませんが、25行のテキスト端末でvi使ってた時代は そういうわけにもいきませんでした。 >あ、ひょっとして勘違いだったかもしれません。申し訳ありません。 うーん、やはりそちらに書き込んだことはないようです。 >40代のオヤジ技術者です。これを機にお見知りおきを。 了解しました。こちらこそよろしくお願いいたします。

>と書くわけです。でも、当時ソースをプリントアウトしたとき、紙の切れ目で「}」が来ると、 >そこでif文が終わりなのか判定しにくいと思いやめました。 なるほど。めったにプリントアウトしないため気づきませんでした。 >す、すみません、「酔漢」さんがどなたかわかりませんです。 >私が定期的に書き込んでいる掲示板等は、そんなにないと思うのですが… あ、ひょっとして勘違いだったかもしれません。申し訳ありません。 40代のオヤジ技術者です。これを機にお見知りおきを。

はじめまして。 >ちなみに私は >if() { > ... >} >else { > ... >} >と、そうとう変則的です。 でも、この書き方はたまに見かけると思います。 私も当初、else ifごとにコメントを入れたくて、そういう書き方にしていた頃があります。 if () { ... } /* ほにゃららの場合 */ else if (ほにゃらら) { ... } と書くわけです。でも、当時ソースをプリントアウトしたとき、紙の切れ目で「}」が来ると、 そこでif文が終わりなのか判定しにくいと思いやめました。 >ご挨拶が遅れました。はじめまして。私のところにいらっしゃるときと雰囲気が違うので驚きました。 す、すみません、「酔漢」さんがどなたかわかりませんです。 私が定期的に書き込んでいる掲示板等は、そんなにないと思うのですが…

begin/endか{/}かというページを読んで、昔読んだインデント論争を思い出しました。こちらもbit誌の連載で、その後単行本に収録されたはずですが、実家の両親に捨てられました。 SIGPLAN　NOTICEの読者投稿で行われた「インデントはいかにあるべきや」という論争で、今で言えば、C言語のifに続く{はifの行末か、ifの次の行で同じ深さか、はたまた一段落とすかという話です。最後は編集者が「もういい」と打ち切ったそうです。 ちなみに私は if() { ... } else { ... } と、そうとう変則的です。最近は誰も「宙ぶらりんのelse」の話をしないので寂しいです。 ご挨拶が遅れました。はじめまして。私のところにいらっしゃるときと雰囲気が違うので驚きました。

このところどたばたしてまして返事が遅くなりましてすみません。 >で、思ったんですが、よくよく考えてみればC言語には昔からオブジェクト指向の標準関数がありますね。FILE * を介して行なうファイル入出力です そう思います。以下のページにそんなことを書きました。 http://kmaebashi.com/programmer/c_yota/inherit.html >その他、X Window System の Xlib やそのツールキットもオブジェクト指向です。 それも上記のページに書いています。 「疑り深い～」に書き足すかどうかはちょっと保留にさせてください。 # ていうか今は無理です。

で、思ったんですが、よくよく考えてみればC言語には昔からオブジェクト指向の標準関数がありますね。FILE * を介して行なうファイル入出力です (これだけでもう分かると思いますが、fopen() が新しいインスタンスを作る new のようなもの。fclose() が C++ の delete のようなもの。fprintf()やfgets()などの入出力関数は全て最初に作った FILE 型領域へのポインタを介して行なって、違う FILE * だと違うファイルが対象になります)。 解説にその辺のことも付け加えるといいんじゃないでしょうか。これならよほどの初心者か特殊な環境のプログラマでない限りは使ったことあるでしょうから理解され易いと思います。 p.s. その他、X Window System の Xlib やそのツールキットもオブジェクト指向です。

最近STLを勉強していて、C++の標準にはハッシュはないので 何で実現するかに迷っています。 もちろんアプリや目的が何かが重要ですが、実行速度優先で 考えていて、mapは遅いので使えないです。 ハッシュ関数はint値をテーブルサイズで割った余りを 返すという単純なものを考えています。 候補としては、以下のものを考えているのですが、 もっとうまい方法や常套手段はあるのでしょうか？ 1) VC++のhash_map 2) SGIのhash_map 3) STLportのhash_map 4) templateで自作する .NET2003のVC++を使っているので1)か4)で考えているのですが、 良いサンプルがなかなかなくて、標準に入ってないだけで 結構苦労してます。慣れの問題かもしれないですが。 MSDNにも簡単なサンプルしかないし。

>　私もそう思いますが、「センス・オブ～」でそう書いたところ査読して > くださった方からの反論があり、多少表現を変更した、という経緯も (^^; (^^; Cで単方向リストを書く場合、私も先頭のダミー要素は使いません。 リンクポインタへのポインタを使えば、不要になるからです。 でも、Lisp 文化圏あたりでは、ダミー要素も割と当たり前に使うんじゃ ないでしょうか？ というか、C と C++ 以外の（リンクポインタへの ポインタを使えない) 言語では、わりと使うことが多いような。 あと私は、Cでも双方向リストを書く場合には、ほとんどの場合、環状にして ダミー要素を使います。結構そういう人は多いと思うんですけど、そうでも ないですかねえ。 試しに Java の標準ライブラリ jdk-1_5_0-src-scsl/j2se/src/share/classes/java/util/LinkedList.java を確認してみましたが、やはりダミー要素を使っているようですよ。

>listのsortとアルゴリズムのsortやqsortなら後者の方が速いような気がしますが(気がするだけですが)、 >その話ではないのです。紛らわしくてすみません。 >連結リストを自分で実装した場合の話です。 > >↓の最後の方法のことを言いたかったのです。 >http://www.kouno.jp/home/c_faq/c13.html#10 了解しました。 ありがとうございました。

>先頭に置くなら番兵とは呼ばずにダミー要素と呼ぶべき。 　私自身そう呼びますが(センス･オブ～ではダミーノードと呼んでいた)、774RRさん自身が「それとも最初に作ってる sta は番兵？」と書いておられるので、先頭のダミーノードを番兵と呼ぶ文化圏というのもありなのかなあ、と私は解釈しましたが。 >１方向リンクリストでも使わないほうが自然でしょう。 　私もそう思いますが、「センス・オブ～」でそう書いたところ査読してくださった方からの反論があり、多少表現を変更した、という経緯も (^^;

>自分自身、リストの有用性自体をはっきりわかってないと思っています。 　crowbarのcrowbar.hを見ると、連結リストをかなり使っていますね。 http://kmaebashi.com/programmer/devlang/crowbar_src_0_4/S/6.html 　動的に追加される要素は、ランダムアクセスの必要がない限り、たいてい連結リストにしている、という感じです。 　途中への追加とかがなくても連結リストを使っているのは、単にrealloc()で配列を伸ばすのが面倒だとか、型Tの配列をrealloc()で伸ばすとTのポインタが変わってしまって誰かが指していたときに困るとか(Tへのポインタの配列にすればいいんだけど)、create.cでの解析木の構築はrealloc()できないMEM_storage_malloc()を使っているとか、事情はいろいろありますが、単なる私の「癖」のような気もしないでもないです。

いろいろどたばたしておりまして、返信がずいぶん遅くなりましてすみません。 >私が初めて買ったCの入門書には「if文は入れ子を避けるために二分岐処理に限定してswitch文の使用を検討しろ」というようなことが書いてありました。 　以前の同僚で、「昔はelse ifという書き方が大嫌いだった」というのがいました。 　「昔は」と言っていたのでその後改宗したわけですが、「if～elseは二分岐処理に限定して使うべき」と昔は思っていた、ということでしょう。私には理由がよくわかりませんが、そう思う人はいるらしい、ということで。

>>＃ リストの最も簡単で速いソート方法は配列にコピーしてqso(略 > >配列へのコピー時間はなしにしても、list#sortよりも早いのですか？ >qsoってqsort()のことですか？ listのsortとアルゴリズムのsortやqsortなら後者の方が速いような気がしますが(気がするだけですが)、 その話ではないのです。紛らわしくてすみません。 連結リストを自分で実装した場合の話です。 ↓の最後の方法のことを言いたかったのです。 http://www.kouno.jp/home/c_faq/c13.html#10

>う、確かに難しかったかも知れません(書くのはともかく読むのは)。 > >　1.最初の要素をピボットにして、 >　　残りの部分をピボット未満の要素のリスト(left)とピボット以上の要素のリスト(right)に分割する >　2.それぞれをソートする >　3.leftと最初の要素とrightをこの順に繋げる > >ということをやっています。 >＃ それぞれを関数化すべきでしたね。 >＃ ちなみに簡単だと思った理由は(ループが1重は冗談として)分割した後の領域の境界について考える必要がないからです 解説ありがとうございます。 簡単かどうかは置いといて、結局やっていることは アルゴリズム的には、配列と同様なことをやっているようですね。 但し、配列とリンクリストは要素へのアクセス方法(の実装)は 違いますが。 >まあ、クイックソートは最悪の場合 O(n^2) になってしまうわけで、 >ランダムアクセスできないとどうしても、 >それを避けるために書いたコードのせいで定数項が大きくなってしまいそうです。 >＃ gccのSTLの実装ではランダムアクセスイテレータにしかできないことばっかりやってたり > >リンクリストの場合はデータ構造を直接いじってマージソートしてしまった方が速いでしょうしね(std::listは実際にそうなっていますが)。 確かに、std::listは、ソート用の自前のメンバ関数を持っていましたね。 >＃ ちなみに上で説明した方法もデータ構造を直接いじっています >＃ ですから、std::sortでは同じことは出来ません > > >>NykRさんのサンプルの計算量はいまいち良く分かりませんでした。 > >平均(のオーダー)は O(n log n) ですが最悪だと O(n^2)です。 結局、std::listで、std::sortが使えないのは、実装がstd::listだけ 特殊扱いになってしまうのでできないということですね。 containerによって場合分けするなら、配列と同様な計算量で 実装できるから問題ない訳で、std::sortは、 汎用的な実装をしているというだけですね。 汎用的と言っても、配列(系)の実装を想定しているだけだと思いますが。 >＃ リストの最も簡単で速いソート方法は配列にコピーしてqso(略 配列へのコピー時間はなしにしても、list#sortよりも早いのですか？ qsoってqsort()のことですか？

勘違いがあったので訂正します。 >>ただ、ピボットを選ぶときにランダムアクセスできないとワーストケースに対応できないので、その意味では配列の方が良いと言えるかもしれません。 ピボットを選ぶのは関数呼び出し1回につき1度だけなので、頭から順にアクセスしていってもオーダーは変わりませんね。 という訳で「ワーストケースに対応できない」というのはこの意味では嘘でした。 >>実装はリンクリストの方がむしろ簡単だと思います。 > >クイックソートがリンクリストで実装できるのは知りませんでしたが、 >私はNykRさんの実装が難しくて理解できませんでした う、確かに難しかったかも知れません(書くのはともかく読むのは)。 　1.最初の要素をピボットにして、 　　残りの部分をピボット未満の要素のリスト(left)とピボット以上の要素のリスト(right)に分割する 　2.それぞれをソートする 　3.leftと最初の要素とrightをこの順に繋げる ということをやっています。 ＃ それぞれを関数化すべきでしたね。 ＃ ちなみに簡単だと思った理由は(ループが1重は冗談として)分割した後の領域の境界について考える必要がないからです >STLのsort()はランダムアクセスイテレータが必要ですが、 >私のイメージは、listはクイックソートに対して、 >実行効率の面で現実的ではないからできないのだと思っています。 >実装が簡単だというのも重要だと思いますが、 >(STLは)ライブラリなのであくまでもパフォーマンスが問題で、 >やはりリンクリストでは配列と同等のパフォーマンスが >でないのではないでしょうか？ まあ、クイックソートは最悪の場合 O(n^2) になってしまうわけで、 ランダムアクセスできないとどうしても、 それを避けるために書いたコードのせいで定数項が大きくなってしまいそうです。 ＃ gccのSTLの実装ではランダムアクセスイテレータにしかできないことばっかりやってたり リンクリストの場合はデータ構造を直接いじってマージソートしてしまった方が速いでしょうしね(std::listは実際にそうなっていますが)。 ＃ ちなみに上で説明した方法もデータ構造を直接いじっています ＃ ですから、std::sortでは同じことは出来ません >NykRさんのサンプルの計算量はいまいち良く分かりませんでした。 平均(のオーダー)は O(n log n) ですが最悪だと O(n^2)です。 ＃ リストの最も簡単で速いソート方法は配列にコピーしてqso(略

>クイックソートは、アルゴリズムそのものにはランダムアクセスは不要です。 >ただ、ピボットを選ぶときにランダムアクセスできないとワーストケースに対応できないので、その意味では配列の方が良いと言えるかもしれません。 >実装はリンクリストの方がむしろ簡単だと思います。 クイックソートがリンクリストで実装できるのは知りませんでしたが、 私はNykRさんの実装が難しくて理解できませんでした (いやみではありません。能力的な問題です)。 STLのsort()はランダムアクセスイテレータが必要ですが、 私のイメージは、listはクイックソートに対して、 実行効率の面で現実的ではないからできないのだと思っています。 実装が簡単だというのも重要だと思いますが、 (STLは)ライブラリなのであくまでもパフォーマンスが問題で、 やはりリンクリストでは配列と同等のパフォーマンスが でないのではないでしょうか？ NykRさんのサンプルの計算量はいまいち良く分かりませんでした。 クイックソートのアルゴリズムにランダムアクセスがなくても 実装可能だと言うのは了解しました。

>>startは、staをさしている訳で、エラーの原因はstaは >>動的に確保されたオブジェクトではないからです。 >御意なのですが、だからといって最初を除外して free するというのも間違いと思う。 間違いではないと思います(逆に正解だとも言えません)。 ある意味どっちでも良いと思います。 サンプルの例ではauto変数であるstaがリンクリストの先頭な訳で、 これをそのまま(あるいはアドレスを)渡した方が分かりやすいと思った訳です。 free_list(sta.next);やfree_list(start->next);は分かりにくい気がします。 何でリンクリストの先頭(あるいはリンクリストそのものを表すもの)を 渡さないで、nextの要素を渡さないといけないのかという気がします。 確かに関数の汎用性を考えれば最初を除外するのは良くないと思います。 しかし、そういう次元の議論ではありません。 また、そもそもマルチプルインスタンスを考えた実装にはなっていないので マルチプルインスタンスに対応しようとすると破綻するのはしょうがないと 思います。 私ならlist(は名前を変えたい)の上にラッパーの構造体 (仮にllistとしましょう)を作成し、その中にlistの先頭を入れてあげます。 こうすれば、llistの中にダミーのstaも持たせることできますし、 どうにでも実装できます。free用の関数も以下で問題ないです。 free_llist(llist *head); マルチプルインスタンスだって当然できます。 問題は、どこまで実装を抽象化するかであり、今の負け組一号さんの 実装を踏襲するならば774RRさんのご指摘通り、問題点は多いです。 >リンクリストで番兵を使うというのが根底の発想として間違っている気がします。 また、これも間違っているとは断言できないと思います。 あくまで実装の問題で、実装を分かりやすくするために 番兵を入れるのであって、番兵を使うのが間違いではないと思います。 但し、負け組一号さんの番兵(ダミー？)の使い方が適切だとは 私も思っていません。

話の腰を揉んでみるテスト。ふにふに >リンクリストは、要素(サンプルの場合、list)を削除する処理が >配列に比べて早いというのが一般的に言われています。 リストを使う理由としては、配列だと削除された要素の後ろの要素を指すイテレータの扱いに困る、というのもありますね。 STLではそういうイテレータは無効になります。 >また、ソートに関しては基本的にリンクリストより配列の方が早いと思います。 >と言うのも、例えばクイックソートを使うならランダムアクセスが必要になるので >そもそもリンクリストでは(クイックソートは)無理です。 クイックソートは、アルゴリズムそのものにはランダムアクセスは不要です。 ただ、ピボットを選ぶときにランダムアクセスできないとワーストケースに対応できないので、その意味では配列の方が良いと言えるかもしれません。 実装はリンクリストの方がむしろ簡単だと思います。 void quick_sort(Node ** head_p) { if (*head_p != NULL && (*head_p)->next != NULL) { Node *p; Node *left = NULL, *right = NULL; Node **left_p = &left, **right_p = &right; for (p = (*head_p)->next; p != NULL; p = p->next) { if (p->value < (*head_p)->value) { *left_p = p; left_p = &(*left_p)->next; } else { *right_p = p; right_p = &(*right_p)->next; } } *left_p = *right_p = NULL; quick_sort(&left); quick_sort(&right); for (; *left_p != NULL; left_p = &(*left_p)->next) ; *left_p = *head_p, (*head_p)->next = right; *head_p = left; } } ＃ いや、ループが1重で済んでるし＜簡単

話の腰を折りまくります。 >774RRさんがおっしゃっていたようにstaは番兵ですね。 リンクリストで番兵を使うというのが根底の発想として間違っている気がします。 >startは、staをさしている訳で、エラーの原因はstaは >動的に確保されたオブジェクトではないからです。 御意なのですが、だからといって最初を除外して free するというのも間違いと思う。 tree や環状リストで番兵を使ったりはしません。 １方向リンクリストでも使わないほうが自然でしょう。 もし仮に番兵を配置するならリンクリストの末尾に置くのが適切です。 先頭に置くなら番兵とは呼ばずにダミー要素と呼ぶべき。 そして、仮に番兵/ダミー要素を使うのであれば、その番兵/ダミーも malloc() でとっておくべきです。 [813] で書いたとおり auto な番兵/ダミーを用意するのは大きな間違いです。 マルチプルインスタンスを実現しようとして list* root1=create_list(...); list* root2=create_list(...); 等と直したくなった場合に破綻します。 んで、この程度の話は [813] で紹介した先にて述べられ済みなのですけど。

>なるほど！！ >ありがとうございます >void free_list(list *start)の内容を見て、なっとくっす。 >チェーンをたぐりよせてmalloc()で取った領域を開放を繰り返し >NULLが来て、解放終わりって感じですね。 >すっごいわかりました。本当にありがとうございました。 void free_list(list *start) { list *curr, *temp; for (curr = start->next; curr != NULL;) { temp = curr->next; free(curr); curr = temp; } start->next = NULL; } あとで気がついたのですが、最後の行 start->next = NULL; という一行も入れておいた方が良いです。 これをしておかないと、freeした後に間違えて staのnextの参照や書き込みを行った場合問題となります。 参照をしたタイミングではオブジェクトはなくても ポインタの値は残っていて(ダングリングポインタと言います) 不正なアクセスとなります。 これは、問題の原因があるところと問題の発生位置 (別のところでアクセスバイオレーションになったりする) がずれる可能性があるため、気づきにくいバグとなります。 ここら辺の知識はポインタ関係ですので、(ぱ)さんの 「C言語ポインタ完全制覇」はかなりお勧めです。 私もこの本に早く出会っていればもっと早くレベルアップ できたのにと思っています。 http://www.amazon.co.jp/exec/obidos/ASIN/4774111422/qid=1141917620/br=3-1/br_lfncs_b_1/249-0186723-6715515

> >void free_list(list *start) { > list *curr, *temp; > > for (curr = start->next; curr != NULL;) { > temp = curr->next; > free(curr); > curr = temp; > } >} > >これで、以下のように呼び出せます。 >free_list(start); > >先ほどの例だと、以下のように呼び出さないといけません。 >free_list(start->next); >もしくは、 >free_list(sta.next); なるほど！！ ありがとうございます void free_list(list *start)の内容を見て、なっとくっす。 チェーンをたぐりよせてmalloc()で取った領域を開放を繰り返し NULLが来て、解放終わりって感じですね。 すっごいわかりました。本当にありがとうございました。

すいません。見落としてました。 free(start)はエラーになったということで、 startは、staをさしている訳で、エラーの原因はstaは 動的に確保されたオブジェクトではないからです。 774RRさんがおっしゃっていたようにstaは番兵ですね。 ですので、以下が正解です。 void free_list(list *start) { list *curr, *temp; for (curr = start->next; curr != NULL;) { temp = curr->next; free(curr); curr = temp; } } これで、以下のように呼び出せます。 free_list(start); 先ほどの例だと、以下のように呼び出さないといけません。 free_list(start->next); もしくは、 free_list(sta.next);

>自分自身、リストの有用性自体をはっきりわかってないと思っています。 >せいぜい「線形リストなら、文字を打ち込んで行ってもチェーンのつなぎ換えで >ソートできて便利だな～」という程度の知識です。 リンクリストは、要素(サンプルの場合、list)を削除する処理が 配列に比べて早いというのが一般的に言われています。 ですので、要素の追加や削除を頻繁に行う場合は有用かもしれないですが、 実のところ、データ構造は配列が一番便利ですし、ツリーやキューなど の方が良いケースもありますので、リンクリストが有用な場面は少ない かもしれないです。 私は、Cで動的に要素を追加するのにリンクリストを使ってたり しましたが、C++ならvectorで動的な追加ができるので C++ならlist(リンクリスト)を使う場面は少ないかもしれません。 あとCでハッシュの実装をする場合は、リンクリストはよく使います。 また、ソートに関しては基本的にリンクリストより配列の方が早いと思います。 と言うのも、例えばクイックソートを使うならランダムアクセスが必要になるので そもそもリンクリストでは(クイックソートは)無理です。 ソートする必要があるなら、配列を使うべきだと思います。 >>関数でfreeするなら、引数でstartを渡してあげればOKです >で、free(start)してみたら、エラーになってしまい、ただ >free(start->next)としたら通りました。 >まぁ、free(start)が通らないのは、僕の理解不足からくる見当違いな事をしてるせい >だと思いますが、free(start->next)としたとき、チェーンで繋がった先のNULLに至るまで >にmalloc()で割り当てたそれぞれのメモリ領域も解放してくれるのかが僕の理解不足の >点です。free(start->next)したとき、next側のメモリだけ解放され、後に続く >NULLまでのmalloc()で取った領域は動かされず、残ったままなら これは私の言葉足らずでしたが、例えば、以下のような関数を作成してやれば OKです(テストしてないですが多分OKだと思います)。 void free_list(list *start) { list *curr, *temp; for (curr = start; curr != NULL;) { temp = curr->next; free(curr); curr = temp; } } で、呼び出し側は、free_list(start)とやれば良いので、 startという変数(の管理)が大事だと言った訳です。 >まだ、ちゃんと理解できてないと自分自身思いますので、まだまだ精進精進だと思って >います。 アルゴリズムとデータ構造は奥が深いですが、このぐらいはまだまだ入門です。 C言語でのアルゴリズムの専門的な本を購入されて読むことをお勧めします。 C++では標準ライブラリで基本的なデータ構造は用意されているのですが、 データ構造の基本的な知識がないときちんとした理解ができないので プログラミングの知識と経験はこつこつと積み上げていくしかないと思っています。 仕事レベルですと、「基本」を押さえておくことが非常に重要になりますし。

レスありがとうございます 返信遅くてすいませんでした。 自分自身、リストの有用性自体をはっきりわかってないと思っています。 せいぜい「線形リストなら、文字を打ち込んで行ってもチェーンのつなぎ換えで ソートできて便利だな～」という程度の知識です。 ところで >負け組一号さんのサンプルで、startという変数が重要になります。 >どこかで(例えば関数で)free処理をするのでしょうが、 >start変数は、listの先頭を表していますので、これさえあれば >listにつながっているデータは全てfreeできます。 >関数でfreeするなら、引数でstartを渡してあげればOKです で、free(start)してみたら、エラーになってしまい、ただ free(start->next)としたら通りました。 まぁ、free(start)が通らないのは、僕の理解不足からくる見当違いな事をしてるせい だと思いますが、free(start->next)としたとき、チェーンで繋がった先のNULLに至るまで にmalloc()で割り当てたそれぞれのメモリ領域も解放してくれるのかが僕の理解不足の 点です。free(start->next)したとき、next側のメモリだけ解放され、後に続く NULLまでのmalloc()で取った領域は動かされず、残ったままなら マスタングさんの言う >現在のlistのnextの情報を先にとっておきます。 >そして、現在のlistをfree()します。 >その処理を現在のカーソルがNULLになるまで繰り返します。 >つまり、nextがNULLになるまで繰り返すのです。 という方法になるのか。と納得を得たしだいです。 まだ、ちゃんと理解できてないと自分自身思いますので、まだまだ精進精進だと思って います。

XSLTという言語では、if文にelse節はありません。 以下のようにあくまでif文しか書けないような言語仕様になっています。 <xsl:if test="...."> <!-- 何らかの処理 --> </xsl:if> 多分岐には、choose文（Cで言うところのswitch文）を使えという言語仕様になってますね。 <xsl:choose> <xsl:when test="...."> <!-- 何らかの処理 --> </xsl:when> <xsl:otherwise> <!-- 何らかの処理 --> </xsl:otherwise> </xsl:choose> これはこれですっきりしていて、キレイだと思います。 >>>then節とelse節で書けるものが違う、とか、if文だけ特別扱い、とか >> >>やっぱりこれを汚いと思う人が多いからではないでしょうか。 >> >>汚いかどうかは主観の問題ですけど、私なら、if文だけ特別扱いするくらいなら、 >>elsifを導入します。 > >なるほど。参考になります。 > > >>確かに、Cプログラマで、Cにはelse ifという特別な構文があると思っている人は >>少なくなかったですから、 > >私が初めて買ったCの入門書には「if文は入れ子を避けるために二分岐処理に限定してswitch文の使用を検討しろ」というようなことが書いてありました。 >「else節にif文を直接書く」という発想は知らなければ出てこないものなのかもしれませんね。 > > > >＃つか金返せやｺﾞﾙｧ

奈々氏 さん、(ぱ) さん、マスタング さん　へ ご返信ありがとうございます。 頂いた情報がかなり参考になりそうです。 とにかく感謝します、これから徹夜でサイトや資料を読みます。

>>then節とelse節で書けるものが違う、とか、if文だけ特別扱い、とか > >やっぱりこれを汚いと思う人が多いからではないでしょうか。 > >汚いかどうかは主観の問題ですけど、私なら、if文だけ特別扱いするくらいなら、 >elsifを導入します。 なるほど。参考になります。 >確かに、Cプログラマで、Cにはelse ifという特別な構文があると思っている人は >少なくなかったですから、 私が初めて買ったCの入門書には「if文は入れ子を避けるために二分岐処理に限定してswitch文の使用を検討しろ」というようなことが書いてありました。 「else節にif文を直接書く」という発想は知らなければ出てこないものなのかもしれませんね。 ＃つか金返せやｺﾞﾙｧ

『UNIXプログラミング環境』という本の第8章にhocという簡易プログラミング言語を yaccとlexを用いて徐々に機能を追加して開発する過程が解説されています。 本書の著者の一人はBrian W. Kernighan、あの『プログラミング言語Ｃ』の著者なので、 かなり信用のおける内容だと思います。 ただし、yaccとlexそのものについてはあまり詳しく解説していません。 あと、『コンパイラの理論と実現』という本には、C-というC言語からいくつかの 機能を取り除いた言語のコンパイラの作成方法が解説されていたと思います。 どちらもソースコード付きなので、オススメです。

訂正(?) >昔、「yacc/lex―プログラムジェネレータonUNIX」という本があって、この本には >・変数はA-Zだけ。配列なし。 >・バイトコードコンパイル方式。 >という簡易言語のサンプルが載っていました。 この本は、昔、啓学出版から出てたと思うんですが(小さめの版形で、半透明の カバーがかかってた奴)、今ぐぐるとテクノプレスから出ています。著者は同じだし、 内容も同じじゃないかと思うんですが。 ついでにこんなのも見つかりました。 http://www.watalab.cs.uec.ac.jp/tinyCabs.html

>flexとbissonで言語を作ってみようと思った人ですが。このページを読むと本当に勉強になりました。 どうもです。 >今、crowbarのソースを読んでますが、初心者なので、これよりもっとシンプルのソースあるでしょうか。 単にcrowbarより簡単なソースなら、うちのページにある(マスタングさんも挙げられた) 「電卓を作ってみよう」のcalcなんかがよいかもしれませんけれども。 ただし、作りたいものが「外面がCっぽい言語」なのか、「中の動きがCっぽい言語」で あるかによって、作り方は相当変わってきます。たとえばcrowbarは配列をヒープに 確保しますけど、内部的な動作を含めてCっぽい言語を作りたいのなら、配列もスタックに 確保すべきでしょう。内部的な動作を含めてCっぽい言語を作ったほうが、Cの理解が 深まる、という利点もあります。 >例え、データ型　intしかない、論理演算　if else　while for　＜＞＝　＋－*　/しかできるC言語サブセットのソース例はあるでしょうか。教えてください。よろしくお願いいたします。＾＾ 昔、「yacc/lex―プログラムジェネレータonUNIX」という本があって、この本には ・変数はA-Zだけ。配列なし。 ・バイトコードコンパイル方式。 という簡易言語のサンプルが載っていました。 また、「yaccによるCコンパイラプログラミング」 http://www.context.co.jp/~cond/books/yacc-book.html には、8086で動作する簡単なCコンパイラのソースが載っていました(構造体がない くらいで、ほぼCコンパチだったような気がします)。 でも、今はどちらも入手できないと思います。図書館とか会社の書庫とかで 探してみるのがよいのではないでしょうか。

>if文のぶら下がり文に関してふと思いついたんですが、 >本体にブロックを強制する場合でも >else節にだけ、if文も書けるようにすればelsif(elif, elseif)というようなキーワードを導入しなくても困りませんよね？ なるほど。確かに構文規則を以下のようにいじってbisonにかましてみましたが、 特にconflictは起きませんでした。 if_statement: IF LP expression RP block | IF LP expression RP block ELSE block | IF LP expression RP block ELSE if_statement | IF LP expression RP block elsif_list | IF LP expression RP block elsif_list ELSE block | IF LP expression RP block elsif_list ELSE if_statement >文法が微妙に汚くなるからでしょうか >then節とelse節で書けるものが違う、とか、if文だけ特別扱い、とか やっぱりこれを汚いと思う人が多いからではないでしょうか。 汚いかどうかは主観の問題ですけど、私なら、if文だけ特別扱いするくらいなら、 elsifを導入します。 確かに、Cプログラマで、Cにはelse ifという特別な構文があると思っている人は 少なくなかったですから、elseの後のif文だけ特別扱いしてもさほど混乱はないのかも しれませんけど、「Cにはelse ifという特別な構文があると思っている人」が 周囲にたくさんいた私としては、そういう人への啓蒙もこめてelsifを導入した、 という意図もあったようななかったような。

>flexとbissonで言語を作ってみようと思った人ですが。このページを読むと本当に勉強になりました。 >今、crowbarのソースを読んでますが、初心者なので、これよりもっとシンプルのソースあるでしょうか。 >例え、データ型　intしかない、論理演算　if else　while for　＜＞＝　＋－*　/しかできるC言語サブセットのソース例はあるでしょうか。教えてください。よろしくお願いいたします。＾＾ crowbar 0.1のソースや「プログラミング言語を作る」の"電卓を作ってみよう"は 参考にならないでしょうか？ また、初心者さんが求めている内容とは少し違いますが、 以下のものはどうでしょうか？ 1) yacc入門講座(簡単な説明) http://www.tokumaru.org/yacc/index.htm 2) Bison入門(リファレンス) http://guppy.eng.kagawa-u.ac.jp/~kagawa/2000/SysProg/bison-1.2.8/bison-ja_toc.html 3) Flex（リファレンス) http://www.asahi-net.or.jp/~wg5k-ickw/html/online/flex-2.5.4/flex_toc.html 4) lex&yaccプログラミング（残念ながら日本語版は売り切れなようです） http://www.amazon.co.jp/exec/obidos/ASIN/4756102972/qid=1141565795/br=3-2/br_lfncs_b_2/249-0186723-6715515 5) いまどきのプログラム言語の作り方(Javaで再帰下降型パーサの実装です) http://www.amazon.co.jp/exec/obidos/ASIN/4839919232/qid=1141567196/br=3-1/br_lfncs_b_1/249-0186723-6715515 私も興味ありますので、何か良いサイトや参考書などあれば 逆に教えてください。 あくまでもflexやbison(yaccやlex)にこだわるなら 私は、ドラゴンブックやタイガーブックなどより先に、 yaccやlexをある程度理解しておくことが重要だと思っています。

flexとbissonで言語を作ってみようと思った人ですが。このページを読むと本当に勉強になりました。 今、crowbarのソースを読んでますが、初心者なので、これよりもっとシンプルのソースあるでしょうか。 例え、データ型　intしかない、論理演算　if else　while for　＜＞＝　＋－*　/しかできるC言語サブセットのソース例はあるでしょうか。教えてください。よろしくお願いいたします。＾＾

>＃ elseというキーワードはあるのにthen節であることを示すキーワードはない訳で 何を言ってるんだろ？ ええと、ブロックを中括弧で表現する言語でelsifのようなものを使う言語の中には、elseはあるのにthen節を示すキーワードは存在しない、というようなものもある訳で、 と言いたかったんですね。多分(ぉ

if文のぶら下がり文に関してふと思いついたんですが、 本体にブロックを強制する場合でも else節にだけ、if文も書けるようにすればelsif(elif, elseif)というようなキーワードを導入しなくても困りませんよね？ 何で世の中の多くの言語はそうなってないんでしょう？ 文法が微妙に汚くなるからでしょうか then節とelse節で書けるものが違う、とか、if文だけ特別扱い、とか でも、then節とelse節を全く同じにする必要はないと思いますし、 ＃ elseというキーワードはあるのにthen節であることを示すキーワードはない訳で ＃ というのはちょっと苦しいか if文の中でif文を特別扱いするのもそんなに変なこととは思いません ＃ うーん、気付いてないだけで何か他に問題があるんだろうか？ ＃ そこまでして else if と書けるようにするより、elsifを導入した方が簡単・・・でもないよなぁ。 どう思います？

タイガー改めマスタングです。 私なりに思ったことを書いてみます。 まず思ったのは、自分が少しでも複雑だなと感じる処理を考える場合は、 図を書いてみると理解しやすいです。 掲示板では少々書きづらいので自分なりに紙にでも書いてみてください。 >線形リストif(sagyou->num < fo->next->num)が、他の参考書を見ながら打ってた時 >next->next->...->numという感じで全部比較して見てるのか？となぜか思い >それで、逐一アドレス表示させるようにしたりして、自分なりに疑問を解消しつつ >本当に、fo->next->numは、nextだけを見てるのかとまだ疑問だったんですが >実は言いますと、この投稿フォームに、その疑問を考えながら書いてる間に >「あれ、これって、for文で回して、単に比較してチェーン変えてるだけだ」 >と、なぜか、その場で気づいたのですが、やはり確認しておこうと思い書きました。 listが数珠つなぎになっていて、forループの中でのfo変数は、 イメージとして、カーソルを表しています。 カーソルが先頭から末尾まで１つずつ各listを指しながら動く感じです。 これは、例えば、for (i = 0; i < num; i++)の、「i」と似ています。 iは、0から(num - 1)まで値を変えながら進んで行きます。 これは、「処理」としては、同じなので抽象化(同じ扱い)ができ、 一般的に、こういったカーソルをiteratorと言います (若干厳密性はないかもしれないですが、イメージはそんな感じだと思います)。 >free()に関しては、リストでmalloc()を使うのは解るが、それらをfree()にする >タイミングがよくわからなかったんですが、リストにして結果をはき出したら >またチェーンでたどってfree()にするのかなとか、まぁ、その、まだまだ >例題をみながら打ち込みながら理解しつつ、昨日覚えた事を今日忘れるような >日々つれづれとおくっておりまして、、、 負け組一号さんのサンプルで、startという変数が重要になります。 どこかで(例えば関数で)free処理をするのでしょうが、 start変数は、listの先頭を表していますので、これさえあれば listにつながっているデータは全てfreeできます。 関数でfreeするなら、引数でstartを渡してあげればOKです。 つまり、どこでfreeするかはユーザの自由ですが、freeするタイミングまで start変数を管理できていればOKな訳です。 start変数を管理(保持)する方法としては、ある関数内(ローカル)に持ち歩くか、 static変数(あるいは、グローバル変数)などで持っておくかの どちらかになると思います。 もちろん、別のデータ(構造)内に保持していても同じです。 freeするタイミングは重要ではないと思うのですが、 言えることがあるとすれば、いらなくなった時です。 >ただ、nextポインタがNULLになってるポインタを順次free()していけば出来るのかな >と思い、試してみます。 これは、違います。 nextポインタがNULLであろうが、NULLでなかろうが、 現在、カーソルが指しているlistをfree()します。 しかし、現在指しているlistをfree()してしまうと、 listに入っているnextの(ポインタの)情報がとれなくなってしまうので、 現在のlistのnextの情報を先にとっておきます。 そして、現在のlistをfree()します。 その処理を現在のカーソルがNULLになるまで繰り返します。 つまり、nextがNULLになるまで繰り返すのです。 まだ不明な点があればいくらでも聞いてください。

確かに、おっしゃるとおりっす。 自分の文章は、論理的に書けてないですね。 とにかく、もっとソースを体当たりで打ち込んで理解を深めます。 その上で、ポインタ関連で疑問が生じたら書き込みささしてもらいます。

あまり本質的な議論には参加してないくせに言うのもおかしいかもしれませんが少しだけ。 負け組一号さんは、一つの文章を短く切った方が文章の意味がわかりやすくなると思います。 「それが私の文章の味」とか言われちゃうと、それまでなのですが、 技術的な文章は、わかりやすさ重視でしょう。 なんとなく古文の授業を思い出してしまいます。 さて(ぱ)さんへのコメント中に 「どうfree()して行けば良いのかが解らない」とおっしゃってますが、 「どこでfree()というやつで解放してやれば良いのでしょうか」という質問では 求める答えが得られないのはお解かりでしょうか。 「方法」がわからないときに「記述する位置」を質問しても求める答えは得られないのは自明でしょう。 わからないことが「考え方や根拠」「概念」「方法」「動作原理」の どれなのかを分類するといいと思います。 少々きつい言葉で批判めいたことを書きましたが 自分自身の経験から「わからないことが何か」を理解した段階で 自然に「理解できる」場合が多いように思えます。 その一助として 「自分がわからない事柄は『方法』なのか?『考え方』なのか?『動作原理』なのか?」 と自問することは重要だと思っています。

774RRさん、(ぱ)さん、返信ありがとうございます。 線形リストif(sagyou->num < fo->next->num)が、他の参考書を見ながら打ってた時 next->next->...->numという感じで全部比較して見てるのか？となぜか思い それで、逐一アドレス表示させるようにしたりして、自分なりに疑問を解消しつつ 本当に、fo->next->numは、nextだけを見てるのかとまだ疑問だったんですが 実は言いますと、この投稿フォームに、その疑問を考えながら書いてる間に 「あれ、これって、for文で回して、単に比較してチェーン変えてるだけだ」 と、なぜか、その場で気づいたのですが、やはり確認しておこうと思い書きました。 free()に関しては、リストでmalloc()を使うのは解るが、それらをfree()にする タイミングがよくわからなかったんですが、リストにして結果をはき出したら またチェーンでたどってfree()にするのかなとか、まぁ、その、まだまだ 例題をみながら打ち込みながら理解しつつ、昨日覚えた事を今日忘れるような 日々つれづれとおくっておりまして、、、 とりあえず、まだまだ、打ち込んで、理解を深め、この劣化した脳に新たなメモリを 加えたく（脳の細胞は再生しないが、新生はするらしいので）思いつつ、今度は ちゃんと何が解らないのかが解らない状態で質問せず、何が解らないか解るよう 質問（甘え）さしてもらいたいです。 上記の文を書いて、ポインタ完全制覇を読み直した結果、駄目じゃん俺と再認識 >>774Rさん >提示コードは先頭に追加される必要がある場合にうまくない。 >それとも最初に作ってる sta は番兵？ 番兵の意味を聞かれて、持ってる書籍を見て初めて意味を知りました。番兵って奴です。 >一番最初の１個目を作る場合と、末尾に追加する場合とが特殊なわけだ。 >でも、実際には特殊ではなくて、ロジック上真ん中に挿入の場合と同じに扱える >ということが理解できるかどうかが肝 まだまだ、理解は出来るが、「さぁ作れ」と言われたら悩んでしまうレベルです。 >>(ぱ)さん >「どうわからないのか」をもう少し具体的に書いていただけませんか。 わからない部分は線形リストでmalloc()で割り当てて行った領域をどうfree()して行け ば良いのかが解らないといった感じです。 ただ、nextポインタがNULLになってるポインタを順次free()していけば出来るのかな と思い、試してみます。

どうも、(いつものことですが)「何がわからないのか」がわからないので 答えようにも困ってしまうわけですが。 >　　　　if(sagyou->num < fo->next->num ) >の、fo->next->numは、その時点でのfoのnext側のnumを見てる >と捉えて良いのでしょうか。 この質問にYesかNoかで答えれば、(774RRさんが書いておられるように)「Yes」と 答えるしかないわけですが、疑問に思ったからには、何か引っかかるところが あるわけでしょう。 ->は所詮演算子なので、 p = fo->next->num; として「foのnext側のnumを見」る代わりに、 temp = fo->next; p = temp->num; と書いてもよいし、 fo->next->numの代わりに(fo->next)->numと書いても構わないわけですが、 こうやって書き換えると感覚的にわかりやすくなったりしますかね。 >ついで、malloc()で得たメモリは >どこでfree()というやつで解放してやれば良いのでしょうか。 これも、「要らなくなったとき」としか答えようがないのですが、 そんなことは入門書にも書いてあるはずで、それでわからなかったから 質問しているわけでしょう。 「どうわからないのか」をもう少し具体的に書いていただけませんか。

リスト構造自体はそんなに難しいものではなくて、単に数珠つなぎになってるだけ。 例えば http://www9.plala.or.jp/sgwr-t/c/sec15-5.html 演習のほうも見てみませう。 提示コードは先頭に追加される必要がある場合にうまくない。 それとも最初に作ってる sta は番兵？ 番兵にせよなんにせよ今のままでは sta が auto なのでまずいけど。 >fo->next->numは、その時点でのfoのnext側のnumを見てる もちろん >どこでfree()というやつで解放してやれば良いのでしょうか。 要らなくなったとき。 malloc() するってことは、当座しばらくは必要だから保持しとけ、ということ。 例えばワード等で文章を開いたときなんかにこうやって文書データを保持してるわけだ。 free() するのは文章を閉じたときとかワードを終了するときとか。 提示コードであればリストを破棄するのは main 終了直前でしょうな。 こういうのはポインタに関する「文法理解」ではなくてむしろ「アルゴリズム理解」の話。 線形リストの場合「真ん中に挿入」する場合がいちばん簡単で、紹介先の図のとおり。 一番最初の１個目を作る場合と、末尾に追加する場合とが特殊なわけだ。 でも、実際には特殊ではなくて、ロジック上真ん中に挿入の場合と同じに扱える ということが理解できるかどうかが肝。

レス頂き、ありがとうございました。 そんで、(ぱ)さんに、甘えた質問さしていただきます。 ソースなんで長いですが自分でリストを理解しようと改造した線形リストです。 typedef struct list { 　　　　int num; 　　　　struct list *next; }list; int main() { 　　　　list sta ={0,NULL}; 　　　　list *start = &sta; /*先頭*/ 　　　　list *sagyou; /*作業領域*/ 　　　　list *fo; /*for用*/ 　　　　char str[16]; /*入力用*/ 　　　　while(1) { 　　　　　　　　printf("整数を入力(Eで終了)-->"); 　　　　　　　　gets(str); 　　　　　　　　if(strcmp(str,"E") != 0){//strcmpは文字列の比較 　　　　　　　　　　　　sagyou = (list *)malloc(sizeof(list)); 　　　　　　　　　　　　if(sagyou == NULL ){ 　　　　　　　　　　　　　　　　printf("メモリ確保できず\n"); 　　　　　　　　　　　　　　　　exit(1); 　　　　　　　　　　　　} 　　　　　　　　} 　　　　　　　　else break; 　　　　　　　　sagyou->num = atoi(str);//atoiは文字列をint型に変換する 　　　　　　　　for(fo = start; fo->next != NULL; fo = fo->next){ 　　　　　　　　　　　　if(sagyou->num < fo->next->num ){ 　　　　　　　　　　　　　　　　sagyou->next = fo->next; 　　　　　　　　　　　　　　　　fo->next = sagyou; 　　　　　　　　　　　　　　　　break; 　　　　　　　　　　　　} 　　　　　　　　} 　　　　　　　　if(fo->next == NULL){ 　　　　　　　　　　　　fo->next = sagyou; 　　　　　　　　　　　　sagyou->next = NULL; 　　　　　　　　} 　　　　} で、上のリストで、数字を大きい順にしようとするとき for(fo = start; fo->next != NULL; fo = fo->next){ 　　　　if(sagyou->num < fo->next->num ) の、fo->next->numは、その時点でのfoのnext側のnumを見てる と捉えて良いのでしょうか。ついで、malloc()で得たメモリは どこでfree()というやつで解放してやれば良いのでしょうか。 線形リスト、双方向リスト等、及び二分木探索などの例ばかりが 載ってる書籍を探しても、あるのは入門書ばかりで、初心者 から脱皮できない自分に負い目を感じる今日このごろです。

>情報ありがとうございます。後ほど「ほげを考えるページ」に追加情報として >挙げさせていただきます。 ありがとうございます。リンクにスペースが入ってリンク切れのようになっていました。もう一度リンクを書き込ませて頂きます。スイマセン…。 http://ameblo.jp/mamoru/entry-10009422221.html >リンクはどのページにもご自由にどうぞ。 勝手な書き込みでしたが、丁寧に対応して頂いてありがとうございました。 ではっ。

なんとなくネタ的に面白いので追加検証。gcc ならソースコードがあるので読んでみた。 gcc-3.4.5 を追っかけ。 gcc-4 では大幅な変更が入っているので変わっているかもしれない。 int array[1]; array=0; なるソースコードに対する挙動 C の場合 gcc/c-typeck.c Line 3677 でエラーメッセージを出力 これは convert_for_assignment() 関数の末尾である。この関数の先頭部分で if (TREE_CODE (TREE_TYPE (rhs)) == ARRAY_TYPE || TREE_CODE (TREE_TYPE (rhs)) == FUNCTION_TYPE) rhs = default_conversion (rhs); なるコードが実行されている(すなわち右辺はデフォルト変換が実施されている) のに対して左辺のデフォルト変換を行うコードは見当たらない。 ＝代入式の左辺においては「配列名を先頭へのポインタに読み替える」変換は実施していない C++ の場合 gcc/cp/typeck.c Line 5295 でエラーメッセージを出力 これは build_modify_expr() 関数の一部であり if (TREE_CODE (lhstype) == ARRAY_TYPE) の内側にある。この例では右辺左辺の型が異なるのでこのエラー。 もし array=array; であるなら、型一致なのでこの行ではなく先に進んで ISO C++ forbids assignment of arrays エラーが発生。 いずれにせよ左辺のデフォルト変換を行う関数は呼ばれていない。

>はじめまして。マモルと申します。 はじめまして。 >カナダのホワイトホースという町で「ほげ通り(HOGE ST.)」を見つけました↓。 > >http://ameblo.jp/mamoru/entry-10009422221.html 情報ありがとうございます。後ほど「ほげを考えるページ」に追加情報として 挙げさせていただきます。 >hoge研究の参考になれば嬉しく思います。また、誠に勝手ながら「ほげを考えるページ 」に無断でリンクを張らして頂きました。もし不都合があればリンクを削除いたします。 リンクはどのページにもご自由にどうぞ。

774RRさん： >ところで JIS X 3010 は 2003 版が発行済で 2003 版には 6.2.2.1 が無かったです。 >引用元は 1990 版でしょうか？ そうです。 NykRさん： >私自身は「変換する」と書いてあるんだから変換するんだろうと思ってますが、 >例えばこんなコードをgccでコンパイルすると コンパイラがそう実装するのは当然なので、特定の3つのケースを除き「変換する」と 書いてありそれに含まれないのだから(文法上は)変換すると解釈するのが自然だろうと 私は思いますが、変換するかどうかはさておき、代入できない理由としては、 「変更可能な左辺値ではないから」という理由も挙げておくべきであるように 思います。今は無理ですが、近々Web上で対応します。 >ついでに、K&Rの附録Aでは制約が書き加えられて変換しないことになっています。 日本語版p.245ですね。規格と違う説明をするのはいかがなものかと思いますが… ポインタ完全制覇を書いているとき、これに気付いてなかったのかなあ… 今となってはすっかり忘れています。

はじめまして。マモルと申します。 カナダのホワイトホースという町で「ほげ通り(HOGE ST.)」を見つけました↓。 http://ameblo.jp/mamoru/entry-10009422221.html hoge研究の参考になれば嬉しく思います。また、誠に勝手ながら「ほげを考えるページ 」に無断でリンクを張らして頂きました。もし不都合があればリンクを削除いたします。 ではっ。

私自身は「変換する」と書いてあるんだから変換するんだろうと思ってますが、例えばこんなコードをgccでコンパイルすると int main(void) { int a[1]; a++; return 0; } array_inc_test.c: In function `main': array_inc_test.c:4: wrong type argument to increment と、型に問題がある、というメッセージが表示されます。 a++を(&a)++と、ポインタ値のインクリメントに置き換えると array_inc_test.c:4: invalid lvalue in increment と表示されますからgccではaはポインタではないみたいです。 ついでに、K&Rの附録Aでは制約が書き加えられて変換しないことになっています。

あう sizeof は右辺値でもいいのか。 だったら「sizeof の係る式が左辺値の場合には右辺値変換するな」って旨を コンパイラ作者に通知する条文でもあるわけだな。 結論は変わらん。

規格書の一部はコンパイラ作者向けに、一部はユーザ向けに書かれている。 で、当該項はユーザ向けだと、俺は思う。 俺がコンパイラ作るなら、左辺値が必要とされる文脈で右辺値変換するなんて無駄なことはしない。 単項 & や sizeof はまさに左辺値が必要とされるところであるから、そこで 無駄な右辺値変換を行わなければ規格書どおりの動作となるわけだ。 同じことが代入式の左辺でもいえる。 だから、俺的には配列名が代入式の左辺に現れたときに右辺値変換されるとは思わない。 「変更不可能」だから左辺におくとエラーと考えるほうが自然。 まあどう解釈しても結果は同じだからどうでもいいけど。

前橋さん、774RRさん、ありがとうございます。 > 配列に代入できないのは変更可能な左辺値ではないから なるほど、 「配列に代入できないのは、配列は左辺値だが変更不可能だから」 と考える必要はないんですね。 「『変更可能な左辺値』ではないもの」には、 「変更不可能な左辺値」だけでなく「右辺値」も含まれますから。 (a)変更可能な左辺値 (b)変更不可能な左辺値 (c)右辺値 (d)その他 に分けたとして、 ・「ポインタ完全制覇」での説明： 　　　「配列に代入できないのは、(c)だから」 ・私が[796]で書いた説明： 　　　「配列に代入できないのは、(b)だから」 ・おそらく最も正確な説明： 　　　「配列に代入できないのは、(a)でないから」 「(a)でない」を満たしさえすれば 配列に代入ができないことには変わりなく、 その実態が(b)なのか(c)なのか、あるいは(d)なのかは 別問題である、ということですね。

char a[10]; char (*p)[10]=&a; // である場合に *p=0; あるいは *p={0}; であれなんであれ *p は代入式の左辺に置けません。 JIS X 3010:2003 6.5.16 代入演算子 [制約] 変更可能な左辺値でなければならない。 JIS X 3010:2003 6.3.2.1 変更可能な左辺値とは...[配列を含まない] なので >配列に代入できないのは変更可能な左辺値ではないから であり、それ以上でも以下でもないです。 ただしこの話はスレ題の「左辺値が要求される場所においても読み替えが起こるか」とは無関係。 無関係ではありますが、やはり同じく JIS X 3010:2003 6.3.2.1 型"～の配列"を持つ式は、型"～へのポインタ"の式に型変換する。 それは配列オブジェクトの先頭の要素を指し、左辺値ではない。 とありますから、スレ題に関して言えば「どちらでもいい」となります。 起こると解釈しても起こらないと解釈しても、いずれにせよ代入式の左辺に置けないことに違いは無い。 ところで JIS X 3010 は 2003 版が発行済で 2003 版には 6.2.2.1 が無かったです。 引用元は 1990 版でしょうか？

>配列名は式の中では先頭要素へのポインタ(右辺値)に読み替えられる、 >という規則は、代入演算子の左側のような、 >「左辺値が要求される場所」においてもそうなのでしょうか？ JIS X3010の6.2.2.1によれば、 | 左辺値がsizeof演算子のオペランド、単項&演算子のオペランド、文字配列を初期化 | するのに使われる単純文字列リテラルまたはwchar_tに適合する要素型をもつ配列を | 初期化するのに使われる文字列リテラルである場合を除いて、型"～型の配列"をもつ | 左辺値は、型"～型へのポインタ"を持つ式に型変換する。 とあります。 もし、代入演算子の左側のような「左辺値が要求される場所」においては配列から ポインタへの読み替えが行われないのだ、とするのなら、上記の3つの条件の中に 単項&演算子のオペランドを含める必要はないはずです。&演算子のオペランドは もともと左辺値が要求される場所だからです。 ということで、上記3つの箇所を除いて、(左辺値が要求されようがされまいが) 式の中では配列はポインタに読みかえられる、と解釈するのが自然ではないでしょうか。 # とはいうものの、「変更可能な左辺値」の定義からわざわざ配列が除かれている # ところからすると、配列に代入できないのは変更可能な左辺値ではないからだ、 # という解釈もできるような気が…

こんにちは。Cの「配列名」について、質問があります。 「ポインタ完全制覇」には、 char hoge[5]; hoge = "abcd"; がダメな理由は、hogeが右辺値だから、とあります。 配列名は式の中では先頭要素へのポインタ(右辺値)に読み替えられる、 という規則は、代入演算子の左側のような、 「左辺値が要求される場所」においてもそうなのでしょうか？ 配列名は、右辺値(先頭要素へのポインタ)に読み替えられる前は、 配列オブジェクトそのものを表す変更不可能な左辺値なので、 「hoge = "abcd";がダメなのは、hogeは左辺値だけど変更不可能だから」 という説明であれば納得できるのですが、 どちらの説明が正しいのでしょうか？

>ところで、ポインタの概念は難しくないですが、使いこなすのは大変だ 禿げ上がるほど御意。 むかーーーーしの自分のソースを見ると良くわかったりします。 >実行時に型情報を持っていると誤解する人が出そうです。 今までに扱ったCPU/コンパイラ全てで「実行時型情報をもつポインタ」って無いですね。 無駄っぽなので。ただ、規格書は何も言及してないので「あっても違反ぢゃない」です。 # CPU 何種類使っただろう? 両手ぢゃ足らんくらいだな。 メモリアドレスをどう扱うか、ソースレベルで指定してる。と言うべきだったかな。 C++ の dynamic_cast/typeid 系が扱う型情報は、ポインタ自体にではなく、 その指す先のオブジェクトにあるワケで、やはりポインタには型情報は無いな。

>タイトルのとおりなのですが、ポインタってそんなに難しいですか？ 難しいのでは。少なくとも難しいと思う人がいるからこそポインタ本の需要が生まれ、 私が日々の酒代を稼ぐ余地が生まれたというものです。ありがたいことです(ぉぃ) >正確には「ポインタの概念が」難しいと思ったこと無いというべきかな。 >ポインタ関連の表記が難しいとは思ったけど。 これはそう思います。私のそのへんに関する認識は、以下のページの冒頭に書きました。 http://kmaebashi.com/programmer/pointer.html だからこそ、ポインタ完全制覇では、宣言の構文やら配列とポインタの関係やらに 力を入れたつもりなのでして、「負け組一号」さんがまだわからないところがあるのなら、 具体的にどこがどうわからないと言っていただければ、アドバイスできるかもしれませんし、 私にとっても参考になるわけなのですが。 ところで、ポインタの概念は難しくないですが、使いこなすのは大変だ、というのも ありますね。同じオブジェクトを複数箇所から指して思わぬ書き換えをしてしまったり、 Cだと、free()しすぎや領域破壊の危険も高いです。 >メモリアドレスに、その扱い方の情報を付帯してるだけぢゃん。 774RRさんは当然わかって書いていると思うのですが、この言い方だと、ポインタが 実行時に型情報を持っていると誤解する人が出そうです。

タイトルのとおりなのですが、ポインタってそんなに難しいですか？ 俺なんかは Z80 のアセンブラから入った口なので、ポインタが難しいと思ったこと無いです。 正確には「ポインタの概念が」難しいと思ったこと無いというべきかな。 ポインタ関連の表記が難しいとは思ったけど。 難攻不落なんて言うほどのものぢゃ糸色文寸無い。 メモリアドレスに、その扱い方の情報を付帯してるだけぢゃん。

>もしsetjmp/longjmpがcreate_jmp()してから使うような形であったら、&なしがきれいですよね。 御意。 > 今まで考えなしに付けてなかったですけど、概念的には付けるべきだったのかしら。 俺なんかはその昔の &array が規定されてなかった頃からＣをやってる人ですから 「配列名が先頭要素へのポインタに変換される」仕様が本能レベルで染み付いているので memset 等のポインタが必要な関数が使われてて引数に & が無い場合にはむしろ 「& がないから、これって配列なんだ」と解釈しがちな傾向がありますな。 # よく読んだら、ポインタ変数だったりすると後からびっくり。 概念的には & があるべきなのだと思う。ただ歴史的事情により 配列であることが明確な場合には & を書かないソースのほうが圧倒的多数だと思います。 > 例えば「配列へのポインタ」と「配列の先頭要素へのポインタ」の > 表現方法が異なるような処理系において > ...では、やっぱりmemset()の使用は推奨されないのかなぁ? void* は、内部表現が最大サイズとなるポインタを保持できなければならず、なおかつ、 必要な時には内部表現を失わずに元の型に戻せることが必須とされていますから、 問題ないです(問題あったら大変だ) # テスト略

#テストの(略) >>jmp_buf の場合は「set/longjmp で使うハンドル」と考えれば & なしにも違和感なし >handle = CreateWindow(...); >みたいなのだと思うので、戻り値ではなく引数で返すならやっぱり&が付くのではないかと。 もしsetjmp/longjmpがcreate_jmp()してから使うような形であったら、&なしがきれいですよね。 jmp_buf myjmp = create_jmp(); if ( (ret = setjmp(myjmp)) == 0 ) { ... } else { ... } ～略～ longjmp(myjmp, ret); >memset()の場合でも、&を付けない人のほうが多いんじゃないかなあ。 今まで考えなしに付けてなかったですけど、概念的には付けるべきだったのかしら。 例えば「配列へのポインタ」と「配列の先頭要素へのポインタ」の 表現方法が異なるような処理系において ...では、やっぱりmemset()の使用は推奨されないのかなぁ?

# テストに反応してみるテスト >jmp_buf の場合は「set/longjmp で使うハンドル」と考えれば & なしにも違和感なし ハンドルといえば、 handle = CreateWindow(...); みたいなのだと思うので、戻り値ではなく引数で返すならやっぱり&が付くのではないかと。 >memset の場合は要求されるのが void* だから &array のほうが適切な場合多し >strcpy の場合は要求されるのが char* だから array と書かなきゃいけない >scanf+%s の場合も同様 memset()の場合でも、&を付けない人のほうが多いんじゃないかなあ。 適当にぐぐって見たけど付いてない例が多いようです。 http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/vclib/html/_CRT_memset.asp http://www.cppreference.com/stdstring/memset.html >C/C++ はエラーメッセージの読み方が難しいのが減点ポイント (馬から落馬) まあ、エラーメッセージの良し悪しはコンパイラによるところもあるとは思いますが、 C言語自体が多様な書き方を許すためにエラーメッセージがわかりにくくなるところは ありますね。

>char* p,p2; >とするとp2は >char p2;となってしまうと理解させていただいています。 この問題だけであれば、一度に複数の変数を宣言するなｺﾞﾙｱで回避できるのですが、 Cではたとえば配列なども型の一部ですから、どっちみち 型 変数名; の形では変数宣言を解読できないんですね。CESさんが出した問題がそうであるように。

>前橋さんの本やこのホームページは、 >扱っている技術の内容が高く、 >現場のプログラミングにおいても、 >ものすごく役に立つのでよく見ています。 ありがとうございます。 >さて、私も「Java謎＋落とし穴」を最近読んだのですが、 >少し内容が古くなってきたように感じます。 これは確かにそう思います。 >特に進化のスピードが速いJavaでは、 >本書で前橋さんが苦言を呈している >ジェネリックやenumなどの機能については、 >現在、ほとんど盛り込まれています。 そうですね。 >そこで、ここ最近、話題になっている? >「疑い深いあなたのためのオブジェクト指向再入門」 >の内容に加筆したものを新規に書き起こして、 >加筆修正した改訂版を出してはどうでしょうか。 >（単に私が読みたいだけですが。） 「疑い深いあなたのためのオブジェクト指向再入門」にあることは、言いっぷりは ともかくとして「謎+落とし穴」にも書いたつもりですから、J2SE5.0対応の改訂版、 ということになるのだと思いますけれど。 書いてみたいネタではあります。ただ、J2SE5.0は仕事で使っていないので、 本が書けるところまで私自身わかっているか、という問題はありますね。 # 仕事じゃまだまだJDK1.3が現役だったりします。

# あれこれ言ってみるテスト jmp_buf の場合は「set/longjmp で使うハンドル」と考えれば & なしにも違和感なし なまじ buf という文字列が見えてしまっているのが名前付けに失敗した例と思う memset の場合は要求されるのが void* だから &array のほうが適切な場合多し strcpy の場合は要求されるのが char* だから array と書かなきゃいけない scanf+%s の場合も同様 GCC はフォーマット文字列がリテラルな場合に警告してくれます。 scanf("%s", &buf); に対して gcc -Wformat hoge.c で piyo.c:4: warning: char format, different type arg (arg 2) みたいに。 C/C++ はエラーメッセージの読み方が難しいのが減点ポイント (馬から落馬) たいていの原因はエラー表示のある行の直前にあったりするし。 template 多用時は俺でもエラー判別がめんどくさかったりするですね。

Thank you for res. >char *p; > >よりも > >char* p; > >と書くほうがわかりやすい、という意味でしょうか? >それはそれで否定しませんが、それで問題は解決しない、ということもポインタ完全制覇は これについては、著書で理解しております。 char* p,p2; とするとp2は char p2;となってしまうと理解させていただいています。 あと、char *p;としてprintf("%p",p);としたとき参照されてない というエラーがでましたが、まぁ、ただ、もう理解してますので、蛇足です。 あと、他の言語では、配列とポインタは、”ほぼ別格”というのは、新たな知識として ありがとうございます。 とりあえず、今は構造体のリストを理解するために、脳をこねくりまわしている状態です。 しっかし、まぁ、I study hard and more hard to purogramming-Cってなことですな～ ついでの蛇足で int dt = (a = 20,b=10);とすると dt=10となるなんていう、たぶん一生必要ない知識ですが、まぁ、なんというか・・・ 色々あるな～・・・と思う、日々。 年々歳々花相似たり、年々歳々人同じからず

>>こんにちは。はじめまして。 >>Java謎＋落とし穴を読ませていただきました。 > >どうもです。 > >>他の著者の方や他の言語でもこういう「面白い」本はあるのでしょうか。 > >分野がわからないとアレですが、アスキーの256倍シリーズとかですかねえ。 はじめまして。 前橋さんの本やこのホームページは、 扱っている技術の内容が高く、 現場のプログラミングにおいても、 ものすごく役に立つのでよく見ています。 さて、私も「Java謎＋落とし穴」を最近読んだのですが、 少し内容が古くなってきたように感じます。 特に進化のスピードが速いJavaでは、 本書で前橋さんが苦言を呈している ジェネリックやenumなどの機能については、 現在、ほとんど盛り込まれています。 そこで、ここ最近、話題になっている? 「疑い深いあなたのためのオブジェクト指向再入門」 の内容に加筆したものを新規に書き起こして、 加筆修正した改訂版を出してはどうでしょうか。 （単に私が読みたいだけですが。） 結構、売れると思いますw（余計なお世話ですか？）

>ポインタの読み方から頑張って導こうとしなくても、こんなのを書いちゃうと一発だと、散々悩んでから気がついた。 > >template< typename ReturnType > >ReturnType Test(); > >std::cout << typeid( Test< char(*)[10] > ) << std::endl; マチガヘタ。 std::cout << typeid( Test< char(*)[10] > ).name() << std::endl; が正しい。

>>問： >>char 型の配列へのポインタを返す関数の宣言を記述しなさい。 >>関数名、引数、戻り値の要素数は任意とする。 > >用途としては、「\0込みで30文字以内の文字列を可変の個数返す関数」とかですかね。 ポインタの読み方から頑張って導こうとしなくても、こんなのを書いちゃうと一発だと、散々悩んでから気がついた。 template< typename ReturnType > ReturnType Test(); std::cout << typeid( Test< char(*)[10] > ) << std::endl; ちなみに、皆さんご存知だと思うけれど、正解はこう（N は要素数）。 char ( * f() )[ N ]; なんでこんなもので悩んでいたかというと、VC++ に奇怪なソースを発見したから。 配列の要素数を数えるコード。 template< typename _TypeOfArray, size_t _SizeOfArray > char ( * __countof_helper( _TypeOfArray ( & )[ _SizeOfArray ] ) )[ _SizeOfArray ]; #define _countof( _Array ) sizeof( * __countof_helper( _Array ) ) __countof_helper は、日本語で言うと「_TypeOfArray 型の配列（要素数は _SizeOfArray 個）の参照を引数に取り、char 型の配列（要素数は _SizeOfArray 個）のポインタを返す関数」の宣言。 返ってきたポインタを間接参照して sizeof すれば、引数に渡した配列と同じ要素数の char 型の配列のサイズ、すなわち引数の要素数が手に入るというカラクリ。 テンプレートに引数配列の要素数まで推測させているのにビックリ。

>これなら、配列に書き込む時オーバーフローしてもしかたがないと思う反面 >過去にどっかで、誰か偉い人が、配列というものをポインタとはまた別の物として >規定をなぜしてくれなかったのかと思います。 配列とポインタがこんなふうにこんがらがった変な言語はC/C++くらいなものであり、 たいがいの言語では、明確に別なものとして定義されています(ポインタではなく 参照と呼んでいるかも知れないけれど)。 ポインタ完全制覇にも書いたように、Cはもともと現場の要求を満たすために でっちあげられた言語なので、「ベストな言語」どころか「ベストを目指した言語」 でもないように思います。でも、そこそこよくできていたため広く使われてしまった、 というのが世の常であるわけで。 デザインの「悪い方がよい」原則 http://chasen.org/~daiti-m/text/worse-is-better-ja.html >ついでに、初期化で >char array[] = "abcd"; >char *p = array; >の意味が最初僕はわかりませんでした。「*pの内容にarray?どういうこと?」と思いました >これもchar* p = array;とすれば意味がすんなりわかりました。 これは、 char *p; よりも char* p; と書くほうがわかりやすい、という意味でしょうか? それはそれで否定しませんが、それで問題は解決しない、ということもポインタ完全制覇には 書きました。

>こんにちは。はじめまして。 >Java謎＋落とし穴を読ませていただきました。 どうもです。 >他の著者の方や他の言語でもこういう「面白い」本はあるのでしょうか。 分野がわからないとアレですが、アスキーの256倍シリーズとかですかねえ。

本多さん： >「&a」で取得できる「配列へのポインタ」って使い道ってあります？ 私の認識は、こっちに書いた通り。 http://kmaebashi.com/programmer/pointer.html | 配列から読み換えられたポインタは左辺値を持たないため、 & 演算子の | オペランドにはならないはずであるが、この例外規則のため、 & でアドレス | (配列の先頭要素のアドレスではなく、配列全体のアドレス)が 取得できる。 | この規則は初心者を混乱させることがある (例えば scanf("%s", buf) でなく、 | scanf("%s", &buf)と書いても 正常に動いてしまう(正常に動いたように見えて | しまう)が、 メリットは今ひとつわからない。 774RRさん： >int a[10]; >memset(&a, 0, sizeof a); >配列だから &a にせずとも a とだけ書けば事足りるのだが、配列の場合だけ & 不要ってのは >（単なる表記の問題ではあるが）初心者を惑わすもととなりうるんで。 strcpy(dest, src)とかでもdestに&は付きませんから、これは付けないほうが むしろ統一が取れるのではないでしょうか。 >typedef int i10[10]; // これは .h ファイルにあって >i10 a; memset(&a, 0, sizeof a); // こっちは .c ファイルにある >の場合には & ありのほうが自然で、ないのは不自然。 MinGWのsetjmp.hより： typedef _JBTYPE jmp_buf[_JBLEN]; でも、setjmp()を使うときは、 jmp_buf buf; if (setjmp(buf) == 0) { ... なのであって、&は付けません。 まあ、前から書いているように、私もこれって不自然だと思うんですが。

>問： >char 型の配列へのポインタを返す関数の宣言を記述しなさい。 >関数名、引数、戻り値の要素数は任意とする。 用途としては、「\0込みで30文字以内の文字列を可変の個数返す関数」とかですかね。 CADやってたころは、たとえば3次元ポリラインなどで、「double3つの可変長配列」を よく受け渡ししたものです。また、4×4の行列もしょっちゅう引数で受け渡ししました。 配列を引数で渡すとき、 void func(double a[]) のように書けるシンタックスシュガーは、私は混乱を招くだけだと思うのですが、 やっぱりこれを使ったほうが読みやすい、という主張もわからなくはないです。 特に多次元配列では。 でも、仮引数の宣言でしか使えない(戻り値とか、一時変数に代入する時には使えない) んじゃやっぱ中途半端だよなあ。

レスありがとうございます 私は 技術評論社の入門本物志向が身に付く本（浅井　淳さん　著）とウェブの初心者ページ で初心者としての知識を身につけ 初心者用問題集（確か～望洋さん　著）の本を一通り解いて C言語ポインタ完全制覇（前橋　和弥さん　著）と C言語文字列操作＋ファイル入出力完全制覇（山地　秀美さん　著）を買い C言語文字列操作＋ファイル入出力完全制覇の構造体を使ったリストの所で 頭がこんがらがり、今は、C言語入門シニア編（林　晴比古さん　著）by ソフトバンク で勉強中で、かつ、プログラムはなぜ動くのか（矢沢　久雄さん　著）by 日系BPを読み アセンブラを勉強した方が良いのか？と思いつつ、とにかくC言語をという感じで 勉強中です。 以上駄文ですが、なにかお勧めの本はありますか？あれば教えて頂きたいです。 このBBSにふさわしくない内容でしたら削除します。駄文もうしわけない。 ちなみに、ポインタに関しては、さし棒と考える事にしてます そんで、array[index]=*((array)+(index))だし これなら、配列に書き込む時オーバーフローしてもしかたがないと思う反面 過去にどっかで、誰か偉い人が、配列というものをポインタとはまた別の物として 規定をなぜしてくれなかったのかと思います。 ついでに、初期化で char array[] = "abcd"; char *p = array; の意味が最初僕はわかりませんでした。「*pの内容にarray?どういうこと?」と思いました これもchar* p = array;とすれば意味がすんなりわかりました。 で、勉強すればするほど、シンタックスシュガーなるもの、プログラミング言語に 存在してはいけないのじゃないのか？と初心者ながらに思いつつ 「まぁ、偉い人がこう決めたんだから、必要性もあるんだろう」と思っています。 以上、失礼します。

たとえばこんなのとか int a[10]; memset(&a, 0, sizeof a); 配列だから &a にせずとも a とだけ書けば事足りるのだが、配列の場合だけ & 不要ってのは （単なる表記の問題ではあるが）初心者を惑わすもととなりうるんで。 typedef int i10[10]; // これは .h ファイルにあって i10 a; memset(&a, 0, sizeof a); // こっちは .c ファイルにある の場合には & ありのほうが自然で、ないのは不自然。 個人的には char (*)[N] を単体で使うってのは他ではナイなぁ。 二次元(以上)配列を使うときに現れるだけだと思う。

こんにちは。はじめまして。 Java謎＋落とし穴を読ませていただきました。 難しい話がなぜか面白い文章になっていて読むのがとても楽しかったのですが、他の著者の方や他の言語でもこういう「面白い」本はあるのでしょうか。

>「配列へのポインタ」の存在価値がわからんという人も居たな。 >多次元配列（より正確には配列の配列）を考えれば存在価値がわかるだろう。 「配列へのポインタ」という型はもちろん存在価値があるのですが、 読んでてふと思ったことがあります。 「int a[10];」という配列に対して、 「&a」で取得できる「配列へのポインタ」って使い道ってあります？ っていうか実務で使った経験ってありますか？ int a[10][20]を受け取る関数の引数とかでなく、 配列自身に「&」をつけて、それを使うプログラムを使ったことが、です。 言語仕様を確認しようとしたチョイプロとかじゃなくて 何か明確な意図を持って、それを使わなくちゃいけない または使うほうが適切と判断するような場面ってありましたか？

カンペキだ... もう何も言うことは無い。俺が書かなかった内容まで指摘済み。以下蛇足。 > ポイント先は「50バイト分のヒトカタマリ」であって、 これが理解できない人がいる、ってのが理解に苦しむというかなんというか。 int* だって 2byte なり 4byte なりの塊を指すワケだし、何一つ違わないと思うのだが。 もっと言うなら char* だって 8bit の塊 (もっと大きいこともあるが) を指すのだし。 「配列へのポインタ」の存在価値がわからんという人も居たな。 多次元配列（より正確には配列の配列）を考えれば存在価値がわかるだろう。 char a[10]; char (*p)[10]=a; なとき *p=0; と書けないから理解できんのだろうか。そりゃ無謀ってもんだが... っと、先の [772] は yuya さん宛てに書いたのではなくって ROM 者のための課題だったので そこの ROM なあなた、自分で一度考察してみると理解が深まって吉ですぜ。 # 774 げっと

頭の整理のために、ということで。 A1'. char(*)[10] はchar配列(要素数10)へのポインタ。 char*[10] はcharへのポインタの配列(要素数10)。 A1". char (*hoge)[10]; Q3. 暗黙の変換前は 「charの配列(要素数10)の配列(要素数5)」型であり、 b[0]～b[4]の5つ(配列が5つ)のこと。 暗黙の変換後はその先頭要素へのポインタになるので、 「charの配列(要素数10)へのポインタ」型の右辺値となり、 そのポイント先はb[0]です。 「b + 1」はb[1]を、つまり10バイト離れたところをポイントします。 Q4. &bの「b」は暗黙の変換が行なわれないので、 配列そのもの(この場合は「配列の配列」という配列そのもの)になり、 それに「&」を付けた「&b」は「charの配列の配列へのポインタ」型の右辺値です。 「&b」のポイント先は「50バイト分のヒトカタマリ」であって、 「&b + 1」はもはや配列外をポイントするので、 ここを書き換えると何が起こるか分かりません。それこそ >「配列へのポインタ」で示される先に実体が１つあるだけ という状態ですね。

こたえ書いちゃうのは簡単なので、書かずに盛り上げるテスト # この辺、ポインタ中級レベルになるのでしょうか？それとも上級？ ここはまず「配列へのポインタ」っつーものがあることを理解しなければならない。 char a[10]; という配列があるとき &a[0] = 配列先頭要素へのポインタ右辺値 (char*) &a = char [10] 配列へのポインタ右辺値 (Q1. この型の表記を行え) である。これも概念レベルの問題なので理解できない人は一生理解しないままだったりする。 # A1.char(*)[10] 型。 Q1'. char(*)[10] と char *[10] の違いを述べよ Q1". char(*)[10] 型の変数を作るにはどう記述するといい? 先の例は「配列へのポインタ」で示される先に実体が１つあるだけ。つまりよくある char c; char* p=&c; と同じレベルの些細でつまらない例に該当する。だからより実用的な例に変えよう。 Q2.char b[5][10]; とするとき &b[0] の型を述べよ (答えは char[10] へのポインタ右辺値) Q3.では b とだけ書いたら何型で何を指す？ (暗黙の変換前と変換後の両者を答えよ) Q4.では &b と書いたら何型で何を指す？ このへんがすらすら答えられるようになるなら CES さんの問題も簡単。

こんにちは、CESさん。面白くてためになる問題ですね。 >関数名、引数、戻り値の要素数は任意とする。 戻り値はポインタなんですよね。 戻り値の要素数というのは？ 戻り値であるポインタが指す先のchar型配列の要素数ということでしょうか？ それとも、戻り値がポインタの配列になるかも知れないということでしょうか？ いや、ポインタの配列を返したくても、その先頭要素へのポインタ(ポインタへのポインタ)を返すしかないわけですけれど(^^;)

この前、読み方で思いっきり躓いた。 せっかくだからクイズにしてみよう。 問： char 型の配列へのポインタを返す関数の宣言を記述しなさい。 関数名、引数、戻り値の要素数は任意とする。

>うーん。なぜ皆「ポインタのポインタ」というのだろうか。すごく不思議。 >「ポインタへのポインタ」というほうがわかりやすくて正確だと思うのだが。 同意します。なので「ポインタ完全制覇」では、ある型Tを指すポインタは、 原則「Tへのポインタ」と言っているはずで…と思い、「ポインタのポインタ」で Googleしたらうちのページがトップに来た Σ（ﾟдﾟlll）ｶﾞｰﾝ >ポインタで躓いている人の半分くらいはポインタ左辺値と右辺値の違いがわかってない。 一応そのつもりで、ポインタ完全制覇では、ポインタはまず型であり、ポインタ型が あるのだから、ポインタ型の変数もポインタ型の値もある、と書いているつもりです。 K&Rに「ポインタはアドレスを格納する変数である」と書いてあるのがやっぱり 諸悪の根源ではないかと。 今は(例によって)酔っ払っているので続きはまた考えます。

うーん。なぜ皆「ポインタのポインタ」というのだろうか。すごく不思議。 「ポインタへのポインタ」というほうがわかりやすくて正確だと思うのだが。 ポインタで躓いている人の半分くらいはポインタ左辺値と右辺値の違いがわかってない。 判ってるほうはわざわざ区別する気にならないのであえて明言しないし。 これは概念理解の問題なので、噛み砕いて説明しても無駄な場合が多くて泣きそう。 残り半分は宣言の読み方が判らないだけで、こっちは技術的問題なので慣れでなんとかなる。 int (*pf)(); と int func(int*); は C++ では明確に非互換なので無問題。 C では JIS X 3010:2003 6.7.5.3 関数宣言子にて「関数型が適合とは」の解説があり、 俺的解釈では pf=func; は適合であるため、「警告が出ないのがあたりまえ」 「もし警告が出るとしたら、それはコンパイラが親切なだけ」であると思われる。 int (*pf2)(void*); と int func(int*); は非互換でなきゃならない。 # 元発言者様の発言が質問になっていないので単なる感想。

はじめまして。 >はじめまして、プログラミングを勉強するには遅すぎる年齢（２８）で >C言語を勉強している者です。それも再就職を目指し今は病気療養で傷病手当 お大事に。無理せずがんばってください。 >そこで、本の内容で、ポインタのポインタについて一切触れられてない点が気になり >ました。（そんなに、使う物では無いのかな？と勝手に思ってもいますが） ご意見ありがとうございます。 うーん、ポインタのポインタ(型)、というのは、単にポインタから派生したポインタ型に 過ぎませんから、宣言の読み方からすれば3章の記述で足りそうですし、 実際の使い方としては、4-2-2の「可変長配列の可変長配列」および4-2-4の 「引数経由でポインタを返してもらう」で扱っているつもりです。 また、実際にプログラムを書くときの用途もそんなところです。 もちろん、ポインタのポインタを引数で返してもらうときにはポインタのポインタのポインタを 使いますし、ポインタのポインタの可変長配列を作りたければやっぱりポインタのポインタの ポインタを… いやこっちはさすがに構造体を導入すると思いますが。 まあ、「ポインタのポインタって何だ?」と疑問を持った人が、ポインタ完全制覇で その説明を探すときのことを考えれば、章タイトルに「ポインタのポインタ」が 入っていたほうがよかったかもしれません。 >例えば >int (*func)(); >int func2(int*); >とプロトタイプ宣言し、mainブロック内で >func = func2； >とした時僕としては、プロトタイプ宣言時に >int (*func)(void*); なぜ、 int (*func)(int*); ではだめなのでしょうか。 ひょっとして、funcに代入される実際の関数は、 int func2(int*); int func3(char*); int func4(double*); のうちのどれだかわからない、ということでしょうか。 もしそうであれば、これはちょっと邪悪な書き方だと思います。 # 厳密に言うと規格上もまずいです。int*とvoid*が同じ形式とは限らないので。 どうしてもこういうことをしたければ、私なら、 int (*func)(void*); としておいて、関数側で、受け取った後でキャストします。 int func2(void *a) { int *int_p = (int*)a; ... }

はじめまして、プログラミングを勉強するには遅すぎる年齢（２８）で C言語を勉強している者です。それも再就職を目指し今は病気療養で傷病手当 で生活している、ま、いわゆる人生の負け組ですが、一応もがくだけもがこうと プログラミングを勉強しだし、前橋さんの著書ポインタ完全制覇を読みました。 そこで、本の内容で、ポインタのポインタについて一切触れられてない点が気になり ました。（そんなに、使う物では無いのかな？と勝手に思ってもいますが） それと、int (*func)()；の様な形でプロトタイプ宣言したときに、引数の型を明示してないですが了解している警告として受け入れてはいますが 例えば int (*func)(); int func2(int*); とプロトタイプ宣言し、mainブロック内で func = func2； とした時僕としては、プロトタイプ宣言時に int (*func)(void*); としときたいのですが、別の著書では、void*を引数にすると厳しいコンパイラーでは エラーが出るとの事で（僕はVisual C++6.0で勉強していて、引数にvoid*を指定しても しなくても、警告もエラーも出ず実行できてしまいました） 引数は省略するほうが良いのだろうと思いつつ 警告でるなら、なんかやだな。とも思うんです。 かといって、引数として受け取る時にキャストする方法なんて知りませんし （ただの勉強不足なのでしょうが）そこら辺をもうちょっと本の中で知りたかったです。

>「疑り深いあなたのためのオブジェクト指向再入門」が非常に為になった。 >有り難うございます。 どうもです。あのページはうちのコンテンツの中でも毀誉褒貶が激しいページなので(w ためになったといっていただけるとたいへん励みになりますです。

「疑り深いあなたのためのオブジェクト指向再入門」が非常に為になった。 有り難うございます。

> そうでもないんですわ。push/popなんて命令も用意してもらえてません(T-T) > だいたい、レジスタに格納した番地のメモリにアクセスすると言う命令すらない(T-T) > 固定番地へのアクセスのみです。 ははあ、なるほど。 そうなると、式評価の途中の値は、レジスタに置くか、それが足りなくなったら どこか決めうちのワークエリアに置くことになるわけですね。その場所は、 コンパイル時に決定できますし。 勉強になりました。

>>っていうか、対象ハードウエア(自社製ASIC)が構造上どない頑張ってもスタック構造を処理できないので(@_@) >すいません、そういうCPUは触ったことないので質問です。 このハードウエアはCPUとは呼べないでしょうね。 今どきのPCの周辺機器のほうがよほど複雑なプログラム実行が出来そうです(^^;) >eval.cの関数をwrite()に置き換えたとのことなので、そこで吐いているのはpush/popだと >思っていましたが、そうでもないんでしょうか? そうでもないんですわ。push/popなんて命令も用意してもらえてません(T-T) だいたい、レジスタに格納した番地のメモリにアクセスすると言う命令すらない(T-T) 固定番地へのアクセスのみです。 だからメモリの上から順にグローバル変数を割り付けていくと言うことしてます。 (っていうか、メモリも2kだけですし...)。 JMP命令はあるけど、固定JMPのみ、というわけで、関数呼び出しも再起呼び出し禁止、 関数の型はvoid func(void)のみって感じになりました。 コンパイラがwrite()で吐いてるのは 「メモリからレジスタ1へのコピー命令(に対応する数値)」とか 「レジスタ aとレジスタ bの演算命令(に対応する数値)」とか 「特殊機能を実行する機械語(に対応する数値)」とかを データファイルに書き出してます。 実際、(PCではないのですが)本当にあるシステムの周辺機器なので メインのCPU(こっちは汎用CPU!)上で動作するプログラムが 作ったデータファイルからデータを読み込んで対象ハードウエアに書き込み、 対象ハードウエアを起動するという形を取ります。

>っていうか、対象ハードウエア(自社製ASIC)が構造上どない頑張ってもスタック構造を処理できないので(@_@) すいません、そういうCPUは触ったことないので質問です。 eval.cの関数をwrite()に置き換えたとのことなので、そこで吐いているのはpush/popだと 思っていましたが、そうでもないんでしょうか? それとも、その程度のスタック操作はできるけど、スタック上のインデクシングができないとか、 そういうことでしょうか?

>　対象とするプログラムが200～300ステップとのことなので、ローカル変数とかは >ばっさり省略されたんでしょうか。crowbar - αだとそんな感じになりそうな気が… はい。ばっさりと。 っていうか、対象ハードウエア(自社製ASIC)が構造上どない頑張ってもスタック構造を処理できないので(@_@) そんなのを作って「C言語のサブセットだ」と言い張るのは少々(だいぶ?)誇張だとは自覚してますが... アセンブラで記述した200～300ステップがC言語で50行以下にできるところが一番の収穫です(^^)

> 感謝状なので、わざわざ 丁寧な書き方してみましたが、 > こそばゆかったっすか...(^^;) そりゃもう。 > じゃあ次からは丁寧に書かないようにしますわ(^O^)/ へい。それで結構でございますです。 > crowbar中のeval_...とか、execute_...って関数をwrite()文の羅列に置き換えたので、 > たぶんcrowbarを簡単にしただけです。 　対象とするプログラムが200～300ステップとのことなので、ローカル変数とかは ばっさり省略されたんでしょうか。crowbar - αだとそんな感じになりそうな気が…

>>前略 前橋様 >　いつものmanybookの本多さんにこういうことを書かれたとすればさすがにこそばゆいので。 いや、いつもの本多ですが...(^^;) そっか、新しい掲示板はメールアドレスないんですよね。 感謝状なので、わざわざ 丁寧な書き方してみましたが、 こそばゆかったっすか...(^^;) じゃあ次からは丁寧に書かないようにしますわ(^O^)/ >>で一念発起、C言語で書けるようにコンパイラ(もどき)を作ることにしました。 >　正直、機械語を生成するCコンパイラだと、せいぜい構文解析までしか役に立たな >かったのでは、と思いますが、多少なりともお役に立てたのでしたらよかったです。 なにせ、コンパイラを作ろうなどと考えたこともなかったので 構文解析やらなにやらと、全く知らなかったので勉強になりました。 何よりソースコード付で、そのコードを丁寧に説明してあるのが わかりやすくて良かったです。 crowbar中のeval_...とか、execute_...って関数をwrite()文の羅列に置き換えたので、 たぶんcrowbarを簡単にしただけです。

>前略 前橋様 　はじめまして…でいいですよね? 　いつものmanybookの本多さんにこういうことを書かれたとすればさすがにこそばゆいので。 >有益なページの提供に心から感謝します。 　や、ありがとうございます。 >で一念発起、C言語で書けるようにコンパイラ(もどき)を作ることにしました。 　正直、機械語を生成するCコンパイラだと、せいぜい構文解析までしか役に立たな かったのでは、と思いますが、多少なりともお役に立てたのでしたらよかったです。

[750] への追補。 > 設計手順としては、まず常識的な is-a を使って継承関係を考えてみた > 上で、それを LSP で検証すればいいんですよ。検証に通らない場合には、 > たとえ常識的なis-a 関係であっても、継承関係にはしません。検証に通 > れば、もちろん継承関係にします。 「常識的な判断」が悪いとは思いません。 ところで、「常識」と「真理」は違います。 日本人の常識とアメリカ人の常識が異なるのと同じように、販売支援ソフトと画像処理ソフトの設計常識が同じはずがありません。要するに、常識ってのはいっぱいあります。 その中から、今回作りたいソフトに適する常識を選ぶ必要があります。 経験に基づいて「常識的な設計手法は、適した設計である可能性が高い」と言うのであれば、俺が言う「いくつもの方法の中から、適したものを選べ」というのと、全く変わりません。 ですから、それを否定する kit さんは、「常識的な設計」すらすることができません。 > これも繰り返しになりますが、「照らすまでもなく」のような暗黙の知識は、 > 法則としては役に立たないんですよ。 では「常識」は暗黙の知識ではなく、明文化されているのですか？

前略 前橋様 有益なページの提供に心から感謝します。 最近、自社製の小さなハードウエアに搭載するためのアセンブラプログラムを作る仕事をすることになったんです。 規模がそれほど大きくない(200～300ステップ)のですが、アセンブラはやっぱり大変です。 で一念発起、C言語で書けるようにコンパイラ(もどき)を作ることにしました。 連載「プログラミング言語を作る」の前橋さんの説明とcrowbarソースコードを繰り返し読むことで なんとか2日ででっち上げることに成功しました。 さすがにcrowbarとは欲しい機能とは大分違うのでソースコードをそのまま利用することはしてません(できません)が、このページのおかげで大分楽に作ることが出来ました。 しょせん、ハードウエアの制限でポインタとか文字列とか浮動小数点とか多くの機能が実装しない超簡単コンパイラですし、当面私しか使わないし、出来たコードをデバッグしなくちゃいけないのは変わらないのですが...(^^;) 勉強になりました。どうも ありがとうございます。

>>ただ、この手法を更に推し進めるとインターフェイスの多重継承の山になりかねないので要注意でしょう。 >>struct fooable { virtual void do_foo()=0; }; >>struct barable { virtual void do_bar()=0; }; >>struct bazable { virtual void do_baz()=0; }; >>struct hoge : fooable, barable {...}; >>struct piyo : barable, bazable {...}; > >推し進めるというか、どこかで一歩飛んでいる気がします。 >FlyingAnimal は（あるいは、飛行機を統一的に扱おうとしてさらに上位に定義した FlyingObject でさえ）、IFlyable とは一線を画したものであるような気がします。 >なぜそう思うのかは、いまのところ「直感」としか言いようがないのですが。 失礼。 今回は既に bird からしてインターフェイスでしたね。 Java や C# が言うところの「インターフェイス」の意味づけが、自分の中でよくできていない感じです。

>ただ、この手法を更に推し進めるとインターフェイスの多重継承の山になりかねないので要注意でしょう。 >struct fooable { virtual void do_foo()=0; }; >struct barable { virtual void do_bar()=0; }; >struct bazable { virtual void do_baz()=0; }; >struct hoge : fooable, barable {...}; >struct piyo : barable, bazable {...}; 推し進めるというか、どこかで一歩飛んでいる気がします。 FlyingAnimal は（あるいは、飛行機を統一的に扱おうとしてさらに上位に定義した FlyingObject でさえ）、IFlyable とは一線を画したものであるような気がします。 なぜそう思うのかは、いまのところ「直感」としか言いようがないのですが。

>「こうもり」を派生したくなった時点で、名前をflying_animalとかに変更するのが筋では？ 御意。それは大いにありだと思う今日子の頃です。 今回のこの案件Ａ’Ａ”では、それでうまく行きそうです。みな幸せ。 ただ、この手法を更に推し進めるとインターフェイスの多重継承の山になりかねないので要注意でしょう。 struct fooable { virtual void do_foo()=0; }; struct barable { virtual void do_bar()=0; }; struct bazable { virtual void do_baz()=0; }; struct hoge : fooable, barable {...}; struct piyo : barable, bazable {...}; とてもまともに分析したとは思えない醜い設計です。 抽象度は増したのかもしれませんが、実用度が薄すぎます。まともに使いこなせるとはとてもとても。 # 自己反省をかねて age

kit さんへのまとめ。 俺は当初、kit さんは「オブジェクトの is-a など問題にしなくてよい。LSP のみが確かな判断基準となる」と言っているのだと思っていました。 理由は、 > 設計手順としては、まず常識的な is-a を使って継承関係を考えてみた > 上で、それを LSP で検証すればいいんですよ。検証に通らない場合には、 > たとえ常識的なis-a 関係であっても、継承関係にはしません。検証に通 > れば、もちろん継承関係にします。 これを [715] まで言わなかったことです。 しかし、実態は上記の通り、kit さんも、LSP を適用する前に、オブジェクトの is-a での判断を行っています。 そして、俺が [722] で書いた > 結局、この文献は「どんなものを継承関係にすべきか」という指針には、一言も言及していないのです（「どんなものを継承関係にしてはいけないか」は、LSP を用いて言及しています。＜以下略＞）。 これは、kit さんにも当てはまります。 上記の [715] の文章は、まさにこれだからです。 LSP で検証したことによって、最初に下した「常識的な判断」が正解だったか間違いだったかは確かに分かりますが、その「常識的な判断」は LSP を用いて下したものではありません。 kit さんも、「どんなものを継承関係にするのが正解か」は、LSP を用いて判断していないのです（判断しているのは「結果的に正解だったか」です）。 > これも繰り返しになりますが、「照らすまでもなく」のような暗黙の知識は、 > 法則としては役に立たないんですよ。 「照らすまでもなく間違いと分かる」のは「まるで神に囁かれたかのごとく、なんとなくわかる」のではありませんよ。「LSP など適用しなくても、分析をしっかりとやることによって、きちんと根拠付けて導かれる」のです。 もっとも、kit さんが求める「分析というステップをすっ飛ばして、『LSP に照らすまでもなく』正解が分かる、設計のお手本」から見れば、これでさえ暗黙的に見えるかもしれませんけれど。 kit さんの求めるものとは、「多くの場合に適用できる（が、たまには失敗することもある）、常識的な設計パターン」さえ超越した、「常に成功を約束された設計パターン」なのでしょう。すなわち、「あるクラスＡは、どのような案件であるかによらず、常に、他のクラスの子クラスではないか、あるいは、Ｂの子クラスであるかのどちらかである」という保証（と、ＡとＢの一対一の対応表）ですね。なぜなら、kit さんは「案件によって、Ａの親はＢが適切な場合も、Ｃが適切な場合もある。それは案件を分析してみるまで分からない」というのではダメだとおっしゃるからです。 そのようなパターンが本当に存在するのなら、それは素晴らしいことでしょう。 しかし、もしそれを実践したとすると、失敗するケースの方が多いように思えてなりません。 > むしろこういう説明は、 > この説明に沿って機械的に作業していけば、「オブジェクト指向設計」ができるんだ。 > という印象を与えかねないという点で有害だと思います。 > 確かに、ソフト屋は常に一定以上の品質のプログラムを供給しなければならないものであり、その意味では、「機械的にやっていけば誰でもちゃんとした設計ができる」という手法があるのならば大変結構なことです。しかし、残念ながら、オブジェクト指向設計はそこまでいっていないと私は思っています ※4。 > ていうか正直私は、こういうことは、未来永劫、決して「機械的にできる」ようにはならないと思います。 「疑り深いあなたのためのオブジェクト指向再入門／なぜわからなくなってしまうのか?」より抜粋。 わかってらっしゃるじゃないですか。

>>もしくは、間違ってfly()させちゃいけないのなら >>例外を投げるのもありかなと思います。 >これは LSP 違反だと思うのです。 >http://www2.ocn.ne.jp/~yamagu/object/LSP-J.pdf >の Rectangle と Square の例[本当の問題]と同等な問題を内在させることになりそうです。 >さて、こういう場合に「そもそも同一視すべきだったか」を私は問いたいのです。 ここで、前提条件として以下のものを考えます。 「struct bird { virtual void fly()=0; }; に対し、birdを継承したbat(こうもり)クラスの実装も クライアント側の処理もうまくいった。 ここで新たにpenguin(ペンギン)クラス(処理)を追加する必要が 生じた。」 この時の設計として、penguinクラスとbatクラスを 同一視(例えば、両方ともbirdから継承)すべきかどうかを考えてみます。 私の前回の発言のように、penguinクラスとbatクラスを 同一視して、penguinのfly()の実装で例外を投げようとすると、 birdを扱うクライアント側の処理でbatとpenguinを 同一扱いできないので、LSPに違反します。 つまり、penguinクラスのfly()の実装でどうしても例外を 投げたいのであれば、明らかに設計ミスで、birdクラスで 例外を投げるように設計しておかなければなりません。 しかし、penguinのfly()を、batクラスのfly()とクライアント側で 同一視できるように実装しておけば問題ありません (例えば、fly() {}のような空実装など)。 すなわち、774RRさんが、[745]の２でおっしゃってるように、 既に実装されているクライアント側の処理にマッチするように penguinのfly()を実装すれば問題ありません。 しかし、現実的には全てのクライアント側の処理を調べるのは 現実的ではないので、LSPを頼りに、 「penguinのfly()の振る舞いがbatのfly()の振る舞いと同等である」 という「常識的な」判断ができれば、クライアント側でbatとpenguinが 同一視できると判断しても妥当と言えるかもしれません。 また逆に、LSPに違反した継承を行った場合でも、 クライアント側で両方に共通した使い方のみで実装してあげれば 問題ありません (もちろん、その後、LSPに違反するような実装をクライアント側の 処理で行う実装を追加すれば問題が起きるので設計としては かなり危険な設計ですが)。 また、774RRさんの[743]での以下の疑問 >さて、こういう場合に「そもそも同一視すべきだったか」を私は問いたいのです。 は、「既に存在するクライアント側の処理がどうなっているか」と 「penguinのfly()の実装をどうしたいか」の両方に依存しているので 常に正解の設計方法論はないと私は思います (クライアント側の処理をあらかじめ規定するには、Design by Contractとかに 類する機能が必要だと思います)。 ここで、私の出た結論としては、私自身かなり混乱しているのですが、 つまり、penguinクラスをbirdから派生させてbatと同一視すべきかどうか という設計を迫られたとき、これがLSPに当てはまるかどうかを 考えようとして、 「penguinのfly()の振る舞いが、batのfly()の振る舞いと同一か」 という疑問を持ったとき、 penguinのfly()を実装しようとした時に、どう転んでも クライアント側の実装がbatのfly()と同一視しかできない実装になっている のであれば、全く問題ない訳で、 クライアント側の実装により、少しでも同一視できない可能性があるなら そういう設計すべきでない訳で、 つまり、それをどう判断できるかと言うと、クライアント側のコードの 予想がつかないため、そんなに単純にLSPで判断できないような気が してきました(クラスが単純ならできる場合もありそうです)。 ここでは、fly()関数1つのみを考えている訳ですが、実際は、クラスは 複数の関数を持つ場合がほとんどなので組み合わせるともっと複雑になるし。 結局、同一視すべきかは、LSPはかなり参考にはなるが、 どんな局面でも通用する設計方法は存在せず、「実装依存」な気がします。

>bird 派生クラスは全て「飛べる」必要があり、飛べないものをこいつから派生したらダメ。 >１．だから、この bird からダチョウクラスを派生させるのはダメ。 >２．もしダチョウクラスを bird から派生させたいのであれば bird の実装を再検討。 >ではどのような bird にすればよいか、は要件に応じて再分析が必要。 >その再分析の際に「特定の設計原理（銀の弾丸）」ってものはありえない。 >ただその分析の結果の実装は LSP に則るべし。 鼻血が出るほど同意。

概ね、皆さんに同意ですね。 >struct bird { virtual void fly()=0; }; このクラス設計が意味するところは簡単で「鳥は飛べる」ただこれだけです。 論理学風の言い方をすれば「鳥ならば飛べる」。 >Q1.案件Ｂ（あるいはＡ’と言い換えても）では「こうもり」を扱う必要が生じた。 >基底クラスを書き換える/書き換えない？派生クラスの実装をどうする？ 「飛べるならば鳥である」ではありませんから、コウモリを鳥のサブクラスにすることはできません。 どうしても統一的に扱いたいのならば、Flying-Animal クラスでも導入すべきです。 >Q2.案件Ｃ（あるいはＡ”）では「ダチョウ」「ペンギン」を扱う必要が生じた。 >基底クラスを書き換える/書き換えない？派生クラスの実装をどうする？ これは、前提条件が崩れているわけですから、理想的には一からやり直すべきです。 鳥クラスの下に「飛べる鳥」クラスと「飛べない鳥」クラスを設けて、fly メソッドは飛べる鳥クラスに移動する…と、既存の bird.fly メソッドを使っているコードは動かなくなりますね。 コスト的にやり直しが許されないのならば、飛べない鳥クラスの fly メソッドは、何もしない空実装にするのも手かもしれません。

>struct bird { virtual void fly()=0; }; オブジェクト指向ぜんぜん分かってない者ですがひとつだけ。 そもそも、birdって言う名前をつかうこと自体、おかしくないですか？ 「こうもり」を派生したくなった時点で、名前をflying_animalとかに変更するのが筋では？ そしたら「ダチョウ」を派生できないことは明らかなはずで。

んと、他人の意見だけ募集して自分の意見を出さないのはアレげなので私の見解。 LSP=同一基底クラスから派生したオブジェクトは、振る舞いが同一であると契約する 契約＝派生クラス実装者と基底クラス利用者の間で取り決め ってことなので、そもそも struct bird { virtual void fly()=0; }; って設計した以上 bird 派生クラスは全て「飛べる」必要があり、飛べないものをこいつから派生したらダメ。 １．だから、この bird からダチョウクラスを派生させるのはダメ。 ２．もしダチョウクラスを bird から派生させたいのであれば bird の実装を再検討。 ではどのような bird にすればよいか、は要件に応じて再分析が必要。 その再分析の際に「特定の設計原理（銀の弾丸）」ってものはありえない。 ただその分析の結果の実装は LSP に則るべし。 ってことなんですけど。

>ダチョウ、ペンギンを例外にするのは良くないので、 >上記の実装なら同一扱いできるので良いと思います。 そこまでは限りなく同意なのですが >もしくは、間違ってfly()させちゃいけないのなら >例外を投げるのもありかなと思います。 これは LSP 違反だと思うのです。 http://www2.ocn.ne.jp/~yamagu/object/LSP-J.pdf の Rectangle と Square の例[本当の問題]と同等な問題を内在させることになりそうです。 さて、こういう場合に「そもそも同一視すべきだったか」を私は問いたいのです。

面白そうなので勝手に考えてみました。 初期の設計として私なら以下のように考えます。 >Shapeにdraw()を付けたら、その時はうまくいったとして。 > >Q1-1)機能拡張でShapeをグループ化できるようにしたとき、ShapeGroupクラスは >　どこに位置づけるべきか? > >Q1-2)機能拡張で「補助線」機能を付けた。補助線は、描画中にだけ使用する機能で、 >　後工程に回らないからデータとしてファイルに保存しない。 > >A1-1(前橋版) >ShapeGroupをShapeのサブクラスにして、draw()をオーバーライドしてその >グループに含まれているShapeのdraw()メソッドを再帰的に呼んでやれば >描画はできますが、それはやっぱりアレなのでShapeのスーパークラスとして >Visibleとかの抽象クラス(またはインタフェース)を作り、ShapeGroupとShapeは >そのサブクラスかなあ。 >たとえば「color」というフィールドは、ShapeGroupには要らないだろうし。 これは、私も(ぱ)さんと同様にします。 つまり、ShapeGroupとShapeを共にVisibleから継承させて、 ShapeGroupにVisibleのリストを持たせます。 そうすればCompositeパターンになり、描画するときは、 トップからつながってるShapeを全て描画できます。 >A1-2(前橋版) >補助線がShapeのコレクションに入らないとすれば、完全に別扱いかなあ。 >もちろんVisibleを導入し、Visibleのコレクションを作って、Shapeは >ShapeコレクションとVisibleコレクションの両方から参照される、という >構造でもいいけど、両方のコレクションをメンテするのも面倒だし。 Visibleのサブクラスとして補助線クラス(AuxLine)を追加します。 AuxLineには、Visibleを集約させて(持たせて)、実際はShapeクラスを 持ちます。必要な機能をShapeから委譲させます。 結局、新たなクラスをShapeのサブクラスにするのは、 結合度が強すぎてガチガチになるので、 ゆるやかな結合で設計しておいた方が良いのかと思います。 これだけの情報だと情報量が少ないですが、 もっとうまい設計があったら教えて欲しいです。 >>Q2.案件Ｃ（あるいはＡ”）では「ダチョウ」「ペンギン」を扱う必要が生じた。 > >具体例が思いつきませんが、「描画されないShape」ですよね。 > >void draw() {} ダチョウ、ペンギンを例外にするのは良くないので、 上記の実装なら同一扱いできるので良いと思います。 もしくは、間違ってfly()させちゃいけないのなら 例外を投げるのもありかなと思います。

>Q1.案件Ｂ（あるいはＡ’と言い換えても）では「こうもり」を扱う必要が生じた。 >基底クラスを書き換える/書き換えない？派生クラスの実装をどうする？ 鳥とかこうもりではあんまり具体的でもないと思うので、私は、例によって ドローツールっぽいものを考えるとします。 Shapeにdraw()を付けたら、その時はうまくいったとして。 Q1-1)機能拡張でShapeをグループ化できるようにしたとき、ShapeGroupクラスは 　どこに位置づけるべきか? Q1-2)機能拡張で「補助線」機能を付けた。補助線は、描画中にだけ使用する機能で、 　後工程に回らないからデータとしてファイルに保存しない。 A1-1(前橋版) ShapeGroupをShapeのサブクラスにして、draw()をオーバーライドしてその グループに含まれているShapeのdraw()メソッドを再帰的に呼んでやれば 描画はできますが、それはやっぱりアレなのでShapeのスーパークラスとして Visibleとかの抽象クラス(またはインタフェース)を作り、ShapeGroupとShapeは そのサブクラスかなあ。 たとえば「color」というフィールドは、ShapeGroupには要らないだろうし。 Shapeのグループ is a Shape と言って言えないことはないけど、苦しいし。 A1-2(前橋版) 補助線がShapeのコレクションに入らないとすれば、完全に別扱いかなあ。 もちろんVisibleを導入し、Visibleのコレクションを作って、Shapeは ShapeコレクションとVisibleコレクションの両方から参照される、という 構造でもいいけど、両方のコレクションをメンテするのも面倒だし。 >Q2.案件Ｃ（あるいはＡ”）では「ダチョウ」「ペンギン」を扱う必要が生じた。 具体例が思いつきませんが、「描画されないShape」ですよね。 void draw() {} でよさそうな… 以上、べたべたに実装よりの解答でした。

盛り上がっているのは良いのですが、なんだか飽きて^H^H^Hわからなくなってきたので、 長すぎるスレにつながずに新規発言してみるテスト。 こんな場合、皆様ならどのように対処なさるでしょうか？ご意見拝借。 ある案件Ａにおいては、こーいう設計が適切だと分析したので、以下のように書いた。 struct bird { virtual void fly()=0; }; そして現実にうまく行った。 Q1.案件Ｂ（あるいはＡ’と言い換えても）では「こうもり」を扱う必要が生じた。 基底クラスを書き換える/書き換えない？派生クラスの実装をどうする？ Q2.案件Ｃ（あるいはＡ”）では「ダチョウ」「ペンギン」を扱う必要が生じた。 基底クラスを書き換える/書き換えない？派生クラスの実装をどうする？ 抽象論だけだと理解しきれないのは俺だけ？なんか具体的な例が欲しくなったのです。

>実はオブジェクト指向に限らず、ジェネリックプログラミングとも >通じる真理だと思うんですが… ジェネリックプログラミングに通じるのはわからなくもないですが、だから何です？ ジェネリックプログラミングがそうだからといって、オブジェクト指向プログラミングもそうだという理由にはなりません。 >Webで公開されている文書であっても、原文の方で確認をすれば > then S is a subtype of T. >と書かれていますから、後者の意味であることは明らかなんですけどね。 なるほど。 件の本はまだ読んでいませんが、であるにしても、長方形と正方形の例をあのように用いているのであれば、どれほど信用が置けようか、という気はしますね。 >「完全に互換性のある属性と振舞いを示すのであれば、それは一見関係ないよ >うに見えても、実は関係があるのだ」というのが正解でしょう。 >CES さんは、この考え方を、一貫して拒否されているようですが… 属性や振る舞いに互換性があろうがなかろうが、何らかの関係はあります…と言うのも語弊がありますね。 関係は「ある」のではなく「作る」のです。作ろうと思えば、どんな関係だろうと作ることができます。これは、その気になればいくらでも互換性を持たせることができる、とも言えます。互換性は「示す」のではなく「持たせる」のですから。 問題は、その関係をプログラム上に表現することにメリットがあるのかどうかです。 そして、メリットがない関係は「関係ない」としても問題ありません。むしろ、そのような関係を徒に表現することは無駄であり害悪でしょう。 >> 俺は「LSP に照らすまでも無く、継承関係にしてはいけない場合がある」 >> と言う。 > >これも繰り返しになりますが、「照らすまでもなく」のような暗黙の知識は、 >法則としては役に立たないんですよ。だからこそ、明文化された LSP に >意味があるわけです。 俺は法則の話はしていません。 kit さんは「どういう関係を継承関係にすればいいのかという法則」を欲しているようですが、そんなものはありませんから。 LSP は満たすべき継承関係の指針ですが、使うべきところが違うと思うのです。 一応言っておくと、経験を否定しているわけではありません。 特定の案件に直面した時、「過去の経験から、こうすればうまく行くと思う」という提案は（最適ではなかったとしても）有意義です。 そのような場合でも「最適な選択肢は毎回違うのだから、経験などに頼らず、一から分析しなおすべきだ」と発言するのはバカです。 しかし、そのような特定の場面に依存しない、普遍的なガイドラインはない、と言っているのです。

「オブジェクト指向における is-a の関係は、オブジェクトの振舞い によって定義される」というのが、件の文献が言ってることなわけ ですが、どうも CES さんには受け入れられないみたいですね。 実はオブジェクト指向に限らず、ジェネリックプログラミングとも 通じる真理だと思うんですが… どうも CES さんとの溝は埋められそうにないわけですが、一応、 直接的な疑問には答えておきます。 > 件の文献も言っているではありませんか。 > 「サブタイプならば同じ振る舞いをすべきである」と書かれています。 > 「同じ振る舞いをするならサブタイプである」とは書かれていません。 訳が分かりづらくて、CESさんを誤解させてしまったのかもしれませんね。 Robert C. Martin の「アジャイルソフトウェア開発の奥義」をお持ちだ そうですから、そちらの該当箇所を参照されてみてはどうでしょうか。 144ページから引用します。 ここで望まれるのは、次に述べるような置換可能な性質である。 S型のオブジェクト o1 の各々に、対応するT型のオブジェクト o2が1つ存在し、Tを使って定義されたプログラムPに対して o2の代わりにo1を使ってもPの振る舞いが変わらない場合、 SはTの派生型であると言える。 Webで公開されている和訳では、確かに > 「サブタイプならば同じ振る舞いをすべきである」 と書かれているように読めるかもしれませんが、本当は > 「同じ振る舞いをするならサブタイプである」 と書かれているんです。Web の和訳のこの部分は誤訳に近いですね。 Webで公開されている文書であっても、原文の方で確認をすれば then S is a subtype of T. と書かれていますから、後者の意味であることは明らかなんですけどね。 > あるクラスと互換性のある属性と振る舞いを持つクラスは、そのクラスと何 > らかの関係があるクラスと見るべきです。 ここまでは合意します。 > 逆転させて言えば「関係の無いクラスに、互換性のある属性と振る舞いを持 > たせるべきではありません＝継承関係にすべきではありません＝LSP が成立 > してはいけません」となるのではないでしょうか。 違いますね。 「完全に互換性のある属性と振舞いを示すのであれば、それは一見関係ないよ うに見えても、実は関係があるのだ」というのが正解でしょう。 CES さんは、この考え方を、一貫して拒否されているようですが… > 小文字の is-a ってどこで使ってますか？　ひょっとして原文？ > 提示された日本語版には見当たらないのですが… ええと、小文字ではじまるのは「is-a」ではなく、「名詞」です。 また、ここで書いているのは原文の話です。日本語版を読んでいるだけでは、 何のことをさして書いているのか、分からないと思います。 > 俺は「LSP に照らすまでも無く、継承関係にしてはいけない場合がある」 > と言う。 これも繰り返しになりますが、「照らすまでもなく」のような暗黙の知識は、 法則としては役に立たないんですよ。だからこそ、明文化された LSP に 意味があるわけです。

>えーと、以前の言及には気づいていませんでした。 ちょっと検索してみました。 # この掲示板には検索機能はないですが、今のところ # http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&range=800 # とかやると過去の全発言が表示されるのでブラウザ内検索。 # もっと発言が増えてくると破綻しますが… そのうちガードをかけないと… 「一度や二度ではない」は言い過ぎだったようです。2回ですね。 このへんとか。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=372&range=1 >私はゲームプログラミングにはうといのですが、Javaで「継承やオー >バーライドやインタフェースやスレッドを知らなければならない」 >というのは、 > > * やろうとしていることが実は複雑である > * Javaの提供するモデルとやろうとしていることが合ってない いくらなんでもボールがマウスを追いかけるくらいが複雑だとは思えないので、 Javaに関して言えば、「Javaの提供するモデルとやろうとしていることが合ってない」 のだと思います。もちろんこれは用途次第で、ダイアログを使うビジネスアプリケーション ならJavaのモデルでよいわけです。 ただ、Javaの場合、もともとWebページの飾り付け用の言語として世間に投入された はずで、にもかかわらずこのモデルはどうよ? とは思います。これは言語ではなく ライブラリの問題ですけど。 また、Javaの場合、たかがhello, worldでも、classとかpublic static void mainとか System.outとかの謎の言葉が出てきます。これはライブラリでなく言語の問題でしょう。 これを見ておっかなく思う初心者はいるかもしれません。が、実は「決まり文句」と 思っておけば済むことかもしれませんし、クラスがあってもhello, worldを1行で 書ける言語は可能です(Rubyのように)。 たとえばクラスが難しいものだとしても、初心者にクラスが見えないのなら、 初心者向け言語からクラスを外す理由にはなりません。その点で、[731] のyuyaさんの 指摘は的を射ていると思います。 ということで、私もおおむね説得されているわけですが、 a)初心者だからといって入門書を最初から順番にやっていくだけとは限らない。 　雑誌に載っていたりネットに転がっているコードを読むこともあるだろう。 b)初心者だってライブラリは使うしマニュアルも読む。 ということは言ってよいと思います。Javaでhello, worldを書くとき、System.outは 決まり文句と思っていればよいかもしれませんが、これを決まり文句と思っている間は APIリファレンスが引けません。 また、C++だと入門書の最初のページでcoutとか使ってるかもしれませんが、 これをちゃんと理解するには演算子のオーバーロードを知らなきゃいけませんし、 ちょっとコレクションを使おうとするとSTLが出てきてtemplateを知らなくては いけなくなったりします。STLでなく(危険を承知で)Cの配列を使おうと決心したと しても、既存の、ゲームを作るのにすごく便利なライブラリが、引数にSTLの vectorを要求してたりして。 そういえば、話としてはずれますが、最初にCを勉強したときには (c = getchar()) != EOF がおっかなく見えたことを思い出しました。 >「削ることによってわかりやすくなる」という意見はよく聞きます >が、実際は「適切なモデル(or 機能)を提供することによってわか >りやすくなる」のであって、削ることだけが能じゃないと思います。 もちろん、なんでもかんでも削ればよいと思っているわけではないです。

>書き込みありがとうございます。正直、ちょっとびっくりです。 ># ていうかここでMatzにっきにリンクしたのは一度や二度ではないのですが、 ># この話題で書き込みいただけるのはびっくりというか。 えーと、以前の言及には気づいていませんでした。 >> * サンプルで扱おうとしている概念そのものが難しい >> * サンプルの作者が難しく表現してしまった >> >>のいずれかで、それを言語のせいにするのはどうかと思います。 > >たとえば、私が[719]で書いた「マウスを追いかけるボールのプログラム」には、 >初心者がおっかなく思う機能はそんなにないと思います。「サンプルで扱おうと >している概念そのものが難しい」わけではないのではないでしょうか。 >でも、同じことをJavaでやろうと思ったら、継承やオーバーライドやインタフェースや >スレッドを知らなければならないわけです。以下のページは、そういう意図で >書きました。 私はゲームプログラミングにはうといのですが、Javaで「継承やオー バーライドやインタフェースやスレッドを知らなければならない」 というのは、 * やろうとしていることが実は複雑である * Javaの提供するモデルとやろうとしていることが合ってない のいずれかなのではないのですか。だとすると、検討すべきことは 初心者におっかない機能を取り除くことではなく、もう一歩踏み出 して、やろうとしていることを簡潔に記述できる高レベルなものを 提供することではないでしょうか。それが文法なのかライブラリな のかは知りませんが。 >という意見が出ていますが、「とりあえずオブジェクト指向は要らんな。」 >「構造体も要らん。」「変数は全部グローバル。」という意見には賛同しないものの、 >初心者にとっておっかない機能を除きつつ、それなりに実用に使える「落としどころ」 >は、どこかにあるんじゃないかと私は思っているわけです。 「削ることによってわかりやすくなる」という意見はよく聞きます が、実際は「適切なモデル(or 機能)を提供することによってわか りやすくなる」のであって、削ることだけが能じゃないと思います。

>プレビュー画面で >「『投稿』ボタンをクリックすると、投稿されます。」 >と言いつつボタンが「送信」になってますね(^^;) 　修正しました。ついでに、前から気になっていた、「ちゃんと改行を入れたかどうかチェックしてください」という文言を削除しました。 　以前の仕様では、<pre>で囲んでいたので改行を入れないと困ったことになりましたが、今は<tt>で囲んでいるので、改行を入れる必要はなくなったためです。 # 引用しにくい気はしますが、画面幅が不明なとき、改行は入れない方がよいという # 面もあるので、今後はそのへんは投稿者にお任せしますです。

>であって、前橋さんが問題としている >(2)「初心者向きでない機能を使わないと初心者向けのサンプルが書けないこと」 うむむ。確かにそうですね。Javaで、ちょっとしたゲームを作るのが大変なのは 「初心者向きでない機能を使わないと初心者向けのサンプルが書けないこと」の方に 相当します。 私自身、考えがまだまとまっていないのですが、 「初心者向きでない機能があると、それは相当な高確率でプログラムに 　顔を出す。たとえその機能を使わずともプログラムが書けたとしても」 というのでなければ、初心者向きでない機能を言語から外す理由にはなりませんね。 問題はこの命題が真かどうかですが。初心者向きでない機能があるが、それを使わずとも 初心者が満足する程度のプログラムが書ける言語を仮定して、 a)初心者向けの本などのサンプルプログラムで、わざわざ初心者向きでない 　機能を使っているとしたら、その本の著者がアホ。 b)初心者がベーシックマガジンの投稿プログラムを解読しようとするケースはどうか。 　これだと、初心者向きでない機能が使われていることもありそう。 c)ライブラリとかで初心者向きでない機能が使われていて、それを知らないと 　重要なライブラリが使えない、とか。 b), c)みたいなケースもあるかなあ、とも思いますが… 現状のJavaScriptプログラマの大半は、たとえばクロージャを知らなくても 幸せにやってるわけで、確かにいらん心配のようにも思います。

>私のお勧めサイトというと、ここの参考URLですかねえ。 >http://kmaebashi.com/programmer/devlang/array.html ありがとうございます。 １回は既に読んでいたのですが、頭に入っていなかったので 何回も読み直してみます。 >あと、紙ものの資料では、大昔の情報処理学会誌に「ごみ集めの基礎と最近の動向」 >というのがあって、とてもよかったのですが、現在では入手不能だと思います。 >私はというと会社で該当の情報処理学会誌が捨てられる直前に気が付いて、 >コピーしておいたのですが、その後数回の引越しで現在行方不明です…だめだめ。 もったいないですね。でも今回の記事に生かせているのでは ないでしょうか。 >>以下の本を購入しようと思ったのですが、(ぱ)さんは読んだことありますか？ >> >>http://www.amazon.co.jp/exec/obidos/ASIN/0471941484/qid=1136566955/sr=1-1/ref=sr_1_10_1/250-0589622-2949018 > >すみません、読んでないです。 有名らしいのですが、読んでなかったのですね。 GCに関してあまり勉強せずにできているなんてすごいですね。 また、投稿します。ありがとうございました。

ひさしぶりに投稿してみて初めて気づいたんですが、 プレビュー画面で 「『投稿』ボタンをクリックすると、投稿されます。」 と言いつつボタンが「送信」になってますね(^^;) つまらんこと言ってすみません。

こんにちは。 まつもとさんが「あまり問題にならない」と書いているのは (1)「言語が初心者向きでない機能を持つこと」 であって、前橋さんが問題としている (2)「初心者向きでない機能を使わないと初心者向けのサンプルが書けないこと」 とは別なのではないでしょうか？ 私自身は(1)はまつもとさんと同様に「問題にならない」と思いますし、 (2)は前橋さんと同様に「そりゃ問題である」と思います。

書き込みありがとうございます。正直、ちょっとびっくりです。 # ていうかここでMatzにっきにリンクしたのは一度や二度ではないのですが、 # この話題で書き込みいただけるのはびっくりというか。 >>これにはいまいち賛同しかねるんですよねえ。サンプルで見かけるプログラムで >>「初心者向きでない機能」が使われていると、おっかなく思う初心者は大勢いそうです。 おっかなく思う初心者がいるから言語からその機能を抜くとすれば、以下の問題が 発生すると思います。 a)おっかなく思うような難しい概念を抜きにして、ゲームとかを作りたいと思う 　初心者が達成したい要件を実現できるかどうか。 b)おっかなく思うような難しい概念を抜きにして、上級者の要件を満たせるかどうか。 おっかない機能を抜いても、a), b)の両方を満たしているのであれば、文句なしだと 思います。そりゃ本当の上級者は別の言語を使ったほうが「よりよい」かもしれませんが、 そういう「よりよい」言語との間に十分な「のりしろ」があるなら、初心者も シームレスに移行できるのではないでしょうか。 >>こちらにある、「「初心者(だけ)のための言語」ってのは駄目だと思っている」 >>という意見にも賛成します。 これ↑に矛盾すると思われるかもしれませんけど、要は程度問題で、いずれツールの 移行を余儀なくされるとしても、その時の抵抗が少ないのであれば、許容されるのでは ないでしょうか。HSPやN88BASICはこのへんが… # と言いつつ、HSPやN88BASICで苦労した経験は、その後他の言語のありがたみを # 理解するのに有用かもしれない、とも思ったりもします。この苦労を知らずに # 大人になると、「グローバル変数が便利だったから、あちこちで使った。」に # なりかねないわけで。 > * サンプルで扱おうとしている概念そのものが難しい > * サンプルの作者が難しく表現してしまった > >のいずれかで、それを言語のせいにするのはどうかと思います。 たとえば、私が[719]で書いた「マウスを追いかけるボールのプログラム」には、 初心者がおっかなく思う機能はそんなにないと思います。「サンプルで扱おうと している概念そのものが難しい」わけではないのではないでしょうか。 でも、同じことをJavaでやろうと思ったら、継承やオーバーライドやインタフェースや スレッドを知らなければならないわけです。以下のページは、そういう意図で 書きました。 http://kmaebashi.com/zakki/zakki0027.html#lang イベントリスナを実現するために内部クラスや匿名クラスを使うのは 「サンプルの作者が難しく表現してしまった」のかもしれませんが、それ以外の点に ついては、Javaでは避けようがないでしょう。 >それに初心者がおっかなく思う危険のある機能を取り除いた言語っ >てのは、結局実務に役立たずで学ぶ価値のない言語になりそうです。 まつもとさんも、Cが「実務に役立たずで学ぶ価値のない言語」とは思いませんよね? 現状でCが難しいのは、実行時のチェックがないためとんでもないバグが出ることと、 宣言の構文やポインタと配列の妙な交換性にあると私は思っています。 前者は多少効率を犠牲にすれば回避できる話ですし、後者は単なる言語のバグです。 こういう点を改良したCもどきは作れると私は思っていて、crowbarは、ある意味 その実装のひとつのつもりです(型無しだったり、プロトタイプベースだったり、 クロージャがあったりするのはアレですが)。 こちらにも、 http://www.rubyist.net/~matz/20040925.html#c05 | 文字列型が違和感なく扱えて、便利そうな関数がもっと多くて（？）、引数が常に値渡しであるC言語最強、と思う。 という意見が出ていますが、「とりあえずオブジェクト指向は要らんな。」 「構造体も要らん。」「変数は全部グローバル。」という意見には賛同しないものの、 初心者にとっておっかない機能を除きつつ、それなりに実用に使える「落としどころ」 は、どこかにあるんじゃないかと私は思っているわけです。

>ただ、 >| 初心者と言えども言語の全ての機能を一度にマスターする必要はない。 >| よって言語が初心者向きでない機能を持つことは、あまり問題にならない。 > >これにはいまいち賛同しかねるんですよねえ。サンプルで見かけるプログラムで >「初心者向きでない機能」が使われていると、おっかなく思う初心者は大勢いそうです。 「おっかなく思う」かもしれませんが、その原因は * サンプルで扱おうとしている概念そのものが難しい * サンプルの作者が難しく表現してしまった のいずれかで、それを言語のせいにするのはどうかと思います。 それに初心者がおっかなく思う危険のある機能を取り除いた言語っ てのは、結局実務に役立たずで学ぶ価値のない言語になりそうです。

この人たちは、どんなソフトウェアかによらず適用できる、万能の分析手法でも求めているんだろうか… そんなものがありゃ誰も苦労しねぇっつうの。

>CESさんいわく > >>「is-a である関係が、LSP を満たすように作れ」と言っているのです。 > >それじゃあ「CESさん言うところのis-a」がLSPを満たすのは当たり前ですわな。 >そう定義したんだから。 「LSP を満たす関係が is-a である」とは言っていませんよ（そう言っているのは kit さんです）。 結果的にはそうなりますが、それは is-a の定義ではありません。 じゃあ is-a の定義は何なんだって話になりますが、言い換える言葉が見つかりませんね。is-a は is-a です。「Ａ is-a Ｂ」は「ＡはＢの一種」です。これがもっともシンプルかつ的確ではないですか。 以前に、ソフトウェアは「分析→設計→実装」の３段階で作られると言う話をしました。 俺の言う「is-a」の関係を決めるのは分析段階、LSP を満たすように作るのは設計段階の話です。 それで設計段階になって、LSP がどうしても満たせなくなったらどうするか？ LSP を捻じ曲げて is-a を固持しろなんていってません。分析からやり直すのです。 ちょっと古い投稿を引用すが… [658] > 設計を見直す＝分析のしなおし、だよん。って。 その通りではないですか。 あるプロジェクトに直面した時、「ＡはＢの一種である」とも「ＡはＢの一種ではない」とも、どちらの考え方もできます。 どちらが適切なのかを選ぶのが「分析」というプロセスですよ。 >我々は、設計段階で、どういう継承関係にすればうまくいくかを知りたい >ため、設計原則を求めているわけです。 そこで機械的に従えばいいガイドラインを求めるのは、分析プロセスの放棄ですよ。 >>１：オブジェクトが is-a であると仮定した。 >>２：LSP に照らし合わせたらうまく行かなかった。 >>　　（照らし合わせるまでも無く判断できる場合もある） >>３：実はオブジェクトは is-a じゃなかったんだ。だから継承関係にはしない。 > >こちらも同様です。is-aの定義が「うまくいくかどうか」で決定されるんなら、 >「うまくいくようにやりなさい」と言ってるだけのことで、結局何も言って >いないのです。 そうですよ。 「どうすればうまく行くのか」は、その場合に応じて変わるのですから、それ以外に言いようが無いではありませんか。 こんな記事見つけました（Wikipedia - 「継承」） http://ja.wikipedia.org/wiki/%E7%B6%99%E6%89%BF > 一般的に、AがBを継承する場合、A is a B. （AはBの一種である）という > 意味的な関係（is-a関係）が成り立つ。従って、同じふるまいを持つから > と言って、意味的に無関係なクラス間に継承関係を持たせるのは適切でない > 場合が多い。 だそうですよ。

あんまりkitさんに押し付けておくのも申し訳ないのでちょっとだけ書きますが。 >>ところが、CES さんは、「継承してうまく動くような関係が is-a である。 >>したがって、継承してうまく動くような関係に対して、継承を当てはめれ >>ば良い」と言ってるに過ぎないわけです。これは見て分かるようにトート >>ロジーに過ぎず、設計の指針としては、全く役に立たないわけです。 このkitさんの言葉がすべてだと思いますがね。 >違います。 >「どういう関係が is-a であるか」については言及していません。 だから、それが問題なんだってば。既に指摘されているじゃないですか。 [715] >なぜなら、CES さんは、is-a という関係が具体的にどうあるべきかを一切述べ >ていないからです。 CESさんいわく >「is-a である関係が、LSP を満たすように作れ」と言っているのです。 それじゃあ「CESさん言うところのis-a」がLSPを満たすのは当たり前ですわな。 そう定義したんだから。 >１：オブジェクトが is-a であると仮定した。 >２：LSP に照らし合わせたらうまく行かなかった。 >　　（照らし合わせるまでも無く判断できる場合もある） >３：実はオブジェクトは is-a じゃなかったんだ。だから継承関係にはしない。 こちらも同様です。is-aの定義が「うまくいくかどうか」で決定されるんなら、 「うまくいくようにやりなさい」と言ってるだけのことで、結局何も言って いないのです。

あといくつか、最初の方の書き込みに対するレス。 俺が「オブジェクトの is-a は LSP よりも優先されるべきだ」と言ったのは、「まずオブジェクトの is-a で判断し、次に LSP で判断すべきだ」という意味です。 その結果、最初に「is-a」とした判断が誤っていたというケースがあるのは既に言っています。 そのような場合でも、LSP を捻じ曲げて、断固、最初の「is-a」に固執すべきだと言った覚えはありません。 そして、まず「（常識的なオブジェクトの）is-a で判断する」のは、kit さんも同じであると [715] で書かれています。しかし、そう書かれたのはここが初めてです。 俺はてっきり「オブジェクトの is-a は問題にしなくていい。LSP だけで継承関係を判断すればいい」のだと思っていたのですが。 [713] では > なぜ、オブジェクト自身の is-a 関係が継承関係の設計に使えない > 場合があるのか、そのことを説明しているのが LSP です (ただし、 > 正方形や円のケースでは、LSP 以外にも、メモリ効率という別の理 > 由もあります)。継承関係の設計において、オブジェクト自身の > is-a 関係は使えない場合がある弱い判断基準なわけですが、LSP > は常に使える絶対的な判断基準なわけです。実はLSP(オブジェクト > の振舞いに関する is-a) の方が、オブジェクト自身のis-aよりも > むしろ本質的な原則なわけです。 と書かれています。 > オブジェクト自身の is-a 関係が継承関係の設計に使えない場合がある のは事実です。 しかし、そういう「場合がある」のであって、「常に使えない」とは書かれていません。 事実、[715] では > たとえば、「常識的に考えた is-a 関係に対して、継承を当てはめれば良 > い」というのは、正方形と長方形の例のようにうまくいかない例外もあり > ますが、かなり使える原則です。 と書かれています。「is-a の関係は使えないわけではない」のですね。 にも関わらず、[713] では「is-a は役に立たない。LSP こそ基準にすべきだ」と書かれているように見受けられます。 そう読んでしまうのは、俺の読解力不足ですか？ [715] を境に、そちらの主張が切り替わっているような気がするのですが。

要点抽出。 >議論が空転している気がするんです。整理しましょう。 >まず（常識的かどうかは置いておくとして）「オブジェクトの is-a」で大まかな関係を作るというのは、どちらも同じことを言ってますね。 >kit さんは、その上で「LSP に照らして破綻したら、継承関係にはしない」と言う。 >俺は「LSP に照らすまでも無く、継承関係にしてはいけない場合がある」と言う。 >結局、どの段階で、最初の「is-a」が間違えていたかを判断するのかが違うだけで、大差ないでしょう。 >問題は「LSP に照らさないと、間違いかどうか判断できないケースはあるのか」だと思うんですよ。 >そのへんどうです？ １：オブジェクトが is-a であると仮定した。 ２：LSP に照らし合わせたらうまくいった。 ３：継承関係を結んだ。 これに異論を差し挟む余地は無いでしょう。 問題は、そうでないケースですね。 kit さんの場合 １：オブジェクトが is-a であると仮定した。 ２：LSP に照らし合わせたらうまく行かなかった。 ３：オブジェクトは is-a なんだけど継承関係にはしない。 俺の場合 １：オブジェクトが is-a であると仮定した。 ２：LSP に照らし合わせたらうまく行かなかった。 　　（照らし合わせるまでも無く判断できる場合もある） ３：実はオブジェクトは is-a じゃなかったんだ。だから継承関係にはしない。 結局、違うのは、過程３の前半だけなんですよね。 だから、[712] ではこう書いているんです。 > is-a と LSP をどうしても両立させられない例を一つでも出していただけませんか。 俺の方法ではうまく行かないケース、つまり 「どこからどう見ても疑念を挟む余地無く is-a なんだけど、LSP に照らし合わせたらうまく行かないから、LSP を優先するケース」 があるのか、ということなんです。俺が度々言う「is-a と LSP が矛盾するケース」ってのはこういうことなんです。 「常識的な is-a と LSP が矛盾するケース」ではないですよ。「どこからどう見ても」ってのは、「あらゆる非常識な関係も考慮に入れて」ってことです。 こういう場合があると言えますか？ 俺は「あらゆる角度から見る」ことが不可能であるため、そのようなケースは存在しないと思うのですが。

>「is-a の意味は常識的なものとは限らない。場合によって、適切なもの >を選べ」というのは、実のところ、まったく意味のない言明です。なぜな >ら、CES さんは、is-a という関係が具体的にどうあるべきかを一切述べ >ていないからです。 どう言えばいいですかねぇ。 「クラスはオブジェクトの集合である」と考えた時、「ある集合Ａと、その部分集合Ｂがあったら、Ｂ is-a Ａである」でいいですか？ もっとも、「どのような基準に従ってオブジェクトを集合に分類するか」には、結局、唯一解がないのは同じことなんですが。 >我々は、設計段階で、どういう継承関係にすればうまくいくかを知りたい >ため、設計原則を求めているわけです。 そんな話は今初めて聞きましたがねぇ… >たとえば、「常識的に考えた is-a 関係に対して、継承を当てはめれば良 >い」というのは、正方形と長方形の例のようにうまくいかない例外もあり >ますが、かなり使える原則です。 それでいいと思いますよ。 我々の社会常識が「大多数にとって都合がいい見方」であるように「多くの場合に都合がいいケース」はあってもおかしくありません。 ただし、それがたまたま成り立たないからといって、それだけを槍玉に挙げないでいただきたい。 ちなみに、件の文献の、長方形と正方形の関係の誤りは、LSP を持ち出すまでも無く「間違いだ」と判断できるものです（まぁ、LSP を考えてみて判断しても構わないのですが。別にそれでも is-a と LSP の矛盾は指摘できませんから）。 オブジェクトの is-a よりも LSP を優先すべきだという根拠にはなりません。 >また、「LSPに従うオブジェクト同士に対して、継承を当てはめれば良い」 >というのは、常に利用可能な原則です。 >ところが、CES さんは、「継承してうまく動くような関係が is-a である。 >したがって、継承してうまく動くような関係に対して、継承を当てはめれ >ば良い」と言ってるに過ぎないわけです。これは見て分かるようにトート >ロジーに過ぎず、設計の指針としては、全く役に立たないわけです。 違います。 「どういう関係が is-a であるか」については言及していません。 「is-a である関係が、LSP を満たすように作れ」と言っているのです。 件の文献も言っているではありませんか。 > あるところで、何か、置き換えが必要なところがあるとする。 > 型Sのオブジェクトo1 と、型Tのオブジェクトo2があって、 > プログラムが既に型Tのオブジェクトを使うように構築されているとする。 > o1がo2で置き換えられても、SがTのサブタイプであるならば、 > Pは同じ振る舞いをするべきである。 「サブタイプならば同じ振る舞いをすべきである」と書かれています。 「同じ振る舞いをするならサブタイプである」とは書かれていません。 結局、この文献は「どんなものを継承関係にすべきか」という指針には、一言も言及していないのです（「どんなものを継承関係にしてはいけないか」は、LSP を用いて言及しています。しかし、それは LSP を用いなくても指摘可能であることは度々述べています）。 >> 全く同じ属性と振る舞いを持つクラスは、同じクラスだと考えるべきです。 >> これは、「LSP が成り立つならば is-a も成り立つ」と言い換えることもできます。 > >一つ目の文章は正しいと思います。 >しかし、一つ目の文章から二つ目の文章を導くことはできません。 突っ込まれるかなーと思っていました。 ちょっと拡大しましょう。 全く同じ属性と振る舞いを持つクラスは、同じクラスだと考えるべきです。 そして、あるクラスと互換性のある属性と振る舞いを持つクラスは、そのクラスと何らかの関係があるクラスと見るべきです。 逆転させて言えば「関係の無いクラスに、互換性のある属性と振る舞いを持たせるべきではありません＝継承関係にすべきではありません＝LSP が成立してはいけません」となるのではないでしょうか。 >なお、Martin 氏の文章を読み返してみて、私がこれまで説明で使って >用語法が、Martin 氏の用語法と異なっているのに気づきました。 >私がこれまで >1. オブジェクトの振舞いに関する is-a >2. オブジェクト自身に関する is-a >という二つの言葉で区別してきたことを、Martin 氏は >1. 振舞いの is-a == オブジェクト(CamelCase にした名詞)の is-a >2. 物(子文字で始まる名詞)の is-a >と呼んでいますね。 >まあ、独立に読んでいれば意味は通じると思いますが、併せて読むと >混乱するのであまり良くありませんね。どうも申し訳ない。 小文字の is-a ってどこで使ってますか？　ひょっとして原文？ 提示された日本語版には見当たらないのですが… >設計手順としては、まず常識的な is-a を使って継承関係を考えてみた >上で、それを LSP で検証すればいいんですよ。検証に通らない場合には、 >たとえ常識的なis-a 関係であっても、継承関係にはしません。検証に通 >れば、もちろん継承関係にします。 >簡単でしょう？ >本来無関係のオブジェクト同士うんぬんなどと悩む必要はありません。 議論が空転している気がするんです。整理しましょう。 まず（常識的かどうかは置いておくとして）「オブジェクトの is-a」で大まかな関係を作るというのは、どちらも同じことを言ってますね。 kit さんは、その上で「LSP に照らして破綻したら、継承関係にはしない」と言う。 俺は「LSP に照らすまでも無く、継承関係にしてはいけない場合がある」と言う。 結局、どの段階で、最初の「is-a」が間違えていたかを判断するのかが違うだけで、大差ないでしょう。 問題は「LSP に照らさないと、間違いかどうか判断できないケースはあるのか」だと思うんですよ。 そのへんどうです？ >なお、もし本来無関係だと思っていたオブジェクト同士にLSPが成り立つ >のであれば、実はそのオブジェクト同士は、たぶん無関係じゃないんですよ。 本当に無関係でないのなら構いませんが、「たぶん」というのはいただけません。 実のところ、「本当に無関係か」を判断することはできません。どうにかして関係を見出すことはできます。 しかし、その関係は、設計者の意図した関係で無い可能性が大きいでしょう。 そのような関係に、LSP を成り立たせることは、メリットがあるとは思えません。 >しかし、通常のソフトウェア開発で、そういう発見を必要とすることは >あまりありませんから、無関係だと思うオブジェクト同士について、 >いちいちLSPを検証してみる必要はありません。 LSP は「たまたま成り立っちゃう」ものではなくて「意図して成り立たせる」ものであると考えます。 であるならば、先のようなデメリットを考えた時に「意図して崩す」ことも、当然ありえる話です。 それをせず、「たまたま成り立っちゃう」のを放置しておくのは、バグの温床になりませんか。

>processingのmouseXの代わりに、get_mouse_x()という関数を用意しました。 get_mouse_x()も、ウインドウ内の座標を返すのですから、ウインドウごとにしないと まずいですね。このへん考えるべきことはいろいろありそうですが、まあ方向性として。 ついでに補足しますけど、私は、HSPに関しては「もう21世紀なのにこの言語はないだろう」 というまつもとゆきひろさんの意見に賛成します。 http://www.rubyist.net/~matz/20040827.html#p01 こちらにある、「「初心者(だけ)のための言語」ってのは駄目だと思っている」 という意見にも賛成します。 http://www.rubyist.net/~matz/20040925.html#p02 ただ、 | 初心者と言えども言語の全ての機能を一度にマスターする必要はない。 | よって言語が初心者向きでない機能を持つことは、あまり問題にならない。 これにはいまいち賛同しかねるんですよねえ。サンプルで見かけるプログラムで 「初心者向きでない機能」が使われていると、おっかなく思う初心者は大勢いそうです。 crowbarはどうでしょうか。クロージャは、[717]を見るとわかるように、言語の作者の 私でさえ使いこなせていない。とほほほほ。 しかし、それはそれとして、オブジェクトの概念自体は必要だと思うし、初心者に わからないものでもないと思います。 w = open_window(800, 500); と書いてウインドウが開くのなら、そしてopen_window()を実行するたびに 何個でもウインドウが開けるのなら、そのウインドウに丸を描くのに w.fill_circle(x, y, 10); と書かなければならないのは、いくら相手が初心者でも、自明じゃないのかなあ。 別にfill_circle(w, x, y, 10); でもいいけど。 んで、シューティングゲームを作るのに敵をたくさん出したければ、自分でクラスっぽい ものを作らざるを得ないし、そのmove()メソッドをオーバーライドすることで、 ポリモルフィズムも自然に利用できるんじゃないかと思うんですけど、どうでしょうか。

> if (get_mouse_x() < x) { > x++; あ、条件式逆だった…

>てなことを書かれておられましたが、Processing(http://processing.org/)はどう >でしょうか？ 情報ありがとうございます。ちょっと見てみました。 ExamplesのStructureを一通り見ただけですが、 ・やっぱりイベントドリブンなのか。(mouseXという謎の変数が出てきてますが) ・ウインドウをふたつ開くことはできるのか? あたりが感想(と疑問)です。イベントドリブンは、処理が分断されるので、 ゲームとかを作りたい人にはわかりにくいのではないか、と私は思っています。 >これは、言語はJavaそのものですが、IDEによって、クラス定義などの >初心者にとって面倒そうな部分をうまく隠蔽してあって、単なる手続き型言語のように >使えます。これなら初心者にとっても比較的とっつきやすいんじゃないかと思います。 うーん。とっつきやすいかとは思いますが、結構用途が限定された言語にも見えます。 draw()は言語仕様に組み込まれているんでしょうか? たとえば現在私が作っているcrowbarをベースに、ライブラリ関数を追加して、 以下のようなプログラムは作れるようになるのではないでしょうか。 processingのmouseXの代わりに、get_mouse_x()という関数を用意しました。 # マウスを追いかけるボールのプログラム。 w = open_window(800, 500); # 引数はウインドウのサイズ x = 0; y = 0; prev_x = x; prev_y = y; for (;;) { # 直前のボールの消去 w.set_color(BLACK); w.fill_circle(prev_x, prev_y, 10); # 中心のx, y, 半径 if (get_mouse_x() < x) { x++; } elsif (get_mouse_x() > x) { x--; } elsif (get_mouse_y() < y) { y++; } elsif (get_mouse_y() > y) { y--; } w.set_color(WHITE); w.fill_circle(x, y, 10); prev_x = x; prev_y = y; wait(100); # 100msec待ちつつイベントを拾う。最後のイベントで上書き。 } 私が件の雑記で書きたかったのは、「ベーシックマガジン向けプログラミング言語」が あったらいいなあ、ということなんですけど、これぐらい書けたら、汎用性を保ちつつ、 それなりに達成してないでしょうかね? もちろん、fill_circle()だけでなく、 イメージを指定された場所に表示する関数とかも必要ですけれど。 wait()あたりの一等地の名前を使うことについては、名前空間で対処するとして。 でも、processingは、Javaアプレットとして実行できるのはいいと思います。 ゲーム作ったらやっぱり友達に自慢したいと思うので。

>ご教授ありがとうございます。 >GCに少し興味を持ったのですが、お勧めのサイトなどありますか？ 私のお勧めサイトというと、ここの参考URLですかねえ。 http://kmaebashi.com/programmer/devlang/array.html あと、紙ものの資料では、大昔の情報処理学会誌に「ごみ集めの基礎と最近の動向」 というのがあって、とてもよかったのですが、現在では入手不能だと思います。 私はというと会社で該当の情報処理学会誌が捨てられる直前に気が付いて、 コピーしておいたのですが、その後数回の引越しで現在行方不明です…だめだめ。 >以下の本を購入しようと思ったのですが、(ぱ)さんは読んだことありますか？ > >http://www.amazon.co.jp/exec/obidos/ASIN/0471941484/qid=1136566955/sr=1-1/ref=sr_1_10_1/250-0589622-2949018 すみません、読んでないです。

土曜はとあるイベントにて大阪で飲んだくれておりまして、ずいぶん返事が遅くなりまして すみません。 それプラス、私自身、クロージャに慣れておらず継続もわかっておらず、今回のNykRさんの サンプルはずいぶん荷が重いものでした。とはいえ放り出していては勉強にならんので、 私なりに解釈してみました。間違い等ありましたらご指摘ください。 さて、単に木をイテレートするだけなら、 tree.each(closure(item) { # このitemについてなんかする }); という形のeachメソッドをツリーに装備するのは簡単で、ツリーの中で再帰して、 要素ごとに、渡されたクロージャを呼び出せばよいのですが、こういう形式(内部イテレータ) だと、あるツリーについて、「ここまで走査した」という状態を保存しておけないのが 問題になるわけですよね。その点、NykRさんの提示されたイテレータでは、こういう 書き方も許される。 # ふたつのイテレータでツリーを並列に走査する。 for (ite1 = iterator_GoF(foreachTree_CPS(tr)), ite2 = iterator_GoF(foreachTree_CPS(tr)); !ite1.isDone() && !ite2.isDone(); ite1.next(), ite2.next()) { print(" " + ite1.currentItem()); print(" " + ite2.currentItem()); } これができるのが外部イテレータの強みです。 Cなどで、再帰を使ってツリーを辿る場合、「ここまで走査した」という情報がスタック上に ありますから、スタックが1本しかない以上、ふたつのイテレータを並行して使うことは できないわけです(片方が片方の繰り返しに完全に含まれるなら可能)。 tr = {13,{5,{3,{},{}},{13,{12,{},{}},{}}},{16,{16,{15,{},{}},{}},{17,{},{}}}}; この例では、nodeの[0]にそのノードの値が、[1]に左の子が、[2]に右の子が 入っていますから、再帰で間順で走査するなら以下のようになります。 function internalIterate(node) { if (node.size() == 0) { } else { internalIterate(node[1]); # ...(a) print(" " + node[0]); # とりあえず表示しておく internalIterate(node[2]); } } (a)の箇所で左の子について再帰呼び出しを行い、それが戻ってきてから続きの処理を やっています。「戻ってきてから続きの処理をやる」ことができるのが再帰の嬉しい ところですが、それを期待していては、外部イテレータは作れない。 そこで、「戻ってきてから続きの処理をする」のではなく、「戻ってきてから やってほしい続きの処理をクロージャとして渡す」とすれば、関数から戻ってこなくても よくなる。その変換をしたのがこれ。 function internalIterate(node, cont) { if (node.size() == 0) { cont(); } else { internalIterate(node[1], closure () { # 続きをクロージャで渡す。 print(" " + node[0]); internalIterate(node[2], cont); }); } } # 第2引数には「処理の続きを渡す」のだから、最後に「おしまい」と表示される。 internalIterate(tr, closure() {print("おしまい");}); さて、この状態では、要素ごとに行う処理がprint()に固定されていますから 汎用性がありません。では引数でなにか関数を渡せば、とこうしても、 internalIterate(node[1], closure () { # 続きをクロージャで渡す。 proc(node[0]); # 処理を引数procで渡す internalIterate(node[2], cont); }); これでは内部イテレータと同じですから意味がありません。 そこで、このproc()にも、続きの処理をクロージャで渡してやることにします。 function foreachTree_CPS(proc) { return closure internalIterate(node, cont) { if (node.size() == 0) { cont(); } else { internalIterate(node[1], closure () { proc(node[0], closure() { internalIterate(node[2], cont); }); }); } }; } 外部イテレータの場合、このprocの第2引数をnext()の際に呼び出せばよいわけですね。 なぜならそれが「処理の続き」だから。 イテレータはこうなります。 function iterator_GoF(foreach_CPS, collection) { this = new_object(); this.first = closure () { this.isDone = closure () { return false; }; foreach_CPS(closure (item, cont) { this.currentItem = closure () { return item; }; this.next = closure () { cont(); }; })(collection, closure(){ # ..(b) this.isDone = closure () { return true; }; }); }; this.first(); return this; } イテレータのfirst()が呼び出されたときに、foreach_CPS()を呼び出して、 internalIetrate()を取得し、それに対しcollectionとクロージャを渡しています(b)。 これがつまり元のソースの internalIterate(tr, closure() {print("おしまい");}); に相当するわけですが、「おしまい」と表示する代わりに、isDoneについて、 trueを返すよう関数を差し替えています。 んで、internalIterate()に渡しているproc()では、 this.currentItem = closure () { return item; }; this.next = closure () { cont(); }; currentItemを設定後、nextに対し、contすなわち「処理の続き」をセットしています。 これで、次に利用者がnext()を呼び出したとき、internalIteratorの続きが実行される、と。 NykRさんのソースとは微妙に変わっていますが、こんな解釈でよいでしょうか? # いやあ、実に勉強になりました。

こんにちは。 大分前の雑記「プログラミングの入門用言語(2003/5/1)」の最後の方で、 > C, Javaライクな文法で、こういう方向性の言語って、現在あるんでしょうか。 てなことを書かれておられましたが、Processing(http://processing.org/)はどう でしょうか？これは、言語はJavaそのものですが、IDEによって、クラス定義などの 初心者にとって面倒そうな部分をうまく隠蔽してあって、単なる手続き型言語のように 使えます。これなら初心者にとっても比較的とっつきやすいんじゃないかと思います。

> 唯一の正解は無いでしょう。場合によって、適切なものを選べば、それ > が正解です。 これが CES さんのやり方の問題なんです。 「is-a の意味は常識的なものとは限らない。場合によって、適切なもの を選べ」というのは、実のところ、まったく意味のない言明です。なぜな ら、CES さんは、is-a という関係が具体的にどうあるべきかを一切述べ ていないからです。 我々は、設計段階で、どういう継承関係にすればうまくいくかを知りたい ため、設計原則を求めているわけです。 たとえば、「常識的に考えた is-a 関係に対して、継承を当てはめれば良 い」というのは、正方形と長方形の例のようにうまくいかない例外もあり ますが、かなり使える原則です。 また、「LSPに従うオブジェクト同士に対して、継承を当てはめれば良い」 というのは、常に利用可能な原則です。 ところが、CES さんは、「継承してうまく動くような関係が is-a である。 したがって、継承してうまく動くような関係に対して、継承を当てはめれ ば良い」と言ってるに過ぎないわけです。これは見て分かるようにトート ロジーに過ぎず、設計の指針としては、全く役に立たないわけです。 結局、CES さんの主張は、LSP どころか、(常にうまくとは限らない)常識的 な is-a 関係による継承関係の設計よりも、さらに劣るものにしか見えません。 また、CES さんは下記のように書いていますが、これはそもそも意味不明です。 > 全く同じ属性と振る舞いを持つクラスは、同じクラスだと考えるべきです。 > これは、「LSP が成り立つならば is-a も成り立つ」と言い換えることもできます。 この二つの文章のうち、一つ目の文章は、クラスとクラスの等価関係に 関する文章です。 二つ目の文章は、クラスとクラスの包含関係に関する文章です。 等価関係に関する文章と、包含関係に関する文章が、同一の意味である という発想は、まったくもって非論理的だと私は思います。 なぜ、この二つの文章が等価だと発想されたのか、残念ながら、私には 理解できません。 一つ目の文章は正しいと思います。 しかし、一つ目の文章から二つ目の文章を導くことはできません。 なお、Martin 氏の文章を読み返してみて、私がこれまで説明で使って 用語法が、Martin 氏の用語法と異なっているのに気づきました。 私がこれまで 1. オブジェクトの振舞いに関する is-a 2. オブジェクト自身に関する is-a という二つの言葉で区別してきたことを、Martin 氏は 1. 振舞いの is-a == オブジェクト(CamelCase にした名詞)の is-a 2. 物(子文字で始まる名詞)の is-a と呼んでいますね。 まあ、独立に読んでいれば意味は通じると思いますが、併せて読むと 混乱するのであまり良くありませんね。どうも申し訳ない。 > オブジェクト指向の第一目的は「わかりやすくすること」であると（今 > は）思っています > 本来、無関係のオブジェクト同士を継承関係にするのがわかりやすいで > すか？ 私が欲しいのは良い設計指針であって、オブジェクト指向の第一目的は 何かという問いの答は実はどうでもいいんですが(なぜなら、人によって 答がそれぞれ違うので、そんなことの統一見解を決めても実益がないから です)、それは置いておいて、かなり誤解されていると思います。 設計手順としては、まず常識的な is-a を使って継承関係を考えてみた 上で、それを LSP で検証すればいいんですよ。検証に通らない場合には、 たとえ常識的なis-a 関係であっても、継承関係にはしません。検証に通 れば、もちろん継承関係にします。 簡単でしょう？ 本来無関係のオブジェクト同士うんぬんなどと悩む必要はありません。 なお、もし本来無関係だと思っていたオブジェクト同士にLSPが成り立つ のであれば、実はそのオブジェクト同士は、たぶん無関係じゃないんですよ。 しかし、通常のソフトウェア開発で、そういう発見を必要とすることは あまりありませんから、無関係だと思うオブジェクト同士について、 いちいちLSPを検証してみる必要はありません。

>> 正方形は長方形のサブクラスであるとしても成り立つ場合は既に >> 書きました。is-a と LSP をどうしても両立させられない例を一 >> つでも出していただけませんか。 > >CES さんご自身が、正方形を長方形のサブクラスに『しない』方が >いい場合があると、[709]で認めているじゃないですか。常識的に >は、正方形 is-a 長方形ですから、当然、正方形は長方形のサブク >ラスとして継承関係を結ぶべきですし、Robert C. Martin 氏のエッ >セイでも、その方法をまず勧めています。しかし、そうしない方が >いい場合もあるわけですから、オブジェクト自身の is-a は必ずし >も判断基準に使えません。 俺はそういうことを言っているのではありません。 LSP なんか関係なく、「正方形 is a 長方形にならない場合もある」ということです。 その場合は、正方形が長方形でないのは何ら問題ではないのですから、「is a と LSP が矛盾する」とは言えません。 「常識的には」と書かれていますが、それが間違いの元です。 世の中に客観的な視点など存在しないというのは以前に書きました。 正方形 is a 長方形というのは、客観的に見えますが、「数学的に都合がいい見方」に過ぎません。常識と言うのも、大多数に都合がいい見方に過ぎません。真理ではないのです。 件の文献の勘違いは「長方形」の定義が曖昧なことです。 「正方形 is a 長方形」は数学に都合がいい見方、「縦と横の長さが独立していなければならない」は、このプログラムに都合がいい見方であって、数学に都合がいい見方ではない。 どちらの見方が間違いというのではありません。どちらも場合によっては正解なのですが、その「場合」が統一されていないのが間違いなのです。 このプログラムが「長方形」に何を期待しているのかが明確になっていないのがいけないのです。 大本の問題は、何のためのプログラムなのかを明確にしないまま、コードだけ示して煙に巻こうとしたことですね。 仮に、「常識的に考えて、正方形 is a 長方形なのだから、当然サブクラスにすべきだ」というのが正しいとして、では「りんご」は何のサブクラスにすべきですか？ 常識的に考えて「果物」のサブクラス？　それとも「バラ科の植物」？　スーパーマーケットのシステム開発だったら「商品」のサブクラスにすべきではないですか？ 唯一の正解は無いでしょう。場合によって、適切なものを選べば、それが正解です。 「正方形 is not a 長方形」にすべき場合は確かにあるでしょう。 それは、LSP に都合が悪いからそうなったのではなく、作りたいソフトの目的に合致しないからそうなったのです。 「is-a は LSP と両立できなかったので泣く泣く諦めた」のではなく「そもそも両立する必要が無かった」のです。 現在は is-a が推奨されています。百歩譲って has-a もまぁ認めるとしましょう。 問題は、「LSP さえ成り立つのなら、まったく無関係のクラス同士を継承関係にしていいのか」ということです。 （どういう設計になるのか知りませんが）LSP が成り立つのなら、車を鳥のサブクラスにするのもアリなのですか？ オブジェクト指向の第一目的は「わかりやすくすること」であると（今は）思っています（以前、この掲示板に長期滞在したときは「バグを減らすこと」だと思っていました。考えは変わる可能性があります）。 本来、無関係のオブジェクト同士を継承関係にするのがわかりやすいですか？ >> よろしければ、おすすめの本を紹介していただけないでしょうか。 > >今回紹介したエッセイ自身を含んだ、Robert C. Martin 氏の >「アジャイルソフトウェア開発の奥義」はいかがでしょう？ >http://hamasyou.com/archives/System/aeeoeeueaconoeoeass.php >http://hamasyou.com/archives/System/aeeoeeueaoeeoeaass.php >に長めの紹介があります。 持ってますけど読んでませんでした。 OCP や LSP の評判を聞いて買ったのですが、買ったきりで。 そのうち読むことにしましょう。 こちらにも一点、考え直したことがあったので、最後にそれについて言及します。 オブジェクト指向において、オブジェクトを特徴付けるものは、属性と振る舞いです（プロパティとメソッドとか、メンバ変数とメンバ関数とか、言語によって呼び方はいろいろあるでしょうが）。 つまり、全く同じ属性と振る舞いを持つクラスは、同じクラスだと考えるべきです。 これは、「LSP が成り立つならば is-a も成り立つ」と言い換えることもできます。 しかし、逆に言えば「違うクラスに、全く同じ属性と振る舞いを持たせるべきではない」「関係の無いクラスに、LSP を成り立たせるべきではない」とも言えます。 そう考えれば、「is-a が成り立つのならば LSP が成り立つのは当然」「is-a が成り立たないのならば、LSP も成り立たせるべきではない」のではないでしょうか。

> 俺がプログラミングを初めてまだ７年、オブジェクト指向が分かっ > てきたのはここ１、２年ほどのことですのでね。 意外と長いんですね。 私はプログラミング歴は24年ぐらい、オブジェクト指向に関しては プログラミング言語C++第1版の和訳や、Smalltalk-80のオレンジブッ クの和訳が出た頃からですから、20年弱くらいですかね。 その前に、先輩から米国byte誌のSmalltalk-80特集号を見せてもらっ たこともありましたが。 > 正方形は長方形のサブクラスであるとしても成り立つ場合は既に > 書きました。is-a と LSP をどうしても両立させられない例を一 > つでも出していただけませんか。 CES さんご自身が、正方形を長方形のサブクラスに『しない』方が いい場合があると、[709]で認めているじゃないですか。常識的に は、正方形 is-a 長方形ですから、当然、正方形は長方形のサブク ラスとして継承関係を結ぶべきですし、Robert C. Martin 氏のエッ セイでも、その方法をまず勧めています。しかし、そうしない方が いい場合もあるわけですから、オブジェクト自身の is-a は必ずし も判断基準に使えません。Robert C. Martin 氏が、エッセイの 「本当の問題」「何が悪いのか?」「Design By Contract」のとこ ろで説明しているのは、そういうことです。オブジェクト自身の is-a で考えるのは誤りであり、オブジェクトの振舞いに関する is-a で考えないといけないのです。前に出た円と楕円の話も同じ です。 このあたりは、和訳を読むよりも、原文 http://www.objectmentor.com/resources/articles/lsp.pdf の "What Went Wrong" のところを読んだ方が、むしろ理解しやす いかもしれません、「a Square object is definitely not a Rectangle object.」と書いてありますから。和訳の「決定的な違 いがあるのです。」という表現では、残念ながら、ここの is-a と is-not-a のニュアンスが消えてしまっています。私は原文の方を 先に読んだので、ここのところが非常に強く印象に残りました。 なぜ、オブジェクト自身の is-a 関係が継承関係の設計に使えない 場合があるのか、そのことを説明しているのが LSP です (ただし、 正方形や円のケースでは、LSP 以外にも、メモリ効率という別の理 由もあります)。継承関係の設計において、オブジェクト自身の is-a 関係は使えない場合がある弱い判断基準なわけですが、LSP は常に使える絶対的な判断基準なわけです。実はLSP(オブジェクト の振舞いに関する is-a) の方が、オブジェクト自身のis-aよりも むしろ本質的な原則なわけです。 現在では、has-a の関係は、継承よりも委譲を使うのが良い解だと されていますが、昔は has-a でも継承を使うことが良くありまし た。今でもたまにそういうプログラムを見ることがあると思います。 これも、アプリケーションを限定すれば、has-a で LSP を満たす 場合があることから来ているわけです。has-a で継承して問題のな いアプリケーションは、オブジェクト自身の is-a 関係で継承して 問題のないアプリケーションよりも、はるかに少ないので廃れてき ているわけですが。 has-a が廃れてきているのに is-a がそうではないのは、オブジェ クト自身についてis-a の関係が成り立つ場合のほとんど(ただし全 てではない)で、同時に、オブジェクトの振舞いに関する is-a 関 係(すなわちLSP)も満たすからです。 > よろしければ、おすすめの本を紹介していただけないでしょうか。 今回紹介したエッセイ自身を含んだ、Robert C. Martin 氏の 「アジャイルソフトウェア開発の奥義」はいかがでしょう？ http://hamasyou.com/archives/System/aeeoeeueaconoeoeass.php http://hamasyou.com/archives/System/aeeoeeueaoeeoeaass.php に長めの紹介があります。 ただ、和訳だと上述したように、ニュアンスが失われる部分はある でしょうね。また、data中心でモデリングした結果の扱いについて は、この本の主張に異論がある場合もあるでしょう。この本では常 にOOAを優先すべしという方向ですが、data中心でモデリングした 結果の方を優先した方がいい場合もある筈です。 私は、Robert C. Martin 氏自身の名前は、亡くなられた石井勝さ んのページで知りました。 http://www.objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-principles.html 石井さんがこのページを書かれたのは1999年ですね。 今ではLSPは有名な原則ですが、これが広まったのは Liskov 氏自 身の功績というよりは、Robert C. Martin 氏の功績の方が大きい と思います。私がこの法則を知ったのも今回のエッセイを読んだ からですし、google で The Liskov Substitution Principle を 検索して最初に出てくるのも、このエッセイですし。

>もちろん、「オブジェクトが is-a であるか」と「オブジェクトの『振舞い』 >が is-a であるか」の二つが矛盾しない場合は問題ありません。しかし、矛盾 >した場合に優先すべきなのは、LSP の方です。 >しかしどうやら CES さんは、矛盾した場合、LSP よりも前者を優先すべきだ >とお考えのようですね。 どちらかと言えばそうかもしれません。 LSP を守ることも重要ですが、まずはオブジェクトの is-a を優先し、その上で LSP が守られるように都合をつけるべきだと思います（結果的には、両方守るべきです）。 >Robert C. Martin がこの文書を発表してから、もう10年近く、Liskov から >数えれば、もう15年以上経っており、私は既に常識的な知識だと思っていまし >たが、驚かれたということは、どうやらそうではなかったようですね。 俺がプログラミングを初めてまだ７年、オブジェクト指向が分かってきたのはここ１、２年ほどのことですのでね。 >そもそも LSP や、この文書が有名になったのは、「オブジェクトが is-a である >か」という判定条件が成り立たない場合があるということを、はっきりと示 >しているからだと思うのですが。 >is-a だけで済むのであれば、わざわざ原則として掲げる必要も、文書で解説 >する必要もありません。 >失礼ながら、御自身の考えを他人の掲示版で開陳されるよりも先に、もう少し >オブジェクト指向関係の良書で勉強された方が良いのではないでしょうか。 よろしければ、おすすめの本を紹介していただけないでしょうか。 >少なくともこれまでのところ、私は CES さんの意見に説得される可能性は >ありません。CES さんの考えを証明する具体的な例を一切目にしていません >ので。前の投稿でも書きましたが、私は机上の空論は嫌いですし、具体的な >例のない議論に説得されることは決してありません。 >(ぱ)さんも同様ではないかと思います。 その言葉はそっくりお返しします。 正方形は長方形のサブクラスであるとしても成り立つ場合は既に書きました。 is-a と LSP をどうしても両立させられない例を一つでも出していただけませんか。

> いや恐れ入った。 > 「オブジェクトが is-a であるか」は守られなくてもいいのか。 その通りです。 もちろん、「オブジェクトが is-a であるか」と「オブジェクトの『振舞い』 が is-a であるか」の二つが矛盾しない場合は問題ありません。しかし、矛盾 した場合に優先すべきなのは、LSP の方です。 しかしどうやら CES さんは、矛盾した場合、LSP よりも前者を優先すべきだ とお考えのようですね。 Robert C. Martin がこの文書を発表してから、もう10年近く、Liskov から 数えれば、もう15年以上経っており、私は既に常識的な知識だと思っていまし たが、驚かれたということは、どうやらそうではなかったようですね。そも そも LSP や、この文書が有名になったのは、「オブジェクトが is-a である か」という判定条件が成り立たない場合があるということを、はっきりと示 しているからだと思うのですが。 is-a だけで済むのであれば、わざわざ原則として掲げる必要も、文書で解説 する必要もありません。 失礼ながら、御自身の考えを他人の掲示版で開陳されるよりも先に、もう少し オブジェクト指向関係の良書で勉強された方が良いのではないでしょうか。 あるいは、もし、「オブジェクトが is-a であるか」は LSP よりも優先する という考えをどうしても主張されたいのであれば、掲示版はそもそも不向きな メディアだと思います。 なぜ LSP よりも優先するのかを、適切な例を含めた上で、ご自分の Web ペー ジで解説された方が良いと思いますよ。 もし、Barbara Liskov や Robert C. Martin も優れた考えであるのなら、 独立した文書として公開する価値が十分あると思います。 少なくともこれまでのところ、私は CES さんの意見に説得される可能性は ありません。CES さんの考えを証明する具体的な例を一切目にしていません ので。前の投稿でも書きましたが、私は机上の空論は嫌いですし、具体的な 例のない議論に説得されることは決してありません。 (ぱ)さんも同様ではないかと思います。 > 「正方形は長方形のサブクラスであるか？」という質問に、唯一の正解はあり > ません。答えは、数学に厳密である必要がある場合には YES 、そうでない場 > 合には NO になります。 あるアプリケーションが、Robert C. Martin が例に示しているような 条件と、数学的に厳密であるという必要があるという条件のどちらも 同時に満たしている必要がある場合はどうすれば良いのでしょうか？ もちろん、答えは NO です。 従って、上に書いた CES さんの答え「数学に厳密である必要がある 場合には YES」は、条件に抜けがある誤った答であるということに なります。 私には、CES さんが LSP の本質を理解していないように見えますね。 理解しているなら、上のような文章が出てくる筈はありません。

＃ちょっと落ち着いて整理しましょう… >だったら最初からそう書けばいいのに。 >つか、それを読み取れというのは無茶と言うものです。 これは、（お互いに）「自分ではそう言ったつもりだったけど、相手には伝わらなかった」ということで傷み分けにしましょうや。 >私が最初から言っているのは、 > >「クラスを辞書で引いて分類と書いてあるからといって、プログラムの設計の際に、 >クラスを分類として捉えることが正しいことになるわけではない」 > >ということです。 なるほど。 俺は「辞書的用語」と「術語」の問題（あくまで用語の問題で、実際の設計はまた別問題）だと思っていました。 前橋さんは「どう呼ぶか」よりも「実際にどう設計するか」を問題視されていた。そこが齟齬の原因。 ちなみに、それに関する俺の答えは [706] > もちろん、実装の都合上、必ずしもそうとは言えないクラスが出てくることはあり得るでしょう。しかし、それらは例外として考えるべきであり、基礎としては無駄ではありません です。一言で言えば「（例外はあるかもしれないが）原則的に、辞書的意味と同じと考えていい」ということ。 後半は感情的になって煽ってしまったことはお詫びいたします。 ＃最後の最後で何とかまとまってよかった。

> リンク先の文章で示されている「正方形を長方形のサブクラスにするのが誤り」という話が的外れであることは、ずいぶん前に書いてますよ。 と言うだけでは何なのでちょっと補足。 「正方形は長方形のサブクラスである」というのは、数学的に見れば、確かにそうです。 しかし、長方形の数学的な性質とは、「４つの角が全て直角である四角形」というだけであって「縦と横の長さが独立していなければならない」という要件はありません。 リンク先の文章では、その数学的には必要とされていない要件を要求しているのですから、もはや「数学的には正方形は長方形のサブクラスだ」という前提は成り立たないのです。 では、正方形クラスを長方形クラスのサブクラスとして設計するのは誤りなのでしょうか？　そうとは限りません。 数学的に正しいプログラムを書く必要があって、長方形の縦と横の長さが独立していなければならないという要件が無いのなら、この設計は全く妥当なものです。 「正方形は長方形のサブクラスであるか？」という質問に、唯一の正解はありません。 答えは、数学に厳密である必要がある場合には YES 、そうでない場合には NO になります。 提示された文章では、それがちぐはぐだからおかしなことになっているのです。 [653] あたりで言っているのはそういうことです。

>> 「サブクラスの方が機能が上」という考え方だと、is-a の関係を考えた時 >> に「機能が豊富なものは機能がショボいものの一種」ということになって変 >> だよね。 > >変じゃないですよ？ >Robert C. Martin が、Liskovの置換原則に関する有名な文書 >http://www2.ocn.ne.jp/~yamagu/object/LSP-J.pdf >で述べた通り、継承の際に使う is-a の関係は、「オブジェクトが is-a で >あるか」ではなく、「オブジェクトの『振舞い』が is-a であるか」で判断 >すべきです。 >「機能が豊富なものは機能がショボいものの一種」というのは、この原則を >平易な言葉で言い替えたものに過ぎません。 >オブジェクト指向設計の大原則です。 いや恐れ入った。 「オブジェクトが is-a であるか」は守られなくてもいいのか。 LSP を守るべきであるのは当然だけど、リンク先の文章で示されている「正方形を長方形のサブクラスにするのが誤り」という話が的外れであることは、ずいぶん前に書いてますよ。

抽象論は苦手なので、このスレッドには書かないようにしようと思ってたの ですが、堂々めぐりしているように見えるので。 > 「サブクラスの方が機能が上」という考え方だと、is-a の関係を考えた時 > に「機能が豊富なものは機能がショボいものの一種」ということになって変 > だよね。 変じゃないですよ？ Robert C. Martin が、Liskovの置換原則に関する有名な文書 http://www2.ocn.ne.jp/~yamagu/object/LSP-J.pdf で述べた通り、継承の際に使う is-a の関係は、「オブジェクトが is-a で あるか」ではなく、「オブジェクトの『振舞い』が is-a であるか」で判断 すべきです。 「機能が豊富なものは機能がショボいものの一種」というのは、この原則を 平易な言葉で言い替えたものに過ぎません。 オブジェクト指向設計の大原則です。 > 集合論（というか論理学のベン図）で考えれば、スーパークラスはサブクラ > スよりも一段階抽象的なので、直接比較できないことはわかるよね。 これは、「オブジェクトが is-a であるか」を継承関係の設計の判断基準に 使うべきだと述べているように見えます。これは、第一近似として使いやすい 方法ではありますが、Robert C. Martin の文書で示されている通り、厳密に 考えると誤りであり、Liskovの置換原則の方を優先すべきです。

>>「術語としてのクラス」に「辞書的な『分類』という意味」を期待する > >ことについてとやかく言った覚えはありません。 >いや、とやかく言っている、というのならその部分を引用して示してください。 このへん＠684 > でも、「クラス」という言葉の辞書的定義が「分類」だったからといって、 > 術語として使われるときそのままの意味とは限らないし、「クラス」という > 言葉を選んだ人が間違えたのかもしれない。だから、その言葉の意味に > 過剰な期待をしてもしょうがないのでは、と言っているのです。 >私が最初から言っているのは、 > >「クラスを辞書で引いて分類と書いてあるからといって、プログラムの設計の際に、 >クラスを分類として捉えることが正しいことになるわけではない」 > >ということです。 だったら最初からそう書けばいいのに。 つか、684 からそれを読み取れというのは無茶と言うものです。 >[684]での引用を再度引用しますが、 > >>この議論の最初のほうで、CESさんは >>>例えば、「クラス」という用語の意味は「分類」であって、「原型」ではありませんから、 > >と書いています。「ありません『から』」なんだというのでしょうか。 >もちろん、術語は用途をちゃんと表しているのにこしたことはないけれど、 >術語の方から、設計や分析についてのあるべき姿を導くことはできない。 「クラス」という用語の意味は「分類」であって、「原型」ではありませんから、「クラスはオブジェクトを作る原型になるもの」ではなく「クラスはオブジェクトを分類したもの」だと捉えるべきだ、ということです。 そして、そう捉えることは、まったく自然なように思われるのです（もちろん、実装の都合上、必ずしもそうとは言えないクラスが出てくることはあり得るでしょう。しかし、それらは例外として考えるべきであり、基礎としては無駄ではありません）。 >だから私は、術語なんかに期待するのではなく、 > >>クラスを分類として考えるのがよいとCESさんがお考えなら、それが具体的に >>有効であるケースを、例示して主張するのがよいのではないでしょうか。 > >と、具体的な例示をするのがよいのでは、と言っているのです。 「クラス」という言葉の「辞書的用法」と「述語的用法」に関しての議論だとばかり思っていたので、「クラスを分類だと考えていない」とはまさか思いませんでした。 こうも書かれているのに。 ># クラスを分類とする考え方を否定しているわけではありません。 > 「そのへんの入門書にある考え方だと、こういう例ではこういうモデリングを > してしまいがちだけど、分類として考えればこんなモデリングになって、 > こういう拡張をするときのことを考えたらこっちのほうが修正箇所が > はるかに少なくてすむよね」とか。 「サブクラスの方が機能が上」という考え方だと、is-a の関係を考えた時に「機能が豊富なものは機能がショボいものの一種」ということになって変だよね。 集合論（というか論理学のベン図）で考えれば、スーパークラスはサブクラスよりも一段階抽象的なので、直接比較できないことはわかるよね。 「サイヤ人とスーパーサイヤ人はどっちがすごいか」は、暗黙のうちに「サイヤ人＝スーパーじゃないサイヤ人」という仮定を置かず、「サイヤ人はスーパーサイヤ人のスーパークラス」とする限り、比べられない（作中ではこの仮定が暗黙のうちに成立している）。 「スーパーじゃないサイヤ人とスーパーサイヤ人」ではスーパーサイヤ人の方がすごいけど、スーパーじゃないサイヤ人はスーパーサイヤ人のサブクラスではない。 …でいい？ 「こう考えるといいよね」というよりも「こう考えないと明らかに変だよね」という感じなので、修正工数云々で対比することはできない。

ふと思ったのは、「オブジェクト指向データベース」っていう言葉からして破綻している気がするなぁ…というものでした。 「オブジェクト指向データベース」って何なんだ…と思って、易しい入門を読んでみましたが、そこでは結局、「データを隠蔽し、getter と setter を持っているものがオブジェクトである」という程度でした。 結局のところ、「データベース」である以上は「オブジェクト指向言語と相性のいい永続化ストア」を脱し切れなくて、一歩踏み出すならば「オブジェクトベース」にならなければいけないような気がします（その具体的な形がどうなるかまでは分かりませんが）。 ＃まぁ、汎用機時代からデータスキーマを使いまわすような運用では、そうそうパラダイムシフトも起こせないでしょうけど。

>まだ酔っ払ってますか？　何故そんな言葉を持ち出されたのかさっぱり分かりません。 スーパークラスやサブクラスは術語であり、悟空やベジータはスーパーサイヤ人です。 単純に置き換えただけですが何か? >「術語としてのクラス」に「辞書的な『分類』という意味」を期待するのは、 >まったく過剰ではないと思える、ということです。 だったら最初からそう書けばいいのに。 つか、 >>「クラス」も「スーパークラス」も、全く過剰だとは思えないので。 これからそれを読みとれというのは無茶というものです。 で、私は、 >「術語としてのクラス」に「辞書的な『分類』という意味」を期待する ことについてとやかく言った覚えはありません。 いや、とやかく言っている、というのならその部分を引用して示してください。 私が最初から言っているのは、 「クラスを辞書で引いて分類と書いてあるからといって、プログラムの設計の際に、 クラスを分類として捉えることが正しいことになるわけではない」 ということです。 [684]での引用を再度引用しますが、 >この議論の最初のほうで、CESさんは >>例えば、「クラス」という用語の意味は「分類」であって、「原型」ではありませんから、 と書いています。「ありません『から』」なんだというのでしょうか。 もちろん、術語は用途をちゃんと表しているのにこしたことはないけれど、 術語の方から、設計や分析についてのあるべき姿を導くことはできない。 だから私は、術語なんかに期待するのではなく、 >クラスを分類として考えるのがよいとCESさんがお考えなら、それが具体的に >有効であるケースを、例示して主張するのがよいのではないでしょうか。 と、具体的な例示をするのがよいのでは、と言っているのです。 私がどのような例示を求めているのかについて、誤解があるといけないので テンプレまで書いてあげました。 >「そのへんの入門書にある考え方だと、こういう例ではこういうモデリングを >してしまいがちだけど、分類として考えればこんなモデリングになって、 >こういう拡張をするときのことを考えたらこっちのほうが修正箇所が >はるかに少なくてすむよね」とか。 ここまでやっているのにさ。 回答はこれだぜ。 >例示が必要でしょうか？　「is-a」「汎化-特化」の考えは、まさに分類だと >思うのですが（「汎化」「特化」という用語を誰が考えたかは知りませんが、 >いくらこれが術語だからと言って「低機能」「高機能」という意味でないのは >明らかでしょう）。 (特に自分とこの掲示板で)こんな終わり方をするのは私も嫌なんですが、 意思の疎通をする気がないようなので、これまでとしたいと思います。

>>何が過剰なのかわからないのです。 > >[684]に書いたことを繰り返すつもりはありません。 ＃こういう終わり方は大嫌いなのですが 「意思の疎通ができてないみたいなので、これまでとしましょう」って打ち切っていいですか？ >>「クラス」も「スーパークラス」も、全く過剰だとは思えないので。 > >もはや日本語むちゃくちゃになっていませんか? > >「スーパーサイヤ人に過剰な期待をするのはいかがなものか」 >「悟空もベジータも、全く過剰とは思えない」 > >意味不明です。 まだ酔っ払ってますか？　何故そんな言葉を持ち出されたのかさっぱり分かりません。 最初の文の意味が通じなかったのならば補足します。 「術語としてのクラス」に「辞書的な『分類』という意味」を期待するのは、まったく過剰ではないと思える、ということです。 何が「過剰な期待」で、何が「過剰でない期待」なのか。術語には何なら期待していいのか。 [684] を何度読み返しても、それがわからないんですよ。

>＃ つhttp://www.shiro.dreamhost.com/scheme/docs/cont-j.html 紹介していただいたshiroさんのページは、以前読んだことはあったのですが、 あまり理解できずにそのままになっていました。 そこで今回、以下のページのActionScript版をベースに、crowbar版を書いて 試してみたところ… クラッシュしました。 http://torus.jp/memo/x200403/nandemo_keizoku_as.rd.html 調べてみたら、「配列リテラルの要素にオブジェクトを格納すると、一時的に スタックからの参照が切れることがあり、そのタイミングでGCすると死ぬ」という 潜在バグが(おそらくver.0.2から)あり、かつ、ver.0.4では「毎回GCする」という テスト用の状態でリリースしてしまったために発覚しました。 取り急ぎ修正版をリリースしました。毎度テストが甘くすみません。 力尽きたので今日はここまでです。

>crowbarでも、CRB_dev.hにあるオブジェクト確保系の関数群において、自動的に >参照をスタックに積んでしまうことは可能です。ネイティブ関数実行後スタックを >戻す処理も、処理系側で苦もなくできます。 >なぜ今そうなっていないかというと… うーん、何故なんでしょう? (^^; >たとえば、オブジェクトを確保して、すぐに既存の配列の要素にセットする、 >という場合、特にスタックに積む必要はないのでその辺の無駄を嫌ったような >気がしますが、現状の仕様は、「いつGCが起きる可能性があるか」という点について >crowbarの内部実装をネイティブ関数の作者に晒していることになりますから、 >大変よろしくないですね。次バージョンでは修正します。 > >ネイティブ関数側で、大量のオブジェクトの確保/破棄を繰り返すような処理が >あるとすると、スタックが大量に無駄になりますが、そんなことわざわざ >ネイティブ関数で書かないですよねえ… あるいはその場合でも、 >ネイティブ関数用を呼び出したときのCRB_LocalEnvironmentに >local referenceの表を持ち、スタックではなくそちらに参照を入れるようにして >おけば、ネイティブ関数のプログラマに手で解放させることも不可能ではないですし。 ご教授ありがとうございます。 GCに少し興味を持ったのですが、お勧めのサイトなどありますか？ 以下の本を購入しようと思ったのですが、(ぱ)さんは読んだことありますか？ http://www.amazon.co.jp/exec/obidos/ASIN/0471941484/qid=1136566955/sr=1-1/ref=sr_1_10_1/250-0589622-2949018

>そちらのblogも拝見しました。 ありがとうございます。 >「業務アプリケーションにはオブジェクト指向は >向かない」というのは同意見です。まあ業務アプリでも、フレームワークや、 >アプリケーションの「機能」の側でOOを使うところはたくさんありますが、 >「データ」に処理は結びつかないと思います。 そうなんですね。処理系、GUIアプリだとOOは相性はいいのですが、多くの本で、その辺の区別をせずに何でもOOがいいとして、で業務アプリを例にとって解説しているのですが、構造を見るとあまりOOっぽくない。最近流行のDIも、シングルトンを使ってかつインターフェースに対する実装クラスは一つが基本なので、これってOOなのって思ってしまいます。 >ということで、総論では賛成ですが、「メモリ中心では無理だから」という方の >理由付けはいらないんじゃないでしょうか。メモリに載ろうが載るまいが、 >あるいはオブジェクト指向データベースがディスク上のデータを透過的に見せて >そのへんの問題をすべてクリアしてくれようが、データに処理が結びついていない以上、 >やっぱりオブジェクト指向には合わないのだと思います。 確かにそのとおりですね。データと処理が結びつかないという議論とは別でした。 形上、オブジェクト指向的に作ったところでデータベースとの絡みでいろいろと問題が出てくるし、データベース中心に考えていった方がいいんじゃない、ということで、業務アプリケーションはオブジェクト指向に向いていないということを言おうとしていました。現在のORマッピングツールでは駄目ですね。おっしゃるとおり、たとえオブジェクト指向データベースで完全に透過的になったとしても、やっぱり「オブジェクト指向的」としか言えないでしょうね。

>はじめまして。happieと申します。 はじめまして。 >また『ポインタの完全制覇』や「疑り深いあなたのためのオブジェクト指向再入門」 >については、本質的なところを突いているため大変興味深く読ませていただきました。 ありがとうございます。 >(ぱ)さんは、ポリモーフィズムに関してあまり記述がなかったように思いますが、 >どのようにお考えですか。 ポリモルフィズムは重要な概念だと思います。 「疑り深い～」でポリモルフィズムについて触れていないのは、今のところまで書いて 力尽きたというか、優先度がそれほど高くないと思ったからです。 マルチプルインスタンスについては、オブジェクト指向を普通に使っている人なら 誰でも普通に使っているにもかかわらず、そして初心者は結構そこでつまずくにも 関わらず、ほとんど誰もそれを重要であると声に出して言わないので、 これはまずいだろ、と思いあれを書いたわけですが、インタフェースと ポリモルフィズムに関しては、私は重要だと思いますし、誰もが重要だと言いますから、 特に声を上げる必要もないかなあ、と。 ただ、ポリモルフィズムが実際にどういう場面でどこまで使えるか、という点に ついては注意を払う必要があるとは思います。 最近、この掲示板の[649]にも書いていますが、「CADを作るとき図形にdraw() メソッドを付けるのは正しいのか」という話を、私はしょっちゅう出しています。 そちらのblogも拝見しました。「業務アプリケーションにはオブジェクト指向は 向かない」というのは同意見です。まあ業務アプリでも、フレームワークや、 アプリケーションの「機能」の側でOOを使うところはたくさんありますが、 「データ」に処理は結びつかないと思います。 業務アプリでは、たくさんのテーブルがあり、また、さらにたくさんの「機能」が あります。そして、しょっちゅう機能追加を行っても、そうそうテーブル定義には 変更を加えません。データが何よりえらいのであって、処理がデータに依存しても、 データが処理に依存してはいけない。これは基本的には「CADで図形にdraw()メソッドを 付けるべきではない」というのと同じことだと思います。 ということで、総論では賛成ですが、「メモリ中心では無理だから」という方の 理由付けはいらないんじゃないでしょうか。メモリに載ろうが載るまいが、 あるいはオブジェクト指向データベースがディスク上のデータを透過的に見せて そのへんの問題をすべてクリアしてくれようが、データに処理が結びついていない以上、 やっぱりオブジェクト指向には合わないのだと思います。

>>これは、Cの関数を抜けた後の話ですよね。レジストリに登録するという。 >>crowbarでは、Cの関数の実行中でも、ヒープ関連の関数を呼び出すと >>GCが動く可能性がありますから、ひとまずスタックに積まなければなりません。 > >私はよく分かっていないのですが、このcrowbarのアプローチは >メジャーなのですか？ たぶん、メジャーでも、望ましいものでもないと思います。 Rubyだと、GCがCスタックをスキャンするから何もしなくてよく、 Pythonだと、参照カウンタを上げたり下げたりを手でやらなければいけなかったと 思いますが(過去形?)、たとえばJavaのJNIでは、別にCスタックをスキャンする わけでもないのに、確保したオブジェクトについては特に何もする必要はありません。 JavaHouseにある首藤さんの記事によれば、 http://java-house.jp/ml/archive/j-h-b/013314.html | JNI: native method のフレームごとに local references (の表) を用意、 | local references から辿れるオブジェクトは回収しない。 とのことです。 crowbarでも、CRB_dev.hにあるオブジェクト確保系の関数群において、自動的に 参照をスタックに積んでしまうことは可能です。ネイティブ関数実行後スタックを 戻す処理も、処理系側で苦もなくできます。 なぜ今そうなっていないかというと… うーん、何故なんでしょう? (^^; たとえば、オブジェクトを確保して、すぐに既存の配列の要素にセットする、 という場合、特にスタックに積む必要はないのでその辺の無駄を嫌ったような 気がしますが、現状の仕様は、「いつGCが起きる可能性があるか」という点について crowbarの内部実装をネイティブ関数の作者に晒していることになりますから、 大変よろしくないですね。次バージョンでは修正します。 ネイティブ関数側で、大量のオブジェクトの確保/破棄を繰り返すような処理が あるとすると、スタックが大量に無駄になりますが、そんなことわざわざ ネイティブ関数で書かないですよねえ… あるいはその場合でも、 ネイティブ関数用を呼び出したときのCRB_LocalEnvironmentに local referenceの表を持ち、スタックではなくそちらに参照を入れるようにして おけば、ネイティブ関数のプログラマに手で解放させることも不可能ではないですし。 >>ただ、たぶんこの場合、グローバル変数を共有して動かしたいのだと思います。 >>そうだとすれば、外部crowbarスクリプトのトップレベルを動かす方法は >>ありません。ただし、外部crowbarスクリプト中の関数であれば、 >>CRB_compile()とCRB_call_function()を使えば実行可能です。 > >外部crowbarスクリプト中の関数を呼べるということは、 >データを引数でC側からcrowbarの関数側にプッシュしてあげて、 >crowbarスクリプトのglobal変数に保存しておけば、 >データの共有はできると思います。 誤解させる書き方をしてしまったかもしれませんが、CRB_compile()と CRB_call_function()を使う方法なら、インタプリタを共有できますから、 グローバル変数によるデータ共有が可能です(まあ、引数で受け渡しするほうが よいのはよいでしょうけど)。 >私は、(ぱ)さんの本はほとんど持っていますが、もう少し内容を濃くして >「プログラミング言語を作る」もぜひ出版して欲しいです。 >早くていつ頃になりそうですか？ いやあ、それはさっぱりわかりません。 まだ企画が動き出したわけですらないですし。

>何が過剰なのかわからないのです。 [684]に書いたことを繰り返すつもりはありません。 >「クラス」も「スーパークラス」も、全く過剰だとは思えないので。 もはや日本語むちゃくちゃになっていませんか? 「スーパーサイヤ人に過剰な期待をするのはいかがなものか」 「悟空もベジータも、全く過剰とは思えない」 意味不明です。

　えー、すみません、興味深い投稿がたくさんされてますが、昨晩は酔っ払って帰って きてそのまま寝てしまいました (^^; 　お返事は今晩ということでよろしくお願いします。

http://kmaebashi.com/programmer/devlang/regexp.html > Java流の、要素を取り出すだけで強制的にポインタを進めてしまう仕様は、 > ちょっとどうかと思うんですがねえ。 同感です。マージとかやりにくそう。 というわけでどちらか片方にするなら、GoFの方が良いな、と思ってたりするのですが、以下のような関数を用意すれば、GoF方式とJava方式の両方をあまり手間をかけずに作ることができます。(両方欲しい、という訳ではありませんが) function iterator_GoF(foreach_CPS) { this = new_object(); this.first = closure () { this.isDone = closure () { return false; }; foreach_CPS(closure (item, cont) { this.currentItem = closure () { return item; }; this.next = closure () { cont(null); }; }, closure (ret) { this.isDone = closure () { return true; }; }); }; this.first(); return this; } function iterator_Java(foreach_CPS) { this = new_object(); closure () { this.hasNext = closure () { return true; }; foreach_CPS(closure (item, cont) { this.next = closure () { cont(null); return item; }; }, closure (ret) { this.hasNext = closure () { return false; }; }); }(); return this; } function foreach(foreach_CPS, proc) { # ついでに作った foreach_CPS(closure (item, cont) { cont(proc(item)); }, closure (ret) {}); } ＃ foreach_CPSは CPS(continuation passing style, 継続渡し形式)で書かれたforeachです。 ＃ つhttp://www.shiro.dreamhost.com/scheme/docs/cont-j.html これらの関数に対し、コレクション側でforeach_CPSを用意して渡せば それぞれの関数に対応したイテレータが返されます。 例えば以下のような2分木があったとすれば tr = {13,{5,{3,{},{}},{13,{12,{},{}},{}}},{16,{16,{15,{},{}},{}},{17,{},{}}}}; function foreachTree_CPS(tree) { return closure (proc, fin) { closure internalIterate(node, cont) { if (node.size() == 0) { cont(null); } else { internalIterate(node[1], closure (ret) { proc(node[0], closure (ret) { internalIterate(node[2], cont); }); }); } }(tree, fin); }; } という関数を1つ定義するだけで print("foreach:"); foreach(foreachTree_CPS(tr), closure (item) { print(" " + item); }); print("\n"); print("GoF :"); for (i = iterator_GoF(foreachTree_CPS(tr)); !i.isDone(); i.next()) { print(" " + i.currentItem()); } print("\n"); print("Java :"); for (i = iterator_Java(foreachTree_CPS(tr)); i.hasNext();) { print(" " + i.next()); } print("\n"); のように、3種類のイテレータが使えてまあ便利。 でもシーケンシャルなコレクションだとそれほど嬉しくはありません。 CPSではforやwhileがまともに使えないので、例えば配列用のforeach_CPSは function foreachArray_CPS(array) { return closure (proc, fin) { closure loop(index, cont) { if (index == array.size()) { cont(null); } else { proc(array[index], closure (ret) { loop(index + 1, cont); }); } }(0, fin); }; } なんてことになって、要素数が多いとforeachに渡したときにクラッシュするなあ、とか、初期値と変数が遠いなあ、とか。 今の実装だと末尾再帰の最適化は物凄く大変そうですしね。 ＃ でもこの形式のループは個人的にはむしろ欲しかったりします、crowbar ver.0.3.02にcall/ccを付けたので。ちなみに、この時点で末尾再帰の最適化はやりやすくなったのですが、CRB_Objectが増えたので先にGCを改造しなければならないのでした(どうでもいい報告)。 この手法は、 ・外部イテレータを直接作るのが難しくて ・ループによらないアクセスが簡単な データ構造(木とか) *では* 役に立ちます。 ＃ ライブラリが簡単に書けます。というのはそれほど嬉しいことではない気がする