K.Maebashi's BBS

おーこんなにたくさんの方が！ みなさんどうもありがとうございます。 おかげさまでだいぶ大事なことをいくつか理解できました。 .hと.cの使い分けは正直うすうす悩んでいたことなので、 今回の質問で、間接的ではありますが、すっきりできてよかったです。 とりあえず元のコードの.hは大掃除した方がよさそうですね。 あと、intの場合なぜ通ってしまったかは、 これから聞こうと思っていたのですが、 皆さん先回りありがとうございます（笑 ここまで分かるとだいぶすっきり感がありますねぇ。 tiさんのサンプルコード大変参考になります。 たぶんまた近いうちに壁に当たって戻ってきますので 引き続きよろしくお願いします。

えっと、今は「関数宣言」の話しかしてない、っての大丈夫？ 「関数定義」の話は一切出てきてないんだけど。 関数宣言が何回現れても、関数定義がなければリンクエラーにはならないよん。

すばらしい。 typedef を使っているあたりが素敵すぎる。 というわけで第三者読者へのふぉろーを追加。 typedef は新しい型を作るのではなくて、既存の型への別名を作る。 提示の例だと名前のない構造体（便宜上 anonymous_struct_1 と名づける） struct anonymous_struct_1 { int val; }; に対して、別名１ KOUZOU1 別名２ KOUZOU2 をつけているだけ。 なので KOUZOU1 と KOUZOU2 はどちらも struct anonymous_struct_1 であり、 関数宣言のほうもエラーにならない。 typedef struct { int x; } KOUZOU1, *PKOUZOU2; KOUZOU1 *func(); PKOUZOU2 func(); int main() { return 0; } これもエラーにならない。 一方で KOUZOU3 は struct anonymous_struct_2 { int val; }; の別名になるので これは KOUZOU1, 2 とは別のものになり、宣言が矛盾するエラー。

へぇ。そうなんだ。問題ないんだ。 遠い昔、Ｃコンパイラに怒られるのが嫌で、○○の一つ覚えみたいに、2個目以降はexternを付けたような、、、、確かリンカでエラーが、ん！あぁなるほど、今回はstaticだからだいじょーぶなんだ。。。

にゃるほどー。 コンパイラは宣言がダブってる(re-declared)ことに怒ってるんじゃなくて、 型が合わない(conflicting types)から怒ってるんですね。 >static KOUZOU3 *func();の行だけエラーです。 さすがにデータ構造がたまたま同じでも、別の構造体だとダメか（笑）

tiです。 >矛盾しない関数宣言は何回行ってもよい（正しいプログラムである）ので、 >この２行があってもエラーにはならない。 >過去に書かれたソースコードとの互換性を維持するために、このコードに対して >警告は出ないのが大多数のコンパイラの挙動だろうね。 ># 俺的には、出たらびっくり。 どうもそうみたいでびっくりです(VC++ 2008で確認)。 実例です。 typedef struct { int val; } KOUZOU1,KOUZOU2; typedef struct { int val; } KOUZOU3; static KOUZOU1 *func(); static KOUZOU2 *func(); static KOUZOU3 *func(); int main(void) { return 0; } static KOUZOU3 *func();の行だけエラーです。

５１２ 氏の [1706] 発言に一言付け加えると理解しやすくなるだろう。 > 構造体ではなくintへのポインタであればエラーは出ません。 「両方を」を追加。 すると main.c 中には static int *func(); // File1.h 由来 static int *func(); // File2.h 由来 と書かれた２行が入ることになる。 矛盾しない関数宣言は何回行ってもよい（正しいプログラムである）ので、 この２行があってもエラーにはならない。 過去に書かれたソースコードとの互換性を維持するために、このコードに対して 警告は出ないのが大多数のコンパイラの挙動だろうね。 # 俺的には、出たらびっくり。

[1706]の > 構造体ではなくintへのポインタであればエラーは出ません。 は、どう？エラーじゃなくても警告ぐらい出す気がするんだけど、 こちら、Cが詳しくないのでよく分りません。

既に回答がついていますが、File1.hとFile2.hの static KOUZOU1 *func(); static KOUZOU2 *func(); このふたつのプロトタイプ宣言が、main.cの中で両方とも見えてしまって いるのが原因です。 「static KOUZOU1 *func()」という関数を、File1.cの中だけで使うのであれば、 .hファイルではなくFile1.cの中で宣言すればOKです。 関数定義自体を、それを呼び出すところよりも先に書けるのであればそれでも OKです(私はこちらの書き方の方が好みです)。

正解っす。あえてフォローするなら ti 氏が解説を省略したところを。 C のプリプロセッサは単純置換を行う機能であるため、 #include "hogehoge.h" は　この行が hogehoge.h の中身に置き換わるだけ である、ということを意識すると理解が早い。 main.c は File1.h と File2.h を両方取り込む 取り込んだ結果のファイルを翻訳単位という main.c 中に static KOUZOU1* func(); と static KOUZOU2* func(); が両方入る 同一関数名が違う機能であると宣言されているのでエラー。 gcc -E hoge.c とか gcc -E -C hoge.c とかしてみると参考になるかもしれない。 次のステップへのヒントを 複数人開発をするようになると、重要度は　.h ファイル＞ .c ファイル になる。 .h ファイルには「他人に使ってもらうため」の宣言・コメントを書く .c ファイルにはその実装を書く だから、 ・他人に使ってもらいたくない static 変数や関数は .h に書かずに .c に書く ・inline 展開される前提の短い static 関数は .h に書くことがある

tiと申します。 自分の勉強のため回答させていただきますので、 前橋さん間違いや補足のご指摘お願いします。 main.cの中で >#include "File1.h" >#include "File2.h" となっていて、 >static KOUZOU1 *func(); >static KOUZOU2 *func(); /* ここがエラーになります：error: conflicting types for 'func' */ で 展開後にfunc識別子が重複していることが原因です。 どちらかと関係するところを変えればコンパイルできるはずです。 なお、static宣言はmain.cなど、公開したくないソースに対してのヘッダファイルに 含めるべきでないと思います。 公開用(extern宣言の関数)と非公開用(ある関数だけで使うstatic宣言の関数)で ヘッダファイルは分けるべきです。 また、ヘッダファイルは二重展開防止機能をつけておきましょう。 #ifndef FILE1_H #define FILE1_H ～ #endif 以上 >お返事遅れました。 >（ぱ）さん、yuyaさん、ありがとうございます。 >（ぱ）さんの回答にひもづけて続けます。 > >下記がサンプルコードとエラーメッセージです。 >(環境はMac OSXのXcode3.2.4です。) > >main.c >-------------------------------------------------- >#include "File1.h" >#include "File2.h" > >int main (int argc, const char * argv[]) { > > file1(); > file2(); > > return 0; >} >-------------------------------------------------- > >File1.h >-------------------------------------------------- >typedef struct KOUZOU1_tag { > int var; >} KOUZOU1; > >void file1(); >static KOUZOU1 *func(); >-------------------------------------------------- > >File1.c >-------------------------------------------------- >#include <stdio.h> >#include <stdlib.h> >#include "File1.h" > >void file1() { > KOUZOU1 *kouzou; > kouzou = func(); > > printf("%d\n", kouzou->var); >} > >static KOUZOU1 *func() { > KOUZOU1 *kouzou; > > kouzou = malloc(sizeof(KOUZOU1)); > kouzou->var = 1; > > return kouzou; >} >-------------------------------------------------- > >File2.h >-------------------------------------------------- >typedef struct KOUZOU2_tag { > int var; >} KOUZOU2; > >void file2(); >static KOUZOU2 *func(); /* ここがエラーになります：error: conflicting types for 'func' */ >-------------------------------------------------- > >File2.c >-------------------------------------------------- >#include <stdio.h> >#include <stdlib.h> >#include "File2.h" > >void file2() { > KOUZOU2 *kouzou; > kouzou = func(); > > printf("%d\n", kouzou->var); >} > >static KOUZOU2 *func() { > KOUZOU2 *kouzou; > > kouzou = malloc(sizeof(KOUZOU2)); > kouzou->var = 2; > > return kouzou; >} >-------------------------------------------------- > >エラーは >error: conflicting types for 'func' >というもので >File2.h の static KOUZOU2 *func(); >の所に出ます。 > >ちなみに >error: previous declaration of 'func' was here >というメッセージも同時に出て、開くと >File1.h の static KOUZOU1 *func(); >を指していました。 > >やっぱりstaticを付けているのに >「funcさっき宣言したじゃん！」と言われているようなんですが、 >いかがでしょうか。 > >うーん、どこを勘違いしてるんだろうか。。。 > >よろしくお願いします！ > >P.S. >「記憶クラス指定子」「型修飾子」の違いなど、 >自分で間違えて指摘されるとスムーズに理解しやすいですね。 >本で読むときはつい飛ばしてしまいがちですが（笑

お返事遅れました。 （ぱ）さん、yuyaさん、ありがとうございます。 （ぱ）さんの回答にひもづけて続けます。 下記がサンプルコードとエラーメッセージです。 (環境はMac OSXのXcode3.2.4です。) main.c -------------------------------------------------- #include "File1.h" #include "File2.h" int main (int argc, const char * argv[]) { file1(); file2(); return 0; } -------------------------------------------------- File1.h -------------------------------------------------- typedef struct KOUZOU1_tag { int var; } KOUZOU1; void file1(); static KOUZOU1 *func(); -------------------------------------------------- File1.c -------------------------------------------------- #include <stdio.h> #include <stdlib.h> #include "File1.h" void file1() { KOUZOU1 *kouzou; kouzou = func(); printf("%d\n", kouzou->var); } static KOUZOU1 *func() { KOUZOU1 *kouzou; kouzou = malloc(sizeof(KOUZOU1)); kouzou->var = 1; return kouzou; } -------------------------------------------------- File2.h -------------------------------------------------- typedef struct KOUZOU2_tag { int var; } KOUZOU2; void file2(); static KOUZOU2 *func(); /* ここがエラーになります：error: conflicting types for 'func' */ -------------------------------------------------- File2.c -------------------------------------------------- #include <stdio.h> #include <stdlib.h> #include "File2.h" void file2() { KOUZOU2 *kouzou; kouzou = func(); printf("%d\n", kouzou->var); } static KOUZOU2 *func() { KOUZOU2 *kouzou; kouzou = malloc(sizeof(KOUZOU2)); kouzou->var = 2; return kouzou; } -------------------------------------------------- エラーは error: conflicting types for 'func' というもので File2.h の static KOUZOU2 *func(); の所に出ます。 ちなみに error: previous declaration of 'func' was here というメッセージも同時に出て、開くと File1.h の static KOUZOU1 *func(); を指していました。 やっぱりstaticを付けているのに 「funcさっき宣言したじゃん！」と言われているようなんですが、 いかがでしょうか。 うーん、どこを勘違いしてるんだろうか。。。 よろしくお願いします！ P.S. 「記憶クラス指定子」「型修飾子」の違いなど、 自分で間違えて指摘されるとスムーズに理解しやすいですね。 本で読むときはつい飛ばしてしまいがちですが（笑

どーでもいい私の感想ですが、 >もちろん関数の名前を変えれば解決するのですが、 >せっかくCを勉強しているので、原因をはっきりさせたいです。 これに惚れますね(笑)

（ぱ）さんのおっしゃる通りで、エラーメッセージ（とサンプルコード）をコピペしたものを見ないと原因は分かりませんが、 >staticが"func"にかかっていないのかな？ >という気がしますが、どうなんでしょうか。 このような疑問が湧くということは、 static, extern のような「記憶クラス指定子」と、 constのような「型修飾子」を混同なさっているのではないかと思います。 static が宣言中のどこにあるかによって、宣言の意味が変わることはありません。 先頭以外に書いた場合には、先頭に書いたのと同じ意味になるか、文法エラーになるか、のどちらかです。 ……って言い切っちゃったけど自信ない(^^;)

はじめまして。 >最近C言語をがんばって勉強しています。（もちろん楽しいです） >ポインタ完全制覇には大変お世話になりました。 ありがとうございます。 で、ご質問の件ですが、 >現在、ソースファイルを分けてプログラムを書いており、 >他のファイルからアクセスしない関数にはstaticをつけています。 >なので、複数ファイル上で同名の関数を持っていても >エラーは出ません。 > >しかし、構造体へのポインタを返す関数の場合は、 >staticを付けてもエラーになってしまいます。 さすがにこれはありえないと思います。 戻り値の型が構造体へのポインタであっても、文法上、staticで名前を隠蔽することに 関係はしませんし、処理系のバグにしてもあまりにも変に見えます。 具体的にどのようなエラーが出ているのか、エラーメッセージを教えてもらえますか?

はじめまして！ 最近C言語をがんばって勉強しています。（もちろん楽しいです） ポインタ完全制覇には大変お世話になりました。 未だに完全消化できておらず、 この本を消化できれば分かることなのかもしれませんが、 身近に頼れる人がいなく、質問させてください！ 現在、ソースファイルを分けてプログラムを書いており、 他のファイルからアクセスしない関数にはstaticをつけています。 なので、複数ファイル上で同名の関数を持っていても エラーは出ません。 しかし、構造体へのポインタを返す関数の場合は、 staticを付けてもエラーになってしまいます。 構造体ではなくintへのポインタであればエラーは出ません。 構造体はそれぞれ別のものです。 もちろん関数の名前を変えれば解決するのですが、 せっかくCを勉強しているので、原因をはっきりさせたいです。 具体的には ファイル１に　static KOUZOU1 *func(); ファイル２に　static KOUZOU2 *func(); を置いています。 ポインタ完全制覇読者としては staticが"func"にかかっていないのかな？ という気がしますが、どうなんでしょうか。 お知恵を拝借できれば幸いです。

> >Board.javaのput()メソッドの中のwindow.redraw()を抜けばよいようです。 > >このメソッドは、最終的にはCanvasのrepaint()を呼び出すことで、オセロの >盤面の再描画を行います。石を置いた後、アニメーションとともに画面の更新は >終わっているのですが、「念のために」全体の再描画をかけているわけです。 > >しかし、AWTにおけるrepaint()は非同期なので、即座に実行されるとは限りません。 >この再描画要求が、「次に石を置き、盤面の状態は変わったが、アニメーションの前」 >という状況で実行されると、アニメーション前に盤面の絵が更新されてしまいます。 > >ソースは近日中に差し替えます。ご指摘ありがとうございました。 お忙しい中、ありがとうございました。

大変遅くなってしまいましてすみません。学生さんがまだここを見ているかどうかも わかりませんが… >>石がひっくり返るアニメーションの前に、既にBoard内のデータは >>書き換えられているので、もしその前に画面の再描画が動いてしまえば >>現状のような現象になると思うのですが、すみませんが最近どたばたしていて >>私のほうでは原因が追えていません。 > >自分の方で調べて直してみたのですができませんでした。 > >今、お忙しそうですが原因がわかったらでいいので教えてもらえるとありがたいです。 Board.javaのput()メソッドの中のwindow.redraw()を抜けばよいようです。 このメソッドは、最終的にはCanvasのrepaint()を呼び出すことで、オセロの 盤面の再描画を行います。石を置いた後、アニメーションとともに画面の更新は 終わっているのですが、「念のために」全体の再描画をかけているわけです。 しかし、AWTにおけるrepaint()は非同期なので、即座に実行されるとは限りません。 この再描画要求が、「次に石を置き、盤面の状態は変わったが、アニメーションの前」 という状況で実行されると、アニメーション前に盤面の絵が更新されてしまいます。 ソースは近日中に差し替えます。ご指摘ありがとうございました。

またまた、お久しぶりです。 最近は、主に３Dグラフィック関係の組込関数ばかり作っています。 言語部分の修正はあまり無いです。しかし、組み込み関数及び、 普通の関数のほとんどがリターンコード0のばかりだったので、void型を 作りました。関数の戻り値だけにしか使い道がありませんが。 　その結果、バイトコードでは、call後のpopが必要なくなったのと、call機能 の実装部分が、void関数ではリターンコード処理がない分シンプルになりました。 　おお、今気がついた、voidの関数はcall_voidの様な命令追加して、より シンプルにしよう。ほとんどがvoid関数なので効果が出る。 　また、関数コールを数倍速する方法。それは、初期値の定数処理バイト コードが不要になり、パラメータ処理も単純になります。しかし、修正部分が 多いのでまた今度にします。 　方法は簡単で、関数コールのスタック情報を事前に総て持っていて、 それをスタックにコピーして、インデックスアドレスとパラメータデータ のみ調整することで高速に関数が呼べます。定数コピーとかパラメータ 領域作成等細かな処理を一発コピーで終わらせます。 　いまはまだ出来ませんが、行く行く組込みます。 　また、シート変数を普通の関数パラメータに指定できるようにするため、 バイトコードが７つも増えてしまいました。orz 　はやく、こんなことがしたかったんですと見せられるといいのですが、 まだまだ先が遠いです。

>今、お忙しそうですが原因がわかったらでいいので教えてもらえるとありがたいです。 すみません、ちょっと手間取ってます…

> >石がひっくり返るアニメーションの前に、既にBoard内のデータは >書き換えられているので、もしその前に画面の再描画が動いてしまえば >現状のような現象になると思うのですが、すみませんが最近どたばたしていて >私のほうでは原因が追えていません。 自分の方で調べて直してみたのですができませんでした。 今、お忙しそうですが原因がわかったらでいいので教えてもらえるとありがたいです。

はじめまして。時間がないので簡単な変身となってしまいますが、 >私のうっすらとした記憶では「Dr.スランプ」で使用されていたのではないかと >思うのですが（ソースが見つけられず、正確な情報でなくて申し訳ございません）。 Dr.スランプ、実家に帰れば文庫版を持っているのですが… >P.S.「ぴよ」といえば、「Dr.スランプ」より「めぞん一刻」や「タッチ」あたりのエプロン、シャツの柄でよく目にする「模様に困ったらpiyo」的なイメージが強いですが・・・これも今書き込もうとしてふと思っただけなので正確な情報でなくてすみません。 で、「ぴよ」のほうですが、こちらは「ほげ」と違い発祥が(たぶん)わかっています。 http://togetter.com/li/47113 やはり響子さんのエプロンが元ネタとのこと。

はじめまして。言語のお勉強をしていたはずが、「ほげ」にはまってしまいました（笑） 私のうっすらとした記憶では「Dr.スランプ」で使用されていたのではないかと思うのですが（ソースが見つけられず、正確な情報でなくて申し訳ございません）。 ちょうど８０年代前半（1979～1984）あたりですし、全国的に広まった理由としてもまぁ納得かなぁ・・・なんて。 （まぁ、流行とコードなどの命名をいっしょにはできないでしょうが） あられちゃんの「ほよよ」などはメジャーですが、爆発に巻き込まれた後や眠いのを起こされたような場面で使用されているイメージがあります。 http://www.studiohs.com/28if/text/slump/whoswho/ka_ko.html の「暗悪健太」に > スーパーほげげスペシャルをやっていたりする。 や、 http://blog.livedoor.jp/comic2ch/archives/80579.html >213 >羽の生えたでかい猿に喰われそうになってほげげーっとか悲鳴あげてるのにワロタw とありました。 もし、機会があればご確認下さい。 P.S.「ぴよ」といえば、「Dr.スランプ」より「めぞん一刻」や「タッチ」あたりのエプロン、シャツの柄でよく目にする「模様に困ったらpiyo」的なイメージが強いですが・・・これも今書き込もうとしてふと思っただけなので正確な情報でなくてすみません。

>これは、どこを直せばよろしいのですか？ 前回書いたとおりJudge.javaがGUIのイベントドリブンなスレッドとは 別スレッドで動いていて、石をひっくり返すところは、Judge.javaの方の スレッドで、Board.javaのput()から呼び出されています (window.animationPut()メソッド)。 石がひっくり返るアニメーションの前に、既にBoard内のデータは 書き換えられているので、もしその前に画面の再描画が動いてしまえば 現状のような現象になると思うのですが、すみませんが最近どたばたしていて 私のほうでは原因が追えていません。

>>いや、確かに表示がおかしくなってますね。 >>実際にコンピュータ同士対戦させてみて、最後のほうの石の表示を観察してみてください。 >>結果的な盤面変化は問題ないのですが、ひっくり返る過程の表示だけ変です。 > >再確認しました。思い込みとは恐ろしいもので、たくさんの石を一気に >ひっくり返すとき、ひっくり返す前から色が変わっているにもかかわらず >気付いていませんでした。失礼しました > 学生さん > >このプログラムは、ゲームのメインループ(先手後手を切り替えながら >ゲームオーバーまでぐるぐる処理)を普通のループで書きたかったため、 >イベントドリブンであるGUIとは別のスレッドで動かしています。 >その待ち合わせがうまくいっていなくて、アニメーション前に盤面が >再描画されているように思います。 > >何年も前に公開したプログラムなのでいまさらなのですが、ちょっと確認してみます。 > これは、どこを直せばよろしいのですか？

>>このプログラムは、ゲームのメインループ(先手後手を切り替えながら >>ゲームオーバーまでぐるぐる処理)を普通のループで書きたかったため、 >>イベントドリブンであるGUIとは別のスレッドで動かしています。 >>その待ち合わせがうまくいっていなくて、アニメーション前に盤面が >>再描画されているように思います。 > >この処理は、どこでやっているんですか？ ゲームオーバーまでぐるぐる回る処理のことであれば、 Judge.javaでやっています。

>このプログラムは、ゲームのメインループ(先手後手を切り替えながら >ゲームオーバーまでぐるぐる処理)を普通のループで書きたかったため、 >イベントドリブンであるGUIとは別のスレッドで動かしています。 >その待ち合わせがうまくいっていなくて、アニメーション前に盤面が >再描画されているように思います。 この処理は、どこでやっているんですか？

>いや、確かに表示がおかしくなってますね。 >実際にコンピュータ同士対戦させてみて、最後のほうの石の表示を観察してみてください。 >結果的な盤面変化は問題ないのですが、ひっくり返る過程の表示だけ変です。 再確認しました。思い込みとは恐ろしいもので、たくさんの石を一気に ひっくり返すとき、ひっくり返す前から色が変わっているにもかかわらず 気付いていませんでした。失礼しました > 学生さん このプログラムは、ゲームのメインループ(先手後手を切り替えながら ゲームオーバーまでぐるぐる処理)を普通のループで書きたかったため、 イベントドリブンであるGUIとは別のスレッドで動かしています。 その待ち合わせがうまくいっていなくて、アニメーション前に盤面が 再描画されているように思います。 何年も前に公開したプログラムなのでいまさらなのですが、ちょっと確認してみます。

>この説明ではなんだかよくわかりませんが、たぶん自動でパスしてるんじゃ >ないでしょうか? このプログラムでは、打つところがないときは勝手にパスします。 > いや、確かに表示がおかしくなってますね。 実際にコンピュータ同士対戦させてみて、最後のほうの石の表示を観察してみてください。 結果的な盤面変化は問題ないのですが、ひっくり返る過程の表示だけ変です。

>たとえば、黒を置いた時に白から黒にひっくり返るのですが >最後のほうになると黒を置いた時に石が黒に代わってから白から黒に回って変化して >いるんですけどそれはなんで最後のほうだけなるんでしょうか？ この説明ではなんだかよくわかりませんが、たぶん自動でパスしてるんじゃ ないでしょうか? このプログラムでは、打つところがないときは勝手にパスします。

>こちらのサンプルアプレットでのオセロゲームで >石がひっくり返るときに > >たとえば、黒を置いた時に白から黒にひっくり返るのですが >最後のほうになると黒を置いた時に石が黒に代わってから白から黒に回って変化して >いるんですけどそれはなんで最後のほうだけなるんでしょうか？ 前の質問ですけど コンピュータの時だけなってしまいます。

アドバイスのおかげでコンピュータが作成できました。 ありがとうございます。 こちらのサンプルアプレットでのオセロゲームで 石がひっくり返るときに たとえば、黒を置いた時に白から黒にひっくり返るのですが 最後のほうになると黒を置いた時に石が黒に代わってから白から黒に回って変化して いるんですけどそれはなんで最後のほうだけなるんでしょうか？

>次にミニマック法を作成してみたいと思うのですが >ComputerPlayer.javaでは何手先まで読んでいて、どこでやっているんでしょうか？ ComputerPlayer.javaはほぼ全域がミニマックス法とαβ枝刈りなので 「どこで」というのはないのですが、先読みの深さについては以下のように なっています。 ・通常は4手先までです(DEFAULT_SEARCH_DEPTH)。 ・残りのマスの数を数えます。これが残りの手数の概算(パスを考慮しない)と 　なるのですが、これが5(WIN_SEARCH_DEPTH)以下になったら、 　完全読み切りモードに入ります。 >後、ab法はどこでやっているのですか？ 変数alphaBetaValueで処理を分けているあたりです。 今ソースを見ると、残手数がPERFECT_SEARCH_DEPTH以下のときと WIN_SEARCH_DEPTH以下のときとでなにやら分岐していますが、 ここで設定した変数は使っていないので、無視してください。すみません。

基本値の計算が作成できました。 次にミニマック法を作成してみたいと思うのですが ComputerPlayer.javaでは何手先まで読んでいて、どこでやっているんでしょうか？ 後、ab法はどこでやっているのですか？

>Eval00.javaでは、 cellPriority[][]で評価をしていて、 >自分の石だったら足して、コンピュータの石だったら引いているのは >わかるのですか最後のcellsValue + canPutNum * 100では >なぜ100をかけているんでしょうか？ canPutNumは石が置ける場所の数(着手数)です。 オセロは石が置ける限りたとえ不利になるとしてもパスはできないので、 着手数は重要です。手詰まりが最大の敵です。 そのため、canPutNumが評価値に対して大きなウエイトを占めるように するために、100をかけています。 もちろん、cellPriorityの各要素の値を小さくしても同じ効果が あるでしょうけど。

返信ありがとうございます。 >Eval00.javaやEval01.javaの方が、Eval02.javaよりはずっと簡単なので、 >読むならそちらの方がよいでしょう。 その通りで、自分にはEval02.javaは難しいので、 Eval00.javaを参考に作成したいと思います。 Eval00.javaでは、 cellPriority[][]で評価をしていて、 自分の石だったら足して、コンピュータの石だったら引いているのは わかるのですか最後のcellsValue + canPutNum * 100では なぜ100をかけているんでしょうか？ 後、Eval00.javaは上の説明であっているでしょうか？ 違っていたら、流れを教えてもらえないでしょうか？ たびたび質問すいません。よろしくお願いします。

>インスタンスを理解していないので、「どのインスタンスのメソッドを呼ぶのか」と >いう発想ができず、その場でnewして呼んでしまう。これは、私が以下のページで書いた >画面に線を引くたびにCanvasをnewした新人君と同レベルの発想です。 すみません、「以下のページ」のURLを貼り忘れました。ここです。 http://kmaebashi.com/programmer/object/shigoto.html いやさ、それにしても、本当にこのページの 「「どの」オブジェクトに仕事をさせればよいのか」 あたりの説明を読んで、それでもまったく理解できなかったの? だとすれば、いかに相手がアレな人とはいえ、さすがに私も自信をなくします……

たいやきさんからの回答がないですが(アクセスログも見ましたが、私が 質問を書いた以後ここを見ていないようです)、 たいやきさんって、ハンドルと発言内容からして、こちらで質問されている taiyaki123さんですよね? http://oshiete.goo.ne.jp/qa/6438120.html >せっかく回答してくださって申し訳ないのですが、１００％の自信がないのであれば >回答くださらなくても結構です。ありがとうございました。 ……まあこれはさておき。 他にこちらでも質問されているようですが、 http://oshiete.goo.ne.jp/qa/6438154.html >信じられないのは、インスタンス変数が書き換えられるということです。 >サーブレットではインスタンス変数が共有されるのは理解していますが、 >サーブレットから呼ばれるインスタンスで定義されているインスタンス変数も >それに該当するのでしょうか。 >それとも、サーブレット内だけの話で、サーブレットから呼ばれるインスタンスでは >インスタンス変数は独立していると思ってよいでしょうか。 >後者の認識ですが、こういう書き方をされると、サーブレットから呼ばれた先でも >インスタンス変数が共有されると読めて、怖くて仕方ないです。 どう見ても、明らかに「インスタンス」を理解してないですよね。 (そしておそらくは「参照」も) 「サーブレットから呼ばれるインスタンス」って、そもそもインスタンスは 呼ぶものではありません。呼ぶことができるのは「インスタンスのメソッド」です。 揚げ足取りに見えるかもしれませんが、おそらくこのケースでは違います。 なぜなら、No.1の回答の方への「お礼」のところに、taiyaki123さんは 以下のように書いているからです。 >念のため質問内容が分かるようなソースをつけます。 >SampleClassで定義されているメンバー変数（staticではない変数）が、 >スレッド毎に共有されるかという質問です。 >servletclass extends HttpServet{ > public int a = 0; > public void doPost(){ > SampleClass sc = new SampleClass(); > } >} > >SampleClass{ > public int x = 0; >} >このようなプログラムがあったとします。 >このプログラムを複数の人が、同時にアクセスした場合に、 >SampleClassで定義されているメンバー変数のxが共有されるかという意味です。 >もちろん、共有されないという認識です。 新しいSampleClassをdoPost()のたびにnewしてるんだから、 共有されないのは当たり前です。サーブレットは何も関係ありません。 以下も。 http://oshiete.goo.ne.jp/qa/6438120.html >オブジェクトを作って実行するなら >testclass tc = new testclass(); >tc.method(); >というように２行です。 >オブジェクトを作らないなら、testclass.method() >というように１行です。 なにしろtaiyaki123さんはインスタンスを理解していないので、 インスタンスは、「メソッドを呼ぶときにnewするもの」でしかないのでしょう。 だから必要性もわからないし、「サーブレットから呼ばれるインスタンス」という トンチンカンな言葉も出てくる。 もしこの人がプロのJavaプログラマなのだとすれば(想像したくないですが)、 よく聞く、staticメソッドだけで開発している職場なのかもしれません。 インスタンスを理解していないので、「どのインスタンスのメソッドを呼ぶのか」と いう発想ができず、その場でnewして呼んでしまう。これは、私が以下のページで書いた 画面に線を引くたびにCanvasをnewした新人君と同レベルの発想です。 つまり、まったくのド素人です。 (いや、こんなのと一緒にしちゃ新人君に失礼ですが) 本来であれば、「疑りぶかい～」は、こういう人を対象読者としている はずなのですが…… サーブレットの件で当然の疑問を提示しているNo.1やNo.2の人に、 >ですので、以下の回答は間違いですね。 とか >まったくもって間違った回答ですね。 >サーブレットからインスタンスを呼ぶことができないなんて・・・。 とか答えて、せっかくのアドバイスを拒絶してしまうような人が相手では、 私の文章が理解されなかったのだとしても、私のせいではないでしょう。 http://oshiete.goo.ne.jp/qa/6402168.html このへんも、ねえ……

今見てみたのですが、 >評価関数がどこにあるかといえば、Eval02.javaにあります。 >これはEvaluateBoardインタフェースを実装しており、Eval00.javaとかEval01.javaと >差し替えられるようになっています。Eval02を実際にnewしてくっつけているのは >ReversiApplet.javaです。 Eval00.javaやEval01.javaの方が、Eval02.javaよりはずっと簡単なので、 読むならそちらの方がよいでしょう。

>評価、着手数、要素の計算などはどこでやっているのか教えてもらえないでしょうか？ 評価関数がどこにあるかといえば、Eval02.javaにあります。 これはEvaluateBoardインタフェースを実装しており、Eval00.javaとかEval01.javaと 差し替えられるようになっています。Eval02を実際にnewしてくっつけているのは ReversiApplet.javaです。 着手数や要石の計算は、このEval02.javaの中のscanLineで盤面を4方向にスキャンし、 フラグを立てています。以下のページに図があります。 http://kmaebashi.com/javaworld/index.html ただ、「学生」さんの現状のプログラムが、 >コンピュータの作成では、ランダムでしか対戦ができないため、 >コンピュータが強くないので強くしたいと思っている所です。 ランダムで(打てるところに?)打つ、というレベルなら、なにもこんな複雑な 評価関数をいきなり導入しなくてもよいのではないでしょうか。 …と、いうことを前回の返信で言いたかったのですが。

ご返信ありがとうございました。 >「学生」さんがどの程度のスキルをお持ちかわかりませんが、 > javaは本を一冊読んだ程度の実力です。 オセロゲームを現在、作成しています。 コンピュータの作成では、ランダムでしか対戦ができないため、 コンピュータが強くないので強くしたいと思っている所です。 リバーシゲームのアルゴリズムは検索して調べてみたのですが、 ソースを見ても詳しくわからないので 評価、着手数、要素の計算などはどこでやっているのか教えてもらえないでしょうか？

はじめまして。 >javaでオセロゲームを作っているのですが、リバーシゲームの思考ルーチンについて >ソースをダウンロードして見ているんですけど、よくわかりませんでした。 >どうやっているのかを詳しく教えていただけないでしょうか？ 「学生」さんがどの程度のスキルをお持ちかわかりませんが、 http://kmaebashi.com/javaworld/index.html このページで簡単に説明しているように、このリバーシゲームのアルゴリズムは ミニマックス法とαβ枝刈りです。 それぞれどんなものかについても上記ページにごく簡単に説明していますが、 もちろんこの説明ではわからないからこそここで質問されたのかと思います。 ミニマックス法とαβ枝刈りはこの手のゲームの思考ルーチンとしては ごく一般的なものなので、検索すれば解説ページは出てきます。 Wikipediaの解説もそんなに悪くないかも。 http://ja.wikipedia.org/wiki/%E3%83%9F%E3%83%8B%E3%83%9E%E3%83%83%E3%82%AF%E3%82%B9%E6%B3%95 αβ枝刈りも検索すれば出ますが、高速化の手段なので(しかもそんな 劇的に早くなるわけでもないので)、最初はなくてもよいかも。 あとは評価関数ですが、少々手抜きの評価関数でも、ある程度先読みすれば、 並の人間の相手は可能なぐらいの強さにはなります。 たとえば盤面の各マスに評価値を付けておいて(当然四隅が最大)、 自分の石があったらその値を加算、敵の意思があったら減算、ぐらいの 評価関数でもそこそこ遊べるようなものになった記憶があります。 私のリバーシゲームでは結構凝った評価関数を実装していますが、 実のところこれがよい評価関数なのか、私には判定できません。 私自身がこの手のゲームが得意でないため、自分の作ったプログラムに まるっきり勝てないので、評価関数を直しても、強くなったのか弱くなったのか 判定できないためです。 実は、私のプログラムの評価関数は、以前別件で作った「6×6オセロ」の 評価関数の焼き直しです。「6×6オセロ」のときは、評価関数同士を 戦わせたりしてまじめに検討したのですが、それを8×8に焼き直すときには、 まったく検証していません。手抜きです……

javaでオセロを作っているものですがよろしくお願いします。 javaでオセロゲームを作っているのですが、リバーシゲームの思考ルーチンについて ソースをダウンロードして見ているんですけど、よくわかりませんでした。 どうやっているのかを詳しく教えていただけないでしょうか？

>>オセロゲームですが、普通に一つのオブジェクトしかつくれないようなプログラムを書いておけば、サーブレットから起動されればそれぞれのオブジェクト（オセロ盤）が >>作られますから、マルチインスタンスを気にしなくてもよいと思います。 >>イメージ沸きますでしょうか。 > >すみません、イメージ沸きません。 >「普通に一つのオブジェクトしかつくれないようなプログラム」における >「プログラム」とはどのような単位ですか? >「サーブレットから起動」の「起動」とは、具体的にどういうことですか? >「起動」されたプログラムが終了するタイミングはいつですか? で、こちらについての回答はなしですか? 上記についても答えてもらいたいのですが、回答に時間がかかるかもしれないので、 追加で質問させてください。簡単に答えられるように選択式にしておきます。 たいやきさんは、今まで、サーブレットのプログラムを一度でも書いたことがありますか? a) 自分で全体を書いたことがある。(小さなテストプログラムのようなものでも可) b) 全体を書いたことはないが、仕事でチームで開発する等で、 c) 実際にコードを書いたことはない。ただ、本で勉強したことはある。 　(書名を書いてください) d) 書いたこともなければ本で勉強したこともない。

>そういう色んな経験やスキルがある人で、オブジェクト指向に挫折した人に、 >ちゃんと全てのオブジェクト指向の特徴とメリットを説明することが、 >アンチテーゼとしての役割だと思います。 知らんがな、としか言いようがありませんが。 うちのページが不満なら読んでいただかなくて結構ですし、 もっといい説明方法があると思うのなら、たいやきさんがご自分で Webでもなんでも書けばよいでしょう。 うちのページの趣旨は、「再入門」ですので、他の書籍やWebページの オブジェクト指向の説明において「欠けている」と私が感じた部分に 特化しています。 当時「マルチプルインスタンス オブジェクト指向」で検索しても 1件もヒットしなかったのが、今だと1000件以上ヒットします。 multiple instanceという言葉自体は一般的なものなので、この1000件 すべてが私の記事からの派生ではないと思いますが、それにしても 相応に需要はあったと言えると思います。 >>>継承には、重複コードを省くというメリットがあります。 >>>ポリモーフィズムには、ロジックの共通化というメリットがあります。 >私はこのメリットが正しいということに自信を持っています。 >また、そういう使い方をしているPGも回りにあります。 >また、書きませんでしたが、他にもメリットがあるとも思っています。 >私が言うメリットが正しいかどうかは置いておいて >ここで言いたかったのは、オブジェクト指向の３大特徴には、 >それぞれメリットがあって、それも説明しないと、オブジェクト指向の >説明としては不足であるということです。 >ですので、管理人様が間違っておられると思うのであれば、それはそれでいいと >思いますし、管理人様が思われるメリットを主張されればよいと思います。 >だた、継承やポリモーフィズムの説明をされる際には「今どきやらない」という >表現は誤解を生むと思います。 「今どきやらない」とは私は書いていません。 「今どきは、流行らない」と書いています。 まあ、これは実際紛らわしいですし、ひらがなで書いた私も悪いと思うのですが、 そもそも「継承やポリモーフィズム」について「今どきやらない」とも 「今どき流行らない」とも書いてはいません。ここで「今どき流行らない」と 書いているのはあくまで実装継承についてのみです。正しく読んでください。 で、 >>>継承には、重複コードを省くというメリットがあります。 実装継承については、かつては確かにもてはやされていた時代がありましたし、 便利な局面もあることはあるんでしょう(もちろん、デメリットの方が大きいと 判断されたからこそ流行らなくなったのですが)。 しかし、 >>>ポリモーフィズムには、ロジックの共通化というメリットがあります。 こっちについては実のところ意味がわかりません。 ポリモルフィズムで、どう、ロジックを共通化するのですか? 具体的な例を挙げて説明してください。 >私はこのメリットが正しいということに自信を持っています。 >また、そういう使い方をしているPGも回りにあります。 仕事のプログラムならそのまま提示することはできないと思いますが、 差し支えのない範囲で、どのようなコードを書いているか提示してもらえませんか? 興味があります。ここを見ている他の方もそうでしょう。

>こちらを見ていただくとわかるかと思うのですが、 >http://kmaebashi.com/programmer/object/othello.html > >「メンバー変数を隠したり、メンバー変数やメソッドをまとめたり」というのは、 >「疑りぶかい～」の想定読者は(たとえCで書いても)すでにやっているだろう、 >というのが前提です。 >この前提が正しいかどうかはよくわかりません。世間のCプログラマは、 >staticを使ってデータや関数を隠そうなどとは考えたこともない人が >大部分なのかもしれません。だとすれば、私がやっていることは効率の悪い方法だ、 >ということになるかと思います。 > >ただ、もしこの前提が正しいとするなら、そういうプログラマにカプセル化を >トクトクと語っても、「何だそんなことは俺もとっくにやってるよ」と思われるのが >オチです。 いいえ。そうではありません。 そもそも不思議なのが、なぜ、C言語をやってきた人（C言語に対するある程度 の知識があること）だけが対象なのでしょうか。 オブジェクト指向の理解に挫折した（このサイトを読む）人には、 今までC言語をやってきた人もいれば、やってきてない人もいます。 オブジェクト指向言語が始めてのプログラム言語の人もいると思います。 COBOLだけ知っている人もいると思います。 そういう色んな経験やスキルがある人で、オブジェクト指向に挫折した人に、 ちゃんと全てのオブジェクト指向の特徴とメリットを説明することが、 アンチテーゼとしての役割だと思います。 その特徴やメリットが、これまでのプログラム言語でも既に出来るのであれば、 それはその言語での特徴やメリットが、オブジェクト指向言語にも 連綿とひきつがれているんですと説明すればいいだけです。 そうすれば、「オブジェクト指向は今までの開発言語で出来ることやメリットも 継承しながら、新しい考え方や技術もとりいているんだよ」という事実が 分かってもらえると思います。その事実をちゃんと説明することが大切で、 「なんだそんなこととっくにやっているよ」という人だけを意識して説明することで、返ってオブジェクト指向を正しく理解してもら阻害になっていると感じます。 もし、C言語をやってきた人（C言語に対する知識がある程度ある方）向けの 説明であれば、「疑りぶかいあなたのためのオブジェクト指向再入門」という 名前の付け方や、書かれている内容は適切ではないと感じます。 すごく期待を持たせるようなタイトルであり、書き出しで オブジェクト指向の説明が不適切であることを指摘し、最適な説明を期待させる ような内容になっていながら、実は端にC言語との比較だけの説明になっています。 >>継承には、重複コードを省くというメリットがあります。 >>ポリモーフィズムには、ロジックの共通化というメリットがあります。 > >このメリットはどっちも間違っているような。 >少なくともいまどき実装継承ははやらないですし、ポリモルフィズムは >同じインタフェースで違うロジックを与える機能ですので(Template Methodパターン >みたいな使い方もあるにはありますが)。 私はこのメリットが正しいということに自信を持っています。 また、そういう使い方をしているPGも回りにあります。 また、書きませんでしたが、他にもメリットがあるとも思っています。 私が言うメリットが正しいかどうかは置いておいて ここで言いたかったのは、オブジェクト指向の３大特徴には、 それぞれメリットがあって、それも説明しないと、オブジェクト指向の 説明としては不足であるということです。 ですので、管理人様が間違っておられると思うのであれば、それはそれでいいと 思いますし、管理人様が思われるメリットを主張されればよいと思います。 だた、継承やポリモーフィズムの説明をされる際には「今どきやらない」という 表現は誤解を生むと思います。 もし、管理人様が世界中の全てのコードをみてそういわれているのであれば いいですが、そうではないと思いますから、このような狭い範囲での経験をもって 断定的な表現は、読む方に誤解を与えます。 今使われているかどうかというより、どういうメリットがあるかを一つ一つ正確に 伝えることが、一番正しく理解してもらえると思います。

>クラスには、メンバー変数を隠したり、メンバー変数やメソッドをまとめたり、 >オブジェクトをたくさんつくれるというメリットがあります。 こちらを見ていただくとわかるかと思うのですが、 http://kmaebashi.com/programmer/object/othello.html 「メンバー変数を隠したり、メンバー変数やメソッドをまとめたり」というのは、 「疑りぶかい～」の想定読者は(たとえCで書いても)すでにやっているだろう、 というのが前提です。 この前提が正しいかどうかはよくわかりません。世間のCプログラマは、 staticを使ってデータや関数を隠そうなどとは考えたこともない人が 大部分なのかもしれません。だとすれば、私がやっていることは効率の悪い方法だ、 ということになるかと思います。 ただ、もしこの前提が正しいとするなら、そういうプログラマにカプセル化を トクトクと語っても、「何だそんなことは俺もとっくにやってるよ」と思われるのが オチです。でも、クラスには、たいやきさんも挙げておられるように 「オブジェクトをたくさんつくれるというメリット」もあるので、 そこを無視して「何だそんなことは俺もとっくにやってるよ」と思われたら 先に進めない。「疑りぶかい～」でマルチプルインスタンスを強調している 意図はそこです。 継承やポリモルフィズムは、いずれ書こうと思ってほったらかしになっている、 というのが実態ではありますが、 >継承には、重複コードを省くというメリットがあります。 >ポリモーフィズムには、ロジックの共通化というメリットがあります。 このメリットはどっちも間違っているような。 少なくともいまどき実装継承ははやらないですし、ポリモルフィズムは 同じインタフェースで違うロジックを与える機能ですので(Template Methodパターン みたいな使い方もあるにはありますが)。 >オセロゲームですが、普通に一つのオブジェクトしかつくれないようなプログラムを書いておけば、サーブレットから起動されればそれぞれのオブジェクト（オセロ盤）が >作られますから、マルチインスタンスを気にしなくてもよいと思います。 >イメージ沸きますでしょうか。 すみません、イメージ沸きません。 「普通に一つのオブジェクトしかつくれないようなプログラム」における 「プログラム」とはどのような単位ですか? 「サーブレットから起動」の「起動」とは、具体的にどういうことですか? 「起動」されたプログラムが終了するタイミングはいつですか?

>JavaでServletを使う場合も、オセロ盤のインスタンスが複数作れないと、 >同時に複数の対戦を行うのはかなりやりにくくないですか? >たいやきさんがどのような作り方を想定しているのか具体的に >教えていただけると嬉しいです。 この質問に答える前に、私はオブジェクト指向が分かっているのか／分かってないのかすら分かりませんが、自分なりにオブジェクト指向とは、 「従来（非オブジェクト指向）のプログラミングを多少なりとも楽にする技術や概念の総称」だと理解しています。 そのオブジェクト指向の考え方を利用した技術や考え方として、フレームワーク、 ザインパターン、UML、オブジェクト指向プログラミングといった技術がありますが、 このサイトではオブジェクト指向プログラミングに焦点を当てておられるので、 それに特化してみると、クラス・継承・ポリフォーフィズムという３つの技術が あると思います。 クラスには、メンバー変数を隠したり、メンバー変数やメソッドをまとめたり、 オブジェクトをたくさんつくれるというメリットがあります。 継承には、重複コードを省くというメリットがあります。 ポリモーフィズムには、ロジックの共通化というメリットがあります。 この中にはオブジェクト指向でなくても出来る点はありますが、オブジェクト指向でも 使える訳で、これらを使うことにより、結果として、従来のプログラミングより 多少なりとも楽が出来るというのが、オブジェクト指向プログラミングだと思います。 これが正しいかどうかわかりませんが、仮りに正しいとすると、他の言語でも出来るとか、最初に覚えることではないとかではなく、 これらを一つ一つ丁寧に説明することが、「疑りぶかい人」へオブジェクト指向 をちゃんと説明することになると思っています。 他の説明を置いておいて、クラスのメリットであるオブジェクトをたくさん 作れることを主眼に置いて説明することは、「疑りぶかい人」にオブジェクト指向を 正しく理解してもらえることにはならないと思います。（私がそうでした。） このサイトは、下手なオブジェクト指向の説明にたいするアンチテーザとして作られた サイトだと思っていますので、このサイトを見た人がさらに挫折することの無いような工夫を期待します。 オセロゲームですが、普通に一つのオブジェクトしかつくれないようなプログラムを書いておけば、サーブレットから起動されればそれぞれのオブジェクト（オセロ盤）が 作られますから、マルチインスタンスを気にしなくてもよいと思います。 イメージ沸きますでしょうか。 　

>サービス毎に（要するに対局１件毎に）別プロセスを起動するってのは UNIX 系では >一般的手法と思う。 それはそうなんですが、たいやきさんの主張は以下なので、 「Servletを使ったとき」を想定しなければいけないでしょう。 >というのはJavaでサーバを動かすときには、servletを使うことが出来ますが、 >その場合はマルチにインスタンスが作れなくても（１つしかつくれなくても）、 >オンラインオセロのようなゲームは作れるためです。 Servletそのもののインスタンスは(少なくとも通常は)全体でひとつなので、 複数対戦をホストしたければBoardのインスタンスを複数作って セッション等からそれを参照するように作るのが自然なように思います。 >俺なら「盤面は先読み１手につき１個必要」と例示するかな・・・ >再帰深さ１段につき盤面１個を要するってことで。 これはわかります。私が作ったプログラムでも実際にそうなっています。 http://kmaebashi.com/javaworld/index.html ただ、これを理解するにはオセロの思考ルーチンに対する理解がある程度必要で、 そうなると本筋から離れてしまいますから、「複数対戦をホストするため」という ことにしました。 ただ、公開当時も「複数対戦をホストするなら、自分ならプロセス分ける」という 方もいらっしゃって、「思考ルーチンで先読みするためにも使いますし」と答えたら 「それなら納得できます」と言われたので、このあたり、どのような説明なら 納得できるかは個人差がありそうです。

たいやき氏ではないが一意見として サービス毎に（要するに対局１件毎に）別プロセスを起動するってのは UNIX 系では一般的手法と思う。 samba などでも接続１件につき１個 smbd が起動するわけで。 静的変数はプロセス毎に作られるものなので「対戦１件につき１プロセス」なら、 プロセス単位で盤面１個でも別に困らない、ってことではないかな・・・ 俺なら「盤面は先読み１手につき１個必要」と例示するかな・・・ 再帰深さ１段につき盤面１個を要するってことで。

ご意見をいただくのは歓迎ですし、「偉そうに」とか恐縮される必要は ないのですが、 >マルチプルインスタンスをオブジェクト指向の特徴としてあげるのはよいと >思いますが、オセロでの説明はやめたほうがよいのではと個人的に思っています。 >というのはJavaでサーバを動かすときには、servletを使うことが出来ますが、 >その場合はマルチにインスタンスが作れなくても（１つしかつくれなくても）、 >オンラインオセロのようなゲームは作れるためです。 JavaでServletを使う場合も、オセロ盤のインスタンスが複数作れないと、 同時に複数の対戦を行うのはかなりやりにくくないですか? たいやきさんがどのような作り方を想定しているのか具体的に 教えていただけると嬉しいです。

>迷惑ということはまったくありません。 ありがとうございます。でも、何かありましたら言ってください。 今は3Dグラフィックの組込を行っており、その一部の組み込み関数が８７個です。 それでもまだまだ少なく、まだ多くの組込関数が必要です。 今は、3Dのマトリックス演算処理に四苦八苦しています。 いま、数行のプログラムで画面に3Dキャラが出て踊ったりはしているのですが、 それ自体では、システムを作っている意味が全く見えないのが残念です。 意味を持って見せられるようになるのは、先が遠そうです。 ふと、vector　なり　Matrix　変数型を作りたいとも思ってしまいましたが、 これはでは、本来の目的と外れて本末転倒とも思ってしまいます。 （でも結局　sheet　変数型作ってるけどね） 気は焦りますが、またーりやっていきます。

管理者様 返信が遅くなり申し訳ありません。 ご回答くださりありがとうございます。 オブジェクト指向でインスタンスがたくさん作れることが特徴であることと、 その特徴によって複数人で同時アクセスできるシステムが作れること （例えばオンラインオセロ）は、まったく無関係だと思います。 マルチプルインスタンスがオブジェクト指向の特徴の一つであることに 異論はありませんが、その説明をオンラインオセロで説明されることは、 返ってオブジェクト指向を間違って説明している（もしくは誤解をさせる）ことに なると思います。 実は、私はオブジェクト指向がわかっておらず、このサイトを読ませていただいて、 オブジェクト指向を教えてくれる親切なサイトがあるんだなとずっと思っていました。 が、最近、オブジェクト指向の本質がわかるにつれ、このサイトの説明は怪しいな と思うようになりました。 マルチプルインスタンスをオブジェクト指向の特徴としてあげるのはよいと 思いますが、オセロでの説明はやめたほうがよいのではと個人的に思っています。 というのはJavaでサーバを動かすときには、servletを使うことが出来ますが、 その場合はマルチにインスタンスが作れなくても（１つしかつくれなくても）、 オンラインオセロのようなゲームは作れるためです。 マルチプルインスタンスの説明は、もっと単純に説明できますし、そのほうが 本当に分かってない人にはわかりやすいと思います。 せっかくご説明をいただいて、偉そうに申し訳ありません。 では、失礼します。

お久しぶりです。Diksamはすっかり放置してしまっていますが、そちらは 開発が進んでいるのですね。 >　また、日記みたいに書いてしまうかもしれません、問題がありましたら注意 >してください。でも、ここで書く事も１つのモチベーションになるので、ご迷惑 >でなければよろしくお願いいたします。 迷惑ということはまったくありません。 > {L"dummy", L"", 0}, > {L"push_int_1byte", L"b",8}, > {L"push_int_2byte", L"s",8}, > {L"push_int_4byte", L"i",8}, // 実際の値を持つ たぶん中身は全然違っていると思うのですが、バイトコードのニモニックには Diksamの痕跡が残っていますね。うれしいことです。

一年以上のお久しぶりです。８ヶ月ほど別のソフトを作っていたので、その間 何もしていませんでした。が、まだまだ作っています。 グラフィック部分をメインに作成しているので、なかなか見れる物ができません。 現在約４万５千行ほどのプログラムになっています。 　また、日記みたいに書いてしまうかもしれません、問題がありましたら注意 してください。でも、ここで書く事も１つのモチベーションになるので、ご迷惑 でなければよろしくお願いいたします。 言語のインプリメントですが色々変えすぎて、何を変えたか分からなくなるほ どです。 　まずはバイトコードが変わりました。 C++のwstringはやはり重たく、zwstringをオリジナルに作りました。 もちろんガーベージコレクションを必要としない可変長文字列変数です。 ↓がオペコードリストです。 {L"dummy", L"", 0}, {L"push_int_1byte", L"b",8}, {L"push_int_2byte", L"s",8}, {L"push_int_4byte", L"i",8}, // 実際の値を持つ {L"push_double_0", L"", 12}, {L"push_double_1", L"", 12}, {L"push_double_8byte", L"d",12}, // 実際の値を持つ {L"push_string_const", L"s",12}, // 文字列の位置NOを持つ０～ {L"push_null", L"", 8}, /**********/ {L"push_stack_int", L"s", 8}, // intローカル変数をスタックに {L"push_stack_double", L"s", 8}, // {L"push_stack_string", L"s", 12}, // {L"pop_stack_int", L"s", -8}, // スタックのintをローカル変数に {L"pop_stack_double", L"s", -8}, // {L"pop_stack_string", L"s", -12}, // /**********/ {L"push_static_int", L"s", 8}, // int静的変数をスタックに 予約 {L"push_static_double", L"s", 12}, // {L"push_static_string", L"s", 12}, // {L"pop_static_int", L"s", -8}, // スタックのintを静的変数に 予約 {L"pop_static_double", L"s", -12}, // {L"pop_static_string", L"s", -12}, // /**********/ {L"push_sheet", L"s", 8}, // sheet番号をスタックに {L"push_sheet_int ", L"s", 8}, // sheet変数をスタックに {L"push_sheet_double", L"s", 12}, // {L"push_sheet_str ", L"s", 12}, // {L"pop_sheet_int ", L"s", -24}, // スタックからsheet変数に {L"pop_sheet_double", L"s", -28}, // {L"pop_sheet_str ", L"s", -28}, // /**********/ {L"push_array_ref ", L"s", 8}, // 配列参照 {L"push_array_int ", L"s", -1}, // int配列処理 {L"push_array_double", L"s", -1}, // {L"push_array_string", L"s", -1}, // {L"pop_array_int ", L"s", -1}, // スタックからint配列に {L"pop_array_double", L"s", -1}, // {L"pop_array_string", L"s", -1}, // /**********/ {L"and_int", L"", -8}, // 以下は総て算術演算子 {L"or_int", L"", -8}, {L"xor_int", L"", -8}, {L"add_int", L"", -8}, {L"add_double", L"", -12}, {L"add_string", L"", -12}, {L"sub_int", L"", -8}, {L"sub_double", L"", -12}, {L"mul_int", L"", -8}, {L"mul_double", L"", -12}, {L"div_int", L"", -8}, {L"div_double", L"", -12}, {L"mod_int", L"", -8}, {L"mod_double", L"", -12}, {L"minus_int", L"", 0}, {L"minus_double", L"", 0}, {L"increment", L"", 0}, {L"decrement", L"", 0}, // ここまで算術演算子 /**********/ {L"cast_int_to_double", L"", 4}, // 以下はキャスト処理 {L"cast_double_to_int", L"", -4}, {L"cast_string_to_int", L"", -4}, {L"cast_string_to_double", L"", -0}, {L"cast_boolean_to_string", L"", 4}, {L"cast_int_to_string", L"", 4}, {L"cast_double_to_string", L"", 0}, // ここまでキャスト処理 /**********/ {L"eq_int", L"", -8}, // 以下は総て論理演算子 {L"eq_double", L"", -16}, {L"eq_string", L"", -16}, {L"gt_int", L"", -8}, {L"gt_double", L"", -16}, {L"gt_string", L"", -16}, {L"ge_int", L"", -8}, {L"ge_double", L"", -16}, {L"ge_string", L"", -16}, {L"lt_int", L"", -8}, {L"lt_double", L"", -16}, {L"lt_string", L"", -16}, {L"le_int", L"", -8}, {L"le_double", L"", -16}, {L"le_string", L"", -16}, {L"ne_int", L"", -8}, {L"ne_double", L"", -16}, {L"ne_string", L"", -16}, // ここまで論理演算子 {L"logical_and",L"", -8}, // {L"logical_or", L"", -8}, // {L"logical_not",L"", 0}, // /**********/ {L"pop", L"", -8}, // スタックを1つ減らす {L"duplicate", L"", 16}, // スタック内容をコピーしてスタックに {L"jump", L"s", 0}, // 指定ポインターにjump {L"jump_if_true", L"s", -8}, // スタックがtrueならjump {L"jump_if_false", L"s", -8}, // スタックがfalseならjump {L"nop------------",L"", 0}, // nop /**********/ {L"push_function", L"", 0}, // 関数情報をスタック、未使用 {L"call_function", L"ssss", 0}, // 関数コール {L"return", L"", -1}, // 関数戻り /**********/ {L"set_array_literal_int", L"ss", 0}, // int定数配列を変数にコピー {L"set_array_literal_double",L"ss", 0}, // double定数配列を変数にコピー {L"set_array_literal_string",L"ss", 0}, // string定数配列を変数にコピー また、メイン関数も１つのスレッドになり、待機リターンをしてVMを保持しないようにしました。 　↓例 //===================================================================== // 最初に実行されるmein関数 //===================================================================== int main(int qid,int p1) { if(qid == スレッド開始) { main_init(); return スレッド待機; } elsif(qid == 終了指示) { return スレッド終了; } return スレッドエラー終了; } また、配列操作のバイトコードもよりシンプルになり　２/３以下のバイトコードになりました。 シートの宣言も関数外で↓のようにラベル宣言するようにしました。 sheet s_system[10][20]; // システム設定のシート定義（変更不可） sheet s_key_input[2][256]; // キー入力定義（変更不可） sheet s_mouse_input[2][11]; // マウス入力定義（変更不可） sheet s_pad_input[8][20]; // パッド入力定義（変更不可） 初期バージョン完成にはまだまだかかりそうです。

>今頃だったら md5 でなく sha1 にするともう少しマシになるかもしれない。 sha1ですか。覚えておきます！

この種のセキュリティって奴を考察する上では、 ・誰から何を守るのか ・かかるコストが効果に見合うか を考えないと意味がない。 正規の管理人が平文パスワードを（見たくないのに誤って）見てしまうこと対策 掲示板運営している httpd サーバに侵入されて掲示板ソースだけ盗まれた場合の対策 遠隔地からデーターベースに侵入されてデータだけ盗まれた場合の対策 httpd と DB 両サーバに侵入されてソース＋データが両方盗まれた場合の対策 下に行くほど、なさそうなシナリオ＋被害大、なわけだが ・現実的にありえないような状況に対する施策のために 　コスト（金銭的、手間的）をどこまでかける必然があるか？ の線引きになるだけのこと。 掲示板ソフト上の固定文字＋乱数 salt ＋ユーザーパスワード、ってのは現実的解だと思う。 今頃だったら md5 でなく sha1 にするともう少しマシになるかもしれない。

>また、データベースの中身を覗けている時点で、悪人はPHPのソースを見て >「秘密」の文字列を見ることができている可能性が高いような気もします。 >その場合には、「秘密」は役に立たないということになります。 ここは懸念ですね。ソースに記述しない方法ってあったりするのかな！

774RRさん、毎回ありがとうございます。 それだけでは何なので蛇足ですが。 こちらに以下のような説明がありますが、 http://kmaebashi.com/programmer/bbs_dev/delete.html | また、こうしておくことで、掲示板を運営しているサーバが万一クラックされたり、 | レンタルサーバ業者がD/B情報を漏洩させたりしたときにも、投稿者のパスワードを | 守ることができます。 | なお、いくらMD5アルゴリズムが逆方向の推測が困難だといっても、辞書攻撃や | 総当り攻撃により破られる可能性はあります。そこで、上のソースでは、 | パスワードに対し秘密の文字列(赤字部分)を連結しています。もちろん実際の | ソースでは、ここには「秘密」という文字列ではなく、推測されにくいでたらめな | 文字列が書かれています。こうしておけば、そのでたらめな文字列がばれない限り、 | パスワードそのものを推測することはできません。 saltの話はひとまず除外し、「秘密」についてだけ考えます。 もしこの「秘密」文字列をくっつけなかったとすると、 データベースの内容が悪人に漏洩した場合、悪人は、辞書等の単語に 片っ端からMD5をかけることでパスワードの推測が可能な場合があります。 ちょっと昔のUNIXでは、パスワードに1方向ハッシュをかけた文字列を そのまま(誰にでも見える形で!)保存していて、私も一度、とあるサーバにて、 「ユーザIDと同じパスワードを使っている人」がいないか調べてみたら ぼろぼろ見つかってしまった、ということがありました。 ユーザIDと同じパスワードは論外として、辞書攻撃的なものには「秘密」は 有効ですが、「総当り攻撃」に対しては、本質的には「程度問題」の防御にしか なりません。もっとも文字列長が増えるので、この「程度問題」はかなり 大きな「程度問題」ですけれども。 また、データベースの中身を覗けている時点で、悪人はPHPのソースを見て 「秘密」の文字列を見ることができている可能性が高いような気もします。 その場合には、「秘密」は役に立たないということになります。

課題１まで理解した上で質問しました。 わかりやすい説明でありがとうございます。 議論の板を読んで、 "秘密"は任意で良いとなんとなく思ってましたが、 確信できずに調べても出てこなかったです。 何度も回答していただいてすみません。

salt の役割を理解していればそんな質問最初から出ないと思うが・・・ 先に挙げた掲示板上の議論の詳細は読んで理解できた？ 課題１：パスワードを平文（ひらぶん）で保存するのはユーザにとっても管理人にとってもうれしくない 解決策：パスワードを１方向ハッシュで保存したらいい １方向ハッシュとして MD5 アルゴリズムを使うとしたら md5($password) でいい # そもそも１方向ハッシュって何か？の解説は略 ここまで大丈夫？これが理解できていないのであれば以下の話は読むだけ無駄。 課題２：データベースクラックされてハッシュ化されているパスワードが漏れたら、 そのときのセキュリティをどう担保すればいい？ 解決策：パスワードだけを md5 すると「md5 辞書アタック」で破られうるので、 パスワードに別の文字をくっつけたら「破るコストが跳ね上がる＝破られない」。 そのために「くっつける文字」というのを用意するとよい (これが salt) PHP では文字列の連結に . を使う。"hoge" . "piyo" は連結されて "hogepiyo" になる。 http://www.php.net/manual/ja/language.operators.string.php ユーザーが入力したパスワード (例： "hoge") に 掲示板ソフトが用意した乱数文字列 salt (例： "piyo") をくっつけて md5("hogepiyo") としてハッシュ値を保存すれば、 データーベースがクラックされてハッシュ結果と salt の "piyo" が漏れても 元パスワード "hoge" を取り出すコストは膨大なものになる＝破りにくい。 # 実用的時間のうちに破ることができないのであれば、破られないと言い切っていい。 先の hash_user_password は「ユーザの入力したパスワード」「ソフトが乱数で用意した salt 」の他に 「掲示板プログラムをインストールするごとに変えられるカスタマイズ可能文字 "秘密"　」をくっつけている。 だから "秘密" のところには何を入れてもいい。

54: function hash_user_password($src, $salt) { 55: $dest = md5("秘密" . $src . $salt); 56: 57: return $dest; 58: } 以上の”秘密”のところに何を入れればいいでしょうか。 hash_user_passwordは$src, $saltの値が入力され、$destを出力すると 自分の理解はここまでですが、色々調べても乱数$saltを使ったMD5関数の使い方は見つからなかったです。 どうか教えてください。

返信が遅くなりましてすみません。 また、774RRさん、回答ありがとうございました。 >このページにある「messageテーブル」についてですが、 >password項目が二個並んでいるのはどうしてでしょうか。 >↓ >password varchar(64) パスワード >password varchar(64) パスワードのsalt このページの記述がこうなってしまっているのは単なる誤植ですね。 修正しました。ご指摘ありがとうございました。

>片方はパスワードではなくて salt であって、要するにただの乱数。 >そのページの最後のほう、およびリンクのある掲示板上の議論参照。 > >salt という乱数を追加することでクラッキングがしづらくなるということ。 分かりました。 項目名をsaltに修正してcreate文が正常終了しました。 ありがとうございます。

片方はパスワードではなくて salt であって、要するにただの乱数。 そのページの最後のほう、およびリンクのある掲示板上の議論参照。 salt という乱数を追加することでクラッキングがしづらくなるということ。

質問です。 http://kmaebashi.com/programmer/bbs_dev/delete.html このページにある「messageテーブル」についてですが、 password項目が二個並んでいるのはどうしてでしょうか。 ↓ password varchar(64) パスワード password varchar(64) パスワードのsalt 宜しくお願いします。

勉強用に使わせていただいています。 初心者なので、とりあえず動くものが欲しいという段階です。 ご親切にありがとうございます。

>get_cssの処理内容を貼ってください。 まあ貼るのはかまいませんけど、 get_css()がないのであれば、そこはひとまずべた書きにしてしまっても 構わないところですよね。 function get_css($board_id) { $sql_str = sprintf("select css from board where boardid='%s'", $board_id); $result = mysql_query_or_die($sql_str); if (mysql_num_rows($result) != 1) { die("掲示板のIDが変です。"); } $row = mysql_fetch_assoc($result); return $row["css"]; } 件のページでは、掲示板のソースを固めたものをダウンロード用として置いていません。 なぜかというと、私にとってあの記事の位置づけは「作り方の解説記事」であり 「掲示板スクリプトの配布ページ」ではないためです。 もちろん何を作るにも実際に動くものを動かしながら勉強する方が身につくものですし、 読者側からすれば動くソースを配布して欲しいという要望があるのもわかるのですが、 まるごと持っていった人にサポートを要求されたりバグの損害賠償を求められたり したらかなわないよな、ということで、現状のようにしています。ご了承ください。 あと、PHP4ですし、いろいろな意味で古くなってしまった記事でもあります。 ご利用は自己責任でお願いします。

phpとmysqlで掲示板作成してみていますが、 「get_cssのfunctionが定義されていない」というエラーが出ました。 確認したところ、 util.phpに定義されていないです！！！ get_cssの処理内容を貼ってください。 宜しくお願いします。

オブジェクト指向という「概念」＝抽象 実際のプログラミング言語という「実装」＝具体 とがごっちゃになっているからわけわからん気味なのだと思うが C++ なり Python なり「オブジェクト指向を意識した言語」では 「対象物」を示す this や self が言語仕様上必須になっているため、 プログラマが引数の形で明示しなくても「何を対象に」が自動的に表現される ＝対象指定を欠くことができない ＝対象を暗示的に使う C の strtok のようなものは実装しづらい だけなのだと思う。 対象を指定することが強制されるってことはすなわち「対象が複数個数あるのが前提」 ＝マルチプルインスタンスであることは前提条件、当たり前である のだと思う。 C では「言語仕様上」 this が必須でない ＝「言語仕様上は」対象を明示しなくてもよい、ってだけで プロジェクトの運用方針などで「第一引数を hogehoge* にすること必須」と決めてしまえば それで十分オブジェクト指向なプログラムは可能。 言語側でのネイティブサポートがあるかないか、の違いでしかないと思うの心

>※C言語では問題という説明でしたよね。strtok()関数の実装[関数仕様]の問題でC言語で不可能という話ではないと思います。 「C言語で不可能」と書いたおぼえはないですが…… 「C言語では問題」と書いたおぼえもないですが…… 「Cの流儀では多くの場合こう書くのではないか」という想定はある程度置いていますけど。 >strtok2( STR, getid, delimiter ); >strtok2( NULL, id, delimiter ); http://kmaebashi.com/programmer/object/othello.html 上記のページで、 void board_put(Board *board, int x, int y, int senteOrGote); というCの関数に対し、 「---つまり、これがオブジェクト指向です。」 と書いています。 同様のことを以下のページでも書いています。 http://kmaebashi.com/programmer/c_yota/module.html >XXX_hoge(XXX_Instance xxx, 第2引数, 第3引数); >敢えて大雑把な言い方をすれば、要するにこれがオブジェクト指向です。 >継承を考えない限りにおいては、 C++でもJavaでも、要するにやってることは >インスタンスのポインタを第1引数に持って回ってるだけのことであって、 >あとは、表記法が若干異なるのと、メソッドの名前空間が異なる程度の話です。 >実例としては昔のSunOSに付属していたSunViewというウィンドウ環境がありました。 私はSunViewはほぼ触ったことがありません。その後のXViewは割と使いました。 Xtはもっと使ってます。 で、このへんのライブラリは、「Cで無理やりオブジェクト指向を実現した例」 だと思っています。 http://kmaebashi.com/programmer/c_yota/inherit.html 私の認識と、「偏」さんの認識はたいへんに近いと思うので、反論(?)の 必要はないですよね。

はじめまして。 >こちらにStringTokenizerの例を出しましたが、これはどうでしょうか? >http://kmaebashi.com/programmer/object/shigoto.html > >StringTokenizerはCのstrtok()と違って、プログラムの複数の箇所から同時アクセス >できる(というよりは、よそで使われているかどうかを意識せずに使うことができる) >わけです。 それって、strtok()がそういう使い方に配慮されてないだけに思えます。 ※C言語(非インスタンス化言語)だからできないという話とすり替えられているように感じました。 ※strtok()はそんな実装なので、それが保証できない時には別途用意したこっちの関数使おうねで良さそうに感じました。 オブジェクト指向が必要ないといいたい訳ではなく、旧来のC言語でも問題なく処理できる(ライブラリ化可能)と思います。 ※C言語では問題という説明でしたよね。strtok()関数の実装[関数仕様]の問題でC言語で不可能という話ではないと思います。 strtok2( STR, getid, delimiter ); strtok2( NULL, id, delimiter ); と呼び出し手順(IF)を変えてstrtok2内部でSTRを複数保持するようにする事で可能となりますよね。 StringTokenizerのインスタンスとして保持している情報をstrtok2()内部で保持してやる。 char coloncol[]="abc:cde:efg:ghij"; char commacol[]="abc,cde,efg,ghij"; char *result; int idcol, idcom; result = strtok2( coloncol, &idcol, ':' ); result = strtok2( NULL, idcol, ':' ); result = strtok2( commacol, &idcom, ',' ); result = strtok2( NULL, idcol, ':' ); result = strtok2( commacol, idcom, ',' ); result = strtok2( commacol, idcom, ',' ); ※実際使うにはインスタンスの開放的なIFも追加する事になるかと >また、たとえば大昔のBASICやHSPとかでは、画面に線を引く命令が、ウインドウを >引数に取りません。まあ、大昔のBASICにはマルチウインドウがなかったから >当然かもしれませんが、オブジェクト指向的に考えれば、最初から「ウインドウ」という >クラスを作り、複数のウインドウを開けるようにするのではないでしょうか。 実例としては昔のSunOSに付属していたSunViewというウィンドウ環境がありました。 C++が作られるより古い時代ですが、例えばPanelCreate()関数でPanelObjectを作る(もちろん複数可)感じでC言語のライブラリ使い実現されてましたよ。 ※WindowやPanelやItemやCanvasやと色々な部品がありました。同じ種類を複数生成する事もできましたよ。 ※SunOS3.x, SunOS4.xで使えた記憶が。4ではX11ベースのOpenWindowへの移行が推奨されてましたが。

はじめまして。 >しかし、複数の人が同時アクセス出来ることがメリットの一つであるのであれば、 >それはそれで納得できます。 オセロでは確かにそういう例を出しましたが、「複数の人(人間)が」と言ってしまうと、 適用範囲がずいぶん狭くなってしまうように思います。 こちらにStringTokenizerの例を出しましたが、これはどうでしょうか? http://kmaebashi.com/programmer/object/shigoto.html StringTokenizerはCのstrtok()と違って、プログラムの複数の箇所から同時アクセス できる(というよりは、よそで使われているかどうかを意識せずに使うことができる) わけです。 また、たとえば大昔のBASICやHSPとかでは、画面に線を引く命令が、ウインドウを 引数に取りません。まあ、大昔のBASICにはマルチウインドウがなかったから 当然かもしれませんが、オブジェクト指向的に考えれば、最初から「ウインドウ」という クラスを作り、複数のウインドウを開けるようにするのではないでしょうか。 もちろん、オブジェクト指向のメリットはこれだけではなくて、継承やら多態も あるのですけれど、そのあたりは他の本とかにも書いてあるということ、 特に継承についてはあまりいい例題がないということから放置してしまっています。 すみません。

疑り深いあなたのためのオブジェクト指向を読ませていただきました。 読んでいくなかで、自分のマルチプルインスタンスに対する知識や理解と、 記載されていることに差異があるように感じました。 どちらが正しいかは別として、まえばし様が記載されている内容を理解した上で、 どちらが正しいのか自分なりに判断したく、まえばし様が記載されている内容を、 私が正しく理解しているかどうか確認させていただければ幸いです。 オブジェクト指向の本質は、マルチプルインスタンスだと記載されており、 その後の説明で、オセロ盤を用いての説明で、C言語では、 （盤面ごとに別プロセスを立ち上げない限り）複数の人が同時アクセスして 使えるようなアプリは作れない（もしくは作りづらい）と書かれている という認識です。 そして、オブジェクト指向型であれば、複数のインスタンス（＝盤面）が作成 出来るので、複数の人が同時アクセスするオセロが作れると記載されていると 理解しています。 もし、この理解が正なのであれば、マルチプルインスタンスの必要性やメリットが なんなのかを考えると、マルチプルインスタンスのメリットの一つは、複数の人が 当時アクセス出来るアプリを作ることが出来るアーキテクトであるということに なると思っています。 逆に、C言語のようなものは、複数の人が同時アクセスして動くアプリが作れない （つくりにくい）という特徴を持っていると理解したのですが、その認識は あっていますでしょうか？ 私は、マルチプルインスタンスを作ることが出来るのがオブジェクト指向の 特徴であることは理解していますが、では、マルチプルインスタンスが作れる メリットは何なのかと考えると、一向に分かりません。 しかし、複数の人が同時アクセス出来ることがメリットの一つであるのであれば、 それはそれで納得できます。 よろしくお願いします。

>すみませんが、この掲示板の作成とは具体的にどういうことでしょうか？ >一応、ｄｂは作ったのですが、データを作成するといったことでしょうか？ こちらを参照してください。 http://kmaebashi.com/programmer/bbs_dev/newbbs.html 具体的には、boardテーブルにレコードをひとつ作る作業となります。

> >よって、ご自分で試されるのであれば、先に掲示板の作成を行ってから >その掲示板のIDを指定するようにしてください。 前橋さま 早速のご返答、感謝しています。 当方は、メインフレーム、ＡＳ／４００などのプログラミングをブラジルで仕事としてやっていましたが、今後はオープン系のプログラミングを趣味もかねて勉強していこと思っているものです。　 すみませんが、この掲示板の作成とは具体的にどういうことでしょうか？ 一応、ｄｂは作ったのですが、データを作成するといったことでしょうか？

from.phpの中の下記のところで　"urlが変です。"と画面にでてきて、処理が先に進まない状態なのですが、進めるにはどうしたらいいのでしょうか？ > > 11: if (!isset($_GET["boardid"])) { > 12: die('URLが変です。'); > 13: } 以下のページにも書いてありますが、 http://kmaebashi.com/programmer/bbs_dev/spec.html この掲示板は、仕様として boardid="掲示板のID" というように、掲示板のIDを渡すようにしています。 今あなたが見ているこの掲示板も、 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs という形で、「kmaebashibbs」という掲示板のIDを渡しています。 テスト投稿用のテスト用掲示板も用意していますが、そのURLはこうです。 http://kmaebashi.com/bbs/list.php?boardid=testbbs よって、ご自分で試されるのであれば、先に掲示板の作成を行ってから その掲示板のIDを指定するようにしてください。

php初心者ですが宜しくお願いします。 いま、このサイトに記載している投稿フォームのプログラムを勉強中なのですが、from.phpの中の下記のところで　"urlが変です。"と画面にでてきて、処理が先に進まない状態なのですが、進めるにはどうしたらいいのでしょうか？ 11: if (!isset($_GET["boardid"])) { 12: die('URLが変です。'); 13: } 教えて頂ければ幸いです。よろしくお願いします。

>minGW でなきゃならない、ってことは無いので cygwin でも問題ないはず。 >現にウチでは問題ないし。 >まあなんにせよ minGW が欲しいのなら http://www.mingw.org/ > >> exeファイルはできるのですがなぜかcommand not foundとなってしまいます。 >どう作った？どう起動した？ >UNIX 系 OS ではセキュリティ的配慮として、標準設定では >カレントディレクトリはコマンド検索パスに含まれない。 >#1621 と同様　gcc -o mycalc y.tab.c lex.yy.c と入力したのであれば >(cygwin の場合) a.exe というファイルが作成される。 >これを起動しようとして a<enter> と入力しても command not found になる。 > >$ ./a.exe <enter> のように どっと すらっしゅ を明示指定し、 >「カレントディレクトリにある a.exe を起動する」とするとよいはずだ。 > ありがとうございます！./で何とか起動しました。 それにしてもなぜ気づかなかったのか？わからないです。

>#1621 と同様　gcc -o mycalc y.tab.c lex.yy.c と入力したのであれば >(cygwin の場合) a.exe というファイルが作成される。 ああ、大嘘 (爆) mycalc.exe というファイルが生成されるんだけど、 これを起動しようとして mycalc <enter> と入力すると以下略。

minGW でなきゃならない、ってことは無いので cygwin でも問題ないはず。 現にウチでは問題ないし。 まあなんにせよ minGW が欲しいのなら http://www.mingw.org/ > exeファイルはできるのですがなぜかcommand not foundとなってしまいます。 どう作った？どう起動した？ UNIX 系 OS ではセキュリティ的配慮として、標準設定では カレントディレクトリはコマンド検索パスに含まれない。 #1621 と同様　gcc -o mycalc y.tab.c lex.yy.c と入力したのであれば (cygwin の場合) a.exe というファイルが作成される。 これを起動しようとして a<enter> と入力しても command not found になる。 $ ./a.exe <enter> のように どっと すらっしゅ を明示指定し、 「カレントディレクトリにある a.exe を起動する」とするとよいはずだ。

はじめまして。Tadashiと申します。非常に初歩的な質問で申し訳ないのですが、MinGW-5.1.4.exeがある場所がわかりません。記載のサイトにアクセスしてみましたが見つかりませんでした。しかたがないのでCygwinで電卓を作成してみたのですが、exeファイルはできるのですがなぜかcommand not foundとなってしまいます。

>前橋様、 なるほどです。ありがとうございます。 >>管理者削除後、日付順インデックスに、「管理者削除」を表記するためのadmindeletedindex.phpのソースが見当たらないので、ソースを教えていただけないでしょうか？　よろしくお願いいたします。 > >たいしたものではありませんがいちおう貼っておきます。 > ><tr> ><td align="right">[<?=$serialid?>]</td> ><td> > <a href="./list.php?boardid=<?=$board_id?>&from=<?=$serialid?>&range=1"> > 管理者により削除されました > </a> ></td> ></tr> > >

>管理者削除後、日付順インデックスに、「管理者削除」を表記するためのadmindeletedindex.phpのソースが見当たらないので、ソースを教えていただけないでしょうか？　よろしくお願いいたします。 たいしたものではありませんがいちおう貼っておきます。 <tr> <td align="right">[<?=$serialid?>]</td> <td> <a href="./list.php?boardid=<?=$board_id?>&from=<?=$serialid?>&range=1"> 管理者により削除されました </a> </td> </tr>

前橋様、こんにちは。 前橋様の、「PHPとMySQLで掲示板を作る」を拝見させていただき、掲示板を作らせていただいてる者です。 本当にありがたく拝見させていただき、勉強させてもらいながら、悪戦苦闘しながら作っています。本当に感謝しております。 つまづいてる箇所がありまして、前橋様にお願いがあります。 管理者削除後、日付順インデックスに、「管理者削除」を表記するためのadmindeletedindex.phpのソースが見当たらないので、ソースを教えていただけないでしょうか？　よろしくお願いいたします。

>http://kmaebashi.com/programmer/devlang/book/hosoku.html >不動になってますが浮動でしょうね(３箇所) > >http://kmaebashi.com/taiatari/seigo.html >p.333 scanf は変換個数ではなく代入個数を返す >（http://kmaebashi.com/seiha/seigo.html こっちは修正済み） ご指摘ありがとうございます。2点とも修正しました。 いやもうなんといいますか本当に、いつもお世話になってます(_o_)

http://kmaebashi.com/programmer/devlang/book/hosoku.html 不動になってますが浮動でしょうね(３箇所) http://kmaebashi.com/taiatari/seigo.html p.333 scanf は変換個数ではなく代入個数を返す （http://kmaebashi.com/seiha/seigo.html こっちは修正済み）

おお、よかったですな。 これに懲りずにいろいろ遊んでみてください。

>俺んところでは MinGW をインストールした履歴は無いのでうまく動くのかもしれない。 >特に理由が無ければ MinGW 系をアンインストールしてみるといいかもしれない。 >ないしは cygwin をアンインストールして MinGW だけにしてみるか。 うわー出来ました！！ アドバイス通りcygwinをアンインストールしてMinGWの方だけで設定したら出来ました。 本当にありがとうございます。 仰られた通りどっちも読み込んでいた（？）のが原因だったみたいです。 みなさんお忙しいなか何度もアドバイスをありがとうございました。 これからまた色々試してみたいと思います。

俺んところと以下の二箇所が違うね・・（メモリ容量の数値とかは無視） >ignoring nonexistent directory "C" こちらは今回のエラーに直接関係なさそうなので無視してよいと思われる。 >#include <...> search starts here: >\MinGW\include こっちが問題の原因であろうと推測される。俺んところではこの行 (\MinGW\include) が無い。 cygwin 1.7 で MinGW のサポートが打ち切られているはずなので MinGW の関連ファイルを探してしまうのはあまりよろしくないのでは・・・ Q1.過去に minGW をインストールした？ Q2.cygwin setup で gcc-mingw gcc-mingw-core とかインストールした？ 俺んところでは MinGW をインストールした履歴は無いのでうまく動くのかもしれない。 特に理由が無ければ MinGW 系をアンインストールしてみるといいかもしれない。 ないしは cygwin をアンインストールして MinGW だけにしてみるか。

>ちなみに gcc --version と入力したときになんて表示される？ >ウチでは gcc (GCC) 4.3.4 20090804 (release) 1 になっている。 全く同じバージョンでした。 ので出力されたhoge.txt載せますね。 gcc: 2: No such file or directory Using built-in specs. Target: i686-pc-cygwin Configured with: /gnu/gcc/releases/respins/4.3.4-3a/gcc4-4.3.4-3/src/gcc-4.3.4/configure --srcdir=/gnu/gcc/releases/respins/4.3.4-3a/gcc4-4.3.4-3/src/gcc-4.3.4 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --infodir=/usr/share/info --mandir=/usr/share/man --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --with-slibdir=/usr/bin --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686 --with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind --with-ecj-jar=/usr/share/java/ecj.jar Thread model: posix gcc version 4.3.4 20090804 (release) 1 (GCC) COLLECT_GCC_OPTIONS='-v' '-o' 'mycalc.exe' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1.exe -quiet -v -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/lib/../../include/w32api y.tab.c -quiet -dumpbase y.tab.c -mtune=generic -march=i686 -auxbase y.tab -version -o /cygdrive/c/DOCUME~1/user-1/LOCALS~1/Temp/ccyoqpc6.s ignoring nonexistent directory "C" ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/include" ignoring duplicate directory "/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/lib/../../include/w32api" #include "..." search starts here: #include <...> search starts here: \MinGW\include /usr/lib/gcc/i686-pc-cygwin/4.3.4/include /usr/lib/gcc/i686-pc-cygwin/4.3.4/include-fixed /usr/include /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../include/w32api End of search list. GNU C (GCC) version 4.3.4 20090804 (release) 1 (i686-pc-cygwin) compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version 4.3.1, MPFR version 2.4.1-p5. GGC heuristics: --param ggc-min-expand=45 --param ggc-min-heapsize=28600 Compiler executable checksum: f80f2b86ee4951059548b57e98331af2 COLLECT_GCC_OPTIONS='-v' '-o' 'mycalc.exe' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/as.exe -v -o /cygdrive/c/DOCUME~1/user-1/LOCALS~1/Temp/ccVAFJ0o.o /cygdrive/c/DOCUME~1/user-1/LOCALS~1/Temp/ccyoqpc6.s GNU assembler version 2.20.51 (i686-cygwin) using BFD version (GNU Binutils) 2.20.51.20100410 COLLECT_GCC_OPTIONS='-v' '-o' 'mycalc.exe' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1.exe -quiet -v -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/lib/../../include/w32api lex.yy.c -quiet -dumpbase lex.yy.c -mtune=generic -march=i686 -auxbase lex.yy -version -o /cygdrive/c/DOCUME~1/user-1/LOCALS~1/Temp/ccyoqpc6.s ignoring nonexistent directory "C" ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/include" ignoring duplicate directory "/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/lib/../../include/w32api" #include "..." search starts here: #include <...> search starts here: \MinGW\include /usr/lib/gcc/i686-pc-cygwin/4.3.4/include /usr/lib/gcc/i686-pc-cygwin/4.3.4/include-fixed /usr/include /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../include/w32api End of search list. GNU C (GCC) version 4.3.4 20090804 (release) 1 (i686-pc-cygwin) compiled by GNU C version 4.3.4 20090804 (release) 1, GMP version 4.3.1, MPFR version 2.4.1-p5. GGC heuristics: --param ggc-min-expand=45 --param ggc-min-heapsize=28600 Compiler executable checksum: f80f2b86ee4951059548b57e98331af2 COLLECT_GCC_OPTIONS='-v' '-o' 'mycalc.exe' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/as.exe -v -o /cygdrive/c/DOCUME~1/user-1/LOCALS~1/Temp/ccEYJmqj.o /cygdrive/c/DOCUME~1/user-1/LOCALS~1/Temp/ccyoqpc6.s GNU assembler version 2.20.51 (i686-cygwin) using BFD version (GNU Binutils) 2.20.51.20100410

>管理人の前橋です。はじめまして。 >しばらくこちらを見ていなくて、反応が遅くなりましてすみません。 はじめまして。お返事ありがとうございます。 >ここ↑からダウンロードしたファイルに含まれているmake.batやmake.shを >使わず、手作業でyacc(bison?)やlex(flex?)も動かしたということでしょうか? そうですね。bisonとflexを手入力で動かしました。そこではエラーは出ないのですが、 gcc -o mycalc y.tab.c lex.yy.c の所で以下の様なエラーが表示されます。 /cygdrive/c/DOCUME~1/Temp/ccxzh81W.o:y.tab.c:(.text+0x8e): undefined reference to `__imp__iob' /cygdrive/c/DOCUME~1/Temp/ccxzh81W.o:y.tab.c:(.text+0xc2): undefined reference to `__imp__iob' /cygdrive/c/DOCUME~1/Temp/ccxzh81W.o:y.tab.c:(.text+0xed): undefined reference to `__imp__iob' /cygdrive/c/DOCUME~1/Temp/ccxzh81W.o:y.tab.c:(.text+0x133): undefined reference to `__imp__iob' /cygdrive/c/DOCUME~1/Temp/ccxzh81W.o:y.tab.c:(.text+0x168): undefined reference to `__imp__iob' /cygdrive/c/DOCUME~1/Temp/ccxzh81W.o:y.tab.c:(.text+0x1af): more undefined reference to `__imp__iob' /cygdrive/c/DOCUME~1/Temp/ccrE3OK5.o:lex.yy.c:(.text+0x872): undefined reference to `__errno' /cygdrive/c/DOCUME~1/Temp/ccrE3OK5.o:lex.yy.c:(.text+0x87f): undefined reference to `__errno' /cygdrive/c/DOCUME~1/Temp/ccrE3OK5.o:lex.yy.c:(.text+0x899): undefined reference to `__errno' /cygdrive/c/DOCUME~1/Temp/ccrE3OK5.o:lex.yy.c:(.text+0x1195): undefined reference to `__errno' /cygdrive/c/DOCUME~1/Temp/ccrE3OK5.o:lex.yy.c:(.text+0x1231): undefined reference to `__errno' /cygdrive/c/DOCUME~1/Temp/ccrE3OK5.o:lex.yy.c:(.text+0x16fb): undefined reference to `__errno' collect2: Id returned 1 exit status make.batを使った場合も同じ部分に「アクセスが拒否されました」と表示されます。 >具体的にどう操作されたのでしょうか。また、そこで何かエラーは出て >いないでしょうか。 特に変わった事をしたつもりはなかったのですが僕がした操作は、 mycalc.y mycalc.lをc/cygwin/home/user/に作成して >bison --yacc -dv mycalc.y >flex mycalc.l >gcc -o mycalc y.tab.c lex.yy.c と入力しただけです。 エラーが表示されたのは先ほど記述したインストールの最後に表示されるものだけです。

特になにか妙な設定が必要であったとか、そういうことはないはずだけど。 ttp://www.cygwin.com/ から setup.exe をダウンロードしローカルに保存 保存した setup.exe を起動 国内ミラーサイトを選択の上でダウンロード＋インストールを実施 cygwin bash shell を起動し cd <to/where/mycalc/is/expanded> bison -y -dv mycalc.y flex mycalc.l gcc -o mycalc y.tab.c lex.yy.c ちなみに gcc --version と入力したときになんて表示される？ ウチでは gcc (GCC) 4.3.4 20090804 (release) 1 になっている。 gcc -v -o mycalc y.tab.c lex.yy.c だと何が表示される？ 結構膨大な量が出るので、先の --version が同じだった場合のみ実行すればいい。 メモを取ったりすると転記ミスが怖いので gcc -v -o mycalc y.tab.c lex.yy.c 2&>hoge.txt として hoge.txt を見たほうがいい。

cygwin (1.5 も 1.7 も) のデフォルトインストール時は unix 改行。 ダウンロードページの mycalc (sjis/zip) に入っているファイルは dos 改行。 ・cygwin の bash-shell 上で make.sh を使うとこの dos 改行が邪魔して動かない。 ・cygwin の bash-shell 上で make.bat を使うと cmd.exe を呼ぶので下記参照 ・アクセサリ→コマンドプロンプトの cmd.exe 上で make.bat を使うと 　cygwin 1.7 の /bin/gcc や /bin/cc が (cygwin 仕様による) symlink であるため 　cmd.exe が gcc/cc を認識できず、起動失敗する といういささか困ったチャン状態なので、手打ちしたほうが早いという・・・ 改行コードの違いで動かないことが発見できる人なら改行コード変換もできるだろうけど 初めてチャレンジします！って人にそれを求めるのも酷な話で。 改行を修正しても cygwin には flex しか存在しないので lex → flex に要修正。 (/bin/yacc は /bin/bison の symlink になっているのでこっちは問題ない)

管理人の前橋です。はじめまして。 しばらくこちらを見ていなくて、反応が遅くなりましてすみません。 さて、チャチャ丸さんが具体的に行った操作がよくわからないのですが、 >今2章のyacc/lexで電卓を作る部分で、とりあえずmycalc.yとmycalc.lを >模写して実行したのですが、 >"cc -o mycalc y.tab.c lex.yy.c"のコマンドを行うとエラーが出ます。 ということは、 >>http://kmaebashi.com/programmer/devlang/book/download.html ここ↑からダウンロードしたファイルに含まれているmake.batやmake.shを 使わず、手作業でyacc(bison?)やlex(flex?)も動かしたということでしょうか? 具体的にどう操作されたのでしょうか。また、そこで何かエラーは出て いないでしょうか。

連続投稿ですいません。 インストール時のエラーを見逃していました。 （長時間のインストールのせいでボケていたのでしょうかｗ） インストール終了時になかったパッケージみたいなのが表示されます。 どのサイトを選んでも同じものが表示されました。 以下 Package: No package boxes.sh exit code 2 brltty.sh exit code 1 docbook-xml-simple10.sh exit code 1 docbook-xml-simple11.sh exit code 1 docbook-xml412.sh exit code 1 docbook-xml42.sh exit code 1 docbook-xml43.sh exit code 1 docbook-xml44.sh exit code 1 docbook-xml45.sh exit code 1 docbook-xsl-ns.sh exit code 1 docbook-xsl.sh exit code 1 exim.sh exit code 1 libglade2.0.sh exit code 2 mined.sh exit code 1 です。 setupの前になにか設定が必要なのでしょうか？

タイトルありがとうございます。 >これは多分ライブラリを正しくリンクできていないことが原因だと思われる。 >ソースコードが原因ではなくて、まず間違いなく開発環境側の原因。 >cygwin のインストールが不足しているか、操作ミスと思われる。 今日再インストールしてみたのですが同じエラーが表示されました。 今回は出来る物は一応全部インストールしました。 またバージョンは確認したところ1.7.6でした。 同じバージョンで出来ないということは、やはり環境構築にミスがあるのかもしれないです。 再度調べて検証してみます。 >チャチャ丸氏のところの cygwin のバージョンとかインストール状態が不明なので、 >今この場でこれ以上のアドバイスはできないなぁ。 とても助かりました。ありがとうございます。

タイトル変えておくね > undefined reference to `__imp__iob' > undefined reference to `__errno' これは多分ライブラリを正しくリンクできていないことが原因だと思われる。 ソースコードが原因ではなくて、まず間違いなく開発環境側の原因。 cygwin のインストールが不足しているか、操作ミスと思われる。 で、ウチの cygwin 1.7.6 だと何の問題も無くうまくコンパイル・リンクされる。 実行結果も期待通り。 チャチャ丸氏のところの cygwin のバージョンとかインストール状態が不明なので、 今この場でこれ以上のアドバイスはできないなぁ。 cygwin の再/追加インストールしてみるとか・・・ > # make.sh 中 lex → flex に修正が必要かも はとりあえず忘れていいよ。こっちを追求しだすと横道にそれていくので。

素早いお返事ありがとうございます。とても助かります。 >提示部はすべて警告であってエラーぢゃない（＝承知の上で使う分には問題ない） >以下略の部分にあるエラー（警告でなくエラー）を見せてもらわないと判断不能。 エラーの方はよくわからなくて勝手にはしょってしまいました。すいません。 以下エラーです。 /cygdrive/c/DOCUME~1/Temp/ccxzh81W.o:y.tab.c:(.text+0x8e): undefined reference to `__imp__iob' /cygdrive/c/DOCUME~1/Temp/ccxzh81W.o:y.tab.c:(.text+0xc2): undefined reference to `__imp__iob' /cygdrive/c/DOCUME~1/Temp/ccxzh81W.o:y.tab.c:(.text+0xed): undefined reference to `__imp__iob' /cygdrive/c/DOCUME~1/Temp/ccxzh81W.o:y.tab.c:(.text+0x133): undefined reference to `__imp__iob' /cygdrive/c/DOCUME~1/Temp/ccxzh81W.o:y.tab.c:(.text+0x168): undefined reference to `__imp__iob' /cygdrive/c/DOCUME~1/Temp/ccxzh81W.o:y.tab.c:(.text+0x1af): more undefined reference to `__imp__iob' /cygdrive/c/DOCUME~1/Temp/ccrE3OK5.o:lex.yy.c:(.text+0x872): undefined reference to `__errno' /cygdrive/c/DOCUME~1/Temp/ccrE3OK5.o:lex.yy.c:(.text+0x87f): undefined reference to `__errno' /cygdrive/c/DOCUME~1/Temp/ccrE3OK5.o:lex.yy.c:(.text+0x899): undefined reference to `__errno' /cygdrive/c/DOCUME~1/Temp/ccrE3OK5.o:lex.yy.c:(.text+0x1195): undefined reference to `__errno' /cygdrive/c/DOCUME~1/Temp/ccrE3OK5.o:lex.yy.c:(.text+0x1231): undefined reference to `__errno' /cygdrive/c/DOCUME~1/Temp/ccrE3OK5.o:lex.yy.c:(.text+0x16fb): undefined reference to `__errno' collect2: Id returned 1 exit status です。 >とりあえずタイプミスとか無いかい？ >http://kmaebashi.com/programmer/devlang/book/download.html >ここからダウンロードした mycalc は正しく動いたよ。 僕もタイプミスしてるのではと思ってそこからダウンロードしたものでも試したんですが同様のエラーが出てしましました。 ># make.sh 中 lex → flex に修正が必要かも とても基本的なことで申し訳ないのですがどのファイルのどのあたりの部分の事でしょうか？

提示部はすべて警告であってエラーぢゃない（＝承知の上で使う分には問題ない） 以下略の部分にあるエラー（警告でなくエラー）を見せてもらわないと判断不能。 とりあえずタイプミスとか無いかい？ http://kmaebashi.com/programmer/devlang/book/download.html ここからダウンロードした mycalc は正しく動いたよ。 # make.sh 中 lex → flex に修正が必要かも

はじめまして。「プログラミング言語を作る」を読み初めて勉強中のチャチャ丸と申します。 まだまだ序盤なのですが質問があって投稿させてもらいました。 今2章のyacc/lexで電卓を作る部分で、とりあえずmycalc.yとmycalc.lを模写して実行したのですが、 "cc -o mycalc y.tab.c lex.yy.c"のコマンドを行うとエラーが出ます。 エラーの内容は-Wallで見たところ y.tab.c: In function 'yyparse' : y.tab.c:1270: warning: implicit declaration of function 'yylex' y.tab.c:1439: warning: implicit declaration of function 'yyerror' lex.yy.c:1120: warning: 'yyunput' defined but not used lex.yy.c:1163: warning: 'input' defined but not used （以下略） と表示されます。 y.tab.cを見てみたところ622行目から #ifdef YYLEX_PARAM # define YYLEX yylex (YYLEX_PARAM) #else # define YYLEX yylex () #endif という部分があったのでyylexは定義されているように思えるのですが、なにが原因なのでしょうか？ ちなみにcygwinを利用しています。 何かお答えいただければ幸いです。よろしくお願いします。

（ぱ）さん、お返事ありがとうございます。 ご事情、了解いたしました。

>日経ソフトウエア8月号「MIL」の記事を読んでいます。 > >本編に進む前に、p18のprime.milでつまづいてしまいました。 もうしわけありません。たしかにprime.milは直感的なコードとは 言えないと思います。ふつうに考えて、そもそもループが三重である必要は ないはずですし。 prime.milがこうなってしまった事情はいろいろあるのですが、最終的には 私の責任であると思います。もうしわけありませんでした。 まあ、prime.milはMILの機能を示すためのサンプルコードなので、制御構造や 計算等の機能を使っていれば問題ない、ということで雑になってしまった面は あります。そこまで丁寧に読んでいただけるのは正直想定外でした。 ありがとうございました。

774RRさん、ご意見ありがとうございます。 >ならば処理上は一見無駄に思えるような記述であっても合目的でおｋだと思いますが。 ># その無駄さ自体がイイというか ># どこがどう無駄かを読者に考えてもらうのがイイというか おっしゃるとおりで、おかげで私も自分で組んでみる機会を得て勉強になりました。 >yuya さんの投稿プログラムも「素数の個数」には実用的でないですよね？ ええ、あれは元のソースとほぼ同じアルゴリズムを、自分に読めるように書き直したものです。 脇道に気を取られて、本編のことに全然言及していませんが、 いつものとおり素晴らしく分かりやすい解説です。 「車輪の再発明」にもピンからキリまで、 歴然としたクォリティの違いがあるものだな、と改めて思いました。

# 元ネタは読んでいません 記事（というかサンプルプログラム）の目的は、 素数の個数を求めることではなくて、その独自言語の解説なんですよね？ ならば処理上は一見無駄に思えるような記述であっても合目的でおｋだと思いますが。 # その無駄さ自体がイイというか # どこがどう無駄かを読者に考えてもらうのがイイというか yuya さんの投稿プログラムも「素数の個数」には実用的でないですよね？

日経ソフトウエア8月号「MIL」の記事を読んでいます。 本編に進む前に、p18のprime.milでつまづいてしまいました。 かなり時間をかけて、「確かにこれで素数は求まる」ことは納得したのですが、 それでも疑問がたくさん残ります。 たとえば、c を number / 2 まで回すのなら分かりますが、 小さな number に対しても一律 HALF_OF_MAX まで回す必要があるのでしょうか？ はじめ、ソースが複雑なのは言語の仕様を切り詰めているせいかと思いましたが、 自分で書いてみるとこうなりました。 MAX = 1000; number_of_prime = 0; number = 2; while(number <= MAX){ i = 2; while(i < number){ # 2 から number - 1 の範囲の整数で if(number / i * i == number){ # 割り切れたら goto *exit; # 素数ではない } i = i + 1; } print(number); number_of_prime = number_of_prime + 1; *exit number = number + 1; } print("the number of prime is"); print(number_of_prime); 書いたあとで再度p18のソースを見ると、 必要以上の複雑さがかなり含まれていると感じました。 （ぱ）さんの記事はいつも日本語が驚異的に分かりやすいので、 ソースにも同じくらいの分かりやすさを無意識に要求してしまっているのかもしれません。 読者のわがままというものですが……。

はじめまして。 >>bison --yacc -dy diksam.y >>diksam.y:428 13-14: $$ for the midrule at $2 of 'block' has no declared type >>gmake: *** [y.tab..h] Error 1 本件、おそらく正誤表の以下の件(p.206の件)だと思います。 http://kmaebashi.com/programmer/devlang/book/seigo.html#p206 当時、どのように判断したのかは正直なところあまり覚えていないのですが、 公開しているソースが修正されていないのは問題かと思います。 週末あたりをめどに確認させてください。

こんばんは、hasimと申します。 言語作成に関する詳しい解説、勉強させて頂いてます。 Diksamのソースコードをコンパイルしようとしたのですが、 bisonのバージョンが2.4だとエラーが起きるようです。 bisonのバージョンを2.3に落としたら、無事コンパイル出来ました。 エラー内容は以下のようなものでした。 % bison compiler/diksam.y compiler/diksam.y:748.13-14: $$ for the midrule at $2 of `catch_clause' has no declared type compiler/diksam.y:786.13-14: $$ for the midrule at $2 of `block' has no declared type ご参考になれば幸いです。

助言をいただき、それをむねに一応完成したソースを書き込みます。 変なところがあれば、ぜひ助言をお願いします。 #include <stdio.h> #include <stdlib.h> #include <string.h> typedef int (*Compare)(int,int) ; typedef struct DATA DATA; struct DATA { DATA * next; char * name; int math; int language; int sum; }; #define MAX 256 int AscendinOrder(int a,int b); int DescendingOrder(int a,int b); DATA* merge_sort(DATA* top,Compare); DATA* merge_list(DATA* x, DATA* y,Compare); /**************************************** 機能：線形リストのデータをすべて解放する。 引数：top 線形リストのトップデータ comp 使用した比較関数 出力：無し ****************************************/ void AllFree(DATA *top,Compare *comp) { DATA *temp,*freeData; if(*comp == AscendinOrder || *comp == NULL){ temp = top; while(temp->next){ freeData = temp; temp =temp->next; free(freeData->name); free(freeData); } }else if(*comp == DescendingOrder){ temp = top->next; while(temp){ freeData = temp; temp =temp->next; free(freeData->name); free(freeData); } } } /**************************************** 機能：線形リストのノードを作成。 引数：無し 出力：DATA型の新しいノードのポインタ ****************************************/ DATA* newnode(){ DATA *p; p=malloc(sizeof(DATA)); p->next=NULL; return p; } /**************************************** 機能：合計点を求める 引数：data 合計点を求めるDATA型のポインタ 出力：mathとlanguageの合計点 ****************************************/ int SUM(DATA *data) { return data->math+data->language; } /**************************************** 機能：線形リストの末尾にノードを追加。 引数：p リストの先頭 c リストnameにはいる名前 lang リストのlanguageに入る数値 math リストのmathに入る数値 出力：無し ****************************************/ void add(DATA *p,char *c,int lang,int math){ while(p->next != NULL){ p= p->next; } p->math = math; p->language = lang; p->sum = SUM(p); p->name=malloc(strlen(c)+1); strcpy(p->name,c); p->next=newnode(); } /**************************************** 機能：線形リストの内容を表示。 引数：data リストの先頭 comp 使った比較関数 出力：無し ****************************************/ void ShowData(DATA *data,Compare *comp) { DATA *temp; if(*comp == AscendinOrder || *comp == NULL){ for(temp = data; temp->next;temp= temp->next){ printf("name : %s, language : %d, math : %d, sum :%d \n",temp->name,temp->language,temp->math,temp->sum); } }else if(*comp == DescendingOrder){ for(temp = data->next; temp;temp= temp->next){ printf("name : %s, language : %d, math : %d, sum :%d \n",temp->name,temp->language,temp->math,temp->sum); } } } /**************************************** 機能：表示方法の設定。 引数：無し 出力：表示方法の値。 ****************************************/ int ShowCase() { char c; printf("昇順で表示 :1 ,降順で表示:2\n"); c = getchar(); switch(c){ case '1': return 1; case '2': return 2; default: return 0; } } int main() { char data[MAX] = {'\0'}; char ctemp[100] = {'\0'}; int m,l,type; FILE *fp = fopen("data.txt","r"); char *n; DATA *top = malloc(sizeof(DATA)); Compare comp = NULL; type=ShowCase(); if(type == 1){ comp = AscendinOrder; }else if(type == 2){ comp = DescendingOrder; }else{ comp = NULL; } top->next = NULL; while(fgets(data,MAX,fp)){ if(n = strchr(data,'\n')) *n = '\0'; sscanf(data,"%s%d%d",ctemp,&m,&l); add(top,ctemp,l,m); } if(comp != NULL){ top =merge_sort(top,comp); } ShowData(top,&comp); AllFree(top,&comp); return 0; } /**************************************** 機能：線形リストのマージソートする。 引数：top リストの先頭 comp 使う比較関数 出力：ソート済みのリストのポインタ ****************************************/ DATA* merge_sort(DATA* top,Compare comp) { DATA *a, *b, *y; /* リストに含まれる要素数が０または１個のときは、ソートの必要がない */ if( top == NULL || top->next == NULL ){ return top; } a = top; /* aは先頭の要素を指す */ b = top->next; if( b != NULL ){ b = b->next; } /* bは先頭から３番目の要素を指す */ /* 線形リストを中心くらいから半分に分けるため、中心位置がどこにあるのか探る */ while( b != NULL ) { a = a->next; /* aは常に１つだけ進む */ b = b->next; if( b != NULL ){ b = b->next; } /* bは基本的に２つ進む */ } /* 線形リストを２つに分割する */ y = a->next; /* yは分割後の２つのリストのうちの、後半部分の方の先頭を指す */ a->next = NULL; /* 分割した２つのリスト */ return merge_list( merge_sort( top ,comp), merge_sort( y ,comp) ,comp); } /************************************************************************ 機能：２つの線形リストをマージする。 引数：x マージする２つの線形リストのうちの片方の先頭要素へのポインタ 　y マージする２つの線形リストのうちの片方の先頭要素へのポインタ comp 比較関数 出力:　マージされた線形リストの先頭要素へのポインタ *************************************************************************/ DATA* merge_list(DATA* x, DATA* y,Compare comp) { DATA z, *p; p = &z; /* xとyをマージしてzを作り上げる */ /* 分割されている２つのリストのいずれか一方が空になるまで繰り返す */ while( x != NULL && y != NULL ) { /* ２つのリストの先頭要素同士を比較する */ if( comp(x->sum , y->sum) ) { /* リストxの方の先頭要素を、マージ後のリストに連結する */ p->next = x; p = x; x = x->next; } else { /* リストyの方の先頭要素を、マージ後のリストに連結する */ p->next = y; p = y; y = y->next; } } /* 先に片方のリストが空になるので、残された方のリストの要素を、マージ後リストに連結する */ if( x == NULL ) { p->next = y; } else { p->next = x; } return z.next; } int AscendinOrder(int a,int b) { return a>=b? 1:0; } int DescendingOrder(int a,int b) { return a <= b?1:0; } data.txtの中身 jon 90 30 sum 40 50 jack 20 100 tom 35 70

>>線形リストをつくったのですが、リストに値をセットした後連結リストをソートしたい >>のですが、わかりません。どなたか教えてください。 > >だったらマージソート…と思ったのですが774RRさんに先に書かれてしまったので、 >本題からずれますが、 > >> DATA *top = malloc(sizeof(DATA)); > >最初にいきなりダミーのノードを作っていて、そのために以後、 >ループをまわすとき、p->nextを終了判定に使うことになっています。 >add()関数が微妙に楽になる以外、ここにダミーノードを置くことは >あまりメリットがないんじゃないかなあ、と私は昔から思っているのですが >(センス・オブ・プログラミングに書いたりもしましたが)どうなんでしょうねえ。 > >あとまあ、ものすごく細かいことですが、 > >>int SUM(DATA *data) >>{ >> return data->language+data->language; >>} > >ここはdata->math + data->languageですよね。 > >また、連結リストのソートは、効率を気にしないのなら単純選択ソートとかでも >できるんじゃないでしょうか。 > >・連結リストを頭からスキャンして、最大値のノードを探す。 >・最大値のノードをリストから引っぺがし、ソート済みリストの先頭につなぐ。 >・上記操作を繰り返す。 > 貴重なご意見ありがとうございました。 たしかにdata->math + data->languageでした。

>線形リストのソートは結構めんどくさいので、できればやらずにすむのが理想。 >最初からデータをソート済みの形で保持する構造を使うほうがよい結果が出ることが多い。 >二分木構造とかを使うのが普通（実用上、赤黒木になるかな） > >でもどうしても線形リストをそのままソートしたいのであれば、 >まさにそのような目的のために考案された「マージソート」を使うといい。 >http://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%BC%E3%82%B8%E3%82%BD%E3%83%BC%E3%83%88 >http://www.geocities.jp/ky_webid/algorithm/021.html > 貴重なご意見ありがとうございました。 無事ソートできました。

>線形リストをつくったのですが、リストに値をセットした後連結リストをソートしたい >のですが、わかりません。どなたか教えてください。 だったらマージソート…と思ったのですが774RRさんに先に書かれてしまったので、 本題からずれますが、 > DATA *top = malloc(sizeof(DATA)); 最初にいきなりダミーのノードを作っていて、そのために以後、 ループをまわすとき、p->nextを終了判定に使うことになっています。 add()関数が微妙に楽になる以外、ここにダミーノードを置くことは あまりメリットがないんじゃないかなあ、と私は昔から思っているのですが (センス・オブ・プログラミングに書いたりもしましたが)どうなんでしょうねえ。 あとまあ、ものすごく細かいことですが、 >int SUM(DATA *data) >{ > return data->language+data->language; >} ここはdata->math + data->languageですよね。 また、連結リストのソートは、効率を気にしないのなら単純選択ソートとかでも できるんじゃないでしょうか。 ・連結リストを頭からスキャンして、最大値のノードを探す。 ・最大値のノードをリストから引っぺがし、ソート済みリストの先頭につなぐ。 ・上記操作を繰り返す。

線形リストのソートは結構めんどくさいので、できればやらずにすむのが理想。 最初からデータをソート済みの形で保持する構造を使うほうがよい結果が出ることが多い。 二分木構造とかを使うのが普通（実用上、赤黒木になるかな） でもどうしても線形リストをそのままソートしたいのであれば、 まさにそのような目的のために考案された「マージソート」を使うといい。 http://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%BC%E3%82%B8%E3%82%BD%E3%83%BC%E3%83%88 http://www.geocities.jp/ky_webid/algorithm/021.html

線形リストをつくったのですが、リストに値をセットした後連結リストをソートしたい のですが、わかりません。どなたか教えてください。 ソース（free用関数は後で作ります。）： #include <stdio.h> #include <stdlib.h> #include <string.h> typedef struct DATA DATA; struct DATA { DATA * next; char * name; int math; int language; int sum; }; #define MAX 256 void listSort(DATA *top); DATA* newnode(){ DATA *p; p=malloc(sizeof(DATA)); p->next=NULL; return p; } int SUM(DATA *data) { return data->language+data->language; } void add(DATA *p,char *c,int lang,int math){ while(p->next != NULL){ p= p->next; } p->math = math; p->language = lang; p->sum = SUM(p); p->name=malloc(strlen(c)+1); strcpy(p->name,c); p->next=newnode(); } void ShowData(DATA *data) { FILE *fp = fopen("result.txt","w"); DATA *temp; for(temp = data; temp->next;temp= temp->next){ printf("name : %s, language : %d, math : %d, sum :%d \n",temp->name,temp->language,temp->math,temp->sum); } for(temp = data; temp->next;temp= temp->next){ fprintf(fp,"name : %s, language : %d, math : %d, sum :%d \n",temp->name,temp->language,temp->math,temp->sum); } fclose(fp); } int main() { char data[MAX] = {'\0'}; char ctemp[100] = {'\0'}; int m,l; FILE *fp = fopen("data.txt","r"); char *n; DATA *top = malloc(sizeof(DATA)); top->next = NULL; while(fgets(data,MAX,fp)){ if(n = strchr(data,'\n')) *n = '\0'; sscanf(data,"%s%d%d",ctemp,&m,&l); add(top,ctemp,l,m); } listSort(top); ShowData(top); return 0; } void listSort(DATA *top) { //ここのしょりがわかりません //ちなみにsumで比較 }

すみません、ものすごく初歩的なバグがあって本来弾けるはずのspamが来ていました。 修正しました。

>一時的にテスト用のスクリプトを上げます。 NGワード機能を搭載し、ひととおりの動作テストをしました。 ここで高級バッグの話をしたりするとひっかかるかもしれません。 spammer以外の人には申し訳ないですがご了承ください。

一時的にテスト用のスクリプトを上げます。 しばらくは投稿がエラーになる可能性があります。

管理人さま ＞どちらについても保証されています。 根拠まで示していただき、ありがとうございました。m(_ _)m 774RRさま、yuyaさま ＞一方で #define TRUE 1 とかしていることが多いので ＞func()==TRUE はバグの元だからやらないほうがいいよ 取り急ぎ、アドバイスにお礼申し上げます。

>IPアドレスがだめで、かつ、人力でやっているのなら、NGワードのような >「spamでない投稿をspam扱いしかねない」手段しかないんですかねえ。 特定のURLが含まれていたらspam扱いする、としたらちょっとはマシになるかも…？

>spamがあまりにひどいので、「ほげほげ認証」のキーワードを「ほげほげ」から >「ほげぴよ」に変更しました。投稿時にはご注意ください。 spam、来ましたねえ…… とほほ。 人力でやっているんでしょうか。やっぱり。 IPアドレスがだめで、かつ、人力でやっているのなら、NGワードのような 「spamでない投稿をspam扱いしかねない」手段しかないんですかねえ。

>ほげぴよ認証のテストを兼ねて ># ってか既に spam ってるんだけど > >C では、偽は０、真は０以外である。 >一方で #define TRUE 1 とかしていることが多いので > >func()==TRUE はバグの元だからやらないほうがいいよ 賛成。 関数が正常終了したら0を返す慣習って、けっこう頭が混乱しますよね。 「この戻り値は、『何かヘンなことが起こりましたか？』という質問に対する答えだ！」と 自分に言い聞かせて納得するようにしてました。

ほげぴよ認証のテストを兼ねて # ってか既に spam ってるんだけど C では、偽は０、真は０以外である。 一方で #define TRUE 1 とかしていることが多いので func()==TRUE はバグの元だからやらないほうがいいよ

spamがあまりにひどいので、「ほげほげ認証」のキーワードを「ほげほげ」から 「ほげぴよ」に変更しました。投稿時にはご注意ください。 spammerが機械的に投稿しているのなら効果があるのかも、と思っています。 IPアドレスによる制限も考えたのですが、結構ばらけているみたいで……

>if((func_hoge() == 真) && (func_piyo() == 真)) // (1) > 実行文; > >if(func_hoge() == 真) > if(func_piyo() == 真) // (2) > 実行文; > >上記(1)または(2)において、func_hoge()が偽であった場合、 >func_piyo が実行されないことは文法上保証されるのでしょうか？ どちらについても保証されています。 (1)は短絡演算子というやつで、JIS X 3010：2003 (ISO/IEC 9899：1999)であれば 6.1.13に以下の記述があります。 | ビット単位の2項&演算子と異なり，&&演算子は左から右への評価を保証する。 | 第1 オペランドの評価の直後を副作用完了点とする。第1オペランドの値が0と | 比較して等しい場合，第2オペランドは評価しない。 「||」も同様です(6.5.14 論理OR演算子より) | ビット単位の|演算子と異なり，||演算子は左から右への評価を保証する。 | 第1オペランドの評価の直後を副作用完了点とする。第1オペランドの値が0と | 比較して等しくない場合，第2 オペランドは評価しない。 (2)はさすがにif文の動作として自明ではないでしょうか。

初めまして。お邪魔します。 C言語の文法？について質問させて下さい。 if((func_hoge() == 真) && (func_piyo() == 真)) // (1) 実行文; if(func_hoge() == 真) if(func_piyo() == 真) // (2) 実行文; 上記(1)または(2)において、func_hoge()が偽であった場合、 func_piyo が実行されないことは文法上保証されるのでしょうか？ ご教示をお願い致します。

>「使われているそうです」や、「ごくたまにC++を使う機会もあります」 >という表現から考えると、主流ではないようですね。 前回、「.NETってどこで使われているんですか?」と言われた、という話を 出したように、会社や業界により使われている言語はかなりまちまちです。 もちろんそれは私にしても同じですので、私自身が仕事で使う言語の 範囲から「主流ではない」という結論を導かれても困ります。 業界全体でのトレンドを見たければ、たとえば以下のようなページはどうでしょうか。 http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html 現時点で、Java, Cに続いて3位です。昔に比べても伸びているようにも見えます。 http://d.hatena.ne.jp/takoratta/20080430/1209512678 前回リンクしたLinusの投稿にしても、「GitってなんでいまどきC++じゃないの?」 という投稿に対する反論ですから、元発言者にしてみれば、「いまどき C++があたりまえ」という感覚だったわけでしょう。 Linuxはさておき、たとえばOpenOfficeのソースはC++ですよね。 もちろん、Hiropyonさんが以下のように思われるのであれば、 >どうもプログラムオタクがひとりよがりで作った言語のような感じがします。 それはそれでひとつの見識ですし(同意する人も多いはず)、根拠を挙げた上で 主張されれば面白い話になるように思います。 >C++を使う場合というのは、今回のソフトウェア開発はC++でいこう！ >とか、仕様で決められて、それでコーディングするのでしょうか？ どうでしょうか。Windowsでネイティブアプリを作りたいとか、環境によって 決められてしまうことが多いように思いますが。 組み込みとかでリソースが少なくて、JavaやC#は到底使えないけれど、 Cじゃあんまりだよね、とか。

管理人様、忙しい中ご回答頂きありがとうございます。 「使われているそうです」や、「ごくたまにC++を使う機会もあります」 という表現から考えると、主流ではないようですね。 C++を使う場合というのは、今回のソフトウェア開発はC++でいこう！ とか、仕様で決められて、それでコーディングするのでしょうか？ >Hiropyonさん、はじめまして。 > >>単純に思うのですが、実際の現場でC＋＋は使われているのでしょうか？ > >これについては774RRさんから回答がついていますが、場所によっては >使われているそうです。私自身も、7～8年くらい前には仕事で使っていました。 >最近は.NETがメインなのですが、ごくたまにC++を使う機会もあります。 > >つい最近、某JavaのMLで、「.NETってどこで使われているんですか?」という話題が出て >「この5年くらいC#ばっかりですが何か?」というようなレスを返したのを >思い出しました…… > >>現にLinuxのプログラムやカーネルソース等もC言語で記述されていて >>だれもC＋＋を使っていないようです。 > >Linuxに関して言えば、Linusさんがこういう人だという理由もあるんでしょう。 > >http://tabesugi.net/memo/2009/1a.html#152154

Hiropyonさん、はじめまして。 >単純に思うのですが、実際の現場でC＋＋は使われているのでしょうか？ これについては774RRさんから回答がついていますが、場所によっては 使われているそうです。私自身も、7～8年くらい前には仕事で使っていました。 最近は.NETがメインなのですが、ごくたまにC++を使う機会もあります。 つい最近、某JavaのMLで、「.NETってどこで使われているんですか?」という話題が出て 「この5年くらいC#ばっかりですが何か?」というようなレスを返したのを 思い出しました…… >現にLinuxのプログラムやカーネルソース等もC言語で記述されていて >だれもC＋＋を使っていないようです。 Linuxに関して言えば、Linusさんがこういう人だという理由もあるんでしょう。 http://tabesugi.net/memo/2009/1a.html#152154

HiroakiSoftwareさん、はじめまして。 >メモリ管理モジュール(MEM) >デバッグライト用モジュール(DBG) > >についてなのですが、オリジナルの言語で使用して >作った言語を配布しても問題ないでしょうか？ >また、使用にあたって条件等はありますでしょうか？ まったく問題ありません。単純なモジュールですが、あんなものでよろしければ いくらでもご利用ください。

前橋様 はじめまして、HiroakiSoftware（※個人のハンドルネームです）と申します。 メモリ管理モジュール(MEM) デバッグライト用モジュール(DBG) についてなのですが、オリジナルの言語で使用して 作った言語を配布しても問題ないでしょうか？ また、使用にあたって条件等はありますでしょうか？ これは著作権侵害等のトラブルを防止するために、 確認の意味で本投稿(質問）をさせていただきました。よろしくお願いいたします。

Windows の MFC や ATL は C++ Ruby on Rails の passenger は C++ ウチではワンチップマイコンの組み込みにも使っている。 自分の狭い視野だけで判断してない？

前橋 様、このサイトのオブジェクト指向の意見について読ませていただきました。 単純に思うのですが、実際の現場でC＋＋は使われているのでしょうか？ どうもプログラムオタクがひとりよがりで作った言語のような感じがします。 現にLinuxのプログラムやカーネルソース等もC言語で記述されていて だれもC＋＋を使っていないようです。

>さて、本題ですが、 >C言語ヨタ話 >その3「モジュールと命名とヘッダファイルと」のページのリンクが死んでいるようです。 報告ありがとうございます。どうもHTMLがPHPとして解釈されているようです。 今は出先なのですが、早めに対処いたします。

こんにちは。 オブジェクト指向再入門のページを見ました。とてもわかりやすかったです。 さて、本題ですが、 C言語ヨタ話 その3「モジュールと命名とヘッダファイルと」のページのリンクが死んでいるようです。 では。

>過去に投稿をされている　山　さん >のプログラムのソースコードは、 >どこで手に入るのですか？ 山さんは私個人宛でソースを送ってくださいましたが、一般公開しているかどうかは私は知りません。

過去に投稿をされている　山　さん のプログラムのソースコードは、 どこで手に入るのですか？

>>PHPとMySQLで掲示板を作るの掲示板のプログラムを圧縮して配布していただけませんか？ >>あと、パーミッションの設定も教えていただけませんか？ > >そういう要望があり得るとは当初より思っていましたが、そのつもりはありません。 >あのページではあくまで作り方の解説をしているだけであり、掲示板のプログラム >そのものをリリースしようとは考えていないためです。 >すぐにインストールできるようなパッケージとして配布すると、インストールできない >等の質問が来る可能性がありますし、そのサポートをする気もないからです。 >プログラムの作り方に関する質問やクレームであれば受け付けます。そういう情報を >共有することは価値があると思えるからです。 > >あしからずご了承ください。 > >あとまあ正直なところ、あのプログラムはPHP4として書いたものですし(5でも >動いてますが)、記事中で言い訳してますがサニタイズ言うなポリシー的にも >よろしくないものですので。 > そうでしたか。 わかりました。 わざわざ返答していただきありがとうございます。

>PHPとMySQLで掲示板を作るの掲示板のプログラムを圧縮して配布していただけませんか？ >あと、パーミッションの設定も教えていただけませんか？ そういう要望があり得るとは当初より思っていましたが、そのつもりはありません。 あのページではあくまで作り方の解説をしているだけであり、掲示板のプログラム そのものをリリースしようとは考えていないためです。 すぐにインストールできるようなパッケージとして配布すると、インストールできない 等の質問が来る可能性がありますし、そのサポートをする気もないからです。 プログラムの作り方に関する質問やクレームであれば受け付けます。そういう情報を 共有することは価値があると思えるからです。 あしからずご了承ください。 あとまあ正直なところ、あのプログラムはPHP4として書いたものですし(5でも 動いてますが)、記事中で言い訳してますがサニタイズ言うなポリシー的にも よろしくないものですので。

>C言語出身の私としては「オブジェクト指向」で言うところのウリ(カプセル化や再利用性など)が、C言語でやってきたこととどこが違うのか！と反発することが理解できない原因だと思ってきましたが、このサイトでは「反発して当然」のように書かれており、かつ説明が非常に具体的でよく理解できました。 ありがとうございます。 >「オブジェクト指向も裏を返せばただの・・・」と思えただけで今後は前回と違った理解ができそうな気がしています。 >再チャレンジするきっかけを与えて頂いてありまとうございました。 孫悟空さんは再チャレンジ中ですので誤解はないと思うのですけれど、 一応補足しますと、私はオブジェクト指向について「役に立たない」とか 「くだらない」と思っているわけではありません。 # 仕事では、あまり使わないケースはあるかもしれないと思っていますが。 http://d.hatena.ne.jp/kmaebashi/20090427/p1 (継承の乱用とかしないで)ちゃんと使えば強力な概念だと思いますので 再チャレンジが成功することをお祈りしております。

>「入力が char_buf のサイズ（1024）を超えていて fgets がナル文字を付けた場合」 >を想定しておりましたです。 「1024文字もあるんだから普通はオーバーしません!」 とか言い切ってしまうとそれはそれで問題ありかとは思うのですが。 実際、こういう意見↓もあるのですが、 http://www.kijineko.co.jp/tech/superstitions/gets-can-be-replaced-with-fgets-simply.html この程度の用途のプログラムでどこまで想定するかは難しいところだと思います。 私の場合、たとえばポインタ完全制覇のp.79でも 「自分で使う程度のプログラムだったらまず大丈夫でしょう」 とかいって逃げてしまっています。

こんにちは。 かなり以前にオブジェクト指向に挫折したものです。 私の「オブジェクト指向」への反発は、このサイトに書かれている事、一つ一つに該当し全文を読み終えてしまいました。 目からうろこです！大変感謝しております！！ C言語出身の私としては「オブジェクト指向」で言うところのウリ(カプセル化や再利用性など)が、C言語でやってきたこととどこが違うのか！と反発することが理解できない原因だと思ってきましたが、このサイトでは「反発して当然」のように書かれており、かつ説明が非常に具体的でよく理解できました。 「オブジェクト指向も裏を返せばただの・・・」と思えただけで今後は前回と違った理解ができそうな気がしています。 再チャレンジするきっかけを与えて頂いてありまとうございました。

さっそく正誤表で対応して頂き、ありがとうございます。 >改行なしの行を食わせるためにはファイルからリダイレクト等しなければならないので うぐぅ、私は単純に 「入力が char_buf のサイズ（1024）を超えていて fgets がナル文字を付けた場合」 を想定しておりましたです。

ああそうか、レクサの問題というより、 テストドライバをそんなに厳密に書いていないというだけの話ですね。 ありがとうございました。

>となっています。'\0'に出会ったら BAD_TOKEN として処理するという意図だと思いますが、 >現状だと'\0'が現れた時点でwhileを抜けてしまうので、 >st_line_pos がインクリメントされないまま再び get_token() が呼ばれてしまい、 >実行時に無限ループに陥ります。 BAD_TOKENが返ってきているのにまたget_token()を呼ぶほうが変なんじゃ、と 思って本に掲載されているソースのテストドライバを確認したのですが、 END_OF_LINE_TOKENのチェックはしていてもBAD_TOKENのチェックをしていないので、 たとえば改行で終わらないファイルをリダイレクトで食わせたときに、 確かに無限ループになりますね。 電卓のパーサと組み合わせる限りではそんなにおかしなことにはならないような 気もします。 バグかというと微妙ではないかと思いますが、補足を入れておきます。 ># ただいま「プログラミング言語を作る」を骨の髄までしゃぶる勢いで読んでます。 ># 面白すぎて睡眠不足（笑）。 ありがとうございます。また何かあればご指摘ください。

「プログラミング言語を作る」p.59の、 lexicalanalyzer.c の23～24行からの構造を見ると、 token->kind = BAD_TOKEN; while(st_line[st_line_pos] != '\0'){ /* メインの処理 */ } となっています。'\0'に出会ったら BAD_TOKEN として処理するという意図だと思いますが、 現状だと'\0'が現れた時点でwhileを抜けてしまうので、 st_line_pos がインクリメントされないまま再び get_token() が呼ばれてしまい、 実行時に無限ループに陥ります。 一度ご確認ください。 # ただいま「プログラミング言語を作る」を骨の髄までしゃぶる勢いで読んでます。 # 面白すぎて睡眠不足（笑）。

ご回答ありがとうございます。 >-が降ってきた時点でそれまでの分をreduceしないと左結合にならないわけですが、 >現状、ここでshift/reduce conflictが起きており、shiftが優先されるため >結合規則が逆順になっています。 なるほどー、よく分かりました。もし右結合を明示したければ expression /* 「式」とは… */ : primary_expression /* 「一次式」、 */ | primary_expression ADD expression /* または、「一次式」 + 「式」 */ と書くべきなわけですね。 そもそも件名に「『一回以上の繰り返し』の定義」なんて書いちゃいましたが、 ただ単にそう定義するだけならレクサのレベルの話であって、 階層的な解析木を築くための構文規則を定めるのがパーサの役割だから、 結合規則によって規則の書き方が変わって当然なのですね。 結果的には誤植（？）がきっかけで非常に勉強になりました。引き続き読み進めていきます。

>expression /* 「式」とは… */ > : primary_expression /* 「一次式」、 */ > | expression ADD expression /* または、「式」 + 「式」 */ > （以下略） >だと、 >yacc: 4 shift/reduce conflicts. >となりますね。 申しわけありません。これはやはり間違いと判断すべきだと思います。 >どうしてそうなるのかは、まだ自分で説明できません……。 1 - 2 - 3 - 4 - 5 のような式のとき、 -が降ってきた時点でそれまでの分をreduceしないと左結合にならないわけですが、 現状、ここでshift/reduce conflictが起きており、shiftが優先されるため 結合規則が逆順になっています。 この構文規則は、優先順位を気にしなくてよいのなら…という文脈で出てきていた はずですし、その趣旨は構文規則を簡単にしたかったためなのですが、 結合規則まで気にしないとは書いてないですし、警告が出るのはそれ自体まずいですね。 数日中にWeb上で補足を入れます。ご指摘ありがとうございました。

人に聞く前に、実験してみるべきでした。 expression /* 「式」とは… */ : primary_expression /* 「一次式」、 */ | expression ADD expression /* または、「式」 + 「式」 */ （以下略） だと、 yacc: 4 shift/reduce conflicts. となりますね。 どうしてそうなるのかは、まだ自分で説明できません……。

「プログラミング言語を作る」p43～p44にかけてのソースに、 expression /* 「式」とは… */ : primary_expression /* 「一次式」、 */ | expression ADD expression /* または、「式」 + 「式」 */ （以下略） とあるのを見て、はたと疑問に思いました。 これって、 expression /* 「式」とは… */ : primary_expression /* 「一次式」、 */ | expression ADD primary_expression /* または、「式」 + 「一次式」 */ （以下略） としなくてもよいのでしょうか？ 他のソースではそうなっているので、反射的に「あっ、間違いだ！」と思ってしまったのですが、 よく考えると、これでもいいような気がします。 一般に、「hoge は piyo の1回以上の繰り返しである」という定義を、 hoge : piyo | hoge piyo と書かずに hoge : piyo | hoge hoge と書いてはいけない理由って、何かありますでしょうか？

こんにちは。 どうもありがとうございます。 私はSEですが、ゲームが嫌いで一切ゲームをしませんので、どういう想定で 書かれているのか理解できませでした。 このサイトは７年程前から知っていたのですが、７年来の疑問がやっと晴れました。 ありがとうございました。 >そうです。 >ネットワーク対戦オセロのサーバを立てるなら、そりゃ複数の対戦を同時に >行えるようにするでしょ、と思ってこう書いているのですが、確かにここで >引っ掛かりを覚える方もいらっしゃるかもしれませんね。 >ちょっと表現を考えてみます。 >

こんにちは。 >この例は、ネットワーク対戦＝複数の対戦が同時に行われる　という意味で >書かれていると理解すればよいのでしょうか。 そうです。 ネットワーク対戦オセロのサーバを立てるなら、そりゃ複数の対戦を同時に 行えるようにするでしょ、と思ってこう書いているのですが、確かにここで 引っ掛かりを覚える方もいらっしゃるかもしれませんね。 ちょっと表現を考えてみます。

「疑りぶかいあなたのためのオブジェクト指向再入門」を読ませていただきました。 そこで、疑問に思ったのが、ネットワーク対戦でオセロをする話なのですが、 どうして、ネットワーク対戦になると「複数のオセロの盤面を管理しなければならない」のかです。 ネットワーク対戦であっても、常にAさんとBさんというような一組だけが対戦する のであれば、オセロ盤は一つ管理すればいいだけですよね。 AさんとBさん、CさんとDさん、EさんとFさんというように複数の対戦が 同時期に行われる場合に、初めて複数管理する必要があると思いますが。 この例は、ネットワーク対戦＝複数の対戦が同時に行われる　という意味で 書かれていると理解すればよいのでしょうか。 よろしくお願いします。

>> 本に掲載したURLにリダイレクトを置くことで対処いたしました。 >と書かれていますが、エラーページが表示されているようです。 まさかと思って試してみたところその通りでした。 どうやら、リダイレクトのページをhttp://kmaebashi.com/devlang/ 直下(bookの 下でなく)に置き、置いたときの動作テストもそこを確認してしまったようです。 さきほど修正いたしました。 ここに書いても仕方がないのかもしれませんが、辿りつけなかった方には 重ね重ね申しわけありませんでした。お詫び申し上げます。 通りすがり様、情報ありがとうございました。

こんにちは。 > 本に掲載したURLにリダイレクトを置くことで対処いたしました。 と書かれていますが、エラーページが表示されているようです。 私はドメイン名からトップに飛び無事に辿り着けましたが…

青餓鬼さん、yuyaさん、ありがとうございます。 管理人が放置してしまいましてすみません。 この結論を関連ページに追記しました。ありがとうございました。 >とりあえず、Macの人に対しては >「とりあえずUTF-8版を試してください。 >駄目なら export LANG=ja_JP.UTF-8 としてからUTF-8版を再度試してください。」 >って指針で、多くの人に使ってもらえそうですね。

青餓鬼さん、試していただいてありがとうございます。 とりあえず、Macの人に対しては 「とりあえずUTF-8版を試してください。 駄目なら export LANG=ja_JP.UTF-8 としてからUTF-8版を再度試してください。」 って指針で、多くの人に使ってもらえそうですね。 私のほうも、ここらで追究を一段落させていただきます。 ありがとうございました。

>(1)10.5のほうはUTF-8版Diksamが無修正で動いた、と理解してよいのでしょうか？ Mac OSX 10.5の方はコマンドの追加もなく、ちゃんと動きました。 >(2)10.4でLANGが設定されていないとなると、LC_ALLが設定されているのでしょうかね。 >差し支えなければ echo $LC_ALL も試してみてください。 echo $LC_ALL の実行結果は、Mac OSXの10.4、10.5共に(空文)でした。

>私のPPCMac G5には、Mac OS X 10.4と10.5の二つのバージョンをインストールして使い分けていますが、10.4の方で実行した　echo $LANGの結果は(空文)でした。 >ついでに覗いた10.5のほうは ja_JP.UTF-8 でした。 返信ありがとうございます。 (1)10.5のほうはUTF-8版Diksamが無修正で動いた、と理解してよいのでしょうか？ (2)10.4でLANGが設定されていないとなると、LC_ALLが設定されているのでしょうかね。 差し支えなければ echo $LC_ALL も試してみてください。 MacOS X のことは全然分かんないや……。FreeBSDベースらしいということと、 http://homepage3.nifty.com/toshi3/osx2t.html の最後に >Mac OS Xではファイル名はUTF-8、Unixに由来する部分では日本語EUC、 >従来のMac OSに由来する部分ではShift-JISと、複数の文字コードが混 >在して使用されている。 と書かれていて、とにかく複雑なことになってる、ってことは分かりました。 あと、Unicode正規化の方式も違うようで、 http://labs.unoh.net/2007/09/unicode-on-mac.html 手元で実験できない私としては混沌とするばかりです。

>export LANG=ja_JP.UTF-8 > >で正常動作するということは、もとのLANGはUTFじゃなかったということですね。 >ちなみに、上のコマンドを実行する前の echo $LANG の結果は何だったのでしょうか？ 私のPPCMac G5には、Mac OS X 10.4と10.5の二つのバージョンをインストールして使い分けていますが、10.4の方で実行した　echo $LANGの結果は(空文)でした。 ついでに覗いた10.5のほうは ja_JP.UTF-8 でした。 環境変数LANGに何も指定されてなくても日本語が表示されるところを見ると別の環境変数があるのでしょうが、それについての解説は見つけることはできていません。 以上

export LANG=ja_JP.UTF-8 で正常動作するということは、もとのLANGはUTFじゃなかったということですね。 ちなみに、上のコマンドを実行する前の echo $LANG の結果は何だったのでしょうか？

Macで実行する際、UTF-8の場合exportコマンドで環境変数を指定すると、正常に実行することがわかりました。 >export LANG=ja_JP.UTF-8 このコマンドを実行した後に DIKSAM を実行すると、サンプルと同じ結果を得ることができます。 Macの技術解説書にこのあたりを体系的に記述したものが見あたらず、たまたま読んだコマンドリファレンスの、別のコマンドの実行例に、上に掲げた一文があり、早速実行すると、エラーなく実行できました。 なお、EUCの場合は、ターミナル上の日本語表示が文字化けしますので、別の環境変数があるのかもしれません。これ以上、深入りは当面控えておきます。 以上

>HEAP_THRESHOLD_SIZEが小さいと、頻繁にGCが走って遅くなるのはわかるのですが、 >死んでしまうのはおかしいと思うのですが…… >念のため当方でcrowbar_book_ver.0.2において、HEAP_THRESHOLD_SIZEを元に戻した >上で2000*2000*2の多次元配列を確保したところ、時間はかなりかかったようですが >死にはしませんでした。(Windows Vista環境) > 私もcrowbarcer_ver.0.2をターミナルで実行したところ時間はすごく掛かりましたが正常に終了しました．申し訳ないです．こちらも確認すべきでした． 私が開発環境はMacのXcodeです．GUIにcrowbarを組み込んでいます．ちなみにOS Xの10.６です． どこか実装にミスがあるのかもしれませんね＾＾；要素が大きくなるときだけGC_mark()で止まってるようなのですが難しいですね．本当にお手数かけました．

>尚，私の環境では200*200*200では４秒ほどなのですが2000*2000*2の多次元配列を利用した場合EXC_BAD_ACCESSで止まってしまいデバッガが起動していました． >実際にHEAP_THRESHOLD_SIZEを変更したところ多少時間はかかるものの正常に実行されました． HEAP_THRESHOLD_SIZEが小さいと、頻繁にGCが走って遅くなるのはわかるのですが、 死んでしまうのはおかしいと思うのですが…… 念のため当方でcrowbar_book_ver.0.2において、HEAP_THRESHOLD_SIZEを元に戻した 上で2000*2000*2の多次元配列を確保したところ、時間はかなりかかったようですが 死にはしませんでした。(Windows Vista環境)

>>サイトの説明:http://kmaebashi.com/programmer/devlang/array.htmlでは下記のコードが追加されています． >>#GCされないようにおまじない >>CRB_push_value(inter, &ret); >> >>CRB_pop_value(inter); > >これは、ネイティブ関数内で確保したオブジェクトがGCされないように >スタックに積んでいるわけですが、この方法は、ネイティブ関数を書く人に >(面倒くさいという意味で)負担をかけますので、 >Webページ版においても以下のページで方法を変更しています。 > >http://kmaebashi.com/programmer/devlang/crowbar_0_4_02.html > >前者の方法が後者の方法に比べて優れているところは特にないと思いますので、 >本の方では、最初から後者の方法で実装しているわけです。 >本では、後者の方法について、171ページで説明しています。 > >>私の実行環境ではnew_array()関数でたまに(要素数が大きくなると)gc_mark()の >>ところで止まってしまいます．私の実装ミスか，その部分のコードが足りない >>せいなのか分からないので質問させていただきました． > >crowbarのGCは単純なstop the world式のmark sweep GCなので、オブジェクト数が >増えてくるとmarkに時間がかかります。1次元の配列なら、多少数が多くても >オブジェクト数はひとつだからよいのですが、多次元ですと、現状の実装では >確保の途中で(無駄に)GCが動くのでかなり遅くなることがあります。new_array()の >中で不要なオブジェクトが増えることはないので、この間GCの発生を抑止する >方がよいのでしょうが、現状ではそうなっていません。 >ひとまずこちらでは、100×100×100の配列程度であればすぐに返りましたが、 >200×200×200だと30秒近く待たされました。 > >簡単にチューニングするには、crowbar.hのHEAP_THRESHOLD_SIZEを増やすという >方法があります。これは、どれだけのサイズのオブジェクトを確保したらGCを >動かすかという閾値で、現状では256KBになっています。 > 早速の返信ありがとうございます． 私はver0.2を参考にしていたのでそれ以降を見ていませんでした．申し訳ありません．最後まで読んで質問するべきでした． >>多次元ですと、現状の実装では確保の途中で(無駄に)GCが動くのでかなり遅くなることがあります なるほど納得しました．実装ミスというわけではないのですね．安心しました． 尚，私の環境では200*200*200では４秒ほどなのですが2000*2000*2の多次元配列を利用した場合EXC_BAD_ACCESSで止まってしまいデバッガが起動していました． 実際にHEAP_THRESHOLD_SIZEを変更したところ多少時間はかかるものの正常に実行されました． どうしても多次元で要素数が多い場合にも対応する必要があるため本当に助かりました． 有り難うございます．

>サイトの説明:http://kmaebashi.com/programmer/devlang/array.htmlでは下記のコードが追加されています． >#GCされないようにおまじない >CRB_push_value(inter, &ret); > >CRB_pop_value(inter); これは、ネイティブ関数内で確保したオブジェクトがGCされないように スタックに積んでいるわけですが、この方法は、ネイティブ関数を書く人に (面倒くさいという意味で)負担をかけますので、 Webページ版においても以下のページで方法を変更しています。 http://kmaebashi.com/programmer/devlang/crowbar_0_4_02.html 前者の方法が後者の方法に比べて優れているところは特にないと思いますので、 本の方では、最初から後者の方法で実装しているわけです。 本では、後者の方法について、171ページで説明しています。 >私の実行環境ではnew_array()関数でたまに(要素数が大きくなると)gc_mark()の >ところで止まってしまいます．私の実装ミスか，その部分のコードが足りない >せいなのか分からないので質問させていただきました． crowbarのGCは単純なstop the world式のmark sweep GCなので、オブジェクト数が 増えてくるとmarkに時間がかかります。1次元の配列なら、多少数が多くても オブジェクト数はひとつだからよいのですが、多次元ですと、現状の実装では 確保の途中で(無駄に)GCが動くのでかなり遅くなることがあります。new_array()の 中で不要なオブジェクトが増えることはないので、この間GCの発生を抑止する 方がよいのでしょうが、現状ではそうなっていません。 ひとまずこちらでは、100×100×100の配列程度であればすぐに返りましたが、 200×200×200だと30秒近く待たされました。 簡単にチューニングするには、crowbar.hのHEAP_THRESHOLD_SIZEを増やすという 方法があります。これは、どれだけのサイズのオブジェクトを確保したらGCを 動かすかという閾値で、現状では256KBになっています。

配列の確保、およびネイティブ関数の書き方についての質問です サイトの説明:http://kmaebashi.com/programmer/devlang/array.htmlでは下記のコードが追加されています． #GCされないようにおまじない CRB_push_value(inter, &ret); CRB_pop_value(inter); ところがこのコードの部分は本書及び，サンプルソースでも書かれていませんでした． これは必要ないということでしょうか？ またそのような関数名はないようなのですが，eval.cのpush_value(),pop_value()のことでしょうか？ 私の実行環境ではnew_array()関数でたまに(要素数が大きくなると)gc_mark()のところで止まってしまいます．私の実装ミスか，その部分のコードが足りないせいなのか分からないので質問させていただきました．

>crowbarのfor文どのように実装されているのですか。 >本を何回も読みましたが見逃してしまっているかもしれませんので、本にあるならば、ページ番号を教えてください。 p.115でwhileの実装についてコード込みで説明しています。 p.115には、「ここから呼び出される関数を全部見ていくのは紙面の無駄ですので、 ここでは代表としてwhile文で呼び出されるexecute_while_statement()を取り上げ ます。」と書いてあります。 紙面節約のため代表としてwhileを取り上げているわけですから、forについての 直接の説明はありません。whileを参考にソースを読めばわかるという意図で 省略しているわけです。

crowbarのfor文どのように実装されているのですか。 本を何回も読みましたが見逃してしまっているかもしれませんので、本にあるならば、ページ番号を教えてください。

>create.oなどOファイルがありますが、これには機械語とリンク処理に必要な情報が含まれている、と考えていいのですか。 何を知りたいのかわかりませんが、その通りです。

create.oなどOファイルがありますが、これには機械語とリンク処理に必要な情報が含まれている、と考えていいのですか。Oファイルを見てみると機械語みたいなものが書いてありました。

>前回はすみません。知りたかったのは、ファイルの題名です。 そのソースファイルでやっていることが理解できているのなら、題名くらい、 自分でつければよいでしょう。 そもそもなぜ「題名」などというものをつけなければいけないのかわかりませんが。 学校のレポートに書くというのなら、それを私にまるごと聞くのはカンニングと同じです。

>crowbar_book_0_1の >string.cとmain.c(memoryフォルダに入ってないほう)の説明がほしいのですが。 >ファイル名や中身からしてなんとなくわかる気もするのですが、 出張中につき手元に本はないのですが、 main.cといえば、これですよね。 http://kmaebashi.com/programmer/devlang/crowbar_src_0_1_01/S/1.html このページの、 http://kmaebashi.com/programmer/devlang/crowbar.html 「Cからcrowbarを呼び出す」 は、説明になっていませんか? また、string.cについては、 http://kmaebashi.com/programmer/devlang/crowbar_0_1.html にて、以下のように説明しています。 | 文字列リテラルに関しては、開始の時点でcrb_open_string_literal() を | 呼び出し、途中の文字はcrb_add_string_literal()で追加、最後は | crb_close_string_literal()で文字列終了、という手順を踏みます。 | その間、文字列は、string.c中の st_string_literal_bufferという | static変数に保持されています。 説明不足でわからないのかもしれませんが、どこがどうわからないのか 言ってもらわないと、回答のしようがありません。

crowbar_book_0_1の string.cとmain.c(memoryフォルダに入ってないほう)の説明がほしいのですが。 ファイル名や中身からしてなんとなくわかる気もするのですが、 簡単にでもいいのでお願いします。

メールにてご指摘がありました。 以下のページのソースコードにおいて、 http://kmaebashi.com/programmer/object/shigoto.html Java版の以下のソースに間違いがありました。 // コロンで区切るためのStringTokenizerを生成 StringTokenizer st = new StringTokenizer(line, ":"); // 著者名を(複数)取り出す writers = st.nextToken(); // コンマで区切られた著者名を順に切り出すために // 新たなStringTokenizerを生成 StringTokenizer st2 = new StringTokenizer(line, ","); i = 0; while (st2.hasMoreTokens()) { writer[i] = st2.nextToken(); i++; } 著者名を順に切り出す対象は、その前のStringTokenizerで取得した writersですから、以下のようにしなければいけません。 // コンマで区切られた著者名を順に切り出すために // 新たなStringTokenizerを生成 StringTokenizer st2 = new StringTokenizer(writers, ","); 現在海外出張中でオリジナルが直せませんので、取り急ぎお知らせします。 すみませんでした。

>util.cについて教えてください。 >/* BUGBUG >CRB_NativeFunctionProc * >　　　　. >　　　　. >*/ >とコメントにしたのはなぜでしょうか。 おそらくは昔はネイティブ関数とcrowbarの関数を別々の連結リストで 管理していたところ、あるとき一本化して、この関数だけ残骸として 残ったようです。無視してください。 リリース前にはきれいにしておくべきでした。すみません。 >/*FALLTHRU*/というのは何かの指令なのですか。 >C ソースコード検査プログラムの lint と関係ありますか。 lintと関係あります。 Cのswitch caseというのは、「breakを書かないと下に落っこちていく」という とんでもない仕様になっているので、よくbreakを書き忘れてはまる人が いるわけです。そこでlintはそれを検出する機能があるわけですが、 といって、本当に「下に落っこちていく」動きにしたい場合に警告が出て しまったのでは困りますので、その警告を抑止するコメントが/* FALLTHRU */です。 とはいえいまどき昔ながらのUNIXのlintを使っている人は少ないでしょうし、 gccとかだと無視するようなのであまり意味はないかもしれませんが。

util.cについて教えてください。 /* BUGBUG CRB_NativeFunctionProc * 　　　　. 　　　　. */ とコメントにしたのはなぜでしょうか。 /*FALLTHRU*/というのは何かの指令なのですか。 C ソースコード検査プログラムの lint と関係ありますか。

>UTF-8版がエラーとなり、 >EUC版がうまくいったのはたまたまLANG環境変数が一致したからですか? たまたまというか、たいていのLinux環境はEUCかUTF-8のどちらかであり、 それに対応するためにふたつの配布パッケージを用意しているわけです。 ところで青餓鬼さんにお願いですが、この掲示板で誰かの投稿に返信する際は、 「新規投稿」リンクではなく、対象の投稿の「返信」リンク(右上にあります)を 使っていただけないでしょうか。 「スレッド順インデックス」で見たときに、応答の流れが見えますので。 http://kmaebashi.com/bbs/thread.php?boardid=kmaebashibbs

こちらはVineLinuxでLANG環境変数がja_JP.UTF-8な環境で試してみました。 ちょうど青餓鬼さんと逆に、test.dkmはUTF版では正常動作し、EUC版では Assertion failure (wc_format != NULL) file..error.c line..92 wc_format is null. Assertion failure (wc_format != NULL) file..error.c line..92 wc_format is null. アボートしました とのメッセージが出ました。当然といえば当然の結果ですね。 これは納得が行きましたが、あとは青餓鬼さんが前に書いていたMacの結果だけが気になりますね（文字コード以前に、素のバイト列のままだった）。 むし返すようで申し訳ないんですけど、Macでの環境変数LANGは何だったのか、 よければ教えてもらえませんか。

Vine Linuxでの　echo $LANG の実行結果は ja_JP.eucJP でした。 UTF-8版がエラーとなり、 EUC版がうまくいったのはたまたまLANG環境変数が一致したからですか? 大変勉強になりました。 以上

>crowbar_book_0_1に、debubgフォルダとmemoryフォルダがあったのですが >これらは何のためのフォルダなのですか。 「高校生」さんが書籍版「プログラミング言語を作る」をお持ちなら、 92ページにディレクトリ構成の図があります。メモリ管理モジュール MEM(memoryフォルダ)の説明はp.92からありますし、デバッグ用モジュール DBG(debugフォルダ)の説明はp.96からです。 Web版なら、以下のページに説明があります。 http://kmaebashi.com/programmer/devlang/crowbar_0_1.html こちらにはdebugのほうの説明はないので補足すると、たとえば 以下のソースが例として挙げられると思います。 http://kmaebashi.com/programmer/devlang/crowbar_src_0_1_01/S/22.html#57 >if (cond.type != CRB_BOOLEAN_VALUE) { > crb_runtime_error(statement->u.if_s.condition->line_number, > NOT_BOOLEAN_TYPE_ERR, MESSAGE_ARGUMENT_END); >} >DBG_assert(cond.type == CRB_BOOLEAN_VALUE, ("cond.type..%d", cond.type)); このDBG_assert()を通るときにはcond.typeは絶対にCRB_BOOLEAN_VALUEであるに 決まっているわけですが、万一なにかの思い違いでそうでなかったとき、 DBG_assert()はメッセージを2行吐いて異常終了します。

crowbar_book_0_1に、debubgフォルダとmemoryフォルダがあったのですが これらは何のためのフォルダなのですか。 一通り見たのですが難しいです。 こんな質問ですみません、学校のレポートにまとめなければならないので...。

>２．UTF-8版の場合 >次のようなメッセージを２回表示しアボートします。 > >Assertion Failure (WC_format != NULL) file .. error.c line .. 92 当方のUbuntu Linuxで再確認しましたが、正常動作しました。 確認ですが、この時のLANG環境変数の値は何になっているでしょうか? Linuxなら、LANG環境変数の値は「echo $LANG」で確認することができます。

Windows XP上のVirtualPCでVine Linuxを起動し、EUC版とUTF-8版のDIKSAM_book_0_4を実行してみました。 どちらもWindowsの時のようにdiksam.yのソース修正することなくmakeは正常に終了しました。 TEST.DKMを引数にして実行すると次のような差異が生じました。 １．EUC版の場合 実行結果はTESTディレクトリ内のTEST.RESULTと同じ内容が表示されます。 正常終了!! ２．UTF-8版の場合 次のようなメッセージを２回表示しアボートします。 Assertion Failure (WC_format != NULL) file .. error.c line .. 92 アボートしました。 *** とりあえず　Linuxでは EUC　コードで先に進めていきます。 *** 誰かＩｎｔｅｌ　Ｍａｃでの実行を試行してみませんか !!! 以上

>CrowbarからCを使うとありましたが,Cで書かれた別アプリケーションからインタプリタを使うことについて、どういうことかイメージがわきません。 「crowbarからCの関数を呼び出すことの意味はわかるけれど、 　Cからcrowbarのインタプリタを呼び出せて何が嬉しいのかわからない」 ということでよいでしょうか? Cで書かれたある程度の規模のプログラムがあるとして、そこからcrowbarが 呼び出せると、crowbarを、そのプログラムのカスタマイズ用言語として使うことが できます。 すぐ思いつく例としては、 ・Microsoft WordやExcelはカスタマイズ用言語としてVBAを使うことができる。 ・UNIXのエディタEmacsは、Emacs Lispでカスタマイズできる。 ・CADなどでは、カスタマイズ用スクリプト言語がついているものがある。 などがありますが…考えてみれば高校生はOfficeは使わない気がするし、 UNIXも使っていなければEmacsも知らないかもしれないし、ましてやCADを 見たことがあるとも思えませんねえ。 手近な例としては、秀丸エディタのマクロなんかどうでしょうか。 http://hide.maruo.co.jp/lib/macro/index.html

CrowbarからCを使うとありましたが,Cで書かれた別アプリケーションからインタプリタを使うことについて、どういうことかイメージがわきません。説明やいいサイトを紹介してくれたら幸いです。

>出力結果と文字コード表を付き合わせると、Shift-JISじゃなくてEUCだと思うのですが……。 出力結果： > str[0]..50940 16進数に直すとC6FC 文字コード表を見ると…すみません、確かにEUCでした。ご指摘ありがとうございます。 同じ手順で確認したはずが、なぜShift-JISだと思ってしまったんだろう。 >つよしさんのテストではワイド文字への変換は行われているがUnicode化されていない。 >青餓鬼さんのテストではそもそもワイド文字にも変換されず、素のバイト列のまま、と。 ということですよね。つよしさんの実験がEUC環境下で行われたなら、実質無変換で、 ただしマルチバイトの1文字として変換されたということでしょうか。

Mac持ってませんが探究中です。 >なぜか当時追及しなかったようなのですが、Windowsと同じようには動いていませんね。 >この出力だけ見ると、ワイド文字に変換した結果がShift-JISになっているように >見えますが、いくらなんでもそんなはずは…… 出力結果と文字コード表を付き合わせると、Shift-JISじゃなくてEUCだと思うのですが……。 つよしさんのテストではワイド文字への変換は行われているがUnicode化されていない。 青餓鬼さんのテストではそもそもワイド文字にも変換されず、素のバイト列のまま、と。 引き続き調査しまーす。

>crowbar.hを見ていると/*create.c*/や/*string.c*/などが書いてありました。 これですね。 http://kmaebashi.com/programmer/devlang/crowbar_src_0_4_02/S/6.html >これは、例えばcreate.cというファイルが、crowbar.hの/*create.c*/と書いてある以下の部分を使うということですか。 「以下の部分を使う」というのをどういう意味で書かれているのかはわかりませんが、 このコメントは、 「/* create.c */というコメントの下にある関数は、create.c内で定義されている」 ということを意味しています。

crowbar.hを見ていると/*create.c*/や/*string.c*/などが書いてありました。 これは、例えばcreate.cというファイルが、crowbar.hの/*create.c*/と書いてある以下の部分を使うということですか。 気になりまして。

>私が問題にしているのは、Test.dkmの726行目 > if (str[i] == '本') { >の解釈で、WindowのCYGWINのGCCが作成した実行部は２バイト文字として >文字リテラルを解釈しているのに、MacのGCCで作成した実行部は文字リテラル数が >複数あるとしてエラーとしていることです。 まず、Diksamでは、"あいうえお".length()は5を返しますし、"あいうえお"[3]の 値は'え'である、というのが仕様です。つまり、Diksamでは、文字列は「バイトの 並び」ではなく「文字の並び」です。この「文字」は、日本語であっても、 1文字は1文字として解釈されなければなりません。 よって、実行に成功していれば、test.dkmにおける以下のコードの実行結果は、 string str = "日本語"; for (i = 0; i < str.length(); i++) { println("str[" + i + "].." + str[i]); if (str[i] == '本') { println("本"); } } 以下のようになるのが正解です。 str[0]..26085 str[1]..26412 本 str[2]..35486 ところが、青餓鬼さんの環境では、str.length()がEUCではが6, UTF-8では9に なっています。これはマルチバイト文字からUNICODEへの変換が行われておらず、 単にバイト列として読み込まれているように見えます。 マルチバイト文字からUNICODEへの変換処理はロケールに依存するので、 環境変数LANGの値はどうなっているのかが気になっているわけです。 とはいえ私はMacは持っておりませんしOS-Xを使ったこともないので、 見当はずれのことを書いている可能性はあります。詳しい方ご指摘ください。 過去MacOSで動かした人はいたはずだったよな、と思い掲示板の過去ログを 探したところ、以下の投稿が見つかりました。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1196&range=1 なぜか当時追及しなかったようなのですが、Windowsと同じようには動いていませんね。 この出力だけ見ると、ワイド文字に変換した結果がShift-JISになっているように 見えますが、いくらなんでもそんなはずは……

私が問題にしているのは、Test.dkmの726行目 if (str[i] == '本') { の解釈で、WindowのCYGWINのGCCが作成した実行部は２バイト文字として文字リテラルを解釈しているのに、MacのGCCで作成した実行部は文字リテラル数が複数あるとしてエラーとしていることです。 文字リテラルに関しては、ほかの手段を執るか制限を設けるのか検討が必要だと思います。 以上

>lexicalanalyzer.cを見ていると >#if 0 >と書かれていましたが、どういう意味でしょうか。 #で始まっていることから、#includeと同じようなプリプロセッサの機能であると 見当がつきます。 そこで、「プリプロセッサ」でGoogle検索すると、たとえば以下のようなページが 見つかります。 http://www.cppll.jp/cppreference/preproc_details.html >/*ここから下はテストドライバ*/ >とありました。これはなくてもよいのですか。 >何を意味しているのかを教えてください。 「テストドライバ」でGoogle検索するとWikipediaの以下のページが見つかります。 http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%86%E3%82%B9%E3%83%88#.E3.83.86.E3.82.B9.E3.83.88.E3.83.89.E3.83.A9.E3.82.A4.E3.83.90.E3.81.A8.E3.83.86.E3.82.B9.E3.83.88.E3.82.B9.E3.82.BF.E3.83.96

scanf()の件はありがとうございました。 lexicalanalyzer.cを見ていると #if 0 と書かれていましたが、どういう意味でしょうか。 本のほうでは、 /*ここから下はテストドライバ*/ とありました。これはなくてもよいのですか。 何を意味しているのかを教えてください。

すみません、時間がないので手短に。 >◎◎結論 >文字列型stringの内部の表現形式は実行環境のＣ言語コンパイラに依存するとなると、他のＵｎｉｘ／Ｌｉｎｕｘは >わかりませんが、Ｍａｃ／Ｗｉｎでの日本語のリテラル処理は、同じソースでは扱えないと思います。 内部の表現形式以前に、test.dkmの文字コードがunix_euc.tarではEUC、 unix_utf8.tarではUTF8になっており、それがそのまま出力されているように 見えます。 echo $LANG とすると、何が表示されますか?

Diksam_book_0_4について、ＷｉｎとＭａｃの実行結果を次に示します。 ★Ｗｉｎｄｏｗｓの場合（ＸＰ　ソースファイルはwin_sjis.lzh） 正誤表にあるCompilerディレクトリのdiksam.yのblockに関するソース修正を行い、diksam.yの７４５行目のソースを catch_clause : CATCH { $$ = dkc_start_catch_clause(); } 次のように修正すると catch_clause : CATCH { $<catch_clause>$ = dkc_start_catch_clause(); } ｍａｋｅは正常に終了し、test.dkmを処理してもtest.resultと同じ結果が得られます。 ★Ｍａｃ（PPC Ｇ５，ＯＳ　１０．４．１１ ソースファイルはunix_euc.tar） diksam.yのソース修正をしなくてもmakeは正常に終了しますが、test.dkmを処理しようとすると 726行目のところでエラーとなります。（たぶんエラー内容は下と同じ） そこで次のようにソース修正すると、 string str = "日本語"; for (i = 0; i < str.length(); i++) { println("str[" + i + "].." + str[i]); // if (str[i] == '本') { if (i>0 && str[i-1] == 203 && str[i] == 220) { println("本"); } } 次のような結果が表示されます。 ・・(前の部分省略) 日本語 str[0]..198 str[1]..252 str[2]..203 str[3]..220 本 str[4]..184 str[5]..236 ★Ｍａｃ（PPC Ｇ５，ＯＳ　１０．４．１１ ソースファイルはunix_etf8.tar） diksam.yのソース修正をしなくてもmakeは正常に終了しますが、test.dkmを処理しようとすると 726行目のところで"文字リテラルが２文字以上あります"というエラーとなります。 そこで次のようにソース修正すると、 string str = "日本語"; for (i = 0; i < str.length(); i++) { println("str[" + i + "].." + str[i]); // if (str[i] == '本') { if (i>2 && str[i-2] == 230 && str[i-1] == 156) && str[i] == 172) { println("本"); } } 次のような結果が表示されます。ただし、結果をファイルに落としてＷｉｎで表示させると日本語の部分は文字化けします。 ・・(前の部分省略) 日本語 str[0]..230 str[1]..151 str[2]..165 str[3]..230 str[4]..156 str[5]..172 本 str[6]..232 str[7]..170 str[8]..158 ◎◎結論 文字列型stringの内部の表現形式は実行環境のＣ言語コンパイラに依存するとなると、他のＵｎｉｘ／Ｌｉｎｕｘは わかりませんが、Ｍａｃ／Ｗｉｎでの日本語のリテラル処理は、同じソースでは扱えないと思います。 以上、Ｍａｃ／Ｗｉｎの実行結果を報告します。

>crowbarにはC言語で言うscanf(キーボードから入力）的なものは、ありましたでしょうか。 少なくとも最新バージョン(book_ver.0.4)では、fgets()の入力元を STDINにすることでキーボードからの入力が可能です。 str = fgets(STDIN); print(str); Cのscanf()のように、文字列を数値に変換するような機能はありませんので、 必要であればネイティブメソッドを書き足してみてください。

電卓の件は、ありがとうございました。 crowbarにはC言語で言うscanf(キーボードから入力）的なものは、ありましたでしょうか。

>mycalc|_exで例えば >..5 >とか入力すると >電卓は終了してしまうのですか。 >それともlexical error とかが出るのですか。 現状では、手書きパーサのほうは syntax error. yacc/lex版のほうは、 lexical error. と表示して終了します。 yacc/lex版の_exありのほうは、パーサのエラーについては対処しており、 たとえば 1++2 のように入力すれば、エラーメッセージを出しますが電卓は終了しません。 確かにレキシカルアナライザの方でエラーが出ると終了してしまうので 実用上は対策がおおいに不完全ですが、ここではyaccのエラー処理の仕方を 説明しているということでご理解ください。 …とはいえ補足記事くらいは書いたほうがよさそうですね。検討します。

mycalc|_exで例えば ..5 とか入力すると 電卓は終了してしまうのですか。 それともlexical error とかが出るのですか。

>win_sjisのcalcフォルダにある電卓にはエラー処理はありますか？ 本のほうで説明しているのはyaccのエラー処理の方法なので、 calcフォルダ以下の、mycalc_ex以下のmycalc.yにはエラー処理が入っています。 _exでないほうには入っていません。

>情報ありがとうございました。正直、Makefileの中身を書き換える根性はないのですが、 >補足等の形で近日中にUPさせていただきます。 修羅場だったり出張してたりでここに書くのが遅くなりましたが、 申しわけ程度の説明を↓のページに入れました。 http://kmaebashi.com/programmer/devlang/book/winenv.html 今見返しても本当に申しわけ程度ですが……

win_sjisのcalcフォルダにある電卓にはエラー処理はありますか？

……とは言っても、Makefileにコマンドを書いた時点で、そもそもシェル依存なのか。 cdの構文が（ある程度）共通してるのはラッキーだったというだけで。 すいません、ひとりで納得してますm(_ _)m

まず、訂正。 >cd ../dvm; $(MAKE)$ 末尾の$は不要でした。 >makeが起動しようとするコマンド行を受け付けるのが、Cmd.exeの場合に >セミコロンを解釈しない、ということでしょうか。 そういうことだろうと思います。 >正直、Makefileの中身を書き換える根性はないのですが、 パスをダブルクォーテーションで囲んでみたり、 なんとかcmd.exeの機嫌をとろうとしたのですが、 うまく行く方法が見つかりません(^^;) 蛇足ですが、cdと$(MAKE)を別行にしてしまうと、 新しいシェルが立ち上がって、cd前のディレクトリに戻ってしまい、 makeで自分と同じMakefileを読みに行って再帰無限地獄に陥いりますよね。 #ってか、MinGWユーザが全員MSYS入れてるわけでもないでしょうし、 #けっこう普遍的な問題のような気がするのですが、情報が見つかりません。

>> cd ../dvm; gmake; >> 指定されたパスが見つかりません。 >> gmake: *** [../dvm/dvm.o] Error 1 > >といったエラーに悩んでる人が出てきてないでしょうか。 > >MSYSだと起こらないので、今日初めて気づいたんですが、 Cygwinを入れている私の環境でもそのままでは再現しませんが、 makeが起動しようとするコマンド行を受け付けるのが、Cmd.exeの場合に セミコロンを解釈しない、ということでしょうか。実際、コマンドプロンプトから 直接入力すると、同様のエラーが出ます。 情報ありがとうございました。正直、Makefileの中身を書き換える根性はないのですが、 補足等の形で近日中にUPさせていただきます。

mingw32-makeを使うときの一般的な話で、CrowbarやDiksamと直接関係ないのですが……。 Makefileに cd ../dvm; $(MAKE)$ などとなっている箇所で、セミコロン以降も全部パスとみなされてしまい、 > cd ../dvm; gmake; > 指定されたパスが見つかりません。 > gmake: *** [../dvm/dvm.o] Error 1 といったエラーに悩んでる人が出てきてないでしょうか。 MSYSだと起こらないので、今日初めて気づいたんですが、 MinGWだけ入れてcmdから直接makeする人はハマる可能性があると思うのです。 余計なお世話ですけど。

>>・そちらのbisonのバージョンが2.1以外であれば、2.1ではどうでしょうか。 >bison2.1にするとちゃんと動くようになりました。 当方と同じ現象が起きているようですね。 >>・m4のみ別途インストールするか、Cygwinを入れてみるとどうでしょうか。 >m4のみ違うバージョンをインストールしてみましたが、だめでした。 > >bisonを空白のないパスにインストールすると、最新のバージョンでも動きました。 こちらについても、わざわざ報告いただきありがとうございました。

>gmake [Enter] > >とタイプしたのですが (中略) >というようなメッセージがでて、crowbar.exeがcrowbar_book_0_1のフォルダの中にできました。 おめでとうございます。コンパイルは成功しています。 >crowbar.exeをダブルクリックすればいいのですか？ダブルクリックしても一瞬だけ黒い画面が出るだけです。 crowbarの実行もコマンドプロンプトから行います。 コンパイルしたフォルダにtestというフォルダがあり、この中に、 test.crbというテストプログラムが入っています。 コンパイルしたフォルダから、 cd test[Enter] でtestフォルダに移動してから、 ..\crowbar test.crb[Enter] とタイプしてください。「..\」は「ひとつ上のフォルダ」を意味しますので、 これでひとつ上のフォルダのcrowbar.exeを実行することができます。 あるいは、test.crbをひとつ上のフォルダに移動してから、 コンパイルしたフォルダにて crowbar test.crb[Enter] でもよいです。

ありがとうございます。 >・そちらのbisonのバージョンが2.1以外であれば、2.1ではどうでしょうか。 bison2.1にするとちゃんと動くようになりました。 >・m4のみ別途インストールするか、Cygwinを入れてみるとどうでしょうか。 m4のみ違うバージョンをインストールしてみましたが、だめでした。 bisonを空白のないパスにインストールすると、最新のバージョンでも動きました。 お忙しいところ、何度もアドバイスありがとうございました。

プログラミングを作る　の本を使ってやっているのでcrowbar_book_0_1は　「C:\Documents and Settings\s2007070\デスクトップ\win_sjis\crowbar_book_0_1」にあります。そこでコマンドプロンプトで cd C:\C:\Documents and Settings\s2007070\デスクトップ\win_sjis\crowbar_book_0_1[Enter] とタイプして C:\C:\Documents and Settings\s2007070\デスクトップ\win_sjis\crowbar_book_0_1に移動し、そこで gmake [Enter] とタイプしたのですが ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー C:\Documents and Settings\s2007070\デスクトップ\win_sjis\crowbar_book_0_1>gmake cd ./memory; gmake; gmake[1]: Entering directory `c:/Documents and Settings/s2007070/デスクトップ/wi n_sjis/crowbar_book_0_1/memory' gmake[1]: `mem.o' is up to date. gmake[1]: Leaving directory `c:/Documents and Settings/s2007070/デスクトップ/win _sjis/crowbar_book_0_1/memory' cd ./debug; gmake; gmake[1]: Entering directory `c:/Documents and Settings/s2007070/デスクトップ/wi n_sjis/crowbar_book_0_1/debug' gmake[1]: `dbg.o' is up to date. gmake[1]: Leaving directory `c:/Documents and Settings/s2007070/デスクトップ/win _sjis/crowbar_book_0_1/debug' gcc lex.yy.o y.tab.o main.o interface.o create.o execute.o eval.o string.o strin g_pool.o util.o native.o error.o error_message.o ./memory/mem.o ./debug/dbg.o -o crowbar -lm C:\Documents and Settings\s2007070\デスクトップ\win_sjis\crowbar_book_0_1> ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー というようなメッセージがでて、crowbar.exeがcrowbar_book_0_1のフォルダの中にできました。 crowbar.exeをダブルクリックすればいいのですか？ダブルクリックしても一瞬だけ黒い画面が出るだけです。

>C:\win_sjis\calc\mycalc>make.bat >> error.txt >m4: cannot open `Files\GnuWin32/share/bison': No such file or directory >m4: cannot open `C:\Program': No such file or directory >m4: cannot open `Files\GnuWin32/share/bison/m4sugar/m4sugar.m4': No such file or > directory (後略) このメッセージは見たことがあります。 以下のページの「bisonのインストール」のところで http://kmaebashi.com/programmer/devlang/book/winenv.html >ただし、私の環境では、m4でエラーが出ました。 >Cygwinのものを使おうがMSYSのものを使おうが、 bisonに付属のものを使おうが >エラーになっています。 >bison2.1は動作したので念のため置いておきます。 と書いていますが、この時に発生したエラーがこれでした。 bisonは内部的にm4を使用するのですが、「MSYSのm4は古いからbisonは動かない」という という記述がいくつかのWebページにありましたし、メッセージを見る限り、 確かにm4がエラーを出しています。ただ、その後MSYSをアンインストールして cygwinを入れなおしても状況が改善されず、bisonの入れ直しで(私のところでは)直りました。 ・そちらのbisonのバージョンが2.1以外であれば、2.1ではどうでしょうか。 ・m4のみ別途インストールするか、Cygwinを入れてみるとどうでしょうか。 はっきりした回答ができず申しわけありません。 私の環境では、bisonはC:\Program Files\GnuWin32\bin\bisonであり、 m4はcygwinのものを使用しています。

ありがとうございます。 >かつ、その中で、該当のエラーになったのは、mycalc以下のmake.batでよいでしょうか? はい。 >エラーメッセージが出るようであれば、そのままこの掲示板にコピペしてください。 C:\win_sjis\calc\mycalc>make.bat >> error.txt m4: cannot open `Files\GnuWin32/share/bison': No such file or directory m4: cannot open `C:\Program': No such file or directory m4: cannot open `Files\GnuWin32/share/bison/m4sugar/m4sugar.m4': No such file or directory m4: cannot open `C:\Program': No such file or directory m4: cannot open `Files\GnuWin32/share/bison/bison.m4': No such file or directory m4: cannot open `C:\Program': No such file or directory m4: cannot open `Files\GnuWin32/share/bison/c-skel.m4': No such file or director y gcc: y.tab.c: No such file or directory mycalc.l:3:19: y.tab.h: No such file or directory mycalc.l: In function `yylex': mycalc.l:12: error: `ADD' undeclared (first use in this function) mycalc.l:12: error: (Each undeclared identifier is reported only once mycalc.l:12: error: for each function it appears in.) mycalc.l:13: error: `SUB' undeclared (first use in this function) mycalc.l:14: error: `MUL' undeclared (first use in this function) mycalc.l:15: error: `DIV' undeclared (first use in this function) mycalc.l:16: error: `CR' undeclared (first use in this function) mycalc.l:20: error: `yylval' undeclared (first use in this function) mycalc.l:21: error: `DOUBLE_LITERAL' undeclared (first use in this function) bisonをインストールした場所が悪かったのでしょうか。エラーを読んでいると、Program Filesが2つのパスに分割されているようにも思えます。環境変数のpathにC:\Program Files\GnuWin32\binを登録してコマンドプロンプトを実行しています。

掲示板＃1432に指摘されているdiksam.yのソース修正を施すと、 無事gmakeは正常終了しました。 これで先に進めます。 ありがとうございました。

こんにちは。 >ソースファイルをダウンロードして、mycalcをmake.batを実行してgccで >コンパイルすると、lex.yy.cというファイルはできましたが、もう一つの >ファイルはCのファイルではなくy.outputになっています。Windows上で、 >MinGW, MSYS, bison, flexをインストールして実行しています。 >アドバイスいただけないでしょうか。 こちらも確認ですが、そちらで試されたファイルは、以下のページからダウンロード した win_sjis.LZHまたはwin_sjis.zipのいずれかで、 http://kmaebashi.com/programmer/devlang/book/download.html かつ、その中で、該当のエラーになったのは、mycalc以下のmake.batでよいでしょうか? (mycalc_exではなく) lex.yy.cができていて、y.tab.cおよびy.tab.hができていないとすると、 yacc(bison)側が何らかのエラーになっているのではないかと思うのですが、 エラーメッセージの類は出ていないでしょうか? もしmake.batをダブルクリックして実行されているのであれば(それだと仮に エラーメッセージが出ていても読めないので)、以下を参考にコマンドプロンプトから 実行してみてください。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&thread=1426 エラーメッセージが出るようであれば、そのままこの掲示板にコピペしてください。 よろしくお願いします。

>こんにちは。初めて投稿します。 はじめまして。 >８月１７日にソースコードをダウンロードして、順にコンパイルしているうち、 >Diksamのcompiler項になったら次のようなエラーメッセージが表示されました。 確認ですが、そちらで試されたファイルは、以下のページからダウンロードした win_sjis.LZHまたはwin_sjis.zipのいずれかで、 http://kmaebashi.com/programmer/devlang/book/download.html かつ、その中で、該当のエラーになったのは、diksam_book_0_1でよいですよね。 >>bison --yacc -dy diksam.y >>diksam.y:428 13-14: $$ for the midrule at $2 of 'block' has no declared type >>gmake: *** [y.tab..h] Error 1 428行目でエラーが出ていますが、確かに、diksam_book_0_1のcompiler\diksam.yの 428行目近辺は、以下のようになっています。 1 2 3 4 　　12345678901234567890123456789012345678901234567890　 425:block 426: : LC 427: { 428: $$ = dkc_open_block(); 429: } 430: statement_list RC 431: { 432: $$ = dkc_close_block($<block>2, $3); 433: } 434: | LC RC 435: { 436: Block *empty_block = dkc_open_block(); 437: $$ = dkc_close_block(empty_block, NULL); 438: } 439: ; 428行目の13～14文字目は「$$」ですが、この$$は、埋め込みアクションの ターゲットを示しています。「プログラミング言語を作る」p.206～207で、 「以下のように書くのと同値です。」と書かれている例におけるdummy_targetです。 メッセージを見る限り、dummy_target相当のターゲットは型の宣言をしていないので、 上記のエラーが出ているようです(「ようです」というのは、当方の環境では エラーにならずに動いているためです)。 428行目を以下のように変更して試してみていただけますでしょうか。 428: $<block>$ = dkc_open_block(); 正直、私はもうずいぶん前からここのところは$$で書いていてLinuxでもWindowsでも 動いていたはずですが、確かに、正しくは「$<block>$」と書くべきところかと 思います。 ご報告ありがとうございました。確認のうえでソースの修正および補足記事を Webで出させていただきます。

ソースファイルをダウンロードして、mycalcをmake.batを実行してgccでコンパイルすると、lex.yy.cというファイルはできましたが、もう一つのファイルはCのファイルではなくy.outputになっています。Windows上で、MinGW, MSYS, bison, flexをインストールして実行しています。アドバイスいただけないでしょうか。

こんにちは。初めて投稿します。 ８月１７日にソースコードをダウンロードして、順にコンパイルしているうち、Diksamのcompiler項になったら次のようなエラーメッセージが表示されました。 >bison --yacc -dy diksam.y >diksam.y:428 13-14: $$ for the midrule at $2 of 'block' has no declared type >gmake: *** [y.tab..h] Error 1 実行環境はWin XPで、MinGWは今回インストールしましたが、CygWinは１年ほど前にインストールしたものを使っています。 システムの起動もツールとソースコードの展開もＤドライブで実行していて、「鬼車」もインストール済みです。 Bisonの文法は自信がないので、エラーの内容について御教授ください。

>[mugenkai@love] % diksam if.dkm >if.dkm: 8:変数名bが重複しています。 これですね。 int a = 10; if (a > 5) { int b = 20; println("<1>b.." + b); } else { int b = 30; println("<2>b.." + b); } わかりにくい仕様ですが、これで「変数名bが重複しています。」エラーになるのは 現状のDiksamでは仕様です。 言語仕様の「ローカル変数」のところで、以下のように書いています。 http://kmaebashi.com/programmer/devlang/dls_0_4_01.html >関数内で宣言された変数はローカル変数(local variable) となる。 >ローカル変数のスコープは、以下の両方の条件を満たす範囲である >(現状で、グローバル変数のスコープは、ブロックの影響を受けない)。 ここでのbは関数内で宣言された変数ではないので、グローバル変数です。 グローバル変数のスコープはブロックの影響を受けないので、ifのブロック内であっても 二重に宣言することはできません。 # 仕様書に書けばバグも仕様に変わる、レベルの話かもしれませんが。 testフォルダにif.dkmが入っているのは、エラーになることを確認した残骸では ないかと思います…… まぎらわしくてすみません。

[mugenkai@love] % diksam if.dkm if.dkm: 8:変数名bが重複しています。 [mugenkai@love] % [/Users/mugenkai/Desktop/diksam_utf8/main/test] main/testフォルダのif.dkmが実行出来ません。 環境：MacOSX10.3.9

こんにちは。 >mingw32-make.exeというファイル名を gmakeという名前にコピーしたのですが >それをどうすればいいのか分かりません。gmakeをダブルクリックしたのですが >[No such file or directory]と表示され,いくつかファイルが作られるだけです。 「gmakeをダブルクリック」しているところからして、コマンドプロンプトを お使いになったことがないのでは、と想像しています。 crowbarやDiksamは、コンパイルするのも実行するのもコマンドプロンプトから 行うことをを想定しています。 WindowsXPやVistaであれば、スタートメニューから 　プログラム → アクセサリ → コマンドプロンプト で、コマンドプロンプトが表示されるはずです。 たとえば、crowbarの圧縮ファイル「crowbar_0_4_02_win.LZH」を C:\直下で展開したのであれば、「C:\crowbar_win」というフォルダができていると 思います。 コマンドプロンプトで cd C:\crowbar_win [Enter] とタイプして C:\crowbar_win に移動し、そこで gmake [Enter] とタイプすることで、crowbarがコンパイルされるはずです。 実行するときも、コマンドプロンプトから、 crowbar xxx.crb のようにタイプして実行します。 コマンドプロンプトの詳細は、たとえば以下のようなページが参考になると思います。 http://ykr414.com/dos/index.html 疑問点があれば遠慮なく書き込んでください。 なお、コマンドプロンプトでエラーが出た場合、それをここに書き込むのであれば かならずエラーメッセージをcopy&pasteしてください(正確なメッセージを知るため です。「エラーが出ました」だけでは何のエラーだかわかりません)。 コマンドプロンプト上のテキストをコピーする際は、コマンドプロンプトの タイトルバーで右クリックし、「範囲指定」→マウスで領域選択→「コピー」で 可能です。 # そのうち「Diksamではじめる12才からのゲームプログラミング」なんてのを # 書いてみたいと思っているのですが、コマンドプロンプトやフォルダ構造のところで # 若い人とはずいぶんギャップがありそうだ、とまさに思っていたところでした…… # とはいえWindowsをちゃんと使うなら、「コマンドプロンプトやフォルダ構造」は # 避けて通れないと思うんですがねえ。

crowbarが実行できないのですが Cコンパイラもcygwinもbisonもflexもいれました。電卓(mycalc)は実行形式ができるのですがcrowbarやDiksamは実行形式ができません。 mingw32-make.exeというファイル名を gmakeという名前にコピーしたのですがそれをどうすればいいのか分かりません。gmakeをダブルクリックしたのですが[No such file or directory]と表示され,いくつかファイルが作られるだけです。

>Diksam 2.0　より流用改変したソースはコンパイルラ部分のみで１２３K、 >全体の２２％。その中はクラス化や、言語仕様の違いで全関数修正している >ため。元の６割ぐらいしか原型が残っていないと思います。VMについては、 >新たに書いているので基本アルゴリズムが同じで、中身は違ったものになっ >ています。 そういえばVMは新規と言う話は以前書いておられたと思うのですけれど、 バイトコードが基本的に同一らしいので、VMも流用かと思い込んでしまいました。 コンパイラをgenerate.cまで含めて流用していれば、そりゃバイトコードは 似たようなものになりますね。 >　ソースの件ですが、正式にフリー公開時点でソース公開も考えています。 >現時点ではまだちょっとです。(ぱ)さん以外非公開を条件にVMのソース送り >ましょうか? 了解です。DiksamはGPLとかではないので、現時点では公開されないという 方針でしたらそれでよいかと思います。

つ、追記。 いや、ソフトを使って行数カウントしてみた。全体で17,657行ありました。それだけ^^;

>山さんのVMがDVMとどれぐらい違うのだろうと思ってダウンロードしてみましたが、 >VM部分のソースはないのでしょうか…… 　どれぐらい違うのかソースファイルのサイズで定量的に計ってみました。 ・システム管理部分　　１１５K（ソースファイルの合計） ・コンパイラ　　　　　１５０K ・VM　　　　　　　　　７３K ・共用　　　　　　　　４５K ・組込み関数　　　　　３４K ・ヘッダーファイル　　１４０K （クラスやテンプレートでヘッダーファイルが大きくなるのはC++の宿命ですね） 　　　　　　　　合計　５５７K 　プログラムの行数的にはコメント含み1万数千行ほどあります。 Diksam 2.0　より流用改変したソースはコンパイルラ部分のみで１２３K、 全体の２２％。その中はクラス化や、言語仕様の違いで全関数修正している ため。元の６割ぐらいしか原型が残っていないと思います。VMについては、 新たに書いているので基本アルゴリズムが同じで、中身は違ったものになっ ています。 　VMは最小になるように作られているので、７３K　全体の１３％です。ソース の６０％は新しく作りこんだ仕様のためでした。内容はマルチVMのシステム・ 言語的にスレッドセーフな仕組み・コンパイルとVM間の協調動作管理、等々です。 　私が言ってはいけないのかもしれませんが、結構複雑なシステムになってます。 難しいのもまた楽しくもあります。 　ソースの件ですが、正式にフリー公開時点でソース公開も考えています。 現時点ではまだちょっとです。(ぱ)さん以外非公開を条件にVMのソース送り ましょうか? 　VMは1つのクラスで、そのクラスのオブジェクトを1つ作ったら、それが1つの VMスレッドになり、VM機能を詰め込んだ、あまりクラスらしくないクラスです。 だから、メモリーがあるだけマルチでVMスレッドを自由に実行できます。 　ちなみにコンパイラも見た目は1クラス（内部でいくつかのクラスを使用）で、 機能的にきれいに分離されています。ただその分システム管理で全体の協調 動作制御が必要です。 >あと、フォルダ名の「editer」は固有名詞でしょうか? いえ、LIZA.iniファイルで自由に変えられます。 　先のことですが、ライザ言語はC言語のシンタックスにとても似ているので、 ライザ言語をC++のソースにコンパイルすることは簡単です。完成した後、 暇だったらシステムをライブラリー化して、コンパイルしたC++ソースとリンクし、 ネイティブな実行形式作成をやってみたいですね。

>http://ux.getuploader.com/yamamoto/download/3/debug.zip 山さんのVMがDVMとどれぐらい違うのだろうと思ってダウンロードしてみましたが、 VM部分のソースはないのでしょうか…… あと、フォルダ名の「editer」は固有名詞でしょうか?

　速いPCでも問題が…、日ごろノートPCで開発しているのですが。 久しぶりにディスクトップでやったら。 　デュアルPC以上だと、本体のスピードが早すぎてモニターの処理が 追いつかないです。　約1秒に1000行ぐらいの情報を送っています。 　UDP送信後　sleep(0)のウェイトをかけているのですが、シングルCPU だと、それなりに時間がかかるのですが、デュアル以上だと多少のウェイト だけで、高速にUDP送信をしていました。さすがに受けきれない結果に なります。t016.lzp t17.lzp　でモニターが動作異常になります。デバック モニターがロックしたような状態、UDP受信例外、等々が発生します。 　モニター側で、過負荷のときの処理を追加すべきでした。 そんな訳で、こんなデバックシステムが出来ましたよ程度としてみてください。 　その他、ディスアセンブラの行情報異常や、システム変数配列処理ミス、 変数のコンフリクト問題、等々その後見つかった問題も対策終了しています。 　見つかったバグのほとんどは、以前は無かったのですが、各種修正と機能 追加で新たにバグを作りこんだようです…　良くあることです　orz

　別のPCで実行したところ、MSVCXXXX.DLLが必要でした。 ↓にDLLを添付したファイルをUPしました。申し訳ありません。 http://ux.getuploader.com/yamamoto/download/3/debug.zip 　また、add_stringのバイトコードでたまーに、システム変数が コンフリクトを起こす現象を発見しています。 　あと、遅いPCでは、UDP通信が大幅に抜ける場合があります。 デバック用に最小時間を指定しているので、遅いPCでは大量の 送信データを受けきれないです。送信後のウェイトを長くすれば 問題ないのですが、デバックターンが長くなるのでこのままに しています。

　プログラムのブレーク、ステップ処理等を除き一応の完成、ブレーク等は アプリケーションのGUIが出来上がらないとボタンが無いので。その他にも いろいろ修正をしました。 　・言語の内部コードをSJISからワイド文字wchat_tに変更。 　・動的コンパイラの組込み。 　・コンパイルエラーのモニター連携 　・VM実行時エラーのモニター連携 　・デバックシステムの組込み（第1段階終了、全体の80%以上は終わったかな） 　・コンパイラのpool導入による高速メモリー確保と一括開放。 　・VMも一部Pool化。 　・VMの言語関数起動の最適化と高速化。 　・ライザ付属エディターの組込み。 　・LIZA.iniファイルによる初期化設定を組込み 　等々いろいろ修正しました。特にデバッグシステムの組み込みは大きかった。 もう、文字で示すのも画像で示すのも困難と思うので。↓にUPしています。 http://ux.getuploader.com/yamamoto/download/2/debug.zip もしお暇がありましたら試してみて、何かありましたらよろしくお願いします。 まだ本体はCUIで出来ています。多分バグだらけです。 　手順は、ライザデバックモニタ「LZ_moniter1_001.exe」を実行して、本体の 「lz002.exe」を実行するとデフォルトの「start.lzp」を実行します。以前出した タイマプログラムです。 　2つともローカルでUDP通信をしているので、通信許可でお願いします。 初期起動時は、UDP通信がごっそり抜ける時があるので、本体は2回以上起動して みたほうがいいかもしれません。時々モニターのログが抜ける時があります 　本体はデバックモードのままなのでEXEも大きく、動作はとても遅いです。 大量のデバックトレースをモニターに送っているので。 　また、XXX.lzpの起動をlz002.exeに起動リンクすれば、その他のプログラムは、 ダブルクリックで直接実行できます。そこに入っているXXX.lzpは総て動きます。 ただ、修正するとこける可能性が高いです。試作以前の段階なので。 　デバックの組込みで以下の言語仕様が追加されました。 ただ、まだほとんど機能しません。本体のGUIを作る時でないと２度手間に なってしまうので。 　次からはようやくアプリケーションの本体です。ああ～～長かった～ 次も長いんだろうな //-- デバック行コントロール ------------- #define DBL 　　　　　　 // デバック行有効 //#define DBL 　　　　　　/-/ // デバック行のコメント化 //-- デバック関係関数 ----------------------- #define 一時停止　　　　debug_break //-- デバックログ関係関数 ------------------- #define ファイル表示　　debug_file_disp // モニタにファイル表示 #define トレースログ　　debug_trace_log // トレースログに表示 #define システムログ　　debug_system_log // sysログに表示 #define ログ1 　　　　　debug_log1 // ログ1に表示 #define ログ2設定 　　　debug_log2_set // ログ2にタブ追加設定 #define ログ2 　　　　　debug_log2 // ログ2に表示 #define ログsys変数 　　debug_sysval // ログするシステム変数の登録 #define クリア　　　　　"クリア" // ログするシステム変数のクリア //-- デバックモニタ制御関数 ------------------- #define デバックモニタ制御　debug_monitor_control #define 変数ログクリア　　　1 // モニタ02の変数ログクリア #define 全ログクリア　　　　2 // モニタ01全ログクリア #define トレースログクリア　3 // トレースログクリア #define sysログクリア 　　　4 // sysログクリア #define ログ1クリア 　　　　5 // デバックログ1クリア #define ログ2クリア 　　　　6 // デバックログ2クリア //-- ログ出力制御用システム変数 --------------- #define 全ログSW　　　　　　SLI001 // 全てのログ0:停止1:開始 #define トレースログSW　　　SLI002 // トレースログSW #define システムログSW　　　SLI003 // #define ログ1SW 　　　　　　SLI004 // #define ログ2SW 　　　　　　SLI005 // #define ローカル変数ログSW　SLI006 // #define システム変数ログSW　SLI007 // //-- 組込み関数宣言 -------------------- DBL int 一時停止()　　　　 // 戻り=0 DBL int デバックモニタ制御(int type); // 戻り=0 DBL int ファイル表示(string fname); // 戻り=0 DBL int システムログ(string str); // 戻り=0 DBL int トレースログ(string str); // 戻り=0 DBL int ログ1(string str); // 戻り=0 DBL int ログ2設定(string tag_name); // 戻り=log2id DBL int ログ2(int log2id,string str); // 戻り=0 DBL int ログsys変数(string str); // 戻り=0 //--------------------------------------

>この週末は、土曜の夜からなんだかまぶたが腫れ上がってましてほとんど寝てました >(医者には行って薬ももらいましたが、原因は不明です)。 >反応が遅れましてすみません。 いえいえ、十分反応は早いですよ。 最近の投稿の時間を見ると夜中の3時前後・・・。 余計なことかもしれませんが、あまり無理をなさらずに。 ご自愛ください。

この週末は、土曜の夜からなんだかまぶたが腫れ上がってましてほとんど寝てました (医者には行って薬ももらいましたが、原因は不明です)。 反応が遅れましてすみません。 >プログラミング言語を作るをもう一度読んでいて2つミスプリントを見つけました。 > >p106 3-3-3「解析木の構築---corwbar.yとcreate.c」の第5パラグラフに >「アクションにて、crb_crete_binary_expression()」とありますが、 >「アクションにて、crb_create_binary_expression()」だと思います。 > >p189 補足「別のあるべき姿---Code Set Independent」の最後から3つめのパラグラフに >「それに対し、CSIだと(N-1)必要になります。」とありますが、 >これではUnicodeに正規化する方法よりエンコーディングを変換するコンバーターが少なくなってしまいます。 >(N-1)はN(N-1)の間違いでしょうか? たびたびすみません。ご指摘ありがとうございます。 正誤表に追加しました。

プログラミング言語を作るをもう一度読んでいて2つミスプリントを見つけました。 p106 3-3-3「解析木の構築---corwbar.yとcreate.c」の第5パラグラフに 「アクションにて、crb_crete_binary_expression()」とありますが、 「アクションにて、crb_create_binary_expression()」だと思います。 p189 補足「別のあるべき姿---Code Set Independent」の最後から3つめのパラグラフに 「それに対し、CSIだと(N-1)必要になります。」とありますが、 これではUnicodeに正規化する方法よりエンコーディングを変換するコンバーターが少なくなってしまいます。 (N-1)はN(N-1)の間違いでしょうか?

>>確かにPerlのlocalはダイナミックスコープですから、CやJavaのローカル変数とは >>挙動が異なります。とはいえグローバル変数とも明確に違うものだと思います。 >確かにその通りのようです。 一応、「プログラミング言語を作る」では、p.153にて、本当にちょっとだけ ダイナミックスコープの説明をしています。お気づきかもしれませんが念のため 補足します。 今読み返すと、ここでのCRB_LocalEnvironment構造体のnextメンバが何を 指しているのかわかりにくいような気がします…… ここでのnextは、 呼び出し元のCRB_LocalEnvironment構造体を指しています。

ひとまずここだけ。 >　Windowsのメッセージシステム…、あれは同期非同期以前のシーケンシャル >処理システムなんです。1スレッドでメッセージ取り出しループ処理して、メッセー >ジを受け取り、そのメッセージに対応する関数を呼んでいるだけで、並列処理は >していないです。 Windowsのメッセージシステムが並列でないのは当然ですけど、 ブラウザであれば、コンテンツの取得の方を別スレッドで回せるはずですよね。 IEがどうなっているかは知りませんが、いまどきのアプリですから当然そうなって いるのではないでしょうか。 でも、コンテンツ取得スレッドがネットワークの待ちでブロックされていたり、 ActiveXコンポーネントが動作中だったりすると、結局×ボタンで止められない ような感じがしています。まあいろいろ難しいよね、という程度の意味です。

>確かにPerlのlocalはダイナミックスコープですから、CやJavaのローカル変数とは >挙動が異なります。とはいえグローバル変数とも明確に違うものだと思います。 確かにその通りのようです。 >>myがない頃はlocalが使われていたそうですが、なぜmyより先にlocalが作られた >>のでしょう? > >過去のある一時点において、多くの人が「ダイナミックスコープかっこいい!」と >思ったことがある、ということなのではないでしょうか。 そういう歴史があるとは知りませんでした。 わざわざ回答してくださってありがとうございます。

>一応検索はしたのですが、Googleでは普通に非同期処理の記事しか出てこなかった >ような…… 　私のほうでは出るのですが…、では「非同期分散処理」という言い方でも いいかな、「非同期処理」までいくと意味合いがちょっと違うんですよね。 >ここのところが、yieldとかwait()とかの方法ではいけないのかな、というのが >私の疑問です。 　その場合、キュー処理にいろいろ問題が出てくるのです。まず第1に、キューの 優先順位ができない、全部のスレッドに優先順位処理を作りこめばいいのかも しれませんが、まったく非効率です。次に、キューを送る元と受け側が同期処理 していなければいけない。こえは、たとえば受け側がキューを処理中に、いくつも キューを送れない。これもまた各スレッドに…。つぎに、受け側がスレッドを 終了した場合、送り元に終了した旨の連絡して止めてもらう同期処理をしなければ、 相手がいないのにキューを送って宙ぶらりんとなる。等々キュー処理には(ぱ)さん が示したスレッドの関数だけでは無理なことが多いです。 　いろいろと作りこめば非同期もできます。しかしそれには、そのスレッド以外 でキューの管理システムを作らなければならないわけで。使用者にその管理部分 を作れと要求しているわけです。その要求をしている言語は「非同期分散処理」 をサポートしているとはいえません。 　（作れば何でもできると考えれば、アセンブラでOKってなってしまう） 　また、スレッド起きに監視ループが必要になってきますが。私が作りたい のは何十何百ものスレッドをターゲットに考えているので、そのスレッドの待機 処理時間が馬鹿にならないのです。私の言語は100スレッドあっても、待機時は 負荷0です。 　「非同期分散処理」を純粋にサポートしようと思ったら、今のスレッド仕様で は無理があるのです。C言語でも、OOPの様にクラスやカプセル化のようなことが 出来ます。でもだれもC言語がOOP言語とは言いません。それと同じことを言って いるように感じます。単純な基本機能があれば、その組み合わせでほとんどの ことが出来ます。しかし、その言語でできる事をサポートしているとはいえま せん。 >固定個のスレッドプールを持っているようなので、それを使い切った場合を想定して >いるのでしょうか? うーん。 　いえ、「非同期分散処理」を言語レベルでサポートするためにです。 >脱線しますけど、よく言われるマルチスレッドのメリットで、GUIのスレッドを >処理のスレッドと分けておけば、ユーザの操作にすぐ反応できる、というのが >ありますけど、じゃあ重たいページをIEで表示してしまった時、×ボタンですぐに >停止できるのかというと、さっぱり押せないことばっかりで…… 　Windowsのメッセージシステム…、あれは同期非同期以前のシーケンシャル 処理システムなんです。1スレッドでメッセージ取り出しループ処理して、メッセー ジを受け取り、そのメッセージに対応する関数を呼んでいるだけで、並列処理は していないです。だからその関数が終わらないと次の処理ができないシステム です。IEの中身がどうなっているかわかりませんが。即応できるシステムを作る のは難しいと思います。 　だからと言って、私の言語は即応かというと、作り方いかんで幾らでも遅く 作れますし、シングルスレッドでも作り方いかんでは早く処理できるし。 　マルチスレッドの方が融通は利きますが、その件は本質ではないと思います。 「非同期処理」だとイメージが違ってくるんです。掲示板で説明するのは難しい ので、作ったソフトを動かしてもらえれば…、ずいぶん先になりますが…。 　PS.終了だけを考えれば、私の言語は終了は遅いです。言語上のスレッドの 終了処理、VMスレッドの終了処理、その他組み込みスレッドの終了処理、 それぞれにリソースの開放処理等々、多分重い。 　終了は結構大変です。問題なければ1秒以内に終わると思いますけど。 何か問題があって、タイムアウト待ちでもしようものなら。冷汗たらー

　下記に示すURLに言語デバックシステムのプロトタイプイメージが あります。 http://dl7.getuploader.com/g/yamamoto/1/lz_db.gif こんな感じのデバックシステムを作る予定。エラーが発生したら、 モニターにファイルと行を表示して修正ができます。ただし、行番号 はないので、好みのエディターを使いたい場合は編集を押押すか エディターを登録してそのエディターを起動します。 　ファイルタブは、ファイルリストとファイルが表示され編集可能 です。簡単な修正ならここでできます。 　関数のトレースとログ１はスレッド置きにタブが作成されるので、 トレースが混合してわけワカメにならない予定。タブは200まで自動 で増えるので問題なし。 　システム情報のログはsysログに、自由に定義して使用可能なのが ログ２です。また、モニタ02がローカル変数とシステム変数のログ を表示します。全部でモニター2種、本体1を起動します。 　通信はUDPを使うので、LAN内の他PCでモニターできます。 　これはまだGUIを作ったものなので、これから詳細の実装です。 また、本体の表示部分はできていないので、真っ黒です。それ に、右上の実行・ステップ・ステップインのボタンはイメージで、 画像合成です。こんなボタンとシステムログが透過で表示される 予定。 　久しぶりにC#触ったけど、ユーザーインターフェース作るのが簡単だった。

回答が遅れましてすみません。 >でも、初期起動の中で必要なことを実行して、終了リターン >すれば、普通のスレッドと同じことが出来ます。 ここは了解です。 >違いは待機リターンが有りキュー待ち状態で待機できることです。 ここのところが、yieldとかwait()とかの方法ではいけないのかな、というのが 私の疑問です。 もちろん、yieldとかwait()とかで待つためには、VMがその状態を保持しなければ ならないので、固定数のネイティブスレッドのスレッドプールしか持たないのであれば 理解できます。これは前回 >固定個のスレッドプールを持っているようなので、それを使い切った場合を想定して >いるのでしょうか? うーん。 と書いたとおりです。 >これを説明しようとすると、とても長くなってしまいます。もしよろしけ >れば、「非同期協調処理」「非同期協調作業」「非同期分散処理」を検索 >していただければ嬉しいです。 一応検索はしたのですが、Googleでは普通に非同期処理の記事しか出てこなかった ような…… >　普通のスレッドを使用しないの理由は、起動するのも遅いし、終わる >のも遅い、非同期協調作業が出来るほど軽いものじゃないです。それに、 >キュー処理にはまったく対応していない。 脱線しますけど、よく言われるマルチスレッドのメリットで、GUIのスレッドを 処理のスレッドと分けておけば、ユーザの操作にすぐ反応できる、というのが ありますけど、じゃあ重たいページをIEで表示してしまった時、×ボタンですぐに 停止できるのかというと、さっぱり押せないことばっかりで……

>P85の補足「各言語のグローバル変数の扱い」のPerlの部分に「localとかmyとかを >付けて宣言するとローカル変数となる。」とあります。 >しかし、Cやjavaをおもに使っている人にとってlocalがローカル変数というのは >かなり違和感があると思います。 確かにPerlのlocalはダイナミックスコープですから、CやJavaのローカル変数とは 挙動が異なります。とはいえグローバル変数とも明確に違うものだと思います。 以下のサンプルで、きっぱり再帰できていますし。 ================================================== &hoge(0); sub hoge { my $depth = shift; #print 'depth..' . $depth; if ($depth > 2) { return; } local $i; for ($i = 1; $i <= 3; $i++) { print ' ' x $depth . '$i..' . $i . "\n"; hoge($depth + 1); } } ================================================== 私の感覚だと、ダイナミックスコープの変数は、自分自身とそこから呼び出された 関数からしか見えないという点でローカルだと思うのですが、確かに単に 「localとかmyとかを付けて宣言するとローカル変数となる。」とだけ書いて しまうのは確かに乱暴かもしれません。まあでもここはPerl, Ruby, PHPそれぞれの 言語の特徴をさらりと書いているだけのところなので、正誤表に載せるような ことではないのでは、と思います。 後日、補足記事をWebに上げようかと思います。 >myがない頃はlocalが使われていたそうですが、なぜmyより先にlocalが作られた >のでしょう? 過去のある一時点において、多くの人が「ダイナミックスコープかっこいい!」と 思ったことがある、ということなのではないでしょうか。 http://hagi.is.s.u-tokyo.ac.jp/pub/essay/hagiya/h/tensai | 僕は、Schemeの開発こそ、コンピュータ・サ | イエンスの典型的なセンスの一つではないかと | 思うのである。それまでは、LISPの考案者 | McCarthyのまやかしともいえる「変数の動的な | スコープ」に、皆がだまされ続けていたわけで | ある。 http://www.rubyist.net/~matz/20041025.html#p01 | 歴史的にはLispは(少なくともインタプリタ処理系では)、ダイナミックスコープが | 当たり前だったのだが、SchemeやCommonLisp以来すっかりスタティックスコープの | 言語になってしまっている。ダイナミックスコープなら外側のローカル変数もごく | 自然に見える。変数名の重複にだけ気をつければ良い(そういう意味ではcondやcommの | ようなありふれた引数名は良くない)。

もう一つ間違いとは言い切れないのですが、気になったところがあるのでついでに書いておきます。 P85の補足「各言語のグローバル変数の扱い」のPerlの部分に「localとかmyとかを付けて宣言するとローカル変数となる。」とあります。 しかし、Cやjavaをおもに使っている人にとってlocalがローカル変数というのはかなり違和感があると思います。 例えば、localを使った次のようなプログラムだとおかしな結果になります。 =============================================================== #!/usr/bin/perl $hoge = "global"; &func_local; &func_my; sub print_hoge { print "hoge is $hoge\n"; } sub func_local { local $hoge = "local"; print "func_local: "; print_hoge; } sub func_my { my $hoge = "my"; print "func_my: "; print_hoge; } =============================================================== 上記のプログラムを実行すると出力結果は func_local: hoge is local func_my: hoge is global になります。 myをつけた変数はCのローカル変数と同じように使えますが、localをつけた変数はCのローカル変数とは違います。 ちなみに、「初めてのPerl 第3版」の4.7 local演算子には「しかしlocalという名前は間違っています---あるいは、少なくとも、誤解を招く名前です。（中略）そうです、local変数と呼ばれる変数の正体は、実はグローバル変数なのです！」と書かれています。 myがない頃はlocalが使われていたそうですが、なぜmyより先にlocalが作られたのでしょう? 実装が楽だったとかなのでしょうか。 Cより新しい言語なのにCと同じローカル変数が使えなかったというのはどうなんだ・・・。

「名無しの読者」様 >「プログラミング言語を作る」を読ませていただきました。 >前橋さまの本は「C言語 ポインタ完全制覇」から読んでいるのですが、 >今回もおもしろい内容でした。 ありがとうございます。 >と書かれていますが、「Javaならファイナライザ、C++やC#なら・・・」の >間違いではないでしょうか？ ご指摘ありがとうございます。正誤表に載せておきました。 普通に読んで変だと思う(たとえJavaやC++やC#をまったく知らなかったとしても!)であろう 文章であるにもかかわらず、チェック時に見落とすとは、人間の思い込みとは 侮れないものです……

前橋さま 「プログラミング言語を作る」を読ませていただきました。 前橋さまの本は「C言語 ポインタ完全制覇」から読んでいるのですが、 今回もおもしろい内容でした。 ところで、ミスプリントらしい部分を見つけました。 303ページの補足「ファイナライザというかデストラクタというか」の第1パラグラフに 「Javaならデストラクタ、C++やC#ならデストラクタというメソッドが呼び出されます。」 と書かれていますが、「Javaならファイナライザ、C++やC#なら・・・」の 間違いではないでしょうか？ まだ、正誤表には載っていなかったようなので。

以下の2行がミスです >　なぜこうしたのかは、真に意味で完全な非同期協調処理をするためです。 　　↓ >　なぜこうしたのかは、真の意味で完全な非同期協調処理をするためです。 >　この説明で、疑問に答えられてのかまったく持って不安です。 　　↓ >　この説明で、疑問に答えられたのかまったく持って不安です。

>「終了指示」を含めると8回になるように思えるのですが…… 　タイマ表示関数に終了指示の処理がありますが、それのデバックのために 書いた部分が残っていました。このプログラムでは終了指示は出していない ので、7回です。 終了待ちをする関数コール > rtn[0] = スレ終了待ち(sid[0],終了待ち,10); 終了指示を出し終了を待ちをする関数コール > rtn[0] = スレ終了待ち(sid[0],終了指示待ち,10); 　出したプログラムは上のコールを使っていました。 誤解を与えるようなプログラムですみません。 >私が不思議なのは、なぜユーザプログラムの側をこのように細切れに >呼び出さなければならないのか、ということです。ユーザプログラムが >自ら処理を明け渡す必要がないことが、マルチスレッドの利点だと思う >のですが。 　一般的なマルチスレッドと、私が組み込みたいマルチスレッドは性格が 少し違います。でも、初期起動の中で必要なことを実行して、終了リターン すれば、普通のスレッドと同じことが出来ます。違いは待機リターンが有り キュー待ち状態で待機できることです。 　なぜこうしたのかは、真に意味で完全な非同期協調処理をするためです。 これを説明しようとすると、とても長くなってしまいます。もしよろしけ れば、「非同期協調処理」「非同期協調作業」「非同期分散処理」を検索 していただければ嬉しいです。いいHPでもあれば紹介するのですが、 びみょーに全部専門的で、びみょーに違うので。 　簡単に言うと、真のマルチ処理（複数CPU）環境における、同期処理を 必要としないで協調してひとつの処理を実行する。ああ、言葉を長くした だけだ。orz 　私はそれを、理論的に構築しようと思っているわけではなく、今のプロ グラミングパラダイム、この場合一番単純なC言語ライクな関数言語パラダ イムの上で、実際的に動くものを構築しようとしている、実利主義的に 泥臭いことをやっているわけです。動けばなんでもOK、きれいな理論なん て求めてません。＾＾　的な立場で作っています。 （動けばなんでもOKだから、シートなんて取って付けた物を使うあたりが） 　orz　orz 　その目的に必衰だったのが、今回のスレッドの仕様です。 　普通のスレッドを使用しないの理由は、起動するのも遅いし、終わる のも遅い、非同期協調作業が出来るほど軽いものじゃないです。それに、 キュー処理にはまったく対応していない。 　この説明で、疑問に答えられてのかまったく持って不安です。 もしよろしければ、説明不足な点をご指摘ください。

まず訂正です。 >>その「タイマ表示」関数は、引数のqidを順に >>変えながら、3回呼び出されているように見えますが……(そして毎回、自ら >>returnしている) 3回ではないですね。指定回数分だけqidが「タイマ」で呼び出されるのだろう、 ということは前回投稿時も認識していたはずですが、書き損じました。 >例えば、６回実行のスレは、初期１回とタイマー６回で、合計７回実行 >しています。 「終了指示」を含めると8回になるように思えるのですが…… それはさておき。 私が不思議なのは、なぜユーザプログラムの側をこのように細切れに呼び出さなければ ならないのか、ということです。ユーザプログラムが自ら処理を明け渡す必要が ないことが、マルチスレッドの利点だと思うのですが。 確認ですが、「スレ開始」(#defineをはがした実体はthread_start)は、山さんの 言語自体が提供しているシステム関数的なものですよね? そして、「タイマ表示」は、ユーザプログラマが作成することを想定したものですよね? マルチスレッドというのなら、ユーザのプログラムがreturnすることで処理を 手放さなくても、別のスレッドは動くわけですから、こんなふうに細切れに 呼び出さなくてもよいと思うのですが。この形式だと、ユーザプログラムは、 毎回カウンタを見て処理を切り替える必要があります。 固定個のスレッドプールを持っているようなので、それを使い切った場合を想定して いるのでしょうか? うーん。

>2:キュー処理開始 vm=3 procid=0 Qid=1 p1=999 >2:キュー処理開始 vm=4 procid=1 Qid=1 p1=6 >2:キュー処理開始 vm=2 procid=2 Qid=1 p1=5 >2:キュー処理開始 vm=0 procid=3 Qid=1 p1=4 >2:キュー処理開始 vm=4 procid=1 Qid=2 p1=1 >2:キュー処理開始 vm=1 procid=2 Qid=2 p1=1 >2:キュー処理開始 vm=1 procid=3 Qid=2 p1=1 >2:キュー処理開始 vm=4 procid=1 Qid=2 p1=1 >2:キュー処理開始 vm=1 procid=2 Qid=2 p1=1 >2:キュー処理開始 vm=1 procid=1 Qid=2 p1=1 >2:キュー処理開始 vm=1 procid=3 Qid=2 p1=1 >2:キュー処理開始 vm=2 procid=1 Qid=2 p1=1 >2:キュー処理開始 vm=4 procid=2 Qid=2 p1=1 >2:キュー処理開始 vm=1 procid=1 Qid=2 p1=1 >2:キュー処理開始 vm=2 procid=3 Qid=2 p1=1 >2:キュー処理開始 vm=1 procid=2 Qid=2 p1=1 >2:キュー処理開始 vm=4 procid=1 Qid=2 p1=1 >2:キュー処理開始 vm=1 procid=2 Qid=2 p1=1 >2:キュー処理開始 vm=1 procid=3 Qid=2 p1=1 　こ、これはVM1の実行が多い… タイマ処理が周期に比べて短くなったので、VMの待機状態が多くなったのでしょう。 その結果、VM1がキューをGETしやすいタイミングになったのではないかと思わ れます。VM3はmainが占有しているので。私のPCはデュアルなので、たまたま VM1が、空きCPUに割り振られたのかもしれませんね。 　面白い結果だと思います。もう少し重くなれば結果的にCPUの処理に対して 均等に負荷が割り振られるでしょう。

連投すみませんです。 このタイミングでスレを起動したときの実行結果です デバックトレースはそのままです。それらしい出力になったと思いますよ。 　　sid[0] = スレ開始("タイマ表示",200,6," 200ms"," で6回実行"); 　　sid[1] = スレ開始("タイマ表示",300,5," 300ms"," で5回実行"); 　　sid[2] = スレ開始("タイマ表示",400,4," 400ms"," で4回実行"); 　　↓ 　　↓ 　　↓ 3:###　スレッド起動　### 3: sid[0] =1 sid[1] =2 sid[2] =3 3:眠る前 ms=36239130 3:タイマ表示スレッド開始 SID=1 QID=1 回数=6 200ms で6回実行 3:タイマ表示スレッド開始 SID=2 QID=1 回数=5 300ms で5回実行 3:タイマ表示スレッド開始 SID=3 QID=1 回数=4 400ms で4回実行 3:タイマ表示 SID=1 QID=2 cnt=1 200ms で6回実行 3:眠る後 ms=36239440 3:タイマ表示 SID=2 QID=2 cnt=1 300ms で5回実行 3:タイマ表示 SID=3 QID=2 cnt=1 400ms で4回実行 3:タイマ表示 SID=1 QID=2 cnt=2 200ms で6回実行 3:タイマ表示 SID=2 QID=2 cnt=2 300ms で5回実行 3:タイマ表示 SID=1 QID=2 cnt=3 200ms で6回実行 3:タイマ表示 SID=3 QID=2 cnt=2 400ms で4回実行 3:タイマ表示 SID=1 QID=2 cnt=4 200ms で6回実行 3:タイマ表示 SID=2 QID=2 cnt=3 300ms で5回実行 3:タイマ表示 SID=1 QID=2 cnt=5 200ms で6回実行 3:タイマ表示 SID=3 QID=2 cnt=3 400ms で4回実行 3:タイマ表示 SID=2 QID=2 cnt=4 300ms で5回実行 3:タイマ表示 SID=1 QID=2 cnt=6 200ms で6回実行 3:タイマ表示スレッド終了 SID=1 QID=2 3:タイマ表示 SID=2 QID=2 cnt=5 300ms で5回実行 3:タイマ表示スレッド終了 SID=2 QID=2 3:タイマ表示 SID=3 QID=2 cnt=4 400ms で4回実行 3:タイマ表示スレッド終了 SID=3 QID=2 3: rtn[0] =0 rtn[1] =0 rtn[2] =0 3:###　全スレッド終了　### 2:### システム開始----- 2:### 組込み関数登録処理開始----- 2:### 組込み関数登録処理終了----- 2:### CL_VMexeスレッド 開始 2:スレッドRUN開始 vmid=0 2:### CL_VMexeスレッド 開始 2:スレッドRUN開始 vmid=1 2:### CL_VMexeスレッド 開始 2:スレッドRUN開始 vmid=2 2:### CL_VMexeスレッド 開始 2:スレッドRUN開始 vmid=3 2:### CL_VMexeスレッド 開始 2:スレッドRUN開始 vmid=4 2:### コンパイル初期化処理開始----- 2:### コンパイル開始----- 2:### コンパイル終了----- 2:### コンパイルの総てのリソースを開放----- 2:キュー処理開始 vm=3 procid=0 Qid=1 p1=999 2:キュー処理開始 vm=4 procid=1 Qid=1 p1=6 2:キュー処理開始 vm=2 procid=2 Qid=1 p1=5 2:キュー処理開始 vm=0 procid=3 Qid=1 p1=4 2:キュー処理開始 vm=4 procid=1 Qid=2 p1=1 2:キュー処理開始 vm=1 procid=2 Qid=2 p1=1 2:キュー処理開始 vm=1 procid=3 Qid=2 p1=1 2:キュー処理開始 vm=4 procid=1 Qid=2 p1=1 2:キュー処理開始 vm=1 procid=2 Qid=2 p1=1 2:キュー処理開始 vm=1 procid=1 Qid=2 p1=1 2:キュー処理開始 vm=1 procid=3 Qid=2 p1=1 2:キュー処理開始 vm=2 procid=1 Qid=2 p1=1 2:キュー処理開始 vm=4 procid=2 Qid=2 p1=1 2:キュー処理開始 vm=1 procid=1 Qid=2 p1=1 2:キュー処理開始 vm=2 procid=3 Qid=2 p1=1 2:キュー処理開始 vm=1 procid=2 Qid=2 p1=1 2:キュー処理開始 vm=4 procid=1 Qid=2 p1=1 2:キュー処理開始 vm=1 procid=2 Qid=2 p1=1 2:キュー処理開始 vm=1 procid=3 Qid=2 p1=1 2:スレッドRUN終了 vmid=3 2:スレッドRUN終了 vmid=1 2:スレッドRUN終了 vmid=0 2:スレッドRUN終了 vmid=2 2:スレッドRUN終了 vmid=4 2:### CL_VMexeスレッド 終了 2:### CL_VMexeスレッドハンドルをクローズしました 2:### CL_VMexeスレッド 終了 2:### CL_VMexeスレッドハンドルをクローズしました 2:### CL_VMexeスレッド 終了 2:### CL_VMexeスレッドハンドルをクローズしました 2:### CL_VMexeスレッド 終了 2:### CL_VMexeスレッドハンドルをクローズしました 2:### CL_VMexeスレッド 終了 2:### CL_VMexeスレッドハンドルをクローズしました 2:#debugMsg 残っているメモリーを開放　66　66 2:#debugMsg 残っている配列メモリーを開放　26　26 2:### システム終了----- 2:### CL_systemスレッド 終了 2:### CL_systemスレッドハンドルをクローズしました 2:### ダミーmain終了-----

ミスです…　orz >　　初期化とパラメーターをセーブして、待機終了　returnする >　　初期化とパラメーターをセーブして、待機returnする

　追記の追加。 　このプログラムは、周期タイマーを例に挙げていますが。本来の使い方は、 メッセージキューによる、完全非同期協調作業のための機能です。 おもに、スレが起動されたらすぐにキュー待ちになり。作業要求が来たら 処理するためにあります。仮にスレッドが１００有っても、キュー待ち状態 のときは、CPU負荷が０なのでなんら問題は有りません。 　う～～これ以上は、絵に描いた餅になりそうなのでこれで終わって。 実物のソフトで示して行きたいと思います。

　追記、オンメモリーだけでも切り替わりのタイミングを調べるのは困難かも しれない。切り替わったことを調べるためには、それぞれのタイミングで どこかにその情報を書くのですが、書き先は順番が分かるために共通の場所に 書かなくてはいけないのだけど、共通の場所とは、セマホ等で排他処理をする わけで、排他処理の時点でスレッドが切り替わってしまうので。意味が無い。 　物理的に信号監視できるＩＣＥがほしいと思ってしまう。^^ まあ問題が起こらなければ、いつ起ころうが関係が無いですけどね。

>ここで、スレッドを3本起動しており、「タイマ表示」という関数名の関数を >呼び出しているようですが、その「タイマ表示」関数は、引数のqidを順に >変えながら、3回呼び出されているように見えますが……(そして毎回、自ら >returnしている) 　ああ、やっぱりそう見えましたか。実は裏のデバックトレースが重過ぎて 実行が周期内に終わっていないのです。常にオーバフロー状態なんです。 で、デバックトレースOFFにすると、表示自体がデバックモニターの分類３ を使っているので、表示も消えてしまうと言うジレンマが… 　なので、最後にデバックトレースのサンプルを出したのですが、やはり^^; 実際は、VMの実行がトレースのためにめちゃくちゃ遅いのです。プログラムの 途中で処理が変わるどころか、バイトコード１命令の実行の中で２－４回VMが 変わって、VMがそれぞれの担当処理を実行しようとがんばっています。 しかし、デバックトレースは、UDP通信でデバックモニターに送っているので、 その通信をしたタイミング（通信処理のためのスレ一時中断）でスレッド チェンジが起こってしまっています。デバック情報１行送るたびにスレッドが ころころ変わってしまっています。 　まあでも、とてもいいデバック環境でした、ほんの些細なタイミングミスも、 ころころ引っかかるので、もう異常が出まくりでした。つぶすのは大変で したが、つぶし終わった後いろいろ変えてもなんら問題がおきませんでした。 　で、そのまま使ってたデータで文を作ってUPした後、これまずいかなーと 思って、デバックトレースサンプルを追加してみました。 　間違いなく、main＋３スレッド=４スレッド、細切れどころかミジン切れの 状態で動いています。後で、タイミングを長くしたものの出力でもUPします。 今ちょっとノートPCシステム入れ直ししてて、それにかかりっきりで… 手順を簡単に説明すると。下のスレ開始から > sid[0] = スレ開始("タイマ表示",40,6," 40ms"," で6回実行"); １、スレッド初期起動キューが作成される ２、空きVMがキューをGET位して、タイマ表示関数を実行 ３．タイマ表示関数は初期起動なので、システム変数を生成し 　　初期化とパラメーターをセーブして、待機終了　returnする ４、管理部分が、周期起動のスレッドが有るので、そのスレッド向けに 　　時間が来たら、周期起動のキューを作る。 ５．空きVMが周期起動キューを取り出し、その関数を実行する。 ６．タイマ表示関数は周期起動キューで起動されたことを理解して 　　カウンタを＋１して、そのカウンタを表示する。そして待機return ７．また４に戻り周期キューが作成されるー＞４に戻り ８．タイマ表示関数は周期起動キューの中で、回数値とカウンタを 　　比較してカウンタ＞＝回数なら、終了returnして、スレッドが終わる。 　こんな感じで動いています。たぶん説明が抜けていたのは、システムが 周期キューを生成している部分だと思います。 例えば、６回実行のスレは、初期１回とタイマー６回で、合計７回実行 しています。 　スレ１が７回、スレ２が６回、スレ３が５回実行しています。 で、タイマ表示関数は周期に追いついていないので、システムは回数以上 の周期タイマーキューを生成していて、VMが実行しようとしています。 また、ちがうVMが同じスレッドの周期キューを平行して実行しようと してしまいます。もちろんこれは問題が起こるので、そうならないように 作られています。言葉で言うと簡単そうですが、複雑な制御をしています。 　常に重い状態で動いているので、キューが溜まってヘビーな状態で デバックをしていました。 >「タイマ表示」関数がreturnしないまま、別のスレッドに制御を奪われることって >あるんでしょうか? もう、１回のキュー処理で数十回はVMのスレッドチェンジが起こっています。 各スレッド処理は、みじん切りの細切れで並列に動いています。 デバックトレースを止めればそのようなことは無いと思います。 　デバックトレースを止めた時に、どの様なタイミングで切り替わるかは 興味があります。しかしそれを調べるためには、表示は一切使えないんで すねね、なんに表示してもその間に切り替わるから。オンメモリーだけで 高速のトレーサでも作りこまないと、それでも、VMの方が早いかもしれ ない。

ホイヘンスさん、はじめまして。 情報ありがとうございます。 >駄文なページの「表計算ソフトって」のページで >Parse error: syntax error, unexpected '^' in /home/km3943/public_html/essay/excel.html on line 62 > >「15パズルの作り方」のページで >Parse error: syntax error, unexpected '^' in /home/km3943/public_html/essay/puzzle.html on line 181 ただのHTMLファイルのはずなのに、なぜかPHPが動いていますね…… .htaccess等でそのような設定にすることはできますが(そして雑記帳では、 その設定を入れていますが)、ここにはそのような設定ファイルは置いていません。 実は今、トップのディレクトリに.htaccessがなぜかあるのを発見し、 これのせいかと思ったのですが中身は0バイトでした(削除しても直らないですし)。 さすがに今は眠いので週末もう少し追ってみます。 情報ありがとうございました。

すみません、今みっつくらいよくわからないのですが、 > sid[0] = スレ開始("タイマ表示",40,6," 40ms"," で6回実行"); > sid[1] = スレ開始("タイマ表示",60,5," 60ms"," で5回実行"); > sid[2] = スレ開始("タイマ表示",80,4," 80ms"," で4回実行"); ここで、スレッドを3本起動しており、「タイマ表示」という関数名の関数を 呼び出しているようですが、その「タイマ表示」関数は、引数のqidを順に 変えながら、3回呼び出されているように見えますが……(そして毎回、自ら returnしている) >int タイマ表示(int sid, int qid,int p1, string p2, string p3) >{ > string questr = " SID=" + sid + " QID=" + qid; > if(qid == スレッド開始) { > // スレッド起動時のみ時実行　-------------- > println("タイマ表示スレッド開始"+questr+" 回数="+p1+p2+p3); > システム変数("HAI000-HAI001",生成); > カウント = 0; > 回数 = p1; > システム変数("HAS000-HAS001",生成); > P2STR = p2; > P3STR = p3; > } elsif(qid == タイマ) { > // タイマキューにより実行　-------------- > カウント++; > println("タイマ表示"+questr+" cnt="+カウント+P2STR+P3STR); > if(カウント >= 回数) { > println("タイマ表示スレッド終了" + questr); > return スレッド終了; > } > } elsif(qid == 終了指示) { > println("タイマ表示　終了指示により終了" + questr); > return スレッド終了; > } else { > println("タイマ表示スレッド エラー終了" + questr); > return スレッドエラー終了; > } > return スレッド待機; >} 「タイマ表示」関数がreturnしないまま、別のスレッドに制御を奪われることって あるんでしょうか?

　参考までに今の2+VM5の７スレッド実行状態でのデバックトレースを 下記に示しますが、もうなんというか、７スレッド入り乱れたトレースで わけわからん状態です。デバックモニターシステムは４分類あるのですが スレ起きに無いともう分けわかめで、デバックモニターシステムも修正です。 　下記ではVM内でぶちぶちにスレッドが入れ替わっている状態が見れます。 ---------------------------------------------------- 1:eq_int PC=25 sp=292 1:eq_int PC=25 sp=292 1:add_string PC=6 sp=416 1:add_string PC=6 sp=424 1:00B5FF54 : ES_INT size=12605 ref=NON int=1 1:00B6FF94 : ES_INT size=12605 ref=NON int=1 1:00BA2160 : ES_STRING size=40 ref=NON string="タイマ表示スレッド開始 SID=1 QID=1 回数=6 40ms で6回実行 " 1:00B916B8 : ES_STRING size=40 ref=NON string="眠る前 ms=40224457 " 1:jump_if_false PC=26 sp=276 1:jump_if_false PC=26 sp=276 1:call_function PC=7 sp=376 1:call_function PC=7 sp=384 1:00B5FF64 : ES_FUNCTION size=244 1:00B6FFA4 : ES_FUNCTION size=244 1:#-C_NF_print::funcexe() 1:#-C_NF_print::funcexe() 3:タイマ表示スレッド開始 SID=1 QID=1 回数=6 40ms で6回実行 1: 関数からの戻りプログラムカウンタ = 0 3:眠る前 ms=40224457 1: 関数からの戻りプログラムカウンタ = 0 1:00BA2178 : ES_INT size=16 ref=NON int=0 1: 関数からの戻りスタックポイント = 0 1:00B916D0 : ES_INT size=16 ref=NON int=0 1: 関数からの戻りスタックポイント = 0 1:pop PC=16 sp=352 1: VMが起動する関数情報 = 00BC60F0 1:pop PC=16 sp=360 1: VMが起動する関数情報 = 00BC60F0 1:00BA2188 : ES_FUNCTION size=320 1: ローカル変数数 = 6 1:00B916E0 : ES_FUNCTION size=352 1: ローカル変数数 = 6 1: 関数からの戻りプログラムカウンタ = 62 1:push_string_const PC=29 sp=260 1: 関数からの戻りプログラムカウンタ = 168 1:push_string_const PC=29 sp=260 1: 関数からの戻りスタックポイント = 65276 1:00B5FF3C : ES_STRING size=40 ref=NON string="タイマ表示スレッド開始" 1: 関数からの戻りスタックポイント = 65268 1:00B6FF7C : ES_STRING size=40 ref=NON string="タイマ表示スレッド開始" 1: VMが起動する関数情報 = 00BC6F48 1:push_stack_string PC=32 sp=300 1: VMが起動する関数情報 = 00BC6F48 1:push_stack_string PC=32 sp=300 1: ローカル変数数 = 1 1:00B5FF14 : ES_STRING size=40 ref=00B5FFB8 string=" SID=2 QID=1" 1: ローカル変数数 = 1 1:00B6FF54 : ES_STRING size=40 ref=00B6FFF8 string=" SID=3 QID=1" 1:push_int_1byte PC=17 sp=336 1:add_string PC=35 sp=340 1:push_int_1byte PC=17 sp=344 1:add_string PC=35 sp=340 1:00BA2178 : ES_INT size=16 ref=NON int=0 1:00B5FF3C : ES_STRING size=40 ref=NON string="タイマ表示スレッド開始 SID=2 QID=1" 1:00B916D0 : ES_INT size=16 ref=NON int=0 1:00B6FF7C : ES_STRING size=40 ref=NON string="タイマ表示スレッド開始 SID=3 QID=1" 1:return PC=19 sp=352 1:push_string_const PC=36 sp=300 1:return PC=19 sp=360 1:push_string_const PC=36 sp=300 1:00BA21C4 : ES_INT size=16 ref=NON int=0 1:00B5FF14 : ES_STRING size=40 ref=NON string=" 回数=" 1:00B9171C : ES_INT size=16 ref=NON int=0 1:00B6FF54 : ES_STRING size=40 ref=NON string=" 回数=" 1:pop PC=62 sp=276 1:add_string PC=39 sp=340 1:pop PC=168 sp=284 1:add_string PC=39 sp=340 1:00BA21D4 : ES_FUNCTION size=244 1:00B5FF3C : ES_STRING size=40 ref=NON string="タイマ表示スレッド開始 SID=2 QID=1 回数=" 1:00B9172C : ES_FUNCTION size=124 1:00B6FF7C : ES_STRING size=40 ref=NON string="タイマ表示スレッド開始 SID=3 QID=1 回数=" 1: 関数からの戻りプログラムカウンタ = 0 1:push_stack_int PC=40 sp=300 1: 関数からの戻りプログラムカウンタ = 0 1:push_stack_int PC=40 sp=300 1: 関数からの戻りスタックポイント = 0 ----------------------------------------------------------------

あれからもいろいろ考えましたが、システム変数をシート形式でやる方法 以上の良い案が浮かびませんでした。ワーク用のグローバル変数を作ること は簡単なのですが、サービスのほとんどはシート上にて提供されるため、 これを越える案が今の所出そうに無いです。 　もしよろしければ、システム変数が座標であることは少し目をつぶって いただけたら嬉しいです。確かに私も抵抗が有りますが、良い代替案が浮か ばない、有れば変えるのもそう難しくないと思います。

　下記はプログラムのアセンブラコードです、特に何も変わっていませんが、 ごく普通のコードでマルチスレッドを問題なく実行しています。 1:*** 一般関数情報ダンプ ****************** 1:int main_001() 1:*** ローカル変数の表示 no = 2 *** 1: 0:int [3] sid 1: 1:int [3] rtn 1:*** 配列定数 数 = 0 ********** 1:*** 文字列 数 = 25 *** 1: 0: "main_001" 1: 1: "sid" 1: 2: "rtn" 1: 3: "###　スレッド起動　###" 1: 4: "println" 1: 5: "タイマ表示" 1: 6: " 40ms" 1: 7: " で6回実行" 1: 8: "thread_start" 1: 9: " 60ms" 1: 10: " で5回実行" 1: 11: " 80ms" 1: 12: " で4回実行" 1: 13: " sid[0] =" 1: 14: " sid[1] =" 1: 15: " sid[2] =" 1: 16: "眠る前 ms=" 1: 17: "get_ms_time" 1: 18: "sleep" 1: 19: "眠る後 ms=" 1: 20: "thread_exit_waiting" 1: 21: " rtn[0] =" 1: 22: " rtn[1] =" 1: 23: " rtn[2] =" 1: 24: "###　全スレッド終了　###" 1:*** 使用予定のスタックサイズ = 2116 1:*** 関数コードのディスアセンブラ size = 348 1: 0 push_string_const 3 1: 3 call_function 4 0 0 1 1: 12 pop 1: 13 push_string_const 5 1: 16 push_int_1byte 40 1: 18 push_int_1byte 6 1: 20 push_string_const 6 1: 23 push_string_const 7 1: 26 call_function 8 0 0 5 1: 35 push_stack_array 0 1: 38 push_int_1byte 0 1: 40 pop_array_int 1: 41 push_string_const 5 1: 44 push_int_1byte 60 1: 46 push_int_1byte 5 1: 48 push_string_const 9 1: 51 push_string_const 10 1: 54 call_function 8 0 0 5 1: 63 push_stack_array 0 1: 66 push_int_1byte 1 1: 68 pop_array_int 1: 69 push_string_const 5 1: 72 push_int_1byte 80 1: 74 push_int_1byte 4 1: 76 push_string_const 11 1: 79 push_string_const 12 1: 82 call_function 8 0 0 5 1: 91 push_stack_array 0 1: 94 push_int_1byte 2 1: 96 pop_array_int 1: 97 push_string_const 13 1: 100 push_stack_array 0 1: 103 push_int_1byte 0 1: 105 push_array_int 0 1: 107 cast_int_to_string 1: 108 add_string 1: 109 push_string_const 14 1: 112 add_string 1: 113 push_stack_array 0 1: 116 push_int_1byte 1 1: 118 push_array_int 0 1: 120 cast_int_to_string 1: 121 add_string 1: 122 push_string_const 15 1: 125 add_string 1: 126 push_stack_array 0 1: 129 push_int_1byte 2 1: 131 push_array_int 0 1: 133 cast_int_to_string 1: 134 add_string 1: 135 call_function 4 0 0 1 1: 144 pop 1: 145 push_string_const 16 1: 148 call_function 17 0 0 0 1: 157 cast_int_to_string 1: 158 add_string 1: 159 call_function 4 0 0 1 1: 168 pop 1: 169 push_int_2byte 300 1: 172 call_function 18 0 0 1 1: 181 pop 1: 182 push_string_const 19 1: 185 call_function 17 0 0 0 1: 194 cast_int_to_string 1: 195 add_string 1: 196 call_function 4 0 0 1 1: 205 pop 1: 206 push_stack_array 0 1: 209 push_int_1byte 0 1: 211 push_array_int 0 1: 213 push_int_1byte 0 1: 215 push_int_1byte 10 1: 217 call_function 20 0 0 3 1: 226 push_stack_array 1 1: 229 push_int_1byte 0 1: 231 pop_array_int 1: 232 push_stack_array 0 1: 235 push_int_1byte 1 1: 237 push_array_int 0 1: 239 push_int_1byte 0 1: 241 push_int_1byte 10 1: 243 call_function 20 0 0 3 1: 252 push_stack_array 1 1: 255 push_int_1byte 1 1: 257 pop_array_int 1: 258 push_stack_array 0 1: 261 push_int_1byte 2 1: 263 push_array_int 0 1: 265 push_int_1byte 0 1: 267 push_int_1byte 10 1: 269 call_function 20 0 0 3 1: 278 push_stack_array 1 1: 281 push_int_1byte 2 1: 283 pop_array_int 1: 284 push_string_const 21 1: 287 push_stack_array 1 1: 290 push_int_1byte 0 1: 292 push_array_int 0 1: 294 cast_int_to_string 1: 295 add_string 1: 296 push_string_const 22 1: 299 add_string 1: 300 push_stack_array 1 1: 303 push_int_1byte 1 1: 305 push_array_int 0 1: 307 cast_int_to_string 1: 308 add_string 1: 309 push_string_const 23 1: 312 add_string 1: 313 push_stack_array 1 1: 316 push_int_1byte 2 1: 318 push_array_int 0 1: 320 cast_int_to_string 1: 321 add_string 1: 322 call_function 4 0 0 1 1: 331 pop 1: 332 push_string_const 24 1: 335 call_function 4 0 0 1 1: 344 pop 1: 345 push_int_1byte 98 1: 347 return 1:*** 行情報 数 = 14 *** 1: 36: from 0 size 13 1: 38: from 13 size 28 1: 39: from 41 size 28 1: 40: from 69 size 28 1: 41: from 97 size 48 1: 43: from 145 size 24 1: 44: from 169 size 13 1: 45: from 182 size 24 1: 49: from 206 size 26 1: 50: from 232 size 26 1: 51: from 258 size 26 1: 52: from 284 size 48 1: 53: from 332 size 13 1: 54: from 345 size 3 1:*** end of main_001() -------------- 1:--------デバックログ中止-------- 1:--------デバックログ開始-------- 1:*** 一般関数情報ダンプ ****************** 1:int タイマ表示(int sid, int qid, int p1, string p2, string p3) 1:*** ローカル変数の表示 no = 6 *** 1: 0:int sid 1: 1:int qid 1: 2:int p1 1: 3:string p2 1: 4:string p3 1: 5:string questr 1:*** 配列定数 数 = 0 ********** 1:*** 文字列 数 = 19 *** 1: 0: "タイマ表示" 1: 1: "sid" 1: 2: "qid" 1: 3: "p1" 1: 4: "p2" 1: 5: "p3" 1: 6: "questr" 1: 7: " SID=" 1: 8: " QID=" 1: 9: "タイマ表示スレッド開始" 1: 10: " 回数=" 1: 11: "println" 1: 12: "HAI000-HAI001" 1: 13: "sysval" 1: 14: "HAS000-HAS001" 1: 15: " cnt=" 1: 16: "タイマ表示スレッド終了" 1: 17: "タイマ表示　終了指示により終了" 1: 18: "タイマ表示スレッド エラー終了" 1:*** 使用予定のスタックサイズ = 1612 1:*** 関数コードのディスアセンブラ size = 282 1: 0 push_string_const 7 1: 3 push_stack_int 0 1: 6 cast_int_to_string 1: 7 add_string 1: 8 push_string_const 8 1: 11 add_string 1: 12 push_stack_int 1 1: 15 cast_int_to_string 1: 16 add_string 1: 17 pop_stack_string 5 1: 20 push_stack_int 1 1: 23 push_int_1byte 1 1: 25 eq_int 1: 26 jump_if_false 127 1: 29 push_string_const 9 1: 32 push_stack_string 5 1: 35 add_string 1: 36 push_string_const 10 1: 39 add_string 1: 40 push_stack_int 2 1: 43 cast_int_to_string 1: 44 add_string 1: 45 push_stack_string 3 1: 48 add_string 1: 49 push_stack_string 4 1: 52 add_string 1: 53 call_function 11 0 0 1 1: 62 pop 1: 63 push_string_const 12 1: 66 push_int_1byte 1 1: 68 call_function 13 0 0 2 1: 77 pop 1: 78 push_int_1byte 0 1: 80 pop_sysval_int 1-364-0 1: 85 push_stack_int 2 1: 88 pop_sysval_int 1-364-1 1: 93 push_string_const 14 1: 96 push_int_1byte 1 1: 98 call_function 13 0 0 2 1: 107 pop 1: 108 push_stack_string 3 1: 111 pop_sysval_str 3-364-0 1: 116 push_stack_string 4 1: 119 pop_sysval_str 3-364-1 1: 124 jump 279 1: 127 push_stack_int 1 1: 130 push_int_1byte 2 1: 132 eq_int 1: 133 jump_if_false 227 1: 136 push_sysval_int 1-364-0 1: 141 increment 1: 142 pop_sysval_int 1-364-0 1: 147 push_string_const 0 1: 150 push_stack_string 5 1: 153 add_string 1: 154 push_string_const 15 1: 157 add_string 1: 158 push_sysval_int 1-364-0 1: 163 cast_int_to_string 1: 164 add_string 1: 165 push_sysval_str 3-364-0 1: 170 add_string 1: 171 push_sysval_str 3-364-1 1: 176 add_string 1: 177 call_function 11 0 0 1 1: 186 pop 1: 187 push_sysval_int 1-364-0 1: 192 push_sysval_int 1-364-1 1: 197 ge_int 1: 198 jump_if_false 224 1: 201 push_string_const 16 1: 204 push_stack_string 5 1: 207 add_string 1: 208 call_function 11 0 0 1 1: 217 pop 1: 218 push_int_1byte 1 1: 220 return 1: 221 jump 224 1: 224 jump 279 1: 227 push_stack_int 1 1: 230 push_int_1byte 3 1: 232 eq_int 1: 233 jump_if_false 259 1: 236 push_string_const 17 1: 239 push_stack_string 5 1: 242 add_string 1: 243 call_function 11 0 0 1 1: 252 pop 1: 253 push_int_1byte 1 1: 255 return 1: 256 jump 279 1: 259 push_string_const 18 1: 262 push_stack_string 5 1: 265 add_string 1: 266 call_function 11 0 0 1 1: 275 pop 1: 276 push_int_1byte 2 1: 278 return 1: 279 push_int_1byte 0 1: 281 return 1:*** 行情報 数 = 29 *** 1: 65: from 0 size 20 1: 66: from 20 size 6 1: 89: from 26 size 3 1: 68: from 29 size 34 1: 69: from 63 size 15 1: 70: from 78 size 7 1: 71: from 85 size 8 1: 72: from 93 size 15 1: 73: from 108 size 8 1: 74: from 116 size 8 1: 89: from 124 size 3 1: 75: from 127 size 6 1: 89: from 133 size 3 1: 77: from 136 size 11 1: 78: from 147 size 40 1: 79: from 187 size 11 1: 83: from 198 size 3 1: 80: from 201 size 17 1: 81: from 218 size 3 1: 83: from 221 size 3 1: 89: from 224 size 3 1: 83: from 227 size 6 1: 89: from 233 size 3 1: 84: from 236 size 17 1: 85: from 253 size 3 1: 89: from 256 size 3 1: 87: from 259 size 17 1: 88: from 276 size 3 1: 90: from 279 size 3 1:*** end of タイマ表示() -------------- 1:--------デバックログ中止-------- 1:--------デバックログ開始-------- 1:*** 一般関数情報ダンプ ****************** 1:int println(string str) 1:*** ローカル変数の表示 no = 1 *** 1: 0:string str 1:*** 配列定数 数 = 0 ********** 1:*** 文字列 数 = 4 *** 1: 0: "println" 1: 1: "str" 1: 2: " " 1: 3: "print" 1:*** 使用予定のスタックサイズ = 356 1:*** 関数コードのディスアセンブラ size = 20 1: 0 push_stack_string 0 1: 3 push_string_const 2 1: 6 add_string 1: 7 call_function 3 0 0 1 1: 16 pop 1: 17 push_int_1byte 0 1: 19 return 1:*** 行情報 数 = 2 *** 1: 95: from 0 size 17 1: 96: from 17 size 3 1:*** end of println() --------------

　下図に示すように、ダミーmainで1スレッド、システム管理で1スレッド VMスレッドが20、トータル22スレッドが動きます、VMが20がいいのか10が いいのかは、今後の調査により決まると思います。　実際の動作はVMの一つ が言語のmain関数が占有します。main関数が終了すると、サブのVMは強制 終了されます。だから、実際に作業するのは残りの19VMスレッドで処理が 自由に割り振られます。優先順位に従い、空いたVMから処理が行われます。 だから、言語上のスレッドはある時はVM3で実行しても次は空いていたVM12 が実行します。この構造が出来たことにより、普通の関数起動と同じよう な負荷でスレッドが起動できる軽いシステムになりました。 　ちなみにVMの待ち状態は、極微小の負荷しかありません。 　ダミーmainは、アプリケーションの各種表示処理の担当に使います。 　このシステムが出来たので言語上のファイバーは、比較的簡単に実装 できます。そのときの実行負荷も軽いです。 ダミーmain　　　　　　　　　システム管理 　-----　　　　---------------------------------------- 　|　 | ｽﾚ起動 |　　　　　　　　　　　　　　　　　　　| 　|　 | －＞ |　　　　　　　　　　　　　　　　　　　| 　-----　　　　---------------------------------------- 　　　　　　　　 ↓　　　　　↓　VMスレッド起動　　↓ 　　------------------　　--------　　　　　　　-------- 　　|　　　　　　　　|　　|　　　|　　　　　　　|　　　| 　　----------|　言　|　　|　Ｖ　|　VMスレッド　|　Ｖ　| 　　　　↓　　|　語　|　　|　Ｍ　|　20個が常に　|　Ｍ　| 　　--------　|　管　|　　|　０　|　　起動し　　|　１　| 　　|　コ　|　|　理　|　　|　０　|　キュー待ち　|　９　| 　　|　ン　|　|　　　|　　|　　　|　　　　　　　|　　　| 　　|　パ　|　|　　　|　　|　　　|　　　　　　　|　　　| 　　|　イ　|　|　　　|　　|　　　|　　　　　　　|　　　| 　　|　ラ　|　|　　　|　　|　　　|　　　　　　　|　　　| 　　--------　--------　　--------　　　　　　　-------- ----------------------------- 　　　　↓ 　　上の構造が実行した場合の、トレース情報。 　　デバック用にVMは5個起動しています。 　　このトレースではVM1がmainスレッドに割り当てられています。 　　　　↓ ----------------------------- 2:### ダミーmain開始----- 2:### CL_systemスレッド 開始 2:### システム開始----- 2:### 組込み関数登録処理開始----- 2:### 組込み関数登録処理終了----- 2:### CL_VMexeスレッド 開始 2:スレッドRUN開始 vmid=0 2:### CL_VMexeスレッド 開始 2:スレッドRUN開始 vmid=1 2:### CL_VMexeスレッド 開始 2:スレッドRUN開始 vmid=2 2:### CL_VMexeスレッド 開始 2:スレッドRUN開始 vmid=3 2:### CL_VMexeスレッド 開始 2:スレッドRUN開始 vmid=4 2:### コンパイル初期化処理開始----- 2:### コンパイル開始----- 2:### コンパイル終了----- 2:### コンパイルの総てのリソースを開放----- 2:キュー処理開始 vm=1 procid=0 Qid=1 p1=999 2:キュー処理開始 vm=2 procid=1 Qid=1 p1=6 2:キュー処理開始 vm=3 procid=2 Qid=1 p1=5 2:キュー処理開始 vm=0 procid=3 Qid=1 p1=4 2:キュー処理開始 vm=4 procid=1 Qid=2 p1=1 2:キュー処理開始 vm=2 procid=2 Qid=2 p1=1 2:キュー処理開始 vm=3 procid=3 Qid=2 p1=1 2:キュー処理開始 vm=0 procid=1 Qid=2 p1=1 2:キュー処理開始 vm=4 procid=2 Qid=2 p1=1 2:キュー処理開始 vm=3 procid=3 Qid=2 p1=1 2:キュー処理開始 vm=2 procid=1 Qid=2 p1=1 2:キュー処理開始 vm=4 procid=2 Qid=2 p1=1 2:キュー処理開始 vm=3 procid=3 Qid=2 p1=1 2:キュー処理開始 vm=0 procid=1 Qid=2 p1=1 2:キュー処理開始 vm=2 procid=2 Qid=2 p1=1 2:キュー処理開始 vm=4 procid=1 Qid=2 p1=1 2:キュー処理開始 vm=0 procid=3 Qid=2 p1=1 2:キュー処理開始 vm=3 procid=2 Qid=2 p1=1 2:キュー処理開始 vm=2 procid=1 Qid=2 p1=1 2:スレッドRUN終了 vmid=1 2:スレッドRUN終了 vmid=4 2:スレッドRUN終了 vmid=0 2:スレッドRUN終了 vmid=2 2:スレッドRUN終了 vmid=3 2:### CL_VMexeスレッド 終了 2:### CL_VMexeスレッドハンドルをクローズしました 2:### CL_VMexeスレッド 終了 2:### CL_VMexeスレッドハンドルをクローズしました 2:### CL_VMexeスレッド 終了 2:### CL_VMexeスレッドハンドルをクローズしました 2:### CL_VMexeスレッド 終了 2:### CL_VMexeスレッドハンドルをクローズしました 2:### CL_VMexeスレッド 終了 2:### CL_VMexeスレッドハンドルをクローズしました 2:#debugMsg 残っているメモリーを開放　66　66 2:#debugMsg 残っている配列メモリーを開放　26　26 2:### システム終了----- 2:### CL_systemスレッド 終了 2:### CL_systemスレッドハンドルをクローズしました 2:### ダミーmain終了-----

　ようやくマルチスレッドの組込みが終わりました。テストモデルは比較的 早くできたのですが、実際の組込みは多少時間がかかりました。全体的なり ファクタリングが必要だったし。 　下記プログラムのように、同じ関数を3スレッドで平行実行しています。 この言語の特徴は、なんらマルチスレッドを意識することなく、ただ関数を 書くだけでマルチで実行可能な点です。関数の入り口の書式は決まっていま すが、そこから呼ばれているprintln()等は何も意識していません。ちなみ にHシートのシステム変数はスレッド置きに作成され、そのスレッドが所有 権を持ちます。スレッドが100個あれば100枚のHシートができます。 　この様にシートによって各種特徴やサービスがあるシートと、自由に使え る汎用シートがあります。 　システム変数は総て所有権が有り、一つのスレッドが所有者になります。 もちろん委譲したり戻したり出来ますが、一度に1つのスレッドしか所有権 を持ちません。 　また、一般的なスレッドと多少性格が違い、1つのスレッドを起動すると、 初期起動実行後、メッセージ（キュー）が来るまで待ち状態で待機します。 待機時のCPU消費は0です。メッセージ駆動型のスレッドです。普通に関数 を書くだけで、いくら並列に起動されようと問題なく動きます。特別な知識 も要りません。 //-- スレッド操作関数 ---------------- #define スレ開始 thread_start #define スレ終了待ち thread_exit_waiting #define 終了待ち　　　0 // 終了を待つ #define 終了指示待ち　1 // 終了指示を出し終了を待つ #define 強制終了待ち　2 // 強制終了を出し終了を待つ //-- スレ終了待ち関数の戻り値 --------- #define 正常終了　　　0 // スレ正常終了 #define タイムアウト　1 // スレ終了待ちがタイムアウト //-- スレッド終了コード -------------- #define スレッド待機　0 // スレッドはキュー待ちに #define スレッド終了　1 // スレッド終了 #define スレッドエラー終了 2 // スレッドエラー終了 //-- キューID ------------------------ #define スレッド開始　1 // スレッド開始キューID #define タイマ　　　　2 // タイマキューID #define 終了指示　　　3 // 終了指示キューID //------------------------------------ #define 時間取出し　　get_ms_time #define 眠る　　　　　sleep #define システム変数　sysval #define 生成 1 // システム変数生成 //-- 組込み関数宣言 ------------------- int print(string str); int スレ開始(string fname,int ms,int p1,string p2,string p3); int スレ終了待ち(int sid,int type,int timeout); int システム変数(string str,int type); int 眠る(int time); int 時間取出し(); //------------------------------------------------------ int main() { //-- 同じ関数を違う周期でマルチスレッド起動する ------- int[3] sid; println("###　スレッド起動　###"); // 関数名, ms周期,P1, P2, P3 sid[0] = スレ開始("タイマ表示",40,6," 40ms"," で6回実行"); sid[1] = スレ開始("タイマ表示",60,5," 60ms"," で5回実行"); sid[2] = スレ開始("タイマ表示",80,4," 80ms"," で4回実行"); println(" sid[0] ="+sid[0]+" sid[1] ="+sid[1]+" sid[2] ="+sid[2]); println("眠る前 ms=" + 時間取出し()); 眠る(300); // 300ms眠る println("眠る後 ms=" + 時間取出し()); //--　スレッドが終了するまで待つ　--------------------- int[3] rtn; rtn[0] = スレ終了待ち(sid[0],終了待ち,10); // 10秒でタイムアウト rtn[1] = スレ終了待ち(sid[1],終了待ち,10); rtn[2] = スレ終了待ち(sid[2],終了待ち,10); println(" rtn[0] ="+rtn[0]+" rtn[1] ="+rtn[1]+" rtn[2] ="+rtn[2]); println("###　全スレッド終了　###"); return 98; } //-- システム変数の定義 -------------------------------- #define カウント HAI000 // タイマのカウンタ #define 回数 HAI001 // p1の終了回数 #define P2STR HAS000 // p2の文字列 #define P3STR HAS001 // p3の文字列 //-- 複数スレッド起動される周期タイマー処理関数 --------- int タイマ表示(int sid, int qid,int p1, string p2, string p3) { string questr = " SID=" + sid + " QID=" + qid; if(qid == スレッド開始) { // スレッド起動時のみ時実行　-------------- println("タイマ表示スレッド開始"+questr+" 回数="+p1+p2+p3); システム変数("HAI000-HAI001",生成); カウント = 0; 回数 = p1; システム変数("HAS000-HAS001",生成); P2STR = p2; P3STR = p3; } elsif(qid == タイマ) { // タイマキューにより実行　-------------- カウント++; println("タイマ表示"+questr+" cnt="+カウント+P2STR+P3STR); if(カウント >= 回数) { println("タイマ表示スレッド終了" + questr); return スレッド終了; } } elsif(qid == 終了指示) { println("タイマ表示　終了指示により終了" + questr); return スレッド終了; } else { println("タイマ表示スレッド エラー終了" + questr); return スレッドエラー終了; } return スレッド待機; } //------------------------------------------------------ int println(string str) { print(str + "\n"); return 0; } //------------------------------------------------------ 　　　　↓ 　　　実行結果 　　　　↓ -------------------------------------------- 3:###　スレッド起動　### 3: sid[0] =1 sid[1] =2 sid[2] =3 3:タイマ表示スレッド開始 SID=1 QID=1 回数=6 40ms で6回実行 3:タイマ表示スレッド開始 SID=2 QID=1 回数=5 60ms で5回実行 3:タイマ表示スレッド開始 SID=3 QID=1 回数=4 80ms で4回実行 3:眠る前 ms=33696948 3:タイマ表示 SID=1 QID=2 cnt=1 40ms で6回実行 3:タイマ表示 SID=2 QID=2 cnt=1 60ms で5回実行 3:タイマ表示 SID=3 QID=2 cnt=1 80ms で4回実行 3:タイマ表示 SID=1 QID=2 cnt=2 40ms で6回実行 3:タイマ表示 SID=2 QID=2 cnt=2 60ms で5回実行 3:タイマ表示 SID=3 QID=2 cnt=2 80ms で4回実行 3:タイマ表示 SID=1 QID=2 cnt=3 40ms で6回実行 3:タイマ表示 SID=2 QID=2 cnt=3 60ms で5回実行 3:タイマ表示 SID=3 QID=2 cnt=3 80ms で4回実行 3:眠る後 ms=33697360 3:タイマ表示 SID=1 QID=2 cnt=4 40ms で6回実行 3:タイマ表示 SID=2 QID=2 cnt=4 60ms で5回実行 3:タイマ表示 SID=1 QID=2 cnt=5 40ms で6回実行 3:タイマ表示 SID=3 QID=2 cnt=4 80ms で4回実行 3:タイマ表示 SID=2 QID=2 cnt=5 60ms で5回実行 3:タイマ表示スレッド終了 SID=3 QID=2 3:タイマ表示スレッド終了 SID=2 QID=2 3:タイマ表示 SID=1 QID=2 cnt=6 40ms で6回実行 3:タイマ表示スレッド終了 SID=1 QID=2 3: rtn[0] =0 rtn[1] =0 rtn[2] =0 3:###　全スレッド終了　### -------------------------------------------- 　上の例は、多少時間的な数値や前後がおかしいですが、この裏で大量の デバックトレースが動いているので、ずれています。

>どうやら、(また勝手に)PHPのバージョンが5に上げられていて、 >しかもなぜか雑記帳のページだけで「Call to undefined function mysql_connect()」と、 >mysqlモジュールがインストールされていないかのようなエラーが出ています…… ポインタ本にいつもお世話になっております。 突然ですがおそらく↑に関連したことだと思いますが 駄文なページの「表計算ソフトって」のページで Parse error: syntax error, unexpected '^' in /home/km3943/public_html/essay/excel.html on line 62 「15パズルの作り方」のページで Parse error: syntax error, unexpected '^' in /home/km3943/public_html/essay/puzzle.html on line 181 上記のエラーが出てページが見れません・・・

このところ更新していませんが、雑記帳 http://kmaebashi.com/zakki/index.html のページが使えなくなっています。 どうやら、(また勝手に)PHPのバージョンが5に上げられていて、 しかもなぜか雑記帳のページだけで「Call to undefined function mysql_connect()」と、 mysqlモジュールがインストールされていないかのようなエラーが出ています…… 見てのとおり、掲示板は動いているのに。

>　なぜこの様になったかを説明しても理解してもらうのは困難と思います。 >結局（ぱ）さんにとって、奇妙な言語ができたに過ぎないのではないかと思う >にいたりました。少し残念です。 ええと、私が先の投稿で書きたかったことは、「私から見れば変に見えるけど、 (NScripterがそうであるように)それがよいという人もいるのでしょう」という ことです。お気を悪くされましたらすみません。 私から見れば奇妙な言語であることは確かですが、Domain Specific Languageが 奇妙な言語に見えるのはよくあることですし、奇妙な言語でなければ、わざわざ 自作する価値がない、とも言えるでしょう(その意味で、crowbarやDiksamは 「おとなしすぎる」んだよなー)。

　ここ数日いろいろ考えたすえ、プロのプログラマやプログラミングに精通して いる人ほど抵抗が大きいと思いました。当初は#defineでは、との返信もありま したが、結局の所シートを前面に出す以上、座標の変数が使われることが多いで しょう。 　なぜこの様になったかを説明しても理解してもらうのは困難と思います。 結局（ぱ）さんにとって、奇妙な言語ができたに過ぎないのではないかと思う にいたりました。少し残念です。 　今は、マルチスレッド化に専念しています。仕組みのベースがほぼ出来上がっ たので、より深く検証した上で本体に組み込と試験になります。

>　変数名は　「シート＋列＋データ型＋項目番号」　＝　AAI000　となります。だから >自由に変数名はつけれない。それを解消するために#defnieが必衰でした。 こ、これは…… 名前が連番というのは私にはちょっと、と思いますし、この方法でプログラムを 作るとなると、「システム変数レイアウトシート」みたいなドキュメント(方眼紙か Excelシート?)上で、「ここからここまでにはこのデータを入れて…」といった 管理をしなければならなさそうです。ソースから離れたところにドキュメントが 必要になるのは、メンテナンスされないのでは、と心配になります。 ……というのが私の感想ですが、たとえばゲーム業界ではNScripterという言語が 結構広く使われているようなのですが、この言語は変数名が連番です。 http://kamakura.cool.ne.jp/o_show/nscripter/syo/08.htm 私の感覚ではのけぞってしまいますが、ユーザがいる以上、この仕様がよいという 人がいるということなのでしょう(山さんは、#defineでセル名を隠そうとして いますから、連番がよいと思っておられるわけではないと思いますが)。 あと、システム変数がこういう形式だと、入力フォームや出力帳票に直接 結びつけることができると便利かもしれませんね。 なつかしのRPGあたりを彷彿とさせますが。

　さすが（ぱ）さんと言うか、鋭い突っ込みありがとうございます。実はシステム変数に ついては多少触れるのを避けていました。。なぜなら（ぱ）さんの「表計算ソフトって」 のコラムで表についての意見を読んでいて、まさにその表を言語に組み込もうとしている のです。だから、完成する前にキツイ指摘を受けるのではないかと… 　システム変数は、簡単に説明すると。項と列によって構成されるシートが基本で、この シートによって複数の機能と特徴を持っています。 　　Aシート　　　　・・・～・・・ 　　　　Zシート　（26シート） 　　----------- ------------ 　　| | | | 　　| | | | 　　----------- ------------ 　このシート名が変数の最初の「A」にあたり 　　000 ...................................... 999 （1000個の項目） ------------------------------------------------- A | | ・・・ | | : | | --------------------- | | Z | | | int double string | | | a | | --------------------- | | : | | ↑一つのセルの中に | | : | | 3つのデータがある | | z | | ・・・ | | ------------------------------------------------- (52の列） 　変数名は　「シート＋列＋データ型＋項目番号」　＝　AAI000　となります。だから 自由に変数名はつけれない。それを解消するために#defnieが必衰でした。 　ちなみに、システム変数にアクセスする方法は、直値＝AAI001と言う形と、相対配列 ＝ABI010「X][Y]　これは、指定の座標から項にX値の相対座標指定、列にY値の相対座標を 指定してアクセスします。　ABI010[X]　は項目のX相対座標指定です。 　もともとこのシート形式は、目的アプリケーションで必要だった機能を実現する為の 些細なアイデアでした。しかし、言語を作っていく上でシステムの基本となり。言語上 でもかなめ的要素（中心的要素）になったのです。注意、EXCELを作るわけではありません。 　ここからは既存の言語的常識を一時保留にして読んでください。 　例えば、市役所等での情報の伝達はシート、書式を持った紙です。市民登録、婚姻届等に 必要な項目を記入し提出する。それを受け取り保存する。別にガッシリとデータ定義された 構造体やclassがあるわけではありません。記入する方も総ての項目を初期化したり記入し たりしません、必要な項目のみ記入して提出します。 　このイメージをモジュール間の情報伝達に使用しようと考えたのです。例えばシートAに に必要なことを書いて、他のモジュールに動作指示を出す。その時シート名を伝達するだ けでいい、構造体やclassは不要です。なおかつしたい事の種類のよって、多くの構造体や 多くのクラス定義が必要になったりしますが、シートでは必要な部分だけを書けばいい。 　と発想したのが元です。 　情報伝達の単位は、最小のint,double,string、そして一つのセル、相対X領域,相対Y領域、 相対矩形の領域、列、シート、そしてパックされた情報の８つの単位で情報伝達を考えてい ます。この処理単位で情報伝達するために、言語は関数内では普通の言語的整合性を持って いますが、一歩外のグローバルではシステム変数で情報伝達する。その結果グローバル変数 はシステム変数となり、言語的整合性ではなくシステムの目的にそって作られています。 補足 １、一つのセルの中にint,double,stringデータの情報が入っているのは、もともとはデータ の型別にシートが分かれていました。しかし、リストやソート、検索、辞書(map)の場合、 3つのデータをまとめて処理したほうが利便性がいいとの理由です。そのため1セルに3つの 情報を入れました。しかし、変数としては別々にアクセスします。 　例えばstringでソートした場合、intもdoubleもいっしょにソートされます。 　例えば、intに優先NOが入っていたら、intでソートしたら文字列もいっしょにソート されます。 　利便性の目的のためだけに、3つの情報を一セルに入れました。 ２、パックされた情報は、stringデータに入ります。なのでstringデータは複数のデータ を大量に保持することが出来ます。 ３．システム変数を言語内の変数と同じように、透過的にアクセスできるように作れたため、 システム変数の操作を速くする事ができた。これは、関数を用いてシステム変数を操作する ことを思えば、スレッドセーフでも、格段に融通が利き速い動作を保証できる。 最後に 　この言語だけでは、奇妙な言語が一つ出来ただけの事です。この仕組が受け入れられる かは、その上に乗ったアプリケーションが洗練されていて使いやすく受け入れるか如何に かかっています。ここから先はいかにいい物を作るかだけでしょう。それに、言語の 初心者を対象にしているので、ここからはバリバリな日本語化に走ります。 　プログラミング言語ができる人は、C/C++なりJavaなり、その他各種汎用言語を使って ください。がベースにあります。＾＾ 　今ある汎用言語は洗練されていて複雑で優秀です。だから私がいまさら作る意味が無い ですし。 追加の補足 　上記のことを書いた後に、グローバル変数でもいいのではないか。の発想もありますが、 その場合、情報の集合体としての構造体やclassが必要です。でも、移転届用紙のような 多数の関係の薄そうなデータ総てを構造体やclassに入れるのは、根本的にシステム設計 が間違っている方向でしょう。やはり書式用紙に代表されるデータ構造と、プログラム上の データ構造とは明らかに違っています。プログラムでは関連のあるデータを参照やキー 情報、その他関連情報で持ちます。しかし、この構造は前にも話したように他の何かの サポート無しに完全な一意の意味を保証することは不可能です。 　でも、シート形式なら完全かと言うとそうでもありません。実は時系列な情報変化の 保証は出来ないのです。これはあきらめています。時系列的な情報の変化とは、転移届を 受理して完全に処理される前に。同じ人から違う転移届を受け取ってしまった場合の矛盾 です。　これは外部の何らかのサポート、受理処理が完全に終了するまで受け付けない フラグ等のサポートが必要になり。これはシステムではなく、プログラマがそれを理解し 作らなければならないのです。 　完全なデータフローマシンでも作ればいいのですが、そのプログラミングはまた違った、 別の複雑な知識が必要になってきます。

>　システム変数は宣言だけが違い、多少特殊ですが普通の変数と同じように >使用できます。なおかつスレッドセーフで使用できます。 (中略) > sysval("AAS001",CREATION); 割と素朴な疑問だと思うんですが、システム変数の宣言がこのように関数形式だとすると、 システム変数の型について、コンパイラは知らないままだということになりませんか? ……と思ったのですが、「AAS」という名前がstring型だという型宣言を兼ねている (かつそれをコンパイラが解釈する)のでしょうか? > sysval("AAI001-ACI005",CREATION); そして、こういう書き方だと、AA「I」なので、intの配列の宣言になる、と。

　ようやくシステム変数の組込みが終わりました。下記に示すような感じで 使用します。上にある#defineは、システムのヘッダーファイルになり。 #includeされます。　また今回は日本語プログラムにするとこんな感じに なります。と言った感じのプログラムリストです。 　システム変数は宣言だけが違い、多少特殊ですが普通の変数と同じように 使用できます。なおかつスレッドセーフで使用できます。 //-- システム変数定義ヘッダーファイル -------------- #define システム変数 sysval #define 生成 1 // システム変数使用 #define 廃棄 2 // システム変数廃棄 #define クリア 3 // システム変数を初期化 #define リスト 4 // システム変数のリスト宣言 #define 辞書 5 // システム変数の辞書宣言(予約) #define 昇順ソート 6 // システム変数をソート #define 降順ソート 7 // システム変数をソート #define システム変数検索 sysval_find #define 線形 1 // システム変数リストを線形検索 #define 二分 2 // システム変数リストを二分検索 #define 辞書 3 // システム変数辞書検索(予約) #define システム変数リスト挿入 sysval_push_list #define システム変数リスト取出 sysval_pop_list #define 先頭 1 // システム変数リストの先頭 #define 最後 2 // システム変数リストの最後 //-- 日本語定義ヘッダーファイル ------------------ #define メイン main #define 表示 print #define 文字列 string #define 整数 int //------------------------------------------------ //-- 日本語で書いた場合 ----------------- 整数 表示(文字列 str); 整数 システム変数(文字列 str,整数 type); 整数 メイン() { システム変数("AAS001",生成); システム変数("AAI001-ACI005",生成); システム変数("BAD001-BCD005",生成); システム変数("CAS001-CCS005",生成); AAS001　= "testdata"; 表示("AAS001 = " + AAS001 + "--\n\n"); AAI001[3][1] = 33; BAD002[2] = 3.2; CAS003[1] = "aaa"; 表示("AAI001 = " + AAI001[3][1] + "--\n\n"); 表示("BAD002 = " + BAD002[2] + "--\n\n"); 表示("CAS003 = " + CAS003[1] + "--\n\n"); } //----------------------------------- 　　　↓ 　　　↓まったく同じプログラムで英語で書いた場合 　　　↓ //----------------------------------- int print(string str); int sysval(string str,int type); int main() { sysval("AAS001",CREATION); sysval("AAI001-ACI005",CREATION); sysval("BAD001-BCD005",CREATION); sysval("CAS001-CCS005",CREATION); AAS001　= "testdata"; print("AAS001 = " + AAS001 + "--\n\n"); AAI001[3][1] = 33; BAD002[2] = 3.2; CAS003[1] = "aaa"; print("AAI001 = " + AAI001[3][1] + "--\n\n"); print("BAD002 = " + BAD002[2] + "--\n\n"); print("CAS003 = " + CAS003[1] + "--\n\n"); } ----------------------------------- 　　　↓ 　　　↓日本語版も英語版まったく同じ下記のコードになります。 　　　↓ ------------------------------------ 1:*** 一般関数情報ダンプ ****************** 1:int main() 1:*** 配列定数 数 = 0 ********** 1:*** 文字列 数 = 23 *** 1: 0: "main" 1: 1: "AAS001" 1: 2: "sysval" 1: 3: "AAI001-ACI005" 1: 4: "sysval" 1: 5: "BAD001-BCD005" 1: 6: "sysval" 1: 7: "CAS001-CCS005" 1: 8: "sysval" 1: 9: "testdata" 1: 10: "AAS001 = " 1: 11: "-- " 1: 12: "print" 1: 13: "aaa" 1: 14: "AAI001 = " 1: 15: "-- " 1: 16: "print" 1: 17: "BAD002 = " 1: 18: "-- " 1: 19: "print" 1: 20: "CAS003 = " 1: 21: "-- " 1: 22: "print" 1:*** 使用予定のスタックサイズ = 1292 1:*** 関数コードのディスアセンブラ size = 223 1: 0 push_string_const 1 1: 3 push_int_1byte 1 1: 5 call_function 2 0 0 2 1: 14 pop 1: 15 push_string_const 3 1: 18 push_int_1byte 1 1: 20 call_function 4 0 0 2 1: 29 pop 1: 30 push_string_const 5 1: 33 push_int_1byte 1 1: 35 call_function 6 0 0 2 1: 44 pop 1: 45 push_string_const 7 1: 48 push_int_1byte 1 1: 50 call_function 8 0 0 2 1: 59 pop 1: 60 push_string_const 9 1: 63 pop_sysval_str 3-0-1 1: 68 push_string_const 10 1: 71 push_sysval_str 3-0-1 1: 76 add_string 1: 77 push_string_const 11 1: 80 add_string 1: 81 call_function 12 0 0 1 1: 90 pop 1: 91 push_int_1byte 33 1: 93 push_sysval_array 1-0-1 1: 98 push_int_1byte 3 1: 100 push_array_int 1 1: 102 push_int_1byte 1 1: 104 pop_array_int 1: 105 push_double_8byte 3.200000e+000 1: 114 push_sysval_array 2-52-2 1: 119 push_int_1byte 2 1: 121 pop_array_double 1: 122 push_string_const 13 1: 125 push_sysval_array 3-104-3 1: 130 push_int_1byte 1 1: 132 pop_array_string 1: 133 push_string_const 14 1: 136 push_sysval_array 1-0-1 1: 141 push_int_1byte 3 1: 143 push_array_int 1 1: 145 push_int_1byte 1 1: 147 push_array_int 0 1: 149 cast_int_to_string 1: 150 add_string 1: 151 push_string_const 15 1: 154 add_string 1: 155 call_function 16 0 0 1 1: 164 pop 1: 165 push_string_const 17 1: 168 push_sysval_array 2-52-2 1: 173 push_int_1byte 2 1: 175 push_array_double 0 1: 177 cast_double_to_string 1: 178 add_string 1: 179 push_string_const 18 1: 182 add_string 1: 183 call_function 19 0 0 1 1: 192 pop 1: 193 push_string_const 20 1: 196 push_sysval_array 3-104-3 1: 201 push_int_1byte 1 1: 203 push_array_string 0 1: 205 add_string 1: 206 push_string_const 21 1: 209 add_string 1: 210 call_function 22 0 0 1 1: 219 pop 1: 220 push_int_1byte 0 1: 222 return 1:*** 行情報 数 = 14 *** 1: 20: from 0 size 15 1: 21: from 15 size 15 1: 22: from 30 size 15 1: 23: from 45 size 15 1: 24: from 60 size 8 1: 25: from 68 size 23 1: 26: from 91 size 14 1: 27: from 105 size 17 1: 28: from 122 size 11 1: 29: from 133 size 32 1: 30: from 165 size 28 1: 31: from 193 size 27 1: 154: from 220 size 2 1: 32: from 222 size 1 1:*** end of main() -------------- --------------------------------------------------

お返事遅れてすみません。 >ええと、細かいことですが「再起」ではなく「再帰」ですね。 うはは～～指摘ありがとうございます。思わぬミスをよくします。 >ファイバーとか考えるなら再考の必要がありますね…… 　ファイバーのことを考えてたら、 「ファイバーは関数ではなく、コードの一部を空きスレッドに渡すだけで実行だな」 と考えていたら下記の点を気がつきました。 　今までは、スレッドは実行時にオブジェクト生成とスレッド起動を考えていま したが、良くよく考えれば毎回不必要ですね。初期に10なり20なり起動して待ち 状態で待たせ、その後プログラムのスレッド実行は空きスレッドで即実行を^^ 　この方法で組み込むことにしました。

ええと、細かいことですが「再起」ではなく「再帰」ですね。 >その後言語内の関数実行部を >作ったのですが。そのまま、再起で実行する部分を使って組み込んだために、関数実行 >はVM実行部の再起になっています。 了解です。 再帰を使わずに作ると、例外処理機構でCの呼び出し階層を遡らなくてよいとか、 ファイバーのような機能を作るときに現在の実行状態を退避できるとかの メリットがあると思いますが、例外処理をDiksamで作ってみたら、再帰を使っている crowbarの例外処理よりもかえって大変だったような気がしますし、再帰なら 再帰でかまわないと思います。 実はDiksamでもネイティブ関数からDiksam関数を呼ぶところは再帰なので、 ファイバーとか考えるなら再考の必要がありますね…… >う～～んどうしようか、当面このままでいこうと思います。既に出来てしまっ >てるし。スタックを増やさない限り再起が450回しか出来ない欠点はあるけど。 実用的には使われてないであろうcrowbarはさておき、RubyやPerlもCのスタックを 使ってガンガン再帰してますからねえ。

>すみません、いまいちよくわからないです。関数呼び出しのたびにVM起動して >いるわけではないですよね? そうだった、VMが違うものでした。簡単にVMの構造を説明します。 ↓AP管理からVMとして起動される -------------------------------------- | 　　　　　VM管理システム　　　　　 | -------------------------------------- 　↓　 　　　・・・　　　　 　　↓ 　　 ------　　　 ------ 　　 | 　 | 　　 | 　 | 　　 | V | 　　 | V | 　　 | M | 　　　・・・　　　　 | M | 　　 | 実 | 　　 | 実 | 　　 | 行 | 　　 | 行 | 　　 | 部 | 　　 | 部 | 　　 | 　 | 　　 | 　 | 　　 ------　　　 ------ 　VMは上記のような構造をしています。VM管理システムは１つのスレッドで、VM実行 部のスレッド実行管理と各種サービスを提供します。機能は、 　・マルチスレッドでVM実行部の起動・停止・廃棄等の実行管理 　・動的コンパイルの管理、関数の管理 　・タイムスケジュールの管理（タイマーキューの生成と管理） 　・スレッドの実行優先順位管理（キューに優先順位がありその管理） 　・メッセージキューの管理（スレッドの実行はキューによって行われる） 　・グローバル変数の管理 　・その他各種IOや外部機能インターフェースの管理 　・言語のデバック機能 　・上記サービスをスレッドセーフで提供するための排他制御管理 等のいろいろな機能があり、それなりに大きなプログラムです。 　それに対し、VM実行部は純粋にバイトコードを実行する以外何の機能も持っていま せん。VM実行部は1つのクラスで、そのオブジェクト一つが1スレッドになり、マルチ スレッドが実行可能であり、VM実行部が再起実行しても問題の無い仕様です。 そして、出来る限り単純で最小になるように作られています。 　で^＾;、最初に組込み関数部分を作りましたが、その時組込み関数から言語内の関数 を自由に起動したり廃棄したり、スレッド起動したり出来るように作ったので、それを 実行する一番いい方法はVM実行部の再起的実行でした。その後言語内の関数実行部を 作ったのですが。そのまま、再起で実行する部分を使って組み込んだために、関数実行 はVM実行部の再起になっています。今思えば別に再起しなくても良かったかな。^^; 　今の実装の欠点は、VMのスタックを消費することと、ほんの少しのオーバーヘッド。 今の方法の利点は関数実行や管理が一元管理されて、プログラム的にすっきりしている。 かな、う～～んどうしようか、当面このままでいこうと思います。既に出来てしまっ てるし。スタックを増やさない限り再起が450回しか出来ない欠点はあるけど。 >なお、現在はDiksamはシングルスレッドですが、スレッドを分けるなら、 >VMのスタックも分離する必要があると考えています。 こちらも、1スレッドおきにスタック領域が作られます。そのためスタック領域はあまり 大きくしたくなっかったので。 ちなみにVM実行部の起動は S_Func_Val * CL_VMexe::execute(CL_Function *sfp,int stackp); 引数は関数情報と戻りスタックポインターです。ローカル変数をスタックに作成後すぐに S_Func_Val * CL_VMexe::execute_code(); のコード実行部が呼ばれる単純な構造です。

>　関数の再起についてですが、VC++ の標準スタックでデバックビルドの時、 >約460回の再起が可能です。その結果上限として450回を超えたらエラーとし、 >エラー表示とともに関数コールをせずにリターンする処理としました。 >リリースビルドでは多分この数倍いけると思いますが、450回も出来ればOK >だと考えています。スレッド分複数VM起動もしますから。 >diksamではどの様にしていますか? ええと、解析木を再帰でほじって実行するcrowbarならいざしらず、Diksamでは、 Diksamの関数をいくら再帰呼び出ししても、Cのスタックは消費しません。 DVMのスタック(ヒープに確保される)が伸びていくだけです。 なお、現在はDiksamはシングルスレッドですが、スレッドを分けるなら、 DVMのスタックも分離する必要があると考えています。 すみません、いまいちよくわからないです。関数呼び出しのたびにVM起動して いるわけではないですよね?

　関数の再起についてですが、VC++ の標準スタックでデバックビルドの時、 約460回の再起が可能です。その結果上限として450回を超えたらエラーとし、 エラー表示とともに関数コールをせずにリターンする処理としました。 リリースビルドでは多分この数倍いけると思いますが、450回も出来ればOK だと考えています。スレッド分複数VM起動もしますから。 diksamではどの様にしていますか?

>本のページの準備やらに追われていまして遅くなりましてすみません。 いえいえ >つまり、Cと同じですね。現実的な落としどころかと思います。 はい、まさにその通りです。スタックに固定で配列を既述する以上。 定数指定も固定にした方が統一的であるし、中身を替えたければ 個別に入れ替えればいいので、この方法にしました。 配列アクセスも直接インデックスなので多少速いですし。 diksamのテストプログラムは、配列の修正とnull削除で総て正しく 動いています。nullは参照の操作が無いのでなくなりました。 今は、システムグローバル変数の組み込みを行っています。

>木曜日に三省堂神保町店で購入しました。ジュンク堂池袋店では、水曜日に入荷してたみたいです。 >http://twitter.com/junkudo_ike_pc/status/2203461804 お買い上げいただきありがとうございます (_o_) 編集さんからは19日ごろからと聞いていたので、サンプルコードをダウンロードできる ページについて、トップからリンクしたのが木曜の晩(というか金曜明け方)、 リンクはしないが暫定公開として配置したのが水曜の晩(というか木曜明け方)でした。 微妙に間に合いませんでした。こころあたりの方は再度見に来ていただきたく、 よろしくお願いいたします……(ここに書いても仕方がないかもしれませんけど) >書店で見つけて、お！と思ったのが書籍のサイズでした。コンパイラ系の本は大学の教科書（まえがきにある∩とかの）風でサイズはA5版が多いように思います（ドラゴンブックも）。 版型の決定については私は関わっていませんが、ゲラを見たとき、思ったより 文字サイズや余白が大きいな、とは思いました。かなり書きすぎた自覚があったので(^^; もっと詰め込まれるのではないかと。少なくとも版型に関しては読みやすい形で まとめていただけたと思っています。

本のページの準備やらに追われていまして遅くなりましてすみません。 >　下記のように、配列の定数は配列定数バッファーに詰め込んで保持し、1命令で >配列変数に書き込みです。 つまり、Cと同じですね。現実的な落としどころかと思います。 リテラルに定数式しか書けなくなっているかとは思いますが。 つまりC同様、 double[] sin_table = {sin(0), sin(0.2*M_PI), sin(0.4*M_PI), ...}; のような書き方はできませんよね。実際使用することがそうそうあるとは 思えないので、問題ないと思いますが。 そういえば、昔のCは、ローカル変数の配列に初期化子を書くときはstaticしか許さない、 ということになっていました。でも、これで困ることも別段なかった気がしますし。

木曜日に三省堂神保町店で購入しました。ジュンク堂池袋店では、水曜日に入荷してたみたいです。 http://twitter.com/junkudo_ike_pc/status/2203461804 書店で見つけて、お！と思ったのが書籍のサイズでした。コンパイラ系の本は大学の教科書（まえがきにある∩とかの）風でサイズはA5版が多いように思います（ドラゴンブックも）。 Webの連載を見ていなかったので、GC、VM、クラス、クロージャなどと類書にはなかなか見られない内容までを含むとは思ってもみませんでした。読みこなすのは大変ですが、なんとか読んでいこうと思います。 はてなをみて、ページ下部のおまけに気がつきました＾＾。

　これで、diksam0.2.0の機能で必要な部分は総て組み込むことが出来ました。 これからが本当の目的部分です。グローバルシステム変数関係、マルチスレッド システム関係。等々を組み込んだら言語としては完了となります。 　そして、本当の目的アプリケーション…、まて、言語のデバックシステムの 組み込みが。簡単なIDEを組み込みます。まだまだです。

　配列の組み込みにより、バイトコードもまた変わりました、下記に。 S_OpcodeInfo D_opcode_info[] = { {"dummy", "", 0}, {"push_int_1byte", "b",16}, {"push_int_2byte", "s",16}, {"push_int_4byte", "i",16}, // 実際の値を持つ {"push_double_0", "", 16}, {"push_double_1", "", 16}, {"push_double_8byte", "d",16}, // 実際の値を持つ {"push_string_const", "s",40}, // 文字列の位置NOを持つ０～ {"push_null", "", 16}, /**********/ {"push_stack_array", "s", 16}, // 配列情報をスタックに {"push_stack_int", "s", 16}, // intローカル変数をi {"push_stack_double", "s", 16}, // {"push_stack_string", "s", 40}, // {"pop_stack_int", "s", -16}, // スタックのintをローカル変数に {"pop_stack_double", "s", -16}, // {"pop_stack_string", "s", -40}, // /**********/ {"push_static_array", "s", 16}, // 配列情報をスタックに 予約 {"push_static_int", "s", 16}, // int静的変数をスタックに 予約 {"push_static_double","s", 16}, // {"push_static_string","s", 40}, // {"pop_static_int", "s", -16}, // スタックのintを静的変数に 予約 {"pop_static_double", "s", -16}, // {"pop_static_string", "s", -40}, // /**********/ {"push_sysval_array", "i", 16}, // 配列情報をスタックに {"push_sysval_int", "i", 16}, // システムグローバル変数をスタックに {"push_sysval_double","i", 16}, // {"push_sysval_str", "i", 40}, // {"pop_sysval_int", "i", -16}, // スタックからシステムグローバル変数に {"pop_sysval_double", "i", -16}, // {"pop_sysval_str", "i", -40}, // /**********/ {"push_array_int", "", -1}, // int配列処理 {"push_array_double", "", -1}, // {"push_array_string", "", -1}, // {"pop_array_int", "", -1}, // スタックからint配列に {"pop_array_double", "", -1}, // {"pop_array_string", "", -1}, // /**********/ {"add_int", "", -16}, // 以下は総て算術演算子 {"add_double", "", -16}, {"add_string", "", -40}, {"sub_int", "", -16}, {"sub_double", "", -16}, {"mul_int", "", -16}, {"mul_double", "", -16}, {"div_int", "", -16}, {"div_double", "", -16}, {"mod_int", "", -16}, {"mod_double", "", -16}, {"minus_int", "", 0}, {"minus_double", "", 0}, {"increment", "", 0}, {"decrement", "", 0}, // ここまで算術演算子 {"cast_int_to_double", "", 0}, // 以下はキャスト処理 {"cast_double_to_int", "", -0}, {"cast_boolean_to_string", "", 24}, {"cast_int_to_string", "", 24}, {"cast_double_to_string", "", 24}, // ここまでキャスト処理 {"eq_int", "", -16}, // 以下は総て論理演算子 {"eq_double", "", -16}, {"eq_string", "", -40}, {"gt_int", "", -16}, {"gt_double", "", -16}, {"gt_string", "", -40}, {"ge_int", "", -16}, {"ge_double", "", -16}, {"ge_string", "", -40}, {"lt_int", "", -16}, {"lt_double", "", -16}, {"lt_string", "", -40}, {"le_int", "", -16}, {"le_double", "", -16}, {"le_string", "", -40}, {"ne_int", "", -16}, {"ne_double", "", -16}, {"ne_string", "", -40}, // ここまで論理演算子 {"logical_and", "", -16}, // {"logical_or", "", -16}, // {"logical_not", "", 0}, // {"pop", "", -1}, // スタックを1つ減らす {"duplicate", "", 16}, // スタック内容をコピーしてスタックに {"jump", "s", 0}, // 指定ポインターにjump {"jump_if_true", "s", -16}, // スタックがtrueならjump {"jump_if_false","s", -16}, // スタックがfalseならjump /**********/ {"push_function", "", 0}, // 関数情報をスタック、未使用 {"call_function","ssss", 1}, // 関数コール {"return", "", -1}, // 関数戻り /**********/ {"set_array_literal_int", "ss", 0}, // int定数配列を変数にコピー {"set_array_literal_double","ss", 0}, // double定数配列を変数にコピー {"set_array_literal_string","ss", 0}, // string定数配列を変数にコピー };

　配列の実装は、結果的にまったく違うものになっています。配列領域を固定で スタックに持つことでGCを無くす。この目的のために結果的に多くの修正をしま した。下記のようなプログラムとディスアセンブルコードを見てください。 　この並列はずいぶん悩みましたが、結果的に一番良いであろう方法に落ち着き ました。 ---------------------------------- int main() { int[2][3] i5dim; int id = 33; boolean[2] bdim1 = { true , false }; int[2][3] idim21 = {{1,2,3},{4,300,65536}}; int[2][3][4] idim3 = {{{1,2,3,4},{5,6,7,300},{8,9,10,11}}, {{11,12,13,65536},{14,15,16,17},{18,19,20,21}}}; double[4] ddim1 = { 0.0, 1.0, 4.1, 5.1 }; string[5] sdim1 = {"aa","bb","cc","dd","ee"}; int a1; i5dim[1][2] = 1; a1 = i5dim[i5dim[1][2]][0]; } ---------------------------------- 　　↓ 　下記のように、配列の定数は配列定数バッファーに詰め込んで保持し、1命令で 配列変数に書き込みです。もちろん配列数と一致したデータ以外はエラーです。 また、変数の配列次元数が一致しない場合もエラーになる処理が入っています。 int[10]　P;　P = P;　の様なポインター的なコードが書けない仕様です。 　　↓ バイトコード 　　↓ 1:*** 一般関数情報ダンプ ****************** 1:int main() 1:*** ローカル変数の表示 no = 8 *** 1: 0:int [2][3] i5dim 1: 1:int id 1: 2:boolean [2] bdim1 1: 3:int [2][3] idim21 1: 4:int [2][3][4] idim3 1: 5:double [4] ddim1 1: 6:string [5] sdim1 1: 7:int a1 1:*** 配列定数 数 = 5 ********** 1: 0:int 配列 [2] size=20 1:int[0] = 1 1:int[1] = 0 1: 1:int 配列 [2][3] size=36 1:int[0][0] = 1 1:int[0][1] = 2 1:int[0][2] = 3 1:int[1][0] = 4 1:int[1][1] = 300 1:int[1][2] = 65536 1: 2:int 配列 [2][3][4] size=108 1:int[0][0][0] = 1 1:int[0][0][1] = 2 1:int[0][0][2] = 3 1:int[0][0][3] = 4 1:int[0][1][0] = 5 1:int[0][1][1] = 6 1:int[0][1][2] = 7 1:int[0][1][3] = 300 1:int[0][2][0] = 8 1:int[0][2][1] = 9 1:int[0][2][2] = 10 1:int[0][2][3] = 11 1:int[1][0][0] = 11 1:int[1][0][1] = 12 1:int[1][0][2] = 13 1:int[1][0][3] = 65536 1:int[1][1][0] = 14 1:int[1][1][1] = 15 1:int[1][1][2] = 16 1:int[1][1][3] = 17 1:int[1][2][0] = 18 1:int[1][2][1] = 19 1:int[1][2][2] = 20 1:int[1][2][3] = 21 1: 3:double 配列 [4] size=44 1:double[0] = 0.000000 1:double[1] = 1.000000 1:double[2] = 4.100000 1:double[3] = 5.100000 1: 4:string_no 配列 [5] size=32 1:string[0] = 9 1:string[1] = 10 1:string[2] = 11 1:string[3] = 12 1:string[4] = 13 1:*** 文字列 数 = 14 *** 1: 0: "main" 1: 1: "i5dim" 1: 2: "id" 1: 3: "bdim1" 1: 4: "idim21" 1: 5: "idim3" 1: 6: "ddim1" 1: 7: "sdim1" 1: 8: "a1" 1: 9: "aa" 1: 10: "bb" 1: 11: "cc" 1: 12: "dd" 1: 13: "ee" 1:*** 使用予定のスタックサイズ = 426 1:*** 関数コードのディスアセンブラ size = 63 1: 0 push_int_1byte 33 1: 2 pop_stack_int 1 1: 5 set_array_literal_int 0 2 1: 10 set_array_literal_int 1 3 1: 15 set_array_literal_int 2 4 1: 20 set_array_literal_double 3 5 1: 25 set_array_literal_string 4 6 1: 30 push_int_1byte 1 1: 32 push_stack_array 0 1: 35 push_int_1byte 1 1: 37 push_array_int 1: 38 push_int_1byte 2 1: 40 pop_array_int 1: 41 push_stack_array 0 1: 44 push_stack_array 0 1: 47 push_int_1byte 1 1: 49 push_array_int 1: 50 push_int_1byte 2 1: 52 push_array_int 1: 53 push_array_int 1: 54 push_int_1byte 0 1: 56 push_array_int 1: 57 pop_stack_int 7 1: 60 push_int_1byte 0 1: 62 return 1:*** 行情報 数 = 10 *** 1: 4: from 0 size 5 1: 5: from 5 size 5 1: 6: from 10 size 5 1: 8: from 15 size 5 1: 9: from 20 size 5 1: 10: from 25 size 5 1: 13: from 30 size 11 1: 14: from 41 size 19 1: 19: from 60 size 2 1: 15: from 62 size 1 1:*** end of main() --------------

>ここで埋め込まれる関数インデックスって、VM内で一意になるんですよね? >だとすれば、コンパイル単位の破棄の際に破棄対象の関数が使っていたインデックスの >ところをぎゅっと圧縮しようとさえ思わなければ、そもそも振りなおし自体不要なのでは >ないかと思うのですが…… 同じ所に、こう書いてあります。 >>　次にスピードの点ですが、現在はVMメイン管理で一元的にカウンターを持ってい >>ますが、これを関数単位でもてば、（ぱ）さんの指摘する問題は回避できます。 >>　ただ、初期は出来る限り単純なもので済ませたいとの思いがあり。簡単な機構で >>すめばそのままにしています。 上記のように、今のところ優先順位が低いので、後回しにしています。 もちろん、圧縮等はしていないので、比較的簡単に実装出来ると思います。 たぶん二人とも同じことを考えてると思います。

>　コンパイル時の負荷はまず棚においておいて、実際問題、再コンパイルが頻繁に >行わなければならない処理が多いと思われますか?、実際的に考えればそんな設計は >良い設計とは思えません。 うーん、再コンパイルの頻度は低くても、それが起きるたびに以後の関数呼び出しに ついてすべて一度ずつリンクが入るのはちょっと心配ですがそれはさておき、 ここで埋め込まれる関数インデックスって、VM内で一意になるんですよね? だとすれば、コンパイル単位の破棄の際に破棄対象の関数が使っていたインデックスの ところをぎゅっと圧縮しようとさえ思わなければ、そもそも振りなおし自体不要なのでは ないかと思うのですが……

>この方法だと、コンパイル単位が増えてきたとき、プログラムの端のほうでちょろっと >動的リンクが発生しただけで、それこそprint()みたいにあちこちで使われる関数の >呼び出し箇所すべて(通るところだけですが)に対し再リンクが必要になるような…… 　必ず突っ込まれるで有ろうと予測した部分が突っ込まれました^^。確かに再コンパ イルが頻繁に行われるようであれば、当然負荷が増えるでしょう。でもその場合、 コンパイル時に再リンクも大きな負荷に思えます。 　コンパイル時の負荷はまず棚においておいて、実際問題、再コンパイルが頻繁に 行わなければならない処理が多いと思われますか?、実際的に考えればそんな設計は 良い設計とは思えません。 　ではなぜ、動的コンパイルが必要だったか。それは、複数の違った処理を一元的 にメニュー管理する目的があったのです。利用目的ですね。このような利用目的が 無い場合、動的コンパイラは不要です。だからdiksamとは指向性が多少違います。 　次にスピードの点ですが、現在はVMメイン管理で一元的にカウンターを持ってい ますが、これを関数単位でもてば、（ぱ）さんの指摘する問題は回避できます。 　ただ、初期は出来る限り単純なもので済ませたいとの思いがあり。簡単な機構で すめばそのままにしています。 　うう～～上記文は多々説明不足な気がすごくしますが、説明を始めると長くなっ てしまいそうなので短文にしています。「もっと説明しろ！」との指摘がありまし たら、ぜひ言ってくださいませ。

>はい、一つ目は文字列バッファーにある関数名インデックスを示し、二つ目はコン >パイル単位カウンター、三つ目は関数ID＝インデックス、四つ目はパラメターの数 >です。P2，P3は実行時に埋め込まれます。コンパイルカウンターは、１～最大値ま >でのループカウンターで動的コンパイル実行時かコンパイル単位の消滅処理時に >＋１されます。コード上は最初は0そしてカウンターは1なので、値が違うためP1の >関数名から動的リンクをしてP2に１、P3に関数インデックスが埋めこめられ、この >関数インデックスで直接関数が起動されます。以後、P2のコンパイルカウンターが >一緒なら、P3で直接関数起動です。直接起動の前にIF文が一回入る程度です。 うーん、いまいちわかりませんが、 ・call_functionのふたつめのオペランドを「P2」として、 ・「コンパイルカウンター」は、「動的コンパイル実行時かコンパイル単位の 　消滅処理時に＋１」というくらいだから、VMにひとつだけ存在するカウンタですよね? つまり、動的コンパイルが動いたり、逆にバイトコードを破棄したりするたびに VMの状態が変わるわけですが、この「状態」に対して、1から始まる連番が振られて いるわけですね。 で、call_functionごとに、それがリンクされた時点の連番(コンパイルカウンター)が 埋め込んであり、呼び出しごとに現在のコンパイルカウンターと比較して違っていたら 再リンクする、と。 この方法だと、コンパイル単位が増えてきたとき、プログラムの端のほうでちょろっと 動的リンクが発生しただけで、それこそprint()みたいにあちこちで使われる関数の 呼び出し箇所すべて(通るところだけですが)に対し再リンクが必要になるような…… ちなみにDiksamでは、バイトコード中の関数インデックスはコンパイル時に 決めています。これは「バイトコードごと」の関数インデックスであり、 ver.0.2～0.3系列では、リンク時に、これを「DVMごと」のインデックスに置き換えます。 ver.0.4では、置換は行わず、変換テーブルをバイトコードごとに持っています。 今のところ動的なバイトコードのアンリンクは実装していません。実装する場合、 DVM上のFunctionテーブルのis_implementedをfalseにすることになるかと思います。

　追記、変数名とか関数名も文字列バッファーに入れています。これは言語のIDE サポートのためです。今デバックのために使っているモニターシステムがあるの ですが、これを高機能にすればIDEになるので、言語デバック用に簡単なIDEをと 思い追加しています。このデバックモニターシステムはC#で作られています。

>2つ目と3つ目のオペランドは全部0, 0なのですが、関数の方はprintf, sprintf, printの はい、一つ目は文字列バッファーにある関数名インデックスを示し、二つ目はコン パイル単位カウンター、三つ目は関数ID＝インデックス、四つ目はパラメターの数 です。P2，P3は実行時に埋め込まれます。コンパイルカウンターは、１～最大値ま でのループカウンターで動的コンパイル実行時かコンパイル単位の消滅処理時に ＋１されます。コード上は最初は0そしてカウンターは1なので、値が違うためP1の 関数名から動的リンクをしてP2に１、P3に関数インデックスが埋めこめられ、この 関数インデックスで直接関数が起動されます。以後、P2のコンパイルカウンターが 一緒なら、P3で直接関数起動です。直接起動の前にIF文が一回入る程度です。 　このような感じで、スレッドセーフな動的リンクを実現しています。実はこれには 面白い副作用があって、例えば画面に文字を出す関数を動的コンパイル単位にすれば。 メインは一切い変更せず。あるときはゴシックで表示、コンパイル単位の消滅そして、 最コンパイルすると、その時から丸文字表示で文字が出される等が可能です。 　関数の内部機能を動的に変えることが出来ます。もちろん総てのスレッドにスレッ ドセーフで。でも、使い道はそんなに無いかもしれませんけどね。^^; そうそう、今の所同じ関数名でも違う文字列IDですが、暇が出来たら同一IDにする 予定。 VMを作り始めてから何度もも構文処理からの修正が必要になり。なかなか前に進み ません。書きあがって動いても、スレッドセーフの問題点が見つかり、書き直しも ごそごそと。言語としては最終的なつめなので、すぐには終わりそうにないです。 　でも、思った通りに作れるのはいい感じです。

自己フォロー。 >おそらく4つ目のオペランドが引数の数、2つ目か3つ目が関数のインデックス >なのだと思いますが(確か分割コンパイルはなかったと思うので、ひとつ余りますね…) >最初のオペランドは何でしょう? 2つ目と3つ目のオペランドは全部0, 0なのですが、関数の方はprintf, sprintf, printの 3種類ありますので、これが直接関数のインデックスということはないですね。 単なる場所取りで、実行前に第1オペランドの文字列を使ってインデックスを検索して ここに埋め込むとか……

おお、私はDiksamのほうにさっぱり手を付けられないでいる間に、 だいぶ進んでいますね。 ぱっと見で目を引くのは関数呼び出しのインストラクションのオペランドの 数の多さですが、 >1: 9 call_function 3 0 0 4 おそらく4つ目のオペランドが引数の数、2つ目か3つ目が関数のインデックス なのだと思いますが(確か分割コンパイルはなかったと思うので、ひとつ余りますね…) 最初のオペランドは何でしょう? 関数名を文字列のコンスタントプールで保持していて、そのインデックスに 見えますが、用途がよくわかりません。リンク用の情報で、実行時には使わない? >1:*** 文字列 数 = 9 *** >1: 0: "main" >1: 1: "str" >1: 2: "printf P1 = %d P2 = %d P3 = %d >" >1: 3: "printf" >1: 4: "sprintf P1 = %d >" >1: 5: "sprintf" >1: 6: "print" >1: 7: "---------- test ---------

　追記で、バイトコードも結構変わっています。下記に。 >---------------------------------- >int printf(string str); >string sprintf(string str); >int print(string str); > >int main() >{ > string str; > printf("printf P1 = %d P2 = %d P3 = %d\n",12,20,30); > str = sprintf("sprintf P1 = %d\n",13); > print(str); > print("---------- test ---------\n"); >} >---------------------------------- ↓ 　バイトコード ↓ 1:*** 一般関数情報ダンプ ****************** 1:--- int main() 1:*** ローカル変数の表示 no = 1 *** 1: 0:string str 1:*** 文字列 数 = 9 *** 1: 0: "main" 1: 1: "str" 1: 2: "printf P1 = %d P2 = %d P3 = %d " 1: 3: "printf" 1: 4: "sprintf P1 = %d " 1: 5: "sprintf" 1: 6: "print" 1: 7: "---------- test --------- " 1: 8: "print" 1:*** 使用予定のスタックサイズ = 240 1:*** 関数コードのディスアセンブラ size = 65 1: 0 push_string_const 2 1: 3 push_int_1byte 12 1: 5 push_int_1byte 20 1: 7 push_int_1byte 30 1: 9 call_function 3 0 0 4 1: 18 pop 1: 19 push_string_const 4 1: 22 push_int_1byte 13 1: 24 call_function 5 0 0 2 1: 33 pop_stack_string 0 1: 36 push_stack_string 0 1: 39 call_function 6 0 0 1 1: 48 pop 1: 49 push_string_const 7 1: 52 call_function 8 0 0 1 1: 61 pop 1: 62 push_int_1byte 0 1: 64 return 1:*** 行情報 数 = 6 *** 1: 8: from 0 size 19 1: 9: from 19 size 17 1: 10: from 36 size 13 1: 11: from 49 size 13 1: 13: from 62 size 2 1: 12: from 64 size 1 1:*** end of main() --------------

　ようやく下記のようなプログラムがVMで実行可能になりました。可変長 パラメータ用の書式は作らず、一部の組込み関数のみ可能にしました。 言語としての美しさは…、スタック情報も大きく変わり、VMはほとんど別の ものになりつつあります。VMの完成にはまだまだです。printfはCのprintf と同等ですが、中身はエミュレートを被せてオーバラン等の危険は一切 ありません。 ---------------------------------- int printf(string str); string sprintf(string str); int print(string str); int main() { string str; printf("printf P1 = %d P2 = %d P3 = %d\n",12,20,30); str = sprintf("sprintf P1 = %d\n",13); print(str); print("---------- test ---------\n"); } ---------------------------------- 　前に出した、組込み関数とのインターフェースは大幅に変更となり。 下記のようになっています。 //== スタック上の組込み関数データ =================================== struct NFstartDat { ushort vtype; // データタイプ E_StackDType ushort size; // スタック消費サイズ ushort m_vmid; // VMID = スレッドID ushort m_prm_inno; // 引き渡されたパラメータ数 void *m_sdatp; // スレッド別データ用ポインター S_Value *m_prmp[PRMMAX]; // 引き渡されたパラメータ S_Value m_return; // 関数からの戻り値データ }; //=================================================================== // 組み込み関数用定義 //=================================================================== class C_NFBase { protected: //-- VMから受け取る情報 ---------------- int m_fid; // 関数ID //-- VMに送る情報 ---------------------- char *m_name; // 関数名 int m_prmno; // 要求するパラメータ数0-10まで20は可変関数 ES_ValueType m_type[PRMMAX]; // 要求するパラメータの型 ES_ValueType m_return_type; // リターン変数タイプ public: C_NFBase() { this->m_name = NULL; this->m_prmno = 0; for(int i=0;i<PRMMAX;i++) { this->m_type[i] = ES_NON; } //----------------------- this->m_fid = 0; this->m_return_type = ES_INT; } virtual ~C_NFBase() { } virtual void * VMstart() { } // VM起動時実行 virtual void VMend() { } // VM終了時実行 virtual void funcexe(NFstartDat *nfd) { } // 関数起動メソッド inline char ** getname() { return &this->m_name; } inline int getprmno() { return this->m_prmno; } inline ES_ValueType getprmtype(int no) { return this->m_type[no]; } inline void setfid(int fid) { this->m_fid = fid; } inline ES_ValueType getrtntype() { return this->m_return_type; } };

>今度印刷してじっくり読んでみます。 ぜひ是非。Diksam でも活用可能かもしれません。 ＃ご出版、おめでとうございます。

>アマゾン詣でをしていたら、、 >こんなんありました！！ > >http://www.amazon.co.jp/dp/4774138959 >2009/6/20 あっ、まだ私のところに見本誌も届いていないのに! 価格とかページ数とか、今はじめて知りました。いやマジで。 >いやー楽しみです。 ありがとうございます(表紙がどんな感じになるのかとか、私も楽しみにしています)。 いやそのなんと言いますか、マイナーな分野だけに、ぜひともよろしくお願いいたします(_o_)

>ちゃんと知るには発案者のシェルリ自身が >書いたものに一度目を通しておくのが無難かと思います。 紹介ありがとうございます。片方はsumimさんのページから辿ってちょっと読みかけたのですが、 けっこう量が挫折してました。今度印刷してじっくり読んでみます。

そうですね。C++ のテンプレートテクニックにも同名のがありますね。ややこしやー。ｗ そんなかんじで Traits にはいろいろと別物がある上、ブラックたち（というかシェルリ） の Traits にインスパイヤされたと言明されたものでも、たとえば Scala の Traits の ように一部機能を限定した実装もあるので、ちゃんと知るには発案者のシェルリ自身が 書いたものに一度目を通しておくのが無難かと思います。 Flattening Traits http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.64.5836&rep=rep1&type=pdf Traits: Composable Units of Behavior http://web.cecs.pdx.edu/~black/publications/TR_CSE_02-012.pdf

アマゾン詣でをしていたら、、 こんなんありました！！ http://www.amazon.co.jp/dp/4774138959 2009/6/20 いやー楽しみです。

>すみません、ちょっと一筋縄ではいかないようです。 やっぱりそうでしたか、yaccエラーを無くすまでは出来たのですが。内部的な 問題が発生してしまって、当面は無視して先に進むことにします。^^;

>下記のようなプログラムで、ただのブロックを書いた場合、diksamで構文エラー >になります。4.01でも。これをエラーにしないように、diksam.yを修正したいの >ですが、お暇がありましたら何かアドバイスをお願いいたします。 そういえば、Diksamはぶら下がりifの類を許していないので、複合文も 作っていませんでした。 Cと同じように文の一種としてcompound_statementを導入すればよいのでは、 とちょっと試してみたのですが、yaccでconflictが出ました。 考えてみればDiksamでは配列リテラルがあるので、「{」の後に式が来たとき ブロックなのか配列リテラルの始まりなのかがわからないわけです。 こういう場合、構文規則を変形してreduceのタイミングを遅らせる手法が 使えることがありますが、現状のDiksamのブロックは、「{」の直後で 埋め込みアクションが動くようになっており、そのためにはreduceが必要です。 すみません、ちょっと一筋縄ではいかないようです。

返信が遅くなりましてすみません。 >それは SELF の trait ですね。ここでいう Traits は、メソッドのセットを用いた多重 >継承機構で、従来のクラスやそれに準ずるものを用いた多重継承から一歩踏み込んだもの >です。Squeak Smalltalk で実効性が示されて、その後、各種言語で応用されています。 >新しい言語では言語組み込みのものもあったりと、ちょっとした流行りの機能かと。 > >http://www.slideshare.net/hiratara/traitmooserole/7 URLを紹介いただきありがとうございます。 Java上がりの私には、Scalaをベースとしたこちらの説明がわかりやすかったです。 http://www.ibm.com/developerworks/jp/java/library/j-scala04298.html 検索してみるとC++のテンプレートのテクニックとしてEffective C++第3版で 紹介されているものがあるようですが、これはまた別物……ですよね。 # うちにあるEffective C++は第2版まででした。 このところ日々の仕事に追われるばかりで、各種情報が追いかけられていないです。 いかんなぁ。

下記のようなプログラムで、ただのブロックを書いた場合、diksamで構文エラー になります。4.01でも。これをエラーにしないように、diksam.yを修正したいの ですが、お暇がありましたら何かアドバイスをお願いいたします。 -------------------------- int func01() { { int a1; } } --------------------------

>traitsは、「プロトタイプベース言語でクラスを実現するもの」ぐらいの認識でしたが、 >これも元祖はSmalltalk? ……と思ったら別物? それは SELF の trait ですね。ここでいう Traits は、メソッドのセットを用いた多重 継承機構で、従来のクラスやそれに準ずるものを用いた多重継承から一歩踏み込んだもの です。Squeak Smalltalk で実効性が示されて、その後、各種言語で応用されています。 新しい言語では言語組み込みのものもあったりと、ちょっとした流行りの機能かと。 http://www.slideshare.net/hiratara/traitmooserole/7

>他方で古くはデザパタ、ユニットテストやアジャイル的な手法、比較的新しいところでも >Classbox や Traits などのような静的型でも応用の利く役立つ物を次々と編み出して >くるのも、また Smalltalk 愛好者たちなので、 今日検索して知ったのですが、ケント・ベックってSmalltalkの開発者だったんですね。 知りませんでした。 http://biography.sophia-it.com/content/%E3%82%B1%E3%83%B3%E3%83%88%E3%83%BB%E3%83%99%E3%83%83%E3%82%AF traitsは、「プロトタイプベース言語でクラスを実現するもの」ぐらいの認識でしたが、 これも元祖はSmalltalk? ……と思ったら別物? http://sumim.no-ip.com:8080/wiki/818

>山さんの言語でこのあたりを変えるとなると、fix_tree.cでのTypeSpecifierの >扱いが変わってくるはずです。 はい、実質中では同じような構造を持っていますが意味が多少違ってきました。 　いまようやくVM 入り口まで書けるようになりました。可変スタックはなかなか やっかいです。まずは動くことを目指してスピードUPはまた今度で書いています。

>ひとつのVMで複数のスレッドを動かすのではなく、VMごと分けてしまって、 >それぞれ別のスレッドで動かせばよいのではないでしょうか。 　大きな単位でのスレッドのことだと思いますが、当初はそう考えていましたが、 結局言語を作ることになったので、理想を少しあげてみました。 >Rubyのまつもとゆきひろさんが以前こんなことを書いています。 >　(中略) >>という(むしろforkを活用すべきという)意見を述べています。 　言語としての統一性と、インタープリター言語としてのスレッド化は、理想的な 形で両立するのは難しいと思います。なので、私はスレッド向けに参照操作を すっぱりなくしました。グローバルシステム変数にいたっては…、いやこれは目的 アプリケーションのためで…。 　でも、せっかくだから殆どの面でスレッドセーフにすることで、利用者は並列動作 のためのプログラミングルールを気にすることなく書けるようになるのではないか と思いチャレンジしています。 　それに、一般的な言語だったら、C/C++なりJavaなりその他のもっといい言語が あるので、作る気なんてしません。^^　どうせ作るなら一般言語では出来ないよう な事を、です。

>おお、ご本人が降臨されるとは。 降臨だなんて勘弁してください。^^; >主義者を殲滅というのは物騒でいかんですねえ。反省。 型安全性を重視する人にとっては、Smalltalk 愛好者やそのやり方・考え方は、正気の 沙汰とは思えないいい加減さがあるでしょうから、「自分の周りからできれば排除した い…」と思うのも、やむを得ない反応だと思います。 他方で古くはデザパタ、ユニットテストやアジャイル的な手法、比較的新しいところでも Classbox や Traits などのような静的型でも応用の利く役立つ物を次々と編み出して くるのも、また Smalltalk 愛好者たちなので、そういう成果物はどんどん活用したいと 思っている人には、生かさず殺さずのさじ加減が難しい存在でもあるでしょうね。ｗ

>この BBS では、だいぶ久しぶりですよね。 恐縮です。 >実は Actor よりも Alan Kay のアイディアの方が先だったとは... >勉強になりました。_o_ ストラウストラップによるＯＯの再定義（抽象データ型のＯＯの提唱）が後にくるので アクターが先、ＯＯはあと、というのが定説になってしまったようです。ふたつのＯＯを 無理矢理ひとくくりにしてしまうと、こんな歴史的な事実も歪曲されてしまうのですね。

>int func(p1[],p2[]) >{ > p1[2]=10; // これはOK > p2[4]=9;　　　　// これはOK > p1=p2;　　　　 // これがエラーです >} >ひょっとしてdiksamはOKでしたか？ DiksamではOKです。Diksamの配列の仕様はJavaとほぼ同じですので。 よって、[]は演算子です。 int[][]という型の式に対し、1回適用すればその式の型はint[]になりますし、 2回適用すればintになります。 山さんの言語でこのあたりを変えるとなると、fix_tree.cでのTypeSpecifierの 扱いが変わってくるはずです。

>私は「クラス単位」で「オブジェクト」で分割です。 前から思っていたのですが、「クラス」と「オブジェクト」の区別、ついてます? >しかしこれは構造化ですよ。オブジェクト指向ではありません。 すてぜりふ?

>　では、スレッド間で複数のデータを渡す場合の方法が無いのではないだろうかと思われ >るでしょう。これには、変数集合体のパック、アンパック機能を提供し、複数の情報を >パックして他スレッドに渡すことで、スレッドセーフを保障しています。 いまさらなのかも知れませんが、スレッド間のデータの受け渡しがこれぐらい疎結合で よいのなら、ひとつのVMで複数のスレッドを動かすのではなく、VMごと分けてしまって、 それぞれ別のスレッドで動かせばよいのではないでしょうか。 このスレッドでは、まさにそういうことを話していたつもりでした。 http://kmaebashi.com/bbs/thread.php?boardid=kmaebashibbs&from=1221&range=1 >この要求に対しポインターや参照を操作することは、スレッドセーフを著しく >阻害する要因です。 >なぜなら、2つのスレッドで同じ参照を持った場合、そのデータアクセスに対し >スレッドセーフを自動で行うことはとても大変であり重い処理となります。 少なくともDiksamの設計なら、ヒープもグローバル変数もDVMの配下にあります。 よって、DVMを複数生成すれば、ふたつのスレッドで同じオブジェクトへの参照を 持つことはありませんし、グローバル変数も別です。 その上で、VM共有変数とかを導入して、VM間のデータのやり取りを考えれば よいのではないかと。 スクリプト言語において、ひとつのVMで複数のネイティブスレッドを使うことに関しては、 Rubyのまつもとゆきひろさんが以前こんなことを書いています。 http://www.rubyist.net/~matz/20070530.html >global interpreter lockを使っているので、native threadを使ってもさほど >並列性はあがらず性能もあがりません。 >というのも、オブジェクトアクセスひとつひとつを排他制御しなければならないので、 >コンフリクトは無視して問題が起きそうなら自分で対処というようなC++のような >対応はスクリプト言語では難しいでしょう。 (中略) >また、PythonのGuido van Rossumはスクリプト言語の並列性について >http://mail.python.org/pipermail/python-3000/2007-May/007414.html >という(むしろforkを活用すべきという)意見を述べています。 まあ、JVMなんかでも、doubleの操作はアトミックであることを保証してはいないので、 割り切ってしまう、という考え方もあるかもしれませんけれど。 # ポインタが不正になってクラッシュするのはさすがにまずいのかなあ。 # でも、黙って間違った答を吐くアプリケーションはもっとひどいと思うけど。

で、以下の指摘については、何の反論も弁明もなしですか? >仮に実装継承による差分プログラミングを(いろいろの弊害は度外視して)認めると >しても、それが趣旨ならUpperStackをStack型の変数に代入してはいけないし、 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1269&range=1 >Stack st = new Stack(); にて、SEさんは、なぜUpperStackをStackに代入しているのですか? そうすることによるメリットは何ですか? >スタックから要素を取得するメソッドはget()をオーバーライドしてはいけません。 >getUpper()のような別のメソッドを作るべきです。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1260&range=1 にて、なぜget()をオーバーライドしたのですか? そうすることによるメリットは何ですか? >>FileWriterを例にした方がいいかもしれません。内容的には同じ意図です。 >「同じ意図です」って、どういう意図でしょうか? で、どういう意図でしょうか? #「抽象化」とか、まるっきり意味のない回答をしないでくださいよ。 >FileWriterがこういう継承関係になっている「意図」を理解しているのなら、 >オセロ盤に棋譜を吐かせるのに、Boardクラスによりによって「ファイル名」を >渡すなどという設計がでてくるはずがないのですけど。 >http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1303&range=1 私には、SEさんが、継承やポリモルフィズムを理解しているようにはとても見えないのですけど。 # ていうか「インスタンス」も理解してなさそうな。

>>http://kmaebashi.com/programmer/c_yota/module.html >まずモジュールの定義が私と違っていたようです。 >(ぱ)さんの所で言うモジュールは「ヘッダファイル単位」で、私の言っていたのは「ライブラリ単位」だったようです。 むちゃくちゃですね。 「ヘッダファイル単位」っていったいどういう意味ですか? 私がどこかにそんなことを 書きましたか? (書いてあるというのなら引用してください) ご自分が何を言っているか 自分で理解していますか? 「モジュール」が先に決まって、それに対応するヘッダファイルを作ることはあっても、 ヘッダファイルが先に決まることはありえないでしょう。常識的に考えて。 よってモジュールが「ヘッダファイル単位」などということがあるわけがありません。 これではモジュール切り分けの指針がどこにもないではないですか。 件のページで、私はこう書いています。 >さて、Cでは、ソースファイル単位で名前空間の隠蔽が出来ますが、プログラムの >規模がさらに大きく、ソースファイルの数自体が膨大になってくると、今度は、 >いくつかのソースファイルをまとめて、もう1段階大きな固まりを作る必要が >出てきます。以下、この文章中では、この固まりのことを「モジュール」と呼びます。 ># こういうのは「ライブラリ」と呼ばれることもありますが、「ライブラリ」と ># 言うとどうも「下請け」的なイメージがあって、私にはちょっとしっくり来ません。 SEさんは、Cでは、「せいぜいDBアクセスとか通信部分など」しかモジュール化しない そうですが、これはやはり私と同様、「ライブラリ」には下請け的なイメージを 持っていて、DBアクセスとか通信部分のような下請け部分しかモジュール(SEさん用語の ライブラリ)にはしない、と言っているわけでしょう。 では、「せいぜいDBアクセスとか通信部分など」以外の部分は、Cの時代には、 どのように作っていたのですか? いっさい分割なしのぐちゃぐちゃですか? >私は、実装隠蔽の単位としてクラスは適当だと思っていて、機能を単位とするのは間違いだと思います。 で、なぜそう思うわけですか? 具体的にどのような例で、クラスで分割するとうまくいって、機能を単位とすると うまくいかないわけですか? 具体例としてSEさんから出てきたのは、[1287]のこの例だけです。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1287&range=1 >ちなみに簡単に変更できた例は、 >メモリ上で頻繁に検索するデータが100件から6万件に変わった時の事でした。 >検索にキャッシュやヒストリー機能などあらゆる機能を組み込み高速化しましたが、 >修正したクラスは1つです。もしCの構造化で組んでいたら、修正箇所と影響範囲を >調べるだけで嫌になっていたと思います。 これを普通に読めば、なにかの検索機能という「機能を単位とした」モジュールが あって、それがうまいこと隠蔽されていたから修正箇所がそこだけで済んだ、という 話にしか読めません(誤読であればご指摘ください)。 そこで私は、「そんなものはオブジェクト指向以前の、モジュール化で達成している ことではないか(よって、オブジェクト指向の利点ではない)」と指摘しているわけです。 ここでそう書いてますよね? http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1292&range=1 >関連する操作やデータをまとめる、というのは普通にモジュール化であって、 >私が「疑りぶかい～」で書いたオセロの例の、Cでstaticで隠蔽を行った >board.cで達成していることでは? 機能単位のモジュール化では実現できず、オブジェクト指向なら実現できることの 具体例を示してもらわないと、SEさんにとってのオブジェクト指向の定義がさっぱり わからないです。

(ぱ)さんも感じているのではないかと思いますが、何か全てが少しづつ違うようです。 ただこの違和感は経験があります。構造化とオブジェクト指向の違いによる違和感です。 (ぱ)さんは、モジュールは「ヘッダ単位ファイル」で「機能」で分割ですね。 私は「クラス単位」で「オブジェクト」で分割です。 プログラムの組み方も変わります。イメージ的に言うと縦割りと横割りぐらい違います。 話が噛み合わないのは、この縦割りと横割りで見方が違うためでしょう。 実際、構造化プログラミングの観点で言えば、(ぱ)さんの意見は納得出来ます。 私もその観点で言えば、「クラスとカプセル化した関数は同じ」とか、 「利点をあげるとしたら見やすさ」などと言うと思います。 しかしこれは構造化ですよ。オブジェクト指向ではありません。

>おお、ご本人が降臨されるとは。 この BBS では、だいぶ久しぶりですよね。 実は Actor よりも Alan Kay のアイディアの方が先だったとは... 勉強になりました。_o_ >「殲滅」ではなくて「粉砕」でしたね。 >しかも対象は「Smalltalk原理主義者」ではなく「Smalltalk原理主義」。 > >主義者を殲滅というのは物騒でいかんですねえ。反省。 字面はたしかにそうでも、内容からすると「河野さんを殲滅せよ！」って感じなので、 実は合ってるかも。:-) 河野さんのボケっぷりが懐かしいですな。

>そういう経験もあって、2000年2月ころに書いたのがこちら。 >http://kmaebashi.com/programmer/c_yota/module.html まずモジュールの定義が私と違っていたようです。 (ぱ)さんの所で言うモジュールは「ヘッダファイル単位」で、私の言っていたのは「ライブラリ単位」だったようです。 ただ、ヘッダーファイル単位だとしてもクラス単位とは違うので、CでJavaと同じ単位ではないと思います。 >なお、なにせCなのでモジュール化の単位はクラスではないですけど、 >これはその方が都合がよいという考えでそうしています。 >Javaでも、メンバのアクセスレベルがデフォルトで「パッケージ」になっている >あたり、「実装隠蔽の単位としてクラスは適当ではない」というのが現状の >コンセンサスでいいんじゃないかと思っています。 私は、実装隠蔽の単位としてクラスは適当だと思っていて、機能を単位とするのは間違いだと思います。

　会話の上で言語仕様に食い違いがあった原因を今理解しました。私の考慮不足だったの ですが、当初より言語に求める基本機能に、スレッドセーフなシステムでした。この要求 に対しポインターや参照を操作することは、スレッドセーフを著しく阻害する要因です。 　なぜなら、2つのスレッドで同じ参照を持った場合、そのデータアクセスに対しスレッド セーフを自動で行うことはとても大変であり重い処理となります。同一スレッド内でも その機構の一部が動いてしまいます。これは避けたいことです。 　次の問題がもっと深刻です。参照先が複数データの場合、他の何らかのサポートなしに 参照された複数のデータをスレッドセーフにすることは原理的に不可能です。 　以上2つの理由により、一番最初から、ポインターや参照を直接操作する行為は無いとの、 大前提が私の思考基本にありました。そのため、無意識にそれが前提で思考や会話をして いたことを気がつきました。よくある事ですが考慮不足です。 　では、スレッド間で複数のデータを渡す場合の方法が無いのではないだろうかと思われ るでしょう。これには、変数集合体のパック、アンパック機能を提供し、複数の情報を パックして他スレッドに渡すことで、スレッドセーフを保障しています。これは始めて 説明しています。その他にもスレッドセーフを自動保障するシステムがあります。まだ 説明されていません。しばらくお待ちください。なにぶん自己検証を先にしたくて。 本当に申し訳ありません。

>>int[] func(p1,p2,p3); >>これの　int[]　配列の戻りが禁止になっています。 > >対策するのであれば、ユーザには、配列への参照自体を取得できないようにしておかな Cで言う所のポインターの存在がありません。だから、グローバル変数に参照を 入れることが出来ません。 int func(p1[],p2[]) { p1[2]=10; // これはOK p2[4]=9;　　　　// これはOK p1=p2;　　　　 // これがエラーです } ひょっとしてdiksamはOKでしたか？ （駄目だと思い込んでいました）仕様が変わっています。

>int[] func(p1,p2,p3); >これの　int[]　配列の戻りが禁止になっています。 具体的にどうされているのかがよくわかりませんが、少なくとも、関数の戻り値の型として 配列型を返せないようにするだけでは不完全ではないでしょうか。 ユーザが、配列への参照を取得できるのなら、それをグローバル変数に代入することも できるはずで、もしそれをされたら、関数を抜けてスタックが開放された時点で 不正なポインタになってしまいます。 対策するのであれば、ユーザには、配列への参照自体を取得できないようにしておかないと だめなのでは。

>ええと、ということは、そもそもユーザは配列への参照を取ることができない >(配列を引数として別関数に渡すときは内部的には参照が作られるが、ユーザがそれを >変数に代入したりすることはできない)ということでしょうか? >それなら問題ないように思います。CやJavaに慣れた身にはちょっと不便そうですが。 言葉足らずですみません。 int[] func(p1,p2,p3); これの　int[]　配列の戻りが禁止になっています。 int func(p1[][],p2[]) これは問題ありません。内部で操作しても問題なく処理されます。 配列は参照渡しなので、子関数で操作したものは、呼びだし関数の配列内が変わります

>>Cですごくありがちなバグである、 >　配列の参照戻しは今エラーにしています。もともと、配列は参照渡しなので、 >リターンで戻す必要を感じなかったので。 ええと、ということは、そもそもユーザは配列への参照を取ることができない (配列を引数として別関数に渡すときは内部的には参照が作られるが、ユーザがそれを 変数に代入したりすることはできない)ということでしょうか? それなら問題ないように思います。CやJavaに慣れた身にはちょっと不便そうですが。

　やはり寝ながら思いついたアイデアは細部まで検討されていませんでした。 出来なくは無いのですが、副作用が見つかったし。やはりトリッキーでnew事態の 一般的な意味の仕様も変えてしまうのは問題が有るので、上のアイデアは 無かったことにしてください。　orz 　今日は寝れそうに無くなってしまった…

>Cですごくありがちなバグである、 　配列の参照戻しは今エラーにしています。もともと、配列は参照渡しなので、 リターンで戻す必要を感じなかったので。 　いや～～寝ようとしたら、動的配列生成でトリッキーな方法を思いついてしまって 眠れなくなってしまいました、ここ2日間の作成をチャラにして元に戻そうかな～～ 　何を思いついたかと言うと、配列をnew宣言したときにスタック上の配列データの所を 開ける、その為にスタックを移動することです。スタックにリアルアドレスを持ってい るわけではないし、アドレス操作をするときは移動してないわけで。たぶん問題ないかと。 　ああ～～～だめだ、思いついたらやらないでおけなくなってしまう。寝ながら だめだ、だめだ、こんな変なこと考えてはと、何度繰り返したことか。でも、どうせ 好きに作れるんだからやってしまおう^^ どう思いますか？　

>>(1)Cのように、配列の領域をスタック上に取る。 >ご指摘ありがとうございます。前の書き込みからVMをいろいろ調べていましたが、 >まさに(1)の方法を取ろうと思っています。このレス読んだのがちょうど今日なん >ですよ。 この方法を取るとして、ローカルな配列への参照を、別関数に渡すことは できるのでしょうか? できるとしたら、配列への参照がプログラマの思いのままにできるということですから、 Cですごくありがちなバグである、 char *get_line() { char buf[256]; /* bufに値をつめる処理 */ return buf; } みたいなのも許すことになりませんか?

　上記の仕様変更により。yacc,lex部分からの修正をしています。 下に示すようなプログラムに。diksamの言語仕様と離れていってしまうのは 仕方の無いことかもしれません。それに、ほぼC言語に近くなってしまう。 ちなみに、配列変数宣言時に[]内に変数を入れるとエラーになります。 ---------------------------------------- int main(int p1,int p2) { 　　int aa; 　　string[1+2] msg = { "asd","qwe","zzz"}; 　　int[1+1+1] i1 = {1,2,65537}; 　　int[10][9] id; 　　id[5][4] = 321; 　　aa =id[9][8]; } ---------------------------------------- 　結局の所、GCを装備して配列の動的確保を可能にし、管理のための処理及び間接 アクセスのためのオーバーヘッドを許すか。領域を固定にもって直接スアクセス し、高速で単純な処理だが配列領域は宣言時に固定で確保しなければならないか。 のチョイスで有ったのではないかと思います。 　私は今回、連続的な処理（一般的なプログラム）より。マルチスレッドで複数の 小さな処理の集合体による制御を優先しているので下の方を選びました。単にGCを 入れたくなかっただけかもしれませんが^^;

>一応、抽象化されていますが、確かに分かりにくいかもしれません。 「分かりにくい」とか「一応、抽象化」といった話ではなくて、SEさんの出した UpperStackでの継承の使い方は *間違っています*。 仮に実装継承による差分プログラミングを(いろいろの弊害は度外視して)認めると しても、それが趣旨ならUpperStackをStack型の変数に代入してはいけないし、 スタックから要素を取得するメソッドはget()をオーバーライドしてはいけません。 getUpper()のような別のメソッドを作るべきです。 たとえ「リスコフの置換原則」とかの名前を知らなくても、ポリモルフィズムを 理解していれば、当然そう考えると思うんですが。 >FileWriterを例にした方がいいかもしれません。内容的には同じ意図です。 「同じ意図です」って、どういう意図でしょうか? FileWriterがこういう継承関係になっている「意図」を理解しているのなら、 オセロ盤に棋譜を吐かせるのに、Boardクラスによりによって「ファイル名」を 渡すなどという設計がでてくるはずがないのですけど。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1303&range=1

>Cではモジュール化しようと思った所しかモジュール化しません。 >具体的に言うと、せいぜいDBアクセスとか通信部分などでしょう。 えーっ! 私がある程度大きなプログラムを最初にCで設計から実施したのは、入社2年目でしたから かれこれ15年くらいは前の話ですけれど、すべての関数をモジュールに入れていました。 5万行程度の、UNIX上のシステムで、XとMotifで画面描画するようなシステムでした。 他にもいろいろなシステムを見ましたが、数万行以上の規模なら、誰が設計しても、 まずモジュール分割はやっていたように思います。ヘッダファイルをちゃんと分離して なかったりして変なことになっているケースはよくありましたが。 そういう経験もあって、2000年2月ころに書いたのがこちら。 http://kmaebashi.com/programmer/c_yota/module.html 現在作っているcrowbarやDiksamといった言語も、モジュール分割はしています。 Diksam ver.0.2のソースにGLOBALをかましたのはこちら。 http://kmaebashi.com/programmer/devlang/diksam_src_0_2/index.html メモリ管理モジュールMEMやデバッグ用モジュールDBGの上に、コンパイラDKCと 仮想マシンのDVMがあります。その中でも機能ごとにソースファイルを分けると いったようなことはしています。 なお、なにせCなのでモジュール化の単位はクラスではないですけど、 これはその方が都合がよいという考えでそうしています。 Javaでも、メンバのアクセスレベルがデフォルトで「パッケージ」になっている あたり、「実装隠蔽の単位としてクラスは適当ではない」というのが現状の コンセンサスでいいんじゃないかと思っています。 ……それはさておき。 私も長いことこの仕事をやってますから、いろいろアレな設計やナニなソースを 見てきたつもりでいましたけど、なんだかんだでずいぶん恵まれた環境にいたのかなあ。 これでも。

おお、ご本人が降臨されるとは。 >それらしいのを見つけましたがこれですか？ >http://groups.google.co.jp/group/fj.comp.oops/msg/973f372a89455de2 そうですそうですこれです。 「殲滅」ではなくて「粉砕」でしたね。 しかも対象は「Smalltalk原理主義者」ではなく「Smalltalk原理主義」。 主義者を殲滅というのは物騒でいかんですねえ。反省。

> {"new_array_int", "b", 16}, // 次元数　基本データ-型の配列生成 > {"new_array_double", "b", 20}, // 次元数　基本データ-型の配列生成 > {"new_array_object", "b", 16}, // 次元数　基本データ-型の配列生成 > {"new_array_literal_int", "s", 16}, // int定数配列を変数に接続 > {"new_array_literal_double","s", 20}, // double定数配列を変数に接続 > {"new_array_literal_object","s", 16}, // object定数配列を変数に接続 補足 　このnewは構文のnewではなくスタック上に実配列生成のnewです。 ちなみに、言語上の総ての関数は特に何も記述することなくスレッドセーフに なります。複数のスレッドから関数AAAを同時に呼んでも問題が無いです。 もちろん組み込み関数も。利用者はスレッドを意識することなく自由に組んでも 問題の無い言語になります。 　しかしよくよく考えてみると、この仕様がOOのクラスに合わないんです。OOP 好きな私がOOPに合わない言語を作るとは、考えてしまいます。早く作って検証 したくてなりません。

>(1)Cのように、配列の領域をスタック上に取る。 ご指摘ありがとうございます。前の書き込みからVMをいろいろ調べていましたが、 まさに(1)の方法を取ろうと思っています。このレス読んだのがちょうど今日なん ですよ。 　ちなみに、配列の添え字記述が宣言時決定でnewは無くなる方向しかないかなと 思っています。スタック上に取る以上は動的確保は無理のようで。VMコードも多少 変わってしまいました。 下記がVMコードの現在の案です。 S_OpcodeInfo D_opcode_info[] = { {"dummy", "", 0}, {"push_int_1byte", "b", 8}, {"push_int_2byte", "s", 8}, {"push_int_4byte", "i", 8}, // 実際の値を持つ {"push_double_0", "", 12}, {"push_double_1", "", 12}, {"push_double_8byte", "d", 12}, // 実際の値を持つ {"push_string", "s", 40}, // 文字列の位置NOを持つ０～ {"push_null", "", 8}, /**********/ {"push_stack_int", "s", 8}, // intローカル変数をスタックに {"push_stack_double", "s", 12}, // {"push_stack_string", "s", 40}, // {"pop_stack_int", "s", -8}, // スタックのintをローカル変数に {"pop_stack_double", "s", -12}, // {"pop_stack_string", "s", -40}, // /**********/ {"push_static_int", "s", 8}, // int静的変数をスタックに {"push_static_double", "s", 12}, // {"push_static_string", "s", 40}, // {"pop_static_int", "s", -8}, // スタックのintを静的変数に {"pop_static_double", "s", -12}, // {"pop_static_string", "s", -40}, // /**********/ {"push_sysval_int", "i", 8}, // システムグローバル変数をスタックに {"push_sysval_double", "i", 12}, // {"push_sysval_str", "i", 40}, // {"pop_sysval_int", "i", -8}, // スタックからシステムグローバル変数に {"pop_sysval_double", "i", -12}, // {"pop_sysval_str", "i", -40}, // /**********/ {"push_array_int", "", 16}, // int配列値をスタックに {"push_array_double", "", 20}, // {"push_array_string", "", 16}, // {"pop_array_int", "", -16}, // スタックからint配列に {"pop_array_double", "", -20}, // {"pop_array_string", "", -16}, // /**********/ {"add_int", "", -8}, // 以下は総て算術演算子 {"add_double", "", -12}, {"add_string", "", -40}, {"sub_int", "", -8}, {"sub_double", "", -12}, {"mul_int", "", -8}, {"mul_double", "", -12}, {"div_int", "", -8}, {"div_double", "", -12}, {"mod_int", "", -8}, {"mod_double", "", -12}, {"minus_int", "", 0}, {"minus_double","", 0}, {"increment", "", 0}, {"decrement", "", 0}, // ここまで算術演算子 {"cast_int_to_double", "", 4}, // 以下はキャスト処理 {"cast_double_to_int", "", -4}, {"cast_boolean_to_string" "", 32}, {"cast_int_to_string", "", 32}, {"cast_double_to_string", "", 28}, // ここまでキャスト処理 {"eq_int", "", -8}, // 以下は総て論理演算子 {"eq_double", "", -12}, {"eq_string", "", -40}, {"gt_int", "", -8}, {"gt_double", "", -12}, {"gt_string", "", -40}, {"ge_int", "", -8}, {"ge_double", "", -12}, {"ge_string", "", -40}, {"lt_int", "", -8}, {"lt_double", "", -12}, {"lt_string", "", -40}, {"le_int", "", -8}, {"le_double", "", -12}, {"le_string", "", -40}, {"ne_int", "", -8}, {"ne_double", "", -12}, {"ne_string", "", -40}, {"logical_and", "", -8}, {"logical_or", "", -8}, {"logical_not", "", 0}, // ここまで論理演算子 {"pop", "", -1}, // スタックを1つ減らす {"duplicate", "", 12}, // スタック内容をコピーしてスタックに {"jump", "s", 0}, // 指定ポインターにjump {"jump_if_true", "s", -1}, // スタックがtrueならjump {"jump_if_false","s", -1}, // スタックがfalseならjump /**********/ {"push_function", "sss", 0},// 関数情報をスタックに {"invoke", "", -1}, // 関数コール {"return", "", -1}, // 関数戻り /**********/ {"new_array_int", "b", 16}, // 次元数　基本データ-型の配列生成 {"new_array_double", "b", 20}, // 次元数　基本データ-型の配列生成 {"new_array_object", "b", 16}, // 次元数　基本データ-型の配列生成 {"new_array_literal_int", "s", 16}, // int定数配列を変数に接続 {"new_array_literal_double","s", 20}, // double定数配列を変数に接続 {"new_array_literal_object","s", 16}, // object定数配列を変数に接続 }; 　（注:ちなみに1とか-1は未定です） 　上の構造だとstringがやたらスタックを食っているのは、string自体の大きさ からです。このへんが、stringを使用するのを変えてしまいそうな気分です。 ちなみに、配列は3次元まで、要素の最大は60KByteまでの制限をする予定。汎用の 言語を作るわけではないし、あくまでもローカル変数の制限だけなので、目的と 効率を優先にしています。 　また、スタック構造ですが、VC++だとenumが4byte取るのでスタック対応する フラグは消して、下記のようなS_Valueに変えて、タイプとサイズを持つことに しました。で結局の所、関数のローカル変数は総てスタックに持つことでint用と double当のプールはなくしました。前に話したようにVMは出来るだけシンプルに したいので、持つデータ構造は違う形になりそうです。配列の仕様も変えてし まったし。下記の構造体をスタックで使用します //=================================================================== typedef struct { ushort dimno; // 配列の次元数 ushort dimsno[DIMMAX]; // 配列の添え字数 union { int *intDim; // int配列実態 double *doubleDim; // double配列実態 string *stringDim; // string配列実態 }u; } SV_array; //=================================================================== typedef struct { ushort vtype; // データタイプ E_StackDType ushort size; // スタック消費サイズ union { int int_value; // intデータ double double_value; // doubleデータ string *string_value // string参照 SV_array *i_array; // int配列参照 SV_array *d_array; // double配列参照 SV_array *s_array; // string配列参照 }u; } S_Value; 　以上が、今日までに想定した仕様です。まだVM自体を作っていないので、まだ 変更があるかもしれません。ちなみに、組み込み関数についてはラフ案で下記の ようなクラスを使用しようと思っています。組み込み関数からのリターンはエラー コードにする予定。パラメータ可変の関数も対応します。それと変数リファレンス 情報を持って一部の関数は総ての変数をリファレンスに操作します。この点は悩み ました。文字列と配列以外は実数渡しなのですが、一部のシステム関数のみリファ レンス操作してしまうんですよ。その一部のために構文を作るべきか特殊仕様とす るかで、たった２つの関数のために構文を変えることは止めにしました。 目的優先に^^; //=================================================================== typedef struct { char *name; // 変数名 ushort gval_x; // グローバル変数横軸数 ushort gval_y; // グローバル変数縦軸数 S_Value *val_ref; // 変数参照データ S_Value val; // 変数コピーデータ } S_Value_info; //=================================================================== class C_NFBase { //-- VMに送る情報 ---------------------- char *m_name; // 関数名 int m_prmno; // 要求するパラメータ数0-10まで20は可変関数 E_ValueType m_type[PRMMAX]; // 要求するパラメータの型 E_ValueType m_rtntype; // 関数戻り値の型 //-- VMから受け取る情報 ---------------------- int m_prninno; // 引き渡されたパラメータ数 S_Value_info m_prm[PRMMAX]; // 引き渡されたパラメータデータ //-- 関数の戻り情報 ---------------------- S_Value m_return; // 関数からの戻り値データ

>Cではモジュール化しようと思った所しかモジュール化しません。 主語は誰なんでしょうか……。

そりゃ単にプログラマの技量の問題ぢゃん。 きれいにモヂュール化された C ソースや Fortran ソースを何度も見たことあるし ぜんぜんモヂュール化されていないグチョグチョ Java ソースも見たことあるよ。 モヂュール化を言語の仕様レベルで推し進める機構があるかないか という点ならば御意。 そしてその機構に関係なくグチョグチョソースを書く下手プログラマが どこにでも、いくらでも、いるのが現実。

>本質は抽象化だと仰っているのにSEさんが出してるスタックの例はまったく >抽象化されていないような気がするのですが…。 一応、抽象化されていますが、確かに分かりにくいかもしれません。 FileWriterを例にした方がいいかもしれません。内容的には同じ意図です。 ----------------------------------------------------------- java.lang.Object 　| 　+--java.io.Writer 　　　　| 　　　　+--java.io.OutputStreamWriter 　　　　　　　| 　　　　　　　+--java.io.FileWriter -----------------------------------------------------------

>Cで「単位を合わせて」モジュール化する困難さと、クラスの階層構造を適切に設計する困難さは、 >あまり違いがないように思うんですが、人によるのかな。 Cではモジュール化しようと思った所しかモジュール化しません。 具体的に言うと、せいぜいDBアクセスとか通信部分などでしょう。 Javaの場合は全てのクラスがモジュール化なのです。 現実的に実システムでは、CでJavaと同様の単位でモジュール化するのは不可能です。

>全然完璧に関係ないですが、大昔、fjに高木浩光さんが >「Smalltalk原理主義者を殲滅せよ」なんてことを書いていて(もちろんネタですが)、 >今これを探そうとしてGoogleグループを見てみたのですが… それらしいのを見つけましたがこれですか？ http://groups.google.co.jp/group/fj.comp.oops/msg/973f372a89455de2

>それと、GCは不要なシステムになります。INT用とdouble用の固定長プール、そして >文字列はstringに任せてしまうのでVMとしてのGCは無くなりました。 intとdoubleが固定長のプールに保持されてGCがないということは、 配列はグローバルなものだけなのでしょうか? ローカルな配列が使えないのはちょっと不便なような。 ローカルな配列を使えるようにする場合、再帰を考えれば (1)Cのように、配列の領域をスタック上に取る。 　→現状のDVMには、スタック上でインデックスを指定して要素を参照する 　　インストラクションがないので、追加が必要。 (2)配列の領域はヒープに取るが、その参照をスタックに持つ。 　→最低でも参照カウンタのGCが必要。 ということになりそうな…

件名変えました。 >>関連する操作やデータをまとめる、というのは普通にモジュール化であって、 >>私が「疑りぶかい～」で書いたオセロの例の、Cでstaticで隠蔽を行った >>board.cで達成していることでは? >ここが重要です。 >構造化プログラミングの「モジュール化」は基本的にモジュール化した所でしか有効ではありません。 >1つの関数で考えた場合は分かりにくいかと思いますが、関連する複数の関数での場合を考えてください。 いや、だから私が例に出したboard.cにはちゃんと複数の関数があるんですけど。 http://kmaebashi.com/programmer/object/othello.html もうSEさんが何を言いたいのかさっぱりです。 >オブジェクト指向の >利点は「再利用性が高まる事」＝「変更がしやすい、変更しても壊れにくい」。 >本質は「抽象化」 >だと言う事です。 「抽象化」なんてのはおよそあらゆるプログラミングパラダイムの目的みたいなもので、 それだけでは何がなんだかさっぱりです。 >774RRさんの言う通り、「対象読者層が異なる」というだけの話のようです。 >つまり「インスタンスが複数あっていい」というあたりを理解していないプログラマ向けの文書で、 >私の指摘は「インスタンスが複数あるのは当たり前」と理解しているプログラマの視点という事です。 私もそう思っていたのですが、ちょっと疑い始めているところです。 >棋譜をセーブデータとして残すために、コンストラクタかセッターにファイル名を渡すと >言うならボードクラスに入れるのはいいと思いますが、 >名人戦の障害発生対応が違うかもしれないので、エラーログクラスを受け渡すと言うのは >おかしいと思います。 まあそのへんは要件次第で、エラーログならstaticでよいという考え方もあるでしょう (Boardが持つのは「おかしい」と言われると、それは何故かと聞きたくなりますが)。 ええと、しかも、「コンストラクタかセッターに『ファイル名を』渡す」んですか? 棋譜をファイルに吐かず、こっちの画面に出したい、とかの場合はどうするんですか? もともとLoggerの話は、SEさんの[1269]における http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1269&range=1 >これを次のように変更します。1行で済みます。 とか、 [1273]における http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1273&range=1 >遠くの所でnewした特有の処理の入ったクラスを、引数で使い回すのは、 >構造化のスタンプ結合的で、オブジェクト指向的には良くない設計です。 とかの話から出てきたものです。Loggerを引数で引き回そうが、staticで保持しようが、 遠いところでnewされたオブジェクトを、その実際のクラスがわからない状態で 使用するということに変わりはありません。そのとき、うまく使えばポリモルフィズムで 動きが変えられるというのがよく言われるオブジェクト指向の利点です。 その点、SEさんのUpperStackは、使う側がUpperStackであることを意識して使わなければ ならない(リスコフの置換原則を破っている)のでダメだ、と言っているわけです。 CばっかりずっとやってきたプログラマにJavaで設計させると、機能単位でクラス分割は するものの、 (1)何もかもstaticフィールドとメソッドで作ってしまう。 (2)staticメソッドにしない代わりに、毎回オブジェクトをnewして、いくつか 　メソッドを呼んだら使い捨てにしてしまう。 このどちらかの設計にしてしまうことがあります。 正直なところ、SEさんはこの(2)のタイプの人に見えてしょうがないんですが。

>つまり私の言いたいのは、 >オブジェクト指向の >利点は「再利用性が高まる事」＝「変更がしやすい、変更しても壊れにくい」。 >本質は「抽象化」 >だと言う事です。 >利点は「見通しの良さ」 >本質は「マルチプルインスタンス」 >ではないと思います。 本質は抽象化だと仰っているのにSEさんが出してるスタックの例はまったく 抽象化されていないような気がするのですが…。

>まるで3つのオブジェクト指向があるように思えますが、実質的にはオブジェクト指向は2です。 >1はメッセージが焦点になっていますが、本質はオブジェクトで2と同様です。 １の本質はオブジェクトではなくてメッセージだと書いてあるはずですが…。 ＃Smalltalkの文法やクラスやオブジェクトといった概念もおまけでしかない、とアランケイはのたまっています >もし初心者が見たら混乱するだけだと思います。2の説明だけあればいいと思います。 きちんと分類して書いてあるから少なくとも混乱することはないと思いますけどね。

クラスの階層構造のおかげで、モジュール化も適切な階層構造で行いやすくなる、ってことでしょうか。 少なくとも私自身は、そんなメリットを実感したこと、一度もないなぁ。 Cで「単位を合わせて」モジュール化する困難さと、クラスの階層構造を適切に設計する困難さは、 あまり違いがないように思うんですが、人によるのかな。 無地のノートより罫線の引いてあるノートのほうが書きやすい、ぐらいの違いはあるかもしれないけど。 Cで適切な階層構造のモジュール化が行えない人が、オブジェクト指向言語でクラス設計したところで、 （しかも実装継承で組んだりしたら）余計ぐちゃぐちゃになっちゃうような気がするんですが。

>関連する操作やデータをまとめる、というのは普通にモジュール化であって、 >私が「疑りぶかい～」で書いたオセロの例の、Cでstaticで隠蔽を行った >board.cで達成していることでは? ここが重要です。 構造化プログラミングの「モジュール化」は基本的にモジュール化した所でしか有効ではありません。 1つの関数で考えた場合は分かりにくいかと思いますが、関連する複数の関数での場合を考えてください。 つまり拡張を見越して単位を合わせてモジュール化しておく必要があると言う事です。 オブジェクト指向の場合はクラス単位でモジュール化されているような物であると言う事です。 つまり末端のクラスから上位のクラスまで、全ての単位でモジュール化されているため、 あらゆる単位で変更が可能だと言う事です。 つまり私の言いたいのは、 オブジェクト指向の 利点は「再利用性が高まる事」＝「変更がしやすい、変更しても壊れにくい」。 本質は「抽象化」 だと言う事です。 利点は「見通しの良さ」 本質は「マルチプルインスタンス」 ではないと思います。 >いや、「世間のCプログラマはstaticで実装を隠蔽するような気の効いたことは >していない。だからお前の認識はズレているのだ」ということならそうなのかも >しれませんけど(1ソースファイル1関数、という規約のプロジェクトとかって、 >今でもあるんでしょうか)。 774RRさんの言う通り、「対象読者層が異なる」というだけの話のようです。 つまり「インスタンスが複数あっていい」というあたりを理解していないプログラマ向けの文書で、 私の指摘は「インスタンスが複数あるのは当たり前」と理解しているプログラマの視点という事です。 >うーん、Loggerくらいならstaticでもかまわないとは確かに思いますけれど、 >私ならアプリケーションのインスタンスのフィールドに持ちますね。 >オセロの例なら、Boardクラスで障害発生時とかのログを残すとして、Loggerは >Boardに持たせます。名人戦のBoardだけ障害発生時の対応が違ったりするかも >知れませんし。よって、BoardのコンストラクタかsetLogger()メソッドの >引数でLoggerを渡すことになります。 棋譜をセーブデータとして残すために、コンストラクタかセッターにファイル名を渡すと 言うならボードクラスに入れるのはいいと思いますが、 名人戦の障害発生対応が違うかもしれないので、エラーログクラスを受け渡すと言うのは おかしいと思います。

>>>これもひどい内容ですね。 > >とSEさんがおしゃるのか、さっぱりわからないんですけど。 1.メッセージ指向 2.クラス指向 3.手続き抽象化 のまるで3つのオブジェクト指向があるように思えますが、実質的にはオブジェクト指向は2です。 1はメッセージが焦点になっていますが、本質はオブジェクトで2と同様です。 3は少なくとも私は知りませんし、一般的ではないと思います。HP筆者の独自解釈では？ もし初心者が見たら混乱するだけだと思います。2の説明だけあればいいと思います。

>＃自分も特にSmalltalkに思い入れがあるわけではありません＾＾； ありゃ、そうですか。了解です。 全然完璧に関係ないですが、大昔、fjに高木浩光さんが 「Smalltalk原理主義者を殲滅せよ」なんてことを書いていて(もちろんネタですが)、 今これを探そうとしてGoogleグループを見てみたのですが…Googleグループって、 NewsGroupの検索ができるのだと思っていましたが、いつのまに2ch検索エンジンに?

>こくぼさんには「Smalltalkが不憫で仕方ありません」と言われそうですが、 >職業プログラマである我々が、現状、仕事でSmalltalkを使うことはまあまずないわけで、 >JavaやC++やC#を使うのに「メッセージ」がどうこう言われたら誤解を招く、というのは >わかります。 Smalltalkが不憫っていうのは、SEさんが紹介している説明を見ると まるでSmalltalkが悪いせいでオブジェクト指向が理解されてない みたいな書き方をされてるせいです。 ＃自分も特にSmalltalkに思い入れがあるわけではありません＾＾； >とSEさんがおしゃるのか、さっぱりわからないんですけど。 ですよね。

見ていただきありがとうございます。 >要点は、文字列以外はコンスタントプールを使わずに、直接定数を >バイトコードの中に埋め込むようにした、ということですよね。 はい >効率を考えてバイトコードではなくワードコード)中に埋め込んでいるそうです。 管理面とスピードを考えて、コードに埋め込みましたが問題なさそうでよかった。 >あと、もしシステムグローバル変数がDVM_Valueを保持しているのなら、 コード生成が一応落ち着いたのでVM部分を見ました。計算スタックはDVM_Value なんですね。VMを複数スレッド起動させるので、VMは極力最小にしようと思って います。その為に、省ける分はがさがさ省いていっています。コンスタントプール も、まさに、文字列を詰め込んだ配列とそのアクセスポインタテーブルのみです。 それと、GCは不要なシステムになります。INT用とdouble用の固定長プール、そして 文字列はstringに任せてしまうのでVMとしてのGCは無くなりました。この部分は VM管理システムで一括管理する予定。コード生成もそうでしたが、必要機能のた めに実行部分は最小に、その結果管理部分が大きくなっています。 　新しく組み込んでいる部分をあいまいに表現して申し訳ありません。なにぶん 出来てみないとなんとも言えなくて、絵に描いたもちを説明するのも気が引けて。 その部分はある程度完成するまでお待ちください。構想したものを組み込んで、 自身が確認しないとなんとも^^; 　追記、目的ターゲットでは、細かい文字列操作は多量にあると思いますが、長い 文字列は無いと思われますので、stringの管理でも問題は無いと思っています。 しかし、実際やってみての部分は有ります。その時は専用の文字列だけを管理する 処理を組み込む予定です。その場合も文字列だけなのでGCは不要で出来ます。

> {"push_int_4byte", "i", 1}, // 直接持に変更 > {"push_double_8byte", "d", 1}, // 直接持に変更 要点は、文字列以外はコンスタントプールを使わずに、直接定数を バイトコードの中に埋め込むようにした、ということですよね。 Diksamは、JVMを真似したのと、将来的にバイトコードをファイルに 吐き出すことを考えてコンスタントプールを持ちましたが、 たとえばYARVでは、効率を考えて定数をバイトコード(ていうかこれも 効率を考えてバイトコードではなくワードコード)中に埋め込んでいるそうです。 http://www.atdot.net/yarv/yarvarch.ja.html > {"push_sysval_int", "s", 1}, // システムグローバル変数アクセス用 > {"push_sysval_double", "s", 1}, // > {"push_sysval_str", "s", 1}, // > {"pop_sysval_int", "s", -1}, // > {"pop_sysval_double", "s", -1}, // > {"pop_sysval_str", "s", -1}, // あと、もしシステムグローバル変数がDVM_Valueを保持しているのなら、 実はpush_sysval_intやpush_sysval_doubleのようにインストラクションを 型ごとに分ける必要はありません。 Diksamの場合、スタックはDVM_Valueの配列のくせにこのインストラクションを 分けているのは、将来的にint型ローカル変数は4バイトしか消費しないようにする、 といった改善を入れるときのためです。

　コード生成部分を作っています。基本部以外がほとんど新たなプログラムに なっています。下にバイトコードの変更およびコードのディスアセンブラです。 　もしお時間が有りましたら見て、何か気になる点が有りますでしょうか？ ---　修正したバイトコード　------------ {"push_int_4byte", "i", 1}, // 直接持に変更 {"push_double_8byte", "d", 1}, // 直接持に変更 // 今考えると、リアル値を持つのはまずい？ ---　追加したバイトコード　------------ {"push_sysval_int", "s", 1}, // システムグローバル変数アクセス用 {"push_sysval_double", "s", 1}, // {"push_sysval_str", "s", 1}, // {"pop_sysval_int", "s", -1}, // {"pop_sysval_double", "s", -1}, // {"pop_sysval_str", "s", -1}, // -------------------------------------------------------- int main(int p1,int p2) { string[] msg = { "asd","qwe","zzz"}; int[] i1 = {1,2,65537}; double d1; d1 =3.1; } -------------------------------------------------------- 　　↓ コード生成後のダンプ 　　↓ 　　↓　上のコード修正で、constデータは文字列だけになりました。 -------------------------------------------------------- 1:*** 関数情報ダンプ ****************** 1:--- int main(int p1, int p2) 1:*** ローカル変数の表示 no = 3 *** 1: 0:string [] msg 1: 1:int [] i1 1: 2:double d1 1:*** 文字列定数 数 = 3 *** 1: 0: "asd" 1: 1: "qwe" 1: 2: "zzz" 1:*** 使用予定のスタックサイズ = 10 1:*** 関数コードのディスアセンブラ size = 45 1: 0 push_string_ptr 0 1: 3 push_string_ptr 1 1: 6 push_string_ptr 2 1: 9 new_array_literal_object 3 1: 12 pop_stack_object 2 1: 15 push_int_1byte 1 1: 17 push_int_1byte 2 1: 19 push_int_4byte 65537 1: 24 new_array_literal_int 3 1: 27 pop_stack_int 3 1: 30 push_double_8byte 3.100000e+000 1: 39 pop_stack_double 4 1: 42 push_int_1byte 0 1: 44 return 1:*** 行情報 数 = 5 *** 1: 3: from 0 size 15 1: 4: from 15 size 15 1: 6: from 30 size 12 1: 8: from 42 size 2 1: 7: from 44 size 1 1:*** end of main() -------------- --------------------------------------------------------

>デザインパターンと言うのは、世の中にある数多くのOOで組まれたプログラムの中から、 >共通性のある物を抜き出して分類し、その特徴や利点／欠点を解析する学問的な物です。 >重要なのは解析する能力を付ける事です。 なるほど、「学問的な物です」というのはよくわかりませんが、 おっしゃりたいことはだいたいわかったように思います。 >誰かの分類したパターンと特徴を暗記しても意味はありません。 しかしこれを「意味はありません」と言い切っちゃうのはどうかと。 kitさんが既に書いておられますが、デザインパターンはパターンに名前をつけて プログラマ間のコミュニケーションに使うことに意味があるわけですから。 >ITproのHPの人も言っていますが、「言語」→「実践」→「デザパタ」と進むのが >いいと思います。実践無しでデザパタを見たら、大抵の人は勘違いすると思います。 ここに異論はありません。

SEさんが何をおっしゃりたいのかますますわからなくなっていくのですが、 >ちなみに簡単に変更できた例は、 >メモリ上で頻繁に検索するデータが100件から6万件に変わった時の事でした。 >検索にキャッシュやヒストリー機能などあらゆる機能を組み込み高速化しましたが、 >修正したクラスは1つです。もしCの構造化で組んでいたら、修正箇所と影響範囲を >調べるだけで嫌になっていたと思います。 関連する操作やデータをまとめる、というのは普通にモジュール化であって、 私が「疑りぶかい～」で書いたオセロの例の、Cでstaticで隠蔽を行った board.cで達成していることでは? http://kmaebashi.com/programmer/object/othello.html 「疑りぶかい～」を書いたときの私の認識は、 「Cなどでプログラムを書いている普通のプログラマは、staticで情報隠蔽するような 　モジュール化は普通に行っているだろう。でもそれは、オブジェクト指向ではない。 　オブジェクト指向(C++流の)といえばカプセル化、継承、ポリモルフィズムと言われるけれど、 　カプセル化は普通のCプログラマも理解していそうだし、継承やポリモルフィズムに 　至る前にマルチプルインスタンスを理解しなければいけないのに、世間にあふれる 　オブジェクト指向の説明からはそこがすっぽり抜けている。 　多くの人がここで引っかかるように思うので、このミッシングリンクは埋めておく 　べきではないか」 というものです。 この認識がズレている、という批判ならお受けしますけれども。 マルチプルインスタンスのさらに手前の事例を持ってきて、オブジェクト指向の 成果だと言われても…… 継承の話はどこにいったんでしょうか。 いや、「世間のCプログラマはstaticで実装を隠蔽するような気の効いたことは していない。だからお前の認識はズレているのだ」ということならそうなのかも しれませんけど(1ソースファイル1関数、という規約のプロジェクトとかって、 今でもあるんでしょうか)。 >普通のLoggerは、staticのフィールド変数として作成して直接使用するため、Logger自体を >メソッドの引数にして使用する事は少ないと思います。 うーん、Loggerくらいならstaticでもかまわないとは確かに思いますけれど、 私ならアプリケーションのインスタンスのフィールドに持ちますね。 オセロの例なら、Boardクラスで障害発生時とかのログを残すとして、Loggerは Boardに持たせます。名人戦のBoardだけ障害発生時の対応が違ったりするかも 知れませんし。よって、BoardのコンストラクタかsetLogger()メソッドの 引数でLoggerを渡すことになります。 >敢えてLoggerを例にするとすると、 >void write(Logger l){} >なら、 >class Logger{ >　　void write(){} >} >にすべきと言う事です。 ええと、write()メソッドがログを吐くメソッドなら、 >class Logger{ >　　void write(){} >} となるのは当たり前だと思うんですが……

件名変えました。 >アランケイの「メッセージ指向」は、C++の登場した当たりから軽視されるようになっていて、 >現在のオブジェクト指向の実装や環境から考えると、誤解しやすい物になっているからです。 >（ぱ）さんも「ただの関数呼び出し」と言っていますが、私もそう思います。 こくぼさんには「Smalltalkが不憫で仕方ありません」と言われそうですが、 職業プログラマである我々が、現状、仕事でSmalltalkを使うことはまあまずないわけで、 JavaやC++やC#を使うのに「メッセージ」がどうこう言われたら誤解を招く、というのは わかります。 で、当のsumimさんのページにはまさにそういうことが書いてあるわけで、 >なお、この文脈の「オブジェクト指向」において、メッセージングはぜんぜん関係ない >無用のもの and/or 動的性実現のための（仮想関数より効率の悪い）実装のひとつに >過ぎない…ということを強く意識する必要があります。ケイの影響で「オブジェクト >指向＝メッセージ」と脳に染みついている人には酷かもしれませんが、いっそ排除して >考えたほうがすっきりしますし、可能な限りそうすべきです。 >しがらみのない初学者へのレクチャーに際しては、ぜひとも「オブジェクトにメッセー >ジを送って…」とか「世の中のあらゆるものを(ry」なんて説明は後々無用な混乱を >招くだけなので、やめて欲しいと思います。 なぜこのページについて >これもひどい内容ですね。 とSEさんがおしゃるのか、さっぱりわからないんですけど。

デザインパターンと言うのは、世の中にある数多くのOOで組まれたプログラムの中から、 共通性のある物を抜き出して分類し、その特徴や利点／欠点を解析する学問的な物です。 重要なのは解析する能力を付ける事です。 誰かの分類したパターンと特徴を暗記しても意味はありません。 ただ私もGoFのパターンは見ました。学者的で実務に使えるのは2割程度だと思いましたが。 ITproのHPの人も言っていますが、「言語」→「実践」→「デザパタ」と進むのが いいと思います。実践無しでデザパタを見たら、大抵の人は勘違いすると思います。

>アランケイの「メッセージ指向」は、C++の登場した当たりから軽視されるようになっていて、 >現在のオブジェクト指向の実装や環境から考えると、誤解しやすい物になっているからです。 >（ぱ）さんも「ただの関数呼び出し」と言っていますが、私もそう思います。 >歴史に関してはウィキペディアに詳しく記載されています。 あぁ…。抽象データ型のオブジェクト指向が現代のオブジェクト指向だと解釈されているのですね。 そこらへんの各人のオブジェクト指向への認識の違いを理解していただくことも含めて sumimさんの説明ページへとリンクしたつもりでしたが伝わってないみたいで…。 ＃Wikipediaの説明も見ましたがあれではSmalltalkが不憫で仕方ありません >オブジェクト指向自体の話ではありませんが、オブジェクト指向の間違いやすい所に関しては、 >以下の記載がかなりいい所をついていると思います。（全て賛成できる訳ではありませんが） >http://itpro.nikkeibp.co.jp/article/COLUMN/20060921/248617/?ST=develop&P=1 ザッと見ました。 このページを見る限りではSEさんが例示しておられる 実装継承を使ったオブジェクト指向プログラミングを推奨しているわけではなさそうですね。

>関数等に切り出されて一箇所にまとめられていれば修正するのは一箇所です。 >ここまではオブジェクト指向は関係ありません。 ここがミソです。1つの関数を考えた場合はそうですが、関数群で考えると違います。 例えばファイル操作を考えてみましょう。 クラスなら以下のようになるとします。 class File{ 　　public void open(){} 　　public void read(){} 　　public void write(){} 　　public void close(){} } これなら明確です。ファイルからメモりに変わっても簡単に変更できるでしょう。 しかしCの構造化なら関数同士の関連はありません。 そのため、もしかしたらread()は業務ロジックに組み込まれ関数化されていないかもしれませんし、 write()は3つに分割されているかもしれません。例がファイルなのでそんな簡単な間違いは しないと言うかもしれませんが、もしこれが業務ロジックなら簡単に判断出来ないかもしれません。 これが関数化（プロセス中心アプローチ（POA）または、データ中心アプローチ（DOA））と、 クラス化（オブジェクト中心アプローチ（OOA））の違いです。 POA、DOA、OOAの特徴と違いについては、以下のサイトがよく分かります。 （分かりにくい表現もありますが） http://itpro.nikkeibp.co.jp/article/COLUMN/20061019/251255/ ちなみに簡単に変更できた例は、 メモリ上で頻繁に検索するデータが100件から6万件に変わった時の事でした。 検索にキャッシュやヒストリー機能などあらゆる機能を組み込み高速化しましたが、 修正したクラスは1つです。もしCの構造化で組んでいたら、修正箇所と影響範囲を 調べるだけで嫌になっていたと思います。 Loggerのようないわゆる「横断的関心事」はOOに適さないので例としては良くないと思いますが、 普通のLoggerは、staticのフィールド変数として作成して直接使用するため、Logger自体を メソッドの引数にして使用する事は少ないと思います。 敢えてLoggerを例にするとすると、 void write(Logger l){} なら、 class Logger{ 　　void write(){} } にすべきと言う事です。 >

>どこがひどいと思われるのでしょうか？ >「この当たりの話は知っています」と書かれていることから類似のWebページなどをご存知なのでしょうか。 >できればその情報のソースを教えていただきたいです。 >(自分的にこの手の情報はsumimさんの日記くらいしか知らないので) アランケイの「メッセージ指向」は、C++の登場した当たりから軽視されるようになっていて、 現在のオブジェクト指向の実装や環境から考えると、誤解しやすい物になっているからです。 （ぱ）さんも「ただの関数呼び出し」と言っていますが、私もそう思います。 歴史に関してはウィキペディアに詳しく記載されています。 >＃できれば他にもSEさんが比較的マシだと思ってる本やWebページを >＃いろいろ教えていただきたいところですが オブジェクト指向自体の話ではありませんが、オブジェクト指向の間違いやすい所に関しては、 以下の記載がかなりいい所をついていると思います。（全て賛成できる訳ではありませんが） http://itpro.nikkeibp.co.jp/article/COLUMN/20060921/248617/?ST=develop&P=1

懐かしいお名前がいっぱいでうれしくなりました。 kitさんも >でも、そもそもデザインパターンの多くは、それなりのプログラマーだったら、 >自分で似たようなものを必要に応じて考えて既に使っているものですよね。 と書かれていますが、SEさんのご意見が、 「天下りに与えられたパターンを憶える（＝学習する？）んじゃなくて、 自分で同じものを作ってみるなりしてきちんと理解する（＝解析する？）べきだ」、 ということならば、賛成ですけどね。 議論の行く末が気になるので、SEさんにはまた登場していただきたいです。

>ちょっと穿って解釈すると、 > >　ちなみにデザインパターンは学習(に値)する(ような)物ではなく、 >　(こんなものを調子こいて使ってしまうとソースが読みにくくなって >　必死に)解析する(ハメになるような)物です。 > >という意味なんでしょうか。 > >そういう趣旨ならわからなくはないし、部分的には賛同しないでもないのですが、 なるほど。 勉強したばかりで調子にのって *必要ないのに* 使いすぎると、問題は問題ですね。 でも、そもそもデザインパターンの多くは、それなりのプログラマーだったら、 自分で似たようなものを必要に応じて考えて既に使っているものですよね。 各種パターン本の意義は、そういうものにきちんと名前をつけて、いちいち説明 しなくても意思の疎通を可能にするという側面が大きいわけです。これにはソース 中の名前づけを標準化して、可読性を高めることを含みます。 したがって、経験のあるプログラマーにとって、デザインパターンの学習という のは、既知の設計手法について、規範となる名前を学習するという意味になります。 また、デザインパターンとして標準化された名前を使うことによって、ソース等を 解析することなく (すなわち、名前を見ただけで) モジュールの役割を理解する ことが可能になります。 また、もちろん初学者にとっては、設計パターンを自分で一から考える手間を省く という学習の意義があります。 というわけで、もしそういう意味だったとしても、やっぱり賛成できませんねえ。

横から口を出しますけど、 >>そもそも OO (というか継承－派生というシステム) のおいしいところは >>・「基底クラスを使う人」と「派生クラスを作る人」が分離できる >>・基底クラス（のメンバー）を使う人は、派生クラスについて知らなくていい >>・派生クラスを作る人は、基底クラス側で期待している動作(=契約)に反しない限り、 >>　自動的に正しく使ってもらえる、と判断してよい >これが利点ですか？ちょっと他人に説明するのが難しいです。 前回私が例に出したLoggerクラスで考えると、 >>・「基底クラスを使う人」と「派生クラスを作る人」が分離できる 「Loggerクラスを使う人」は、logger.write()のようなメソッドを単に呼べばよく、 「ログをファイルに出力するFileLoggerクラスを作る人」と分離できる。 >>・基底クラス（のメンバー）を使う人は、派生クラスについて知らなくていい 「Loggerクラスを使う人」は、logger.write()のようなメソッドを単に呼べばよく、 FileLoggerクラスについては知らなくていい。 >>・派生クラスを作る人は、基底クラス側で期待している動作(=契約)に反しない限り、 >>　自動的に正しく使ってもらえる、と判断してよい 「FileLoggerクラスを作る人」は、基底クラス側で期待している動作(=契約)に 反しない限り、自動的に正しく使ってもらえる、と判断してよい わけで、私から見れば、774RRさんはごく普通にオブジェクト指向の利点を 挙げていると思うんですけど。 もちろん、何にでも利点と欠点はあるものですし、その重み付けは用途によって 変わります。SEさんの過去の業務で実装継承がすごく役に立ったのなら、 それはそれで興味深いことです。 だからこそ、実際に役に立ちそうな現実的な例を挙げていただきたいと思いますし、 上記774RRさんが挙げられたような利点をあまり重視しておられないように見える割に、 [1260]のUpperStackにおいて、getUpper()のようなメソッドを作らずにget()を オーバーライドしていたり、 [1270]で >>「要素をgetする側は、大文字が欲しいとき、そのことを意識しないで済む」 >>ということにしたいのでしょうか? という問いに対して >そうです。 と答えていたり、 同じく[1270]で new LinkedHashMap<String, String>()の戻り値を Map<String, String>型の変数に代入したりしている 意図がさっぱりわからないわけです。

kitさん、おひさしぶりです。 >>>ちなみにデザインパターンは学習する物ではなく、解析する物です。 >> >>？？ >>すみません、仰っておられる意味がわかりません…。 > >素直に解釈すると、SEさんは GoF本や PofEAA あたりも読んだことがないって >ことになります (こういった本を読むこと == デザインパターンを学習すること >ですから)。 私にもSEさんのおっしゃる意味はよくわからないのですが、ちょっと穿って解釈すると、 　ちなみにデザインパターンは学習(に値)する(ような)物ではなく、 　(こんなものを調子こいて使ってしまうとソースが読みにくくなって 　必死に)解析する(ハメになるような)物です。 という意味なんでしょうか。 そういう趣旨ならわからなくはないし、部分的には賛同しないでもないのですが、 もしそういう意図なら、もっとわかりやすく書いていただきたいです……

>こちらの返信が遅くなってしまいました。 いえいえ、お返事いただけるだけで嬉しいので、気にしないでゆっくりして下さい。 >(私の感覚では)かなり実用的な問題でして。 了解しました >また、ヘッダファイルの依存関係が漏洩するという問題もあるでしょう。 >あるライブラリがウインドウに絵を描いたりするのでprivateメンバで >windows.hで定義されている型などを使っていたりすると、それを使う人にまで >もれなくwindows.hがプレゼントされ名前空間が汚染されてしまったりとか。 賛同です。これは問題ですね。OOP以前C言語の時は、それはキッチリとヘッダーが きれいに分割され必要な所だけが#includeされていたのですが。OOPになって、 必要も無いようなヘッダーが次から次へと#includeされているのを見るのは、 正直止めてほしいと思っています。特にVCはひどい、プリコンパイルヘッダーを 作ったのは苦肉の策ではないかと疑ってしまうほどです。 　しかし、現実に自身が作っている内容でも、結局多くのヘッダーが#include してしまっているのを見るにつけ、何かの対策がほしいと思います。 >これを問題と思わない人が多かったようなので、私のような心配をするのは >少数派なのかもしれませんけれども。 私もそうですが、目をつぶっているだけなのかも知れません。 　ちょっと真剣に考えて見ます。軽はずみな返事をしたくないと思っているので ちょっと期間をくださ。今は、作っている言語仕様に頭がいっぱいなんです。 いま佳境に入ってて、最近はプログラムではなく仕様書の書き込み書き直しばか りしています。楽しくもあり苦しくもある時間です。 　いやほんと、こんな仕様を発表したら、けちょんけちょんにけなされっるので はないかとか、本当に良いんだろうかとか、でも当面第1弾はこれしかないよな～ とか、悩んだりしています。 　　今作っている言語そしてシステムの最大の目的は。 　　「簡単なルールを持った言語で、いかに複雑な処理を簡単に書けるか」 なので、熟練のプログラマーのほうが抵抗が大きいのではないかと… 　プログラミング言語というものは論理的に整然と矛盾が無く、どんな形でも 記述可能であり。その中においてさえ、書きやすくセーフティーな環境を提供し 見やすさを追求している、と私は思っています。でも、私が目指しているのは。 記述目的を限定することで、自由が無くなる分、普通では考えられないような 記述で複雑なものを簡単に記述すシステムを出してみたい。 　大風呂敷はこのへんで終わって、早く実物が出来るようにがんばります。

>>ちなみにデザインパターンは学習する物ではなく、解析する物です。 > >？？ >すみません、仰っておられる意味がわかりません…。 素直に解釈すると、SEさんは GoF本や PofEAA あたりも読んだことがないって ことになります (こういった本を読むこと == デザインパターンを学習すること ですから)。 そう解釈していいんですかね?

SEさんとの議論がアツいので、こちらの返信が遅くなってしまいました。 >　カプセル化という言葉に対して、きっちりとした完全な意味を求めてるのだ >ろうと思いますが、私はそこまでのことを意識してこの言葉を使っていません。 ええと、用語定義の問題と言うよりは、(私の感覚では)かなり実用的な問題でして。 >　必要なこと意外一切情報を出さないほうがいいのか。内部がある程度想像 >できるほうがいいのか？Cはたとえ使えなくともクラスのデータやメソッドが見 >える。これが良いか悪いかでしょう。私は後者のほうが気分的には良いです。 チームで開発するとき、ライブラリとそれを使うアプリケーションがあったとして、 これらを平行して開発することがあります。そういう場合、ライブラリの ヘッダファイルだけ先に作ってしまえばアプリケーション側のコンパイルが通せますが、 その時、空実装のメソッドを暫定で書いて後で差し替えるような作業は バージョン管理が面倒になるので避けたい。また、ヘッダファイルはドキュメント的な 性格も大きいですから、ここに実装やprivateメンバを書いてごちゃごちゃして しまうのも避けたい。 また、ヘッダファイルの依存関係が漏洩するという問題もあるでしょう。 あるライブラリがウインドウに絵を描いたりするのでprivateメンバで windows.hで定義されている型などを使っていたりすると、それを使う人にまで もれなくwindows.hがプレゼントされ名前空間が汚染されてしまったりとか。 ……という話題が昔JavaHouseであったとき、 http://java-house.jp/ml/archive/j-h-b/048357.html#body http://java-house.jp/ml/archive/j-h-b/048360.html#body これを問題と思わない人が多かったようなので、私のような心配をするのは 少数派なのかもしれませんけれども。 >　言語の設計において、理想的なものを作っていくのもあります。私の場合は >目的が実現できれば簡単なものでいいと思って設計しています。その代表が >#defineです。古い仕様で問題点も内包しますが、実に使いやすく融通が利きます。 >今では#defineはあまり良くないとされていますが、私は利点を選びました。 これは同意です。「わかって使う」分には、#defineは便利ですよね。

>大文字小文字の例が悪かったのか、話がそこから進まないようです。 では、よい例を出してもらえませんか。具体的な例なしでこの手の話をしても 意味がありません。 774RRさんへの返信に >例えば総合試験で性能目標に達しなかった場合、従来の方法では普通は大変更に >なりますが、オブジェクト指向の場合、一部のクラスの取得処理を変更しただけで >修正できた例もあります。 とありますが、これも具体的にどういうケースだったのかわかりません。 普通に考えて、どこかの処理がボトルネックになっていたのなら、そこだけ 書き直せば速くなるでしょう。もちろん、その処理がプログラムのあっちこっちに コピペされていれば大変更になるでしょうが、関数等に切り出されて一箇所に まとめられていれば修正するのは一箇所です。ここまではオブジェクト指向は 関係ありません。 オブジェクト指向であったがゆえにうまくいった、とのことなので、 関数化ではうまくいかないケースだったのでしょう。どういう理由で、関数化では うまくいかず、オブジェクト指向(実装継承?)でうまくいったのでしょうか。 仕事のソースをここに貼ることができないのはわかっていますが、概要だけでも 教えてもらえませんか。興味深いので。 >遠くの所でnewした特有の処理の入ったクラスを、引数で使い回すのは、 >構造化のスタンプ結合的で、オブジェクト指向的には良くない設計です。 オブジェクト指向の最大の特徴のひとつであるポリモルフィズムは、遠いところで newしたオブジェクトのメソッドを呼ぶと、呼ぶ側が意識しなくても、 そのオブジェクトに応じたメソッドが呼び出される、というものですよね? デザインパターンなどでは生成に関するパターンだけでいくつもあって、 うちいくつかは、具体的なクラスが何であるかを意識させないようにするための ものですし、DI(Dependency Injection)なんかも考え方はそっち方面です。 まあ、この手のことは、当面用途もないのに調子に乗って柔軟性を求めると ソースが追えなくなってしまうので、私はあまり好きではないのですけれど。 ありがちな例では、たとえばログを出力するLoggerクラスをabstractクラスもしくは interfaceとして作って、それを継承またはimplementsしてファイルに吐くLoggerや syslogに吐くLoggerを作ったりしますが、これは、遠く離れたところでnewした Loggerを引数等で持って回ることになると思うんですが。 >オブジェクト指向の場合は処理は関連するデータと共にクラスに >まとめられるため、その引数を必要とするメソッドを、引数のクラス内 >に実装できるか検討すべきです。 意味がわかりません。 さっきのLoggerの例で言えば、Loggerクラスを引数として受け取るメソッドは Loggerを使うアプリケーションですが、アプリケーションのメソッドを Loggerクラスの中に作れ、という主張……ではないですよね。 >>ひとつ伺いたいのですが、SEさんはどんな本でオブジェクト指向の勉強をされたの >>でしょうか。 こくぼさんからも質問が出ていますが、私もSEさんが「比較的マシ」だと思ってる 本やWebページを教えていただきたいです。

>ちなみにデザインパターンは学習する物ではなく、解析する物です。 ？？ すみません、仰っておられる意味がわかりません…。 >これもひどい内容ですね。 詳しく教えていただきたいのですが、 どこがひどいと思われるのでしょうか？ 「この当たりの話は知っています」と書かれていることから類似のWebページなどをご存知なのでしょうか。 できればその情報のソースを教えていただきたいです。 (自分的にこの手の情報はsumimさんの日記くらいしか知らないので) >これならまだ「ウィキペディア」の「オブジェクト指向プログラミング」の >方がマシです。 >一度読んでみてはいかがですか？ ありがとうございます。 読んでみます。 ＃できれば他にもSEさんが比較的マシだと思ってる本やWebページを ＃いろいろ教えていただきたいところですが

>デザインパターンを学習されているなら継承を使う機会は減ると思うんですけど。 >＃減るというか注意深くなるというか デザインパターンは知っています。 ちなみにデザインパターンは学習する物ではなく、解析する物です。 >ちなみにこのページはオブジェクト指向を学ぶうえにおいてとても参考になります。 >一読してみてください。 >http://d.hatena.ne.jp/sumim/20040525/p1 これもひどい内容ですね。 この当たりの話は知っていますが、参考にするのはまずいでしょう。 これならまだ「ウィキペディア」の「オブジェクト指向プログラミング」の 方がマシです。 一度読んでみてはいかがですか？

>俺も (ぱ) 氏ももっとマクロな＝大規模プログラムでの応用の話をしているわけです。 >そういうレベルでは、提示のコードのような派生はうまくいきません。 なぜ大規模プログラムでうまくいかないのかが分かりません。 実際、大規模プログラムで使用していますが、効果が出ています。 例えば総合試験で性能目標に達しなかった場合、従来の方法では普通は大変更に なりますが、オブジェクト指向の場合、一部のクラスの取得処理を変更しただけで 修正できた例もあります。 オブジェクト指向ではオブジェクト単位であるため、大きいレベルから小さいレベル まで対応できるのが特徴です。 >そもそも OO (というか継承－派生というシステム) のおいしいところは >・「基底クラスを使う人」と「派生クラスを作る人」が分離できる >・基底クラス（のメンバー）を使う人は、派生クラスについて知らなくていい >・派生クラスを作る人は、基底クラス側で期待している動作(=契約)に反しない限り、 >　自動的に正しく使ってもらえる、と判断してよい これが利点ですか？ちょっと他人に説明するのが難しいです。 私の例では、処理に大修正が入った場合（例えばDB変更や、ローカルファイルから 通信を使ったリモートファイルへの変更）、これだけの修正で済みますなどと 言えますが、上記の場合はどう説明しますか？ >んで、マルチプルインスタンスの件のほうはもういいのでしょうか？ >俺としては既に書いたとおり「対象読者層が異なる」というだけの話だと思っております。 了解しました。

スタックの例とかあんまり細かく見ずにコメントしますが…。 >それぞれ用途が違いますが、オブジェクト指向特有で強力なのが2,3です。 >別に全て2でやれと言っているわけではなく、2の使い方が出来るのが >利点だと言っている訳です。 >... >つまり、分かりやすいとか間違えやすいとか言う話は別として、 >4種類の変更方法を選択できるため、再利用性が高いと言っている訳です。 そもそも継承というメカニズムを使うのが間違いのもとになっちゃうような。 デザインパターンを学習されているなら継承を使う機会は減ると思うんですけど。 ＃減るというか注意深くなるというか >本は色々読みましたが、全てが同意できる物はありません。 となると、ここで力説されていらっしゃる実装継承を使ったOOP をどこから学ばれたのか興味深いですね。 ちなみにこのページはオブジェクト指向を学ぶうえにおいてとても参考になります。 一読してみてください。 http://d.hatena.ne.jp/sumim/20040525/p1

大文字小文字の例が悪かったのか、話がそこから進まないようです。 修正方法には以下の4つがあります。 ----------------------------------------------------------- 1.別名でメソッド追加 　別々の処理として追加したい場合に使用 2.継承 　関連処理をまとめて変更したい場合に使用 3.分割して親クラスを継承 　関連処理をグループ化して、片方のグループを変更したい場合に使用 4.staticメソッドを作成 　関連のない任意の場所で使用したい場合に使用 ----------------------------------------------------------- それぞれ用途が違いますが、オブジェクト指向特有で強力なのが2,3です。 別に全て2でやれと言っているわけではなく、2の使い方が出来るのが 利点だと言っている訳です。 間違いやすいとか分かりにくいと言うのは、実装者のスキルの話で、 よく見て追えば分かるし、変な設計をすれば分かりにくくなります。 遠くの所でnewした特有の処理の入ったクラスを、引数で使い回すのは、 構造化のスタンプ結合的で、オブジェクト指向的には良くない設計です。 オブジェクト指向の場合は処理は関連するデータと共にクラスに まとめられるため、その引数を必要とするメソッドを、引数のクラス内 に実装できるか検討すべきです。 つまり、分かりやすいとか間違えやすいとか言う話は別として、 4種類の変更方法を選択できるため、再利用性が高いと言っている訳です。 >ひとつ伺いたいのですが、SEさんはどんな本でオブジェクト指向の勉強をされたの >でしょうか。 本は色々読みましたが、全てが同意できる物はありません。 殆どが、オブジェクト指向と言いつつ、デザインパターンの説明本や、UMLの説明本、 プログラミング言語の小技本、翻訳がおかしい本、中にはWEBアプリケーションの 作り方本もありました。 WEBサイトも同意できる物もあれば、出来ない物もあり、半々ぐらいです。 オブジェクト指向関係の書籍のひどさは、(ぱ)さんもご存じだと思います。

# 題名にハンドル入れるのやめてほしい > SE 氏 変えちゃいました # [1269] に返信してもよかったんだけどこっちにつなぐことにする [1269] > これを次のように変更します。1行で済みます。 ものすごく近視眼的コメントがついていて思わず苦笑してしまったのだけど、 *** そういう範囲でしか変更がありえない **** のであれば [1260] [1269] で提示のような修正もまぁあり、の範疇に収まります。 が、実世界においてはそういう局所な話ですまないことのほうが多く、 俺も (ぱ) 氏ももっとマクロな＝大規模プログラムでの応用の話をしているわけです。 そういうレベルでは、提示のコードのような派生はうまくいきません。 そもそも OO (というか継承－派生というシステム) のおいしいところは ・「基底クラスを使う人」と「派生クラスを作る人」が分離できる ・基底クラス（のメンバー）を使う人は、派生クラスについて知らなくていい ・派生クラスを作る人は、基底クラス側で期待している動作(=契約)に反しない限り、 　自動的に正しく使ってもらえる、と判断してよい という点にあるのであって、 決して「ソースの再利用のためのテクニック」ではないのです。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&thread=270 このへんとか。 基底クラスを使っている側にとって 基底クラス側が本来期待している挙動と異なる動きをするような派生クラス というのはまずいのです。 しかも、基底クラスユーザと派生クラス作者はたいてい別人なのです。 基底クラスを使うソースファイルと派生クラスを作るソースファイルも別ファイルなのです。 [あたかも便利そうに見える] [が、正しく設計されているとは必ずしも言い切れない] 派生クラスを安直に作り、使ってしまうと 異なる開発者がいて、複数のファイルから構成されていて、各プログラマは自分の担当範囲しか理解しきれない という大規模開発では見えにくい/直しにくいバグの元となります。 LSP (Liskov Substitution Principle) という概念も、この辺から来ています。 んで、マルチプルインスタンスの件のほうはもういいのでしょうか？ 俺としては既に書いたとおり「対象読者層が異なる」というだけの話だと思っております。

# どうもサーバの調子が悪いようで…… まずSEさんにお願いですが、投稿に返信を付ける際には各投稿の右上にある 「返信」リンクを使ってください。そうすることでスレッドがつながりますので [この投稿を含むスレッドを表示]をクリックすると関連する投稿をまとめて 読むことができます。 この掲示板の上のほうにある「スレッド順インデックス」をクリックすると、 他の投稿はちゃんとスレッドがつながっているのに、SEさんの投稿だけ 切り離されていることがわかるでしょう。 http://kmaebashi.com/bbs/thread.php?boardid=kmaebashibbs >>まあ、オセロの例で注記したように、マルチプロセスにはオブジェクト指向と似た面は >>ありますけど。「その論理で行くと」の「その論理」がどういう論理か、教えて >>いただきたいです。 >「マルチプルインスタンスがオブジェクト指向」と言う論理です。 >マルチプルインスタンスと言うのが何を指すのがよく分かりませんが、 >状態（内部の変数の値）の違う複数の処理群（クラス）と解釈しました。 「状態（内部の変数の値）の違う複数の"オブジェクト"」ですよね? まあ、クラスベースのオブジェクト指向ではオブジェクトの生成の雛形として クラスを使うわけで、「疑りぶかい～」ではクラスベースのオブジェクト指向の 話しかしていないわけですけれども。 実のところオブジェクト指向という用語は定義などないも同然なのですが、 「状態（内部の変数の値）の違う複数の"オブジェクト"を持てること」が たいていのオブジェクト指向の定義の必要条件である、ぐらいのことはたぶん 言ってもよいでしょう。 で、そうするとなぜ「マルチプロセスやマルチスレッドはオブジェクト指向になる」 のですか? 「DOSを乗っけたPCを2台もってこれば同時に複数のプログラムを動かせるので、 DOSはマルチプロセスだ!」という主張は誰もしないと思いますけど。 >>・Stackが引数かなにかで渡されたとき、本家StackなのかUpperStackなのかわからなくて危険。 >引数の型を見れば分かると思います。 void hoge(Stack s) { …… } というメソッドがあったとき、sがStackなのかUpperStackなのかは 「わからない」と思いますが? >>・別の誰かがLowerStackを作ったら、いつかマージするの? >もし別機能として作るなら、Stackを継承してLowerStackを作ります。 >例えば大文字にした後に先頭に0を付加するような、UpperStackの処理結果に追加する物なら、 >UpperStackを継承して作ります。 >すでにLowerStackが出来てしまっているならマージしません。 で、同一インスタンスのスタックに放り込んだデータについて、ある場所では 大文字で取り出したいし、ある場所では小文字で取り出したい、という場合、 どのクラスを使えばよいのですか? >>「要素をgetする側は、大文字が欲しいとき、そのことを意識しないで済む」 >>ということにしたいのでしょうか? >そうです。 だとすれば比較対象にget(boolean up)を持ってきているのはおかしいですね。 get(boolean up)を使う人は、大文字が欲しいとき、意識して引数にtrueを 渡さなければならないからです。 774RRさんへの返信に >ダウンキャストでなく、newするときに新しいクラスを使うと考えてください。 とありますが、(かなり離れた場所でnewされたかもしれない)Stackが UpperStackなのかStackなのかを意識しなければ、UpperStackのget()を 便利に使うことはできません。SEさんの主張は矛盾しています。 >>この改修により、プログラムにUpperStackという「異物」が実行時に紛れ込むわけで、 >>「Stackにputしたんだから、当然同じものがgetできるだろう」と思い込んでいる >>既存コード(Stackそのものを含む)にはおもいっきり影響を与えます。 >既存コードはソースに手を入れないので、影響はないと思いますが。 既存コードに引数でUpperStackを渡したら、入れたものを勝手に大文字に 変換するおかしなStackが紛れ込むことになります。ここではそういうことを 書いています。 >もう少し分かりやすい例をあげます。 Javaのコレクションクラスライブラリは、StackがVectorを継承していたりして いろいろトホホなので、「良い例」として出せるものではないと思います。 現実的に許容範囲内の例ではあるかもしれませんけど。 で、LinkedHashMapやTreeMapですが、これらがHashMapを継承してしまったために、 ・同じコレクションに対し、ある時は入力順に表示したいし、ある時は ソートして表示したい、という場合どうすればよいのか? (要件としてはすごくありそうだと思いますけれども) ・サブクラスにアクセスさせるために、HashMapのフィールドであるtableが 　パッケージアクセスになってしまっているがこれはカプセル化の破壊では 　ないのか。 (protectedにしなかったのはSunのエンジニアの良識だと思います) ・ていうかLikedHashMapではaddEntryとかcreateEntryとかパッケージアクセスの メソッドをばんばんオーバーライドしているけれど大丈夫か(スーパークラスの 実装に強く依存している)。 といった問題があるわけです。 それでもまあなんとか「現実的に許容範囲」なのは、オーバーライドした メソッドが、スーパークラス側のメソッドに対し「最低限同等の責務を果たす」と いうオーバーライドにおける大原則を守っているからでしょう。 その点においてもSEさんのUpperStackはだめです。同じget()でありながら、 勝手に大文字に変換してしまうためです。 で、 >Map<String, String> mp = new LinkedHashMap<String, String>(); ここでMapに代入しているのはなぜですか? 入力順に出てくることを期待するのなら、LinkedHashMapのまま持ち歩くほうが 安全です。あるMapがLinkedHashMapのつもりだったのに実はそうでなかった、 というケースは、プログラムが大きくなって、newする場所と使う場所が離れれば 離れるほどいくらでも発生することです。そうなってしまえば、入力順に 取り出せないのですから致命的な上、コンパイルエラーどころか実行時のエラーも出ず、 黙って間違った順番でデータを吐き続けることになります。 これを避けるには、ダウンキャストするか、instanceofでクラスを確認する 必要があるでしょう。危険ですけれども。774RRさんがおっしゃっているのは そういうことです。 Mapに代入するメリットと言えば、たとえばMapの中身をダンプする void dumpMap(Map m);というメソッドに対し、LinkedHashMapを渡せば 入力順に表示されるしTreeMapを渡せばソートして表示される、という動きを 期待したいときでしょう。でもこれは、dumpMap()という既存メソッドに 新たに開発したオブジェクトを混入させることに他ならず、それでうまく 動くかどうかは保証の限りではありません。『「異物」が実行時に紛れ込む』と 書いたのはそういうことです。 # これをうまく動かすためには、やはり先ほどの「オーバーライドにおける大原則」 # を守る必要があるわけです。 で、 >ひとつ伺いたいのですが、SEさんはどんな本でオブジェクト指向の勉強をされたの >でしょうか。 これについては答えていただけないのでしょうか。ぜひ書名を教えて欲しいのですけれども。

>まあ、オセロの例で注記したように、マルチプロセスにはオブジェクト指向と似た面は >ありますけど。「その論理で行くと」の「その論理」がどういう論理か、教えて >いただきたいです。 「マルチプルインスタンスがオブジェクト指向」と言う論理です。 マルチプルインスタンスと言うのが何を指すのがよく分かりませんが、 状態（内部の変数の値）の違う複数の処理群（クラス）と解釈しました。 >そこでわざわざ継承してクラスを作ったって、以下のような問題が起きるだけです。 >・Stackが引数かなにかで渡されたとき、本家StackなのかUpperStackなのかわからなくて危険。 引数の型を見れば分かると思います。 >・別の誰かがLowerStackを作ったら、いつかマージするの? もし別機能として作るなら、Stackを継承してLowerStackを作ります。 例えば大文字にした後に先頭に0を付加するような、UpperStackの処理結果に追加する物なら、 UpperStackを継承して作ります。 すでにLowerStackが出来てしまっているならマージしません。 >「要素をgetする側は、大文字が欲しいとき、そのことを意識しないで済む」 >ということにしたいのでしょうか? そうです。 >この改修により、プログラムにUpperStackという「異物」が実行時に紛れ込むわけで、 >「Stackにputしたんだから、当然同じものがgetできるだろう」と思い込んでいる >既存コード(Stackそのものを含む)にはおもいっきり影響を与えます。 既存コードはソースに手を入れないので、影響はないと思いますが。 新たに作るコードはどちらを使うか意識する必要はありますが。 >上のほうで『実のところ「要素を大文字に変換して返すスタック」がどんな時に >役に立つのか想像できません』と書きましたが、結城浩さんが「例は嘘をつかない」 >と書いておられるように、こういうところで現実のプログラムに即した適切な例が >出てこないなら、おそらくそれは考え方のほうが間違っています。 もう少し分かりやすい例をあげます。 --------------------------------------------------------------------- Map<String, String> mp = new HashMap<String, String>(); mp.put("aa", "11"); mp.put("cc", "33"); mp.put("bb", "22"); for(String key : mp.keySet()){ 　　System.out.println(key); } --------------------------------------------------------------------- 入力した順番に表示したい場合 --------------------------------------------------------------------- Map<String, String> mp = new LinkedHashMap<String, String>(); mp.put("aa", "11"); mp.put("cc", "33"); mp.put("bb", "22"); for(String key : mp.keySet()){ 　　System.out.println(key); } --------------------------------------------------------------------- ソート表示したい場合 --------------------------------------------------------------------- Map<String, String> mp = new TreeMap<String, String>(); mp.put("aa", "11"); mp.put("cc", "33"); mp.put("bb", "22"); for(String key : mp.keySet()){ 　　System.out.println(key); } ---------------------------------------------------------------------

>あえて言わせていただくと、提示例はやっちゃダメな「実装継承」の典型例であって >俺の後輩君がこんなコードかいてたら０点つけるですよ。 大文字変換は何かしらの処理の例として出したので、getで何かの処理を行った結果を返すと考えてください。 >これは、実体が Stack であるインスタンスに対して UpperStack にダウンキャストして使う、としか読めない。 >そんな危険なことをさせるわけにはいかないと思うのだが。 ダウンキャストでなく、newするときに新しいクラスを使うと考えてください。 --------------------------------------------------------------------- Stack st = new Stack(); st.put("aa"); st.put("bb"); st.put("cc"); System.out.println(st.get()); System.out.println(st.get()); System.out.println(st.get()); --------------------------------------------------------------------- これを次のように変更します。1行で済みます。 --------------------------------------------------------------------- UpperStack st = new UpperStack(); st.put("aa"); st.put("bb"); st.put("cc"); System.out.println(st.get()); System.out.println(st.get()); System.out.println(st.get()); ---------------------------------------------------------------------

Kmyaccを使用していましたが、エラー復帰がうまくいかず。1回の構文エラーで yaccが終了してしまう問題を抱えてしまいました。いろいろ調査したが、どう にも情報が見つからなかったため、Bisonに変更。問題なくエラー処理および エラー復帰が出来るようになりました。堅牢なシステムへまた1歩です。

>これなんですが、C++だと、privateなメンバ変数とかは、外から参照すれば >コンパイラにエラーで怒られるとはいうものの、.hファイル中には記述されて >しまいますよね。 　カプセル化という言葉に対して、きっちりとした完全な意味を求めてるのだ ろうと思いますが、私はそこまでのことを意識してこの言葉を使っていません。 問題は。 　必要なこと意外一切情報を出さないほうがいいのか。内部がある程度想像 できるほうがいいのか？Cはたとえ使えなくともクラスのデータやメソッドが見 える。これが良いか悪いかでしょう。私は後者のほうが気分的には良いです。 使わない情報が見えたとしても、実質的にカプセル化されていれば問題ないと 考えます。 　言語の設計において、理想的なものを作っていくのもあります。私の場合は 目的が実現できれば簡単なものでいいと思って設計しています。その代表が #defineです。古い仕様で問題点も内包しますが、実に使いやすく融通が利きます。 今では#defineはあまり良くないとされていますが、私は利点を選びました。

>　私にとってOOPを使う最大の理由は。 > >　「カプセル化により見透視のよさ！」これに尽きます。 これなんですが、C++だと、privateなメンバ変数とかは、外から参照すれば コンパイラにエラーで怒られるとはいうものの、.hファイル中には記述されて しまいますよね。Javaだとメソッドの実装も書くことになるのでもっと深刻です。 これでは利用者側の再コンパイルが必要になりますし、ライブラリの実装が 終わる前にアプリケーションを作り始めたいという場合にも困る、ということで、 (Javaで言えば)インタフェースのみ公開してHogeImplみたいなクラスを作る、 なんてパターンが知られています。 私にはこれは必須に思えるので、Diksamではもうちょっと言語で積極的に サポートしたかったんですけどね。うまい文法が思いつかずにJavaと同等に なってしまっています。うーん、いつかそのうち。

>その論理で行くと、マルチプロセスやマルチスレッドはオブジェクト指向になると >思いますが、 ならないと思いますが…… まあ、オセロの例で注記したように、マルチプロセスにはオブジェクト指向と似た面は ありますけど。「その論理で行くと」の「その論理」がどういう論理か、教えて いただきたいです。 >例えばこれを修正して、大文字に変換して返す物を使いたいとします。 >----------------------------------------------------------- >public class UpperStack extends Stack { >　　public String get(){ >　　　　return super.get().toUpperCase(); >　　} >} >----------------------------------------------------------- 774RRさんがすでに書いていますけど、これは典型的な「ダメな実装継承の例」でしょう。 # 「実装継承」でGoogleしてみることをお勧めします。 実のところ「要素を大文字に変換して返すスタック」がどんな時に役に立つのか 想像できませんが、それはまあ、「あくまで例だから」ということにしても、 このケースは、 「要素をgetする側は、大文字が欲しいとき、そのことを意識している」 のでしょうか。 意識しているのであれば、そもそも「stack.get().toUpperCase();」で済む話です。 大文字に変換する、という単純な処理でないのなら、ユーティリティメソッドを 作ればよいでしょう。 そこでわざわざ継承してクラスを作ったって、以下のような問題が起きるだけです。 ・Stackが引数かなにかで渡されたとき、本家StackなのかUpperStackなのか 　わからなくて危険。 ・別の誰かがLowerStackを作ったら、いつかマージするの? ・ユーティリティメソッドではprivateメンバにアクセスできないが、 　継承なら、protectedにしておけばサブクラスからアクセスできる、というのが 　趣旨なら、それはカプセル化の破壊以外の何者でもない。 ところで、SEさんの例では、get()メソッドがオーバーライドされています。 「要素をgetする側は、大文字が欲しいとき、そのことを意識している」のであれば、 仮に継承を使うとしても、getUpper()メソッドをつけることでしょう。 オーバーライドしているということは、 「要素をgetする側は、大文字が欲しいとき、そのことを意識しないで済む」 ということにしたいのでしょうか? # それにしては、get(boolean up)と対比しているのでよくわかりませんが。 もしそうなら、 >そのため、変更により以前の機能のまま使用したい場所には影響がありません。 というわけにはいきません。 この改修により、プログラムにUpperStackという「異物」が実行時に紛れ込むわけで、 「Stackにputしたんだから、当然同じものがgetできるだろう」と思い込んでいる 既存コード(Stackそのものを含む)にはおもいっきり影響を与えます。 しかも、get(boolean up)とは違い、実際に動かしてみなければ検出できない バグになりますからさらにタチが悪いです。 上のほうで『実のところ「要素を大文字に変換して返すスタック」がどんな時に 役に立つのか想像できません』と書きましたが、結城浩さんが「例は嘘をつかない」 と書いておられるように、こういうところで現実のプログラムに即した適切な例が 出てこないなら、おそらくそれは考え方のほうが間違っています。 ひとつ伺いたいのですが、SEさんはどんな本でオブジェクト指向の勉強をされたの でしょうか。 いまどきこんなバリバリの実装継承でオブジェクト指向を説明している教科書は そうそうないと思っていたので、もし新しい本にそういうことが書いてあったのなら 興味があります。ぜひ書名を教えてください。 ところで、私が現在作っているクラスベースオブジェクト指向言語Diksamでは、 「concreteクラスは継承できない」ということにしてしまっています。これは 実装の手抜きではなく、意図して行っています。 ここまでやってしまうと異論はあるかもしれませんが、Effective Javaとか GoFのデザパタ本とかで、かなり昔から、散々「抽象クラス以外は継承するな」と 言われてますし、SEさんのような誤解を防止するためにもこの方がよいのではないかと。 http://java-house.jp/ml/archive/j-h-b/050862.html

原因は不明ですが、しばらくこの掲示板が投稿できない状態になっていました。 閲覧は通常通り可能でしたが、送信ボタンを押してもプレビュー画面に遷移しない、という状態でした。 それでしばらくテスト掲示板で様子を見ていましたが、どうも直ったようです。

　yacc,lecの修正とプリプロセッサの作成が終わりました。ファイルの多重#includeと 多重の#define宣言を処理できるようになりました。 　次の3つのファイルをt001.dkmで起動すると。 --ファイルt001.dkm--------------------------- // aaaaaaaa #include "t001-01.dkm" #define DEF1 DEF2 + "def1 " // aa int main() { string str; str = DEF1; str = DEF2; str = DEF3; } --ファイルt001-01.dkm------------------------ //ssssssssssss #define DEF2 DEF3 + "def2 " // bb #include "t001-02.dkm" //aaaa int print (string str); --ファイルt001-02.dkm------------------------ //ssssssssssss #define DEF3 "def3 " // cc int printnl(string str) { print(str + "\n"); } ------------------------------------- 　　↓ 　プリプロセッサ 　　↓ ------------------------------------- int printnl (string str ) { print (str +"\n"); } int print (string str ); int main () { string str ; str ="def3 "+"def2 "+"def1 " ; str ="def3 "+"def2 " ; str ="def3 " ; } ------------------------------------- 　になってコンパイラに渡されます。もちろんメモリ渡し、エラーもファイル名＋行番号で出さ れます。コメントやインデントは内部的に不要なので無くなっています。 　最上位の制御構造がマルチスレッドを意識した構造を作りこみ、コンパイラは単独で動作する 構造になりつつあります。ジェネレータは関数単位で実行される予定です。 　これでようやく中断前に戻れます。 　関数のリンクは総て動的リンクにする予定です。最初の1回だけ動的リンクが行われ、その後 コンパイラが起動されるか、中間コードが破棄された時のみ再度動的リンク試験が行われます。 これでほとんどの関数コールは、直接起動されることになり。スピード的に問題ないと思って います。

　私にとってOOPを使う最大の理由は。 　「カプセル化により見透視のよさ！」これに尽きます。 　継承や多態化はそのサポートのために。再利用性は設計の問題であり。OOとは 関係が薄い場合がある。ただし、OOを使っても見透視の悪いコードはいくらでも かける。が、よく整理されたクラスの見透視の良さは、OOが無い言語に比べて 格段にいい。

「再入門」のそのあたりの記述は、そもそも「インスタンスが複数あっていい」というあたりを理解していないプログラマ向けの文書。 SE氏の指摘は「インスタンスが複数あるのは当たり前」と理解しているプログラマの視点なわけで。 そういう意味で、対象読者層が異なるだけのことだと思う。 あえて言わせていただくと、提示例はやっちゃダメな「実装継承」の典型例であって 俺の後輩君がこんなコードかいてたら０点つけるですよ。 > そして、大文字で取得したい場所では、このUpperStackを使うようにします。 これは、実体が Stack であるインスタンスに対して UpperStack にダウンキャストして使う、としか読めない。 そんな危険なことをさせるわけにはいかないと思うのだが。

疑りぶかいあなたのための「オブジェクト指向再入門」を読みました。 部分的に同意できる所もありますが、オブジェクト指向の「本質」はマルチプル インスタンスだと言うのは全く違うと思います。 その論理で行くと、マルチプロセスやマルチスレッドはオブジェクト指向になると 思いますが、これらはオブジェクト指向云々以前から存在する、別の話だと思います。 オブジェクト指向プログラミングの利点は、 「変更がしやすい」事と「変更しても以前の機能が失われない」事です。 簡単に説明します。 先入れ後出し形式のデータ（スタック）をクラス化したとします。 エラー処理を考慮しなければ、大体以下のようになるでしょう。 ----------------------------------------------------------- public class Stack { 　　private String[] data = new String[100]; 　　private int index = 0; 　　public Stack(){ 　　} 　　public void put(String val){ 　　　　data[index] = new String(val); 　　　　index++; 　　} 　　public String get(){ 　　　　String ret = ""; 　　　　index--; 　　　　ret = data[index]; 　　　　return ret; 　　} } ----------------------------------------------------------- 例えばこれを修正して、大文字に変換して返す物を使いたいとします。 ----------------------------------------------------------- public class UpperStack extends Stack { 　　public String get(){ 　　　　return super.get().toUpperCase(); 　　} } ----------------------------------------------------------- そして、大文字で取得したい場所では、このUpperStackを使うようにします。 ここで重要なのは、基のクラスのStackには全く修正が入らない事です。 そのため、変更により以前の機能のまま使用したい場所には影響がありません。 ちなみに、Stackに別名の大文字で返すメソッドを追加すると言う方法もありますが、 基のソースに修正が入るため、デグレートの危険が発生します。 やたらに継承をしたくない場合は、それでも構いませんが、以下の方式はダメです。 ----------------------------------------------------------- public class Stack { 　　private String[] data = new String[100]; 　　private int index = 0; 　　public Stack(){ 　　} 　　public void put(String val){ 　　　　data[index] = new String(val); 　　　　index++; 　　} 　　public String get(boolean up){ 　　　　String ret = ""; 　　　　index--; 　　　　if(up){ 　　　　　　ret = data[index].toUpperCase(); 　　　　}else{ 　　　　　　ret = data[index]; 　　　　} 　　　　return ret; 　　} } ----------------------------------------------------------- なぜダメかは、構造化プログラミングを行っていて、度重なる修正で スパゲッティープログラム化しているのを見た事のある人なら分かるでしょう。 これを使用している所で、変更の必要ない既存部分にも手が入り、処理にも分岐が 入って複雑化するためです。 適切にオブジェクト指向プログラミングされていれば、修正が入っても劣化せず、 むしろ抽象化され使いやすいクラスになっていきます。 オブジェクト指向プログラミングの目的はこれだけです。 カプセル化、継承や多態化もこれを実現するための手段に過ぎません。 そのため「オブジェクト指向の目的は、再利用性を高める事」は正しいです。 しかしこの場合の再利用性は、関数化などの話ではなく、変更の時の使いやすさを 指しています。 新人が誤解するので「オブジェクト指向はマルチプルインスタンス」と言う記述は 修正か注意書きをしてほしいです。

>>　見間違いかもしれないけど、0.2.0はメモリーストレージを使ってないような･･･ >見間違いかと思います (^^; >了解しました、構文解析の所を今見た所確かにそうです。失礼いたしました。 >しかし、以前メモリートラブルでと話したとき、いつもmallocの中でこけてた >んです。 補足ですが、構文解析部分はMEM_Storageを使用してまとめて開放していますが、 コンパイルにより作られるDVM_Executableは各オブジェクトを個々にMEM_malloc()して 作っています。こちらは、配列のオーバーランなどすると、次のmalloc()で こける可能性が高いと思います(いまどきはそうでもないかも)。 malloc()で確保した領域を配列のオーバーランで壊したことを検出するために、 MEMではアプリケーションに渡す領域の前後を0xCDで埋めていて、これをチェックする 関数MEM_check_all_blocks()を用意しています。実際これでバグを見つけたことも 多いのですが、最近はLinux環境ではとっととvalgrindを使っていたりします。 Windowsで、フリーなvalgrind相当品があるかどうかは不勉強にて知りません。

>見間違いかと思います (^^; 了解しました、構文解析の所を今見た所確かにそうです。失礼いたしました。 しかし、以前メモリートラブルでと話したとき、いつもmallocの中でこけてた んです。それで思い違いをしたかな、結局追いきれなくてあきらめたんですけ ど。いや、相当粘ったんですよこれでも… >fix_tree.cでは主にTypeSpecifierを解析木に付加しますが、おっしゃるとおり、 >たとえばある式がintのTypeSpecifierを持っていて、それにマイナス演算子を適用した >このへんのことは以下にちょっとだけ書いてありました。 了解しました、と言うかまとめて開放だから無問題です。単に私がちょっとfixtree で手間取ったのが、それが理由だったんです。結局、メモリー監視デバックルーチ ンが、shared_ptrのような機能を持ってメモリー管理になってしまいましたんです。 もともとスマートポインターは重いからやめようと思ってた矢先の出来事で。 ええ、Boostのpoolに変えます… >「一番外側のブロック」ではなく、その名のとおり「現在のブロック」です。 了解しました。実はコメントを書き換えなおすの忘れてた。昔のままだった。 何も考えずに、有るのそのままコピペしてました。 >> ST_MemberExpression member_expression; // 使用していない？ >クラスを導入していないver.0.2では確かに使っていませんね。 了解しました。ありがとうございます。これなんだろう？調べなきゃと思っていました。

>　見間違いかもしれないけど、0.2.0はメモリーストレージを使ってないような･･･ 見間違いかと思います (^^; create.cで解析木のノードを確保する際も、fix_tree.cで主にTypeSpecifierを 確保する際も、最終的にはdkc_malloc()を呼んでいますし、dkc_malloc()は コンパイラが保持してるMEM_Storageを使用してメモリ確保しています。 http://kmaebashi.com/programmer/devlang/diksam_src_0_2/S/11.html#22 >　実は、構文解析で構文ツリーが出来た時点では、TOPのCT_Compilerのオブジェクトを >deleteすればディストラクタ繋がりできれいに総てのメモリーを解放できたのですが >Fixtreeを作ってみると、多重リンクはするはリンクが切れてフリーが山ほど出てくる >はで。 fix_tree.cでは主にTypeSpecifierを解析木に付加しますが、おっしゃるとおり、 たとえばある式がintのTypeSpecifierを持っていて、それにマイナス演算子を適用した ような場合には、マイナス演算子の式のTypeSpecifierは、その子ノードのものを 直接使用していたはずです(多重リンク)。また、[]演算子を適用するとTypeDeriveが 1段階外されますが、この時、[]演算子のノードのTypeSpecifierは、TypeDeriveの 連結リストの途中のノードを指します(その下のノードでは根元を参照していますが)。 このへんのことは以下にちょっとだけ書いてありました。 http://kmaebashi.com/programmer/devlang/diksam_0_1_comp.html | コンパイル時のTypeSpecifierは、なにしろ解析木のすべての式のノードに | 割り当てられます。たとえば「a + 1」という式がありaがint型の時、 | intを表現するためのTypeSpecifierが(「a」と「1」と「a + 1」のために) | (現状の実装では)3つ確保されています。でもよく考えれば「a + 1」のノードの | TypeSpecifier は左辺か右辺かどっちかのを直接参照してもよいはずで、 | 実際マイナス演算子ではそうしています。 | このように、TypeSpecifier構造体は、誰が所有者なのかわけがわからんような | こんがらがった参照で保持されているので、解析木の他の部分同様、 | コンパイル終了時に(MEM_Storageの機能を使用して)一括で破棄しています。 >class CT_Compiler : public CBase >{ >public: > CT_Block * current_block; // 一番外側のブロック 微妙に気になるのですが、current_blockは、少なくとも元のソースでは、 「一番外側のブロック」ではなく、その名のとおり「現在のブロック」です。 create.cにおいてBlockを生成する際に、親のブロックへの参照をセットするために 使用しています。 >class CT_Expression : public CBase >{ ... > union { > ST_MemberExpression member_expression; // 　　　使用していない？ これは、オブジェクトのメンバを参照するためのノードですが、 クラスを導入していないver.0.2では確かに使っていませんね。 ていうかソースには一応入っていたことに私の方が驚きました。

お疲れ様です。返事をもらえると嬉しいのですが、ごゆっくりどうぞ。 　↓のクラスを見てわかるとおりに、ほとんどstructをクラスにしたままです。内部 データが少し変わっていますが、structの全体接続構造はほとんどそのままです。 　私も意味もなくポリモルフィズムするのは好きではないし。本来の目的は クラスでパッキングして見通しを良くしよう。そして、書くことによる自身の 理解、そして必要機能の追加のためです。それと、diksamもほぼ同じ量のメモリー 確保をしていますよ。 　見間違いかもしれないけど、0.2.0はメモリーストレージを使ってないような･･･ class CT_Compiler : public CBase { public: int function_count; // 関数の数 CT_FunctionDefinition * function_list; // 関数のリスト CT_DeclarationList * declaration_list; // トップの宣言リスト CT_StatementList * statement_list; // トップのステートメントのリスト CT_Block * current_block; // 一番外側のブロック //== 式のツリーノード =========================================== class CT_Expression : public CBase { public: CT_TypeSpecifier *type; // E_ExpressionKind kind; // 式の種類 int line_number; union { E_Boolean boolean_value; // boolデータ　リテラル int int_value; // intデータ　リテラル double double_value; // doubeデータ　リテラル string *string_value; // stringデータ　リテラル ST_IdentifierExpression identifier; // 関数又は宣言文の識別子 ST_CommaExpression comma; // カンマ(,)式 ST_AssignExpression assign_expression; // 代入式 ST_BinaryExpression binary_expression; // 演算式 CT_Expression *minus_expression; // マイナス式 CT_Expression *logical_not; // 論理否定式 ST_FunctionCallExpression function_call_expression; // 関数式 ST_MemberExpression member_expression; // 　　　使用していない？ CT_ExpressionList *array_literal; // 配列データ　リテラル ST_IndexExpression index_expression; // 配列の添え字式 ST_IncrementOrDecrement inc_dec; // ++,--,式 ST_CastExpression cast; // キャスト演算式 ST_ArrayCreation array_creation; // 配列生成式 } u; 　実は、構文解析で構文ツリーが出来た時点では、TOPのCT_Compilerのオブジェクトを deleteすればディストラクタ繋がりできれいに総てのメモリーを解放できたのですが Fixtreeを作ってみると、多重リンクはするはリンクが切れてフリーが山ほど出てくる はで。メモリー監視・チェック・報告のデバックプログラムが、一躍メモリー管理 プログラムに昇格して、多重リンクや放置されたメモリーを管理して、きれいに掃除 することになりました。思わぬ副作用が･･･ 　今大改造中で動かせなかったのですが、構文解析時点で5千数百のnewをしていました。 　実は、ジェネレータとVM部分を始めていたのですが、ほしい仕様のための変更部分が 目立って見えてきたため、yacc,lex部分から大きく改造を始めてしまいました。 いま、#include　#define　構文の追加と最外枠のステートメント禁止、main()関数起動 を組み込み始めました。そして上の二つの構文のためにプリプロセッサを書いています。 だから、コンパイルは+1増えて4ステージになりました。#includeは単に外部ファイルを 同一ファイルとしてコンパイルできる普通の機能です。でも、その為にライン数管理が ファイル名+ライン数になってその部分が全体的改造に。 　本当は、一通り終わるまで新機能は入れないつもりでしたが、チョコチョコ変えている 時点で、もう全体変更しようと思ってしまった。

世間では連休で私も会社は休みだったはずですが何かとどたばたしてまして お返事が遅れましてすみません。 >　ちなみに、test.dkmで最高6800ぐらいnewします。 これで速度低下しないかと心配して、crowbarやDiksamではMEMモジュールを作って MEM_storage_malloc()を使ったのですが、C++でクラスを使おうとすると単純に 置き換えはできませんね(newのオーバーロードで置き換えはできますが、私には、 演算子のオーバーロード自体相当に腰が引けます。boostのように、汎用的で 一般的に知られたライブラリを使うのなら、だいぶ軽減されると思いますけど)。 ところで、DiksamをC++で書き直し、fix_tree.cppでたくさんnewが起きるということは、 DiksamでのExpressionやStatementの構造体をクラスにしておられるのだと思いますが、 これはやっぱり、fix_tree.cppではfix()、generate.cppではgenerate()という メンバ関数を作って、クラスごとにポリモルフィズムで呼び出しているのでしょうか? オブジェクト指向の教科書にはそう書いてありますが、実際にやってみると クラスごとに細かい制御ができなかったりモデルにロジックが侵食したりして あまりうまくいかない、と経験上思っておりますので。

　fix_treeのところで多少手間取っていますが一応終了。トータルの結合 試験で多分たくさんのがバグが･･･ 　少し長いプログラムを読み込ませるだけで、細かいサイズのメモリーを ７千ぐらい、newとdeleteしているのを見るにつけ、これは結構システムに 負担ではないと思いつつ、区切りが出来たらboostの高速メモリー管理poolに 変えようとかと考えています。一括削除が可能だし。また、メモリー上のトラ ブルが起こったら追うだけでも大変だと思う、今のところそのトラブルには 遭遇していないのが救いです。バグは当たり前のようにありますが･･･ 　ちなみに、test.dkmで最高6800ぐらいnewします。 　特に新しいところがなく日記的なので、不要だったら削除してください。

>Diksam ver.0.4以降だと、ファイルをrequireしておけば、 >呼ぶ際は普通の関数呼び出しですけれど、 そうなんですか、同じものを再発明しそうですね。 >Emacs Lispはダイナミックロードですが、私としては初回呼び出しのタイムラグは >気にならないと思っているので、まあ問題ないと思っているのですけれども。 私の場合、スレッドが必要だと思うほどクリティカルな部分を意識しているので やはり、利用者がコンパイラ起動を意識したほうがいいかなと思っています。 >ということはDVMはひとつでグローバル変数とヒープ領域は共有ですね。 >結構ロックが大変そうな気はします。 　この辺はまだ希望的観測の部分が多いので、実際に作りこんでみないと なんともいえない感じです。 　今現在はfix_tree部分を作っていますが、途中でnew、deleteが頻発するので 思わず。new、deleteに被せて、newのアドレスとサイズをコンテナMAPに総て入れ、 deleteで検証する監視プログラムやサポ－トプログラムばかり作ってて脱線気味 です。目的プログラム70%残り30%は監視やデバックプログラムです･･･ 文字列リテラルも、wchar_tを使ってもポータビリティーが上がらないのでstring に変えてしまったし、diksam言語部分だけでも一通り動くようになるのはまだまだ 先です。

>　言語仕様から見ると、Aプログラムの内部からBファイル内にある関数B1を普通に >コールすることです。当初は、ファイル名.関数名();で起動しようか、関数プロ >タイプ宣言で"ファイル名":関数名();で内部的には普通の関数記述と思いましたが。 Diksam ver.0.4以降だと、ファイルをrequireしておけば、 呼ぶ際は普通の関数呼び出しですけれど、 >いつ重いコンパイラが走るかコントロール出来ないので、 .dkhにシグニチャ宣言だけ書いて.dkmに実装を書くと、関数呼び出し時にコンパイラが 動きますから、状況によって問題になるかもしれません(実装まで.dkhに書いてしまえば いいわけですけど)。 Emacs Lispはダイナミックロードですが、私としては初回呼び出しのタイムラグは 気にならないと思っているので、まあ問題ないと思っているのですけれども。 >スレッド起動の仕様 >普通に関数名(P1,,,Pn);を書くと戻ってくるまでコール元は待ちます。 >start(関数名,起動P,,,Pn);と書くとスレッド起動となります。 ということはDVMはひとつでグローバル変数とヒープ領域は共有ですね。 結構ロックが大変そうな気はします。

>これは、CからDiksamの関数を関数名を指定して呼び出すということですよね。 内部的に見るとそうです。 　言語仕様から見ると、Aプログラムの内部からBファイル内にある関数B1を普通に コールすることです。当初は、ファイル名.関数名();で起動しようか、関数プロ タイプ宣言で"ファイル名":関数名();で内部的には普通の関数記述と思いましたが。 いつ重いコンパイラが走るかコントロール出来ないので、プログラムファイル読込 み関数と破棄関数(中間コードリソースの破棄)を作ることにしました。 　この仕様でVMの変更が発生します。それは、1ファイル内の関数コールはコンパ イラで関数アドレスを生成しますが。ファイル外の場合、関数アドレスではなく関 数名を持って、実行時リンクして関数コールする仕様が追加になります。 （最外枠ブロックの実行構文はなくなり、ファイル名起動ではmain()が実行） 中間コードの構造は。 親　ファイル１　　ﾌｧｲﾙ親ー＞子　　　　ファイルｎ ↓　　　｜－－－－－－－－－－￢　　　　｜－－－－－－－－－－￢ 子　　　関数１　・・・・・・　関数ｎ　　関数１　・・・・・・　関数ｎ 　の様に、階層構造の親子関係で関数置きに分離した中間コードになる予定です。 この、ファイルｎの部分が必要時にコンパイルされ中間コードに追加される感じです。 　この構造はちょうど関数単位のマルチスレッドに適応できます。 スレッド起動の仕様 普通に関数名(P1,,,Pn);を書くと戻ってくるまでコール元は待ちます。 start(関数名,起動P,,,Pn);と書くとスレッド起動となります。 例 　　thread_ID1 = start(fnc1,,,); 　　thread_ID2 = start(fnc1,,,); 　　thread_ID3 = start(fnc1,,,); と書くとメインスレッドと3つのfnc1スレッドが同時に動きます。 関数については、この様な仕様を組込みたいと考えています。 また、グローバルシステム変数とスレッド起動された関数は一般的なCのグローバ ル変数やスレッドとは、かなり性格が違ったものになります。でも、この点は実物 のめどが出来そうなときにでも、評価していただければ嬉しいと思っています。

訂正します。 >と思って見ていたらbaseが初期化されていない >ことに気付きました。またバグです。すみません (_o_) いくらなんでもこれじゃ動かないよな、と思ってよく考えると baseはローカル変数の参照に使うので関数内でしか使用されず、 関数を読んだ際にセットされるので問題ありませんでした。

>追加したい機能 >・関数指定起動、スクリプトファイル名と関数名を指定して起動 >　（スクリプトファイル間の連携したプログラミングのために） これは、CからDiksamの関数を関数名を指定して呼び出すということですよね。 特定の関数を実行するには、dvm/execute.cのexecute()関数を、 http://kmaebashi.com/programmer/devlang/diksam_src_0_2/S/18.html#544 ・事前にdvmのcurrent_executableとcurrent_functionとpcを設定して 　(プログラムカウンタは関数ごとなのでpcは0に設定)、 ・execute()関数を、適切な引数で呼び出す ことで可能なはずです。 ただ、実際にはDiksamからネイティブ関数を呼び出して そのネイティブ関数からさらにDiksamの関数を呼び出す、というケースも あるので、スタックポインタを設定の上、execute()関数のローカル変数 baseも引数で渡してやらないと… と思って見ていたらbaseが初期化されていない ことに気付きました。またバグです。すみません (_o_) gccの-Wallでは当てにならないですし、山さんがされたようにVisual Studioでも コンパイルしたいのですがなかなか時間が取れない状態です。明日からは連休ですが、 連休は連休でまた色々と… 編集さんはゲラを発送されたとのことですし(ん?) >その結果、diksam0.2.0の系譜をもつ別の言語になってしまいます。 >なので、言語名は別のものになります。そこでお聞きしたいので >す。diksam0.2.0の系譜をもつ別のものを作ることになりましたが、 >ここでお話しすることは可能でしょうか？ まったく問題ありません。 >　ぶちゃけて言います。気分を害したりしませんか？＞＜ それはないです(^^) Diksamベースで新しい言語ができるのであれば、 どこをどう直されるのか興味深いです。

　各種機能を追加しようとdiksam0.2.0を解析修正をトライしていましたが、メモリ破壊トラブル に数回遭遇しメモリーダンプ解析を行う状態になってしまいました。さすがにこれは私の手に負え る状態ではないと感じ、diksam0.2.0を元にＯＯで新たに言語を作るほうが早いと思い、現在作成し ています。今は構文解析ツリーの生成まで終了しています。 ちなみに、yaccはkmyaccを使用、lex部分は自作です。 追加したい機能 ・グローバルシステム変数への透過的アクセス ・関数指定起動、スクリプトファイル名と関数名を指定して起動 　（スクリプトファイル間の連携したプログラミングのために） ・関数単位でのスレッドセーフなマルチスレッド起動 ・関数単位でのスレッドセーフな通信 ・#define構文の追加（別名定義のみ） 　等の、APとして必要な要件を組み込む必要がありました。その結果、diksam0.2.0の系譜をもつ 別の言語になってしまいます。なので、言語名は別のものになります。そこでお聞きしたいので す。diksam0.2.0の系譜をもつ別のものを作ることになりましたが、ここでお話しすることは可能 でしょうか？ 　ぶちゃけて言います。気分を害したりしませんか？＞＜

>ちなみにlex.zz.cを見ればわかりますが >トークンを漢字に変えると、なでしこのようにすぐになってしまいます。 それだけだと、ぴゅう太の日本語BASICとか http://labs.yaneu.com/20090401/ 年刊Ah!SKI第1号のアレみたいなのになりそうです。 トシがばれますねえ。

>ただ、書くのはともかく、読むほうは「あそこまで日本語化」したほうが >よいというニーズはあるかと思います。 なでしこのHP見に行きましたが、結構すごいことになっていますね。 私のイメージが古かった。ちなみにlex.zz.cを見ればわかりますが トークンを漢字に変えると、なでしこのようにすぐになってしまいます。 それが良いか悪いかは別の話ですが。 　言語の意味合いをもう少し膨らませて、len.zzで「if」と「もし」を同じ 意味にして、プログラムを日本語変換するソフトを作ると･･･ 日本語英語両用自由自在のなでしこをこ･･･　げほんげほん 　今は目的を先に

>なでしこは知っていますが、あそこまで日本語化するのは反対の立場です。 確かに。わかります (^^; ただ、書くのはともかく、読むほうは「あそこまで日本語化」したほうが よいというニーズはあるかと思います。 >>よろしければPXU00211@nifty.ne.jpまで送付ください。 >送りました。内容はメールにて書いています。 受け取りました。ありがとうございます。 さっそく購入以来数度しか使っていないVisual Studio2005でビルドしてみました。 includeパスが絶対指定されていましたが、相対に直したらビルドできました。 >>(例外処理機構がないため)exit()以外に選択肢がなく、実用上問題が出るかも >>しれません。 >この辺が今の課題の一つです、 ver.0.4系だと例外処理機構があるのですが、ビルドが難航しているわけですよね。 >手を着けていないものに、「初期値が設定されていない変数が使われています」が >数十出ています。 これがそんなに出るようではいけないわけですが… こちらでも調べてみたほうがよさそうです。 >コンパイラも何かあるとexitで落ちてしまいます。 ダイナミックリンクである以上確かにこれも問題です。 実用に使い始める前にコンパイルエラーぐらいは取ってくれるだろう、と思うので、 優先度は下げているのですけれども。

ご返答ありがとうございます。 　う～～ん、ある程度予測をして、場所を下に移すも等いろいろやってはいたのですが･･･ 　うまく動かずにここに書き込みました。しかし、いまだにdiksam4.0.3はトラブル で落ちてしまいます。VC++への移植にミスがあると思うのですが。エラーが数百近く 出たのを端からつぶしていったのに問題があるのかもしれません、いまだにワーニン グエラーはたくさん残っています。手を着けていないものに、「初期値が設定されて いない変数が使われています」が数十出ています。対処しないといけないのですがい まだにそこまでは。 　やはり、4.0は一時保留にして、いまは2.0で問題なく動いています。2.0ソースの 拡張子を.cから.cppに総て変えて、ワーニングも総てつぶして、diksam内部からclass を扱えるようにしました。私が使用しているデバッククラスも使えるようになったの で、多少楽になりました。

>１．argcの中身は初期化されていません。 これは明らかにおかしいですね。ご指摘ありがとうございます。 argcによる判定は、parse_parameter()実行後に行うべきことです。 今までは偶然動いてしまっていたようです…… >２．GetCommandLine();は何もやっていない･･･ GetCommandLine()はコマンドライン引数を取得するWindowsの関数です。 http://msdn.microsoft.com/ja-jp/library/cc429108.aspx これの戻り値はワイド文字列なので、 >３．DVM_wcstombs(command_line_wc);のcommand_line_wcはアドレスなのですが･･･ DVM_wcstombs()により、マルチバイト文字列に変換し、parse_parameter()で 引数列に分解しています。

再度、diksam0.4.03のコンパイルを試していますが。 どう見てもWinmMainがおかしいように思います。 WINAPI WinMain(HINSTANCE hInstance , HINSTANCE hPrevInstance , PSTR lpCmdLine , int nCmdShow ) { DKC_Compiler *compiler; FILE *fp; DVM_ExecutableList *list; DVM_VirtualMachine *dvm; int argc; char **argv; DVM_Char *command_line_wc; char *command_line_mb; if (argc < 2) { fprintf(stderr, "usage:%s filename arg1, arg2, ...", argv[0]); exit(1); } command_line_wc = GetCommandLine(); command_line_mb = DVM_wcstombs(command_line_wc); argv = parse_parameter(command_line_mb, &argc); MEM_free(command_line_mb); １．argcの中身は初期化されていません。 ２．GetCommandLine();は何もやっていない･･･ ３．DVM_wcstombs(command_line_wc);のcommand_line_wcはアドレスなのですが･･･ やはり、私には手に余りそうです。何をしたいのかわからないので対処が出来そうに ありません。

追記、ソースはタブ4スペースできれいに見えます。タブ８だとがたがたに･･･ 上に出したソースもがたがただった。

>ご存知かと思いますが、日本語プログラミング言語としては「なでしこ」が有名です。 >http://nadesi.com/ なでしこは知っていますが、あそこまで日本語化するのは反対の立場です。わざと やっているのではないかと思うぐらい読みづらいです。日本語の中にも和製英語が かなりたくさん入っています。それが当たり前に使われている現状を考えてみるに、- なでしこは、古文を読むような感じで現代的では有りません。日本語プログラミン グにおいても、和英混合で問題がないと私は思っています。 >よろしければPXU00211@nifty.ne.jpまで送付ください。 送りました。内容はメールにて書いています。 >http://kmaebashi.com/programmer/devlang/diksam_src_0_1_01/S/20.html ありがとうございます。意外と簡単に組み込めそうです。 >(例外処理機構がないため)exit()以外に選択肢がなく、実用上問題が出るかも >しれません。 この辺が今の課題の一つです、コンパイラも何かあるとexitで落ちてしまいます。 堅牢なシステムを作る予定なのでこの改善が必要です。

>うわぁ、これはなかなか破壊力がありますね。ずっと半角英数でプログラムを書いてきた >ロートルな私などからするとかなり違和感がありますが、メールとかで「Ｗinｄｏｗs」 >みたいに書くおじさんは実際いましたから、需要はあるかもしれません。 >ていうかプロポーショナルフォントのおかげで全角と半角の区別がつきにくくなったのは >よいことなのか悪いことなのか… 投稿後にちょっと考えたのですが、 私の世代の感覚からすると、全角英数字と半角英数字の区別がつかないのは コンピュータリテラシの欠けたおっさんであり、そもそも全角英数字なんか いらんだろ、ぐらいに思っているのですが、 そんなふうに思うこと自体、端境期のおっさんの戯言かもしれませんねえ。 http://onisci.com/802.html

>　下記のような半角全角入り混じったようなプログラムも意味的に言語仕様と有って >いれば動くようになりました。 うわぁ、これはなかなか破壊力がありますね。ずっと半角英数でプログラムを書いてきた ロートルな私などからするとかなり違和感がありますが、メールとかで「Ｗinｄｏｗs」 みたいに書くおじさんは実際いましたから、需要はあるかもしれません。 ていうかプロポーショナルフォントのおかげで全角と半角の区別がつきにくくなったのは よいことなのか悪いことなのか… そういえば、失敗プロジェクトとして名高い「Σプロジェクト」はUNIXベースのOSだった のですが、全角で「ｌｓ」とか書いても通ったという話を聞いたことがあります。 裏は取っていませんが。 なお、せっかくの(数少ない)Diskamユーザをなくしたくはないですし有名なので ご存知かと思いますが、日本語プログラミング言語としては「なでしこ」が有名です。 http://nadesi.com/ >ソース必要でしたらVCのソリューションごと送りましょうか？ 私はロートルプログラマなので本体に取り込むことはないと思いますが、 一般公開してよいものでしたら、興味を持つ方がいるかもしれません。 よろしければPXU00211@nifty.ne.jpまで送付ください。 >　次は関数の組み込みおよびVMのスレッドセーフ化かな。関数の組み込みの仕方を >習得したら、本格的にdiksamを組み込んだアプリケーションの作成に入れます。 ネイティブ関数の自作についてであれば、dvm/native.cが参考になるかと思います。 http://kmaebashi.com/programmer/devlang/diksam_src_0_1_01/S/20.html ただ、ver.0.1ベースだと、引数に変な値が渡されたりしたときに (例外処理機構がないため)exit()以外に選択肢がなく、実用上問題が出るかも しれません。

　下記のような半角全角入り混じったようなプログラムも意味的に言語仕様と有って いれば動くようになりました。もちろん総て全角で書いても動きます。付属の test.dkmも問題なく動作しました。 ------------------------------------------------- int print (string str); string　今時； ｉｎｔ　時間； 　今時＝"朝";　挨拶(今時); 　今時＝"昼";　挨拶(今時); 　今時＝"夜";　挨拶(今時); 　今時＝"わからん";　挨拶(今時); int 挨拶(ｓｔｒｉｎｇ　今　) { print("パラメータ　今＝"　+　今　＋　"\n"); ｉｆ(今＝＝"朝") 　{　print("------ おはようございます\n"); }elsif(今＝="昼") 　{　print("------ こんにちは\n"); }eｌｓif(今=="夜") 　{　print(”------ こんばんは￥ｎ”); }else 　{　ｐｒｉｎｔ　（　"------ おいすー\n"　）　；　 } } ---（注：デバック用に故意に半角全角入り乱れています）------------- lex部分を独自に書くことで問題がないようです。ソース必要でしたらVCのソリュー ションごと送りましょうか？ VC++2005で書かれてSJIS専用になっています。またdiksam1.0対応のみです。 　次は関数の組み込みおよびVMのスレッドセーフ化かな。関数の組み込みの仕方を 習得したら、本格的にdiksamを組み込んだアプリケーションの作成に入れます。

>これなんですが、「誰にとって」簡単であることを目指しているのでしょうか。 　う～～ん、正直言いまして、私の方法論もいいのか悪いのか、わからない結果となりました。やっぱり聞いてみて正解です。したがってアプリがある程度で来た時点で両方を実装して実際に使ってみてから判断がよさそうであると考えました。だいぶ先になるかもしれませんが、実装して使ってみて感想・批評・訂正・修正・駄目押し、ぜひよろしくお願いします。 　この他にも、いろいろ、単純に出来るのではないかと構想しています。なにぶん逆の目から見た発想なので実際に実装してみるまでは評価は難しいのかもしれません。複雑なことを意識せずに複雑な操作をプログラムするアプリケーションなので、お暇がありましたらお付き合いください。特に言語の構造に深くかかわる可能性もあります。よろしくお願いいたします。 　また、現在字句解析が７割ほどかけました。書き終わった後接続試験です。ifもｉｆも10も１０も12３４00も受け付ける字句解析は結構大変です。漢字を受け付ける以上、10と１０は同じ意味なのでやはり数字リテラルとして処理しなければ^^;

>私の目的は、最も簡単な方法だけを提供しそれ以上のことは出来ない、 >知らなくていい、とても初期の段階のプログラミングを想定しています。 これなんですが、「誰にとって」簡単であることを目指しているのでしょうか。 VMを作る山さんの立場からすれば、ネイティブスレッドを相手に共有変数の整合性を 保持しようと思ったら、結局、セマフォというかミューッテクスによるロックが 必要であるように思います。 それにより、個々の変数が任意の時点で正しい値を持つことが保証されるなら、 アプリケーションを作成するユーザの立場からすれば、困らないように思います。 あるいはもし、複数の変数の整合性まで保証しなければならないのであれば (たとえば点の座標をx, yのふたつの共有変数で持つとき、点を(10, 10)から (20, 20)に移動させる際、(10, 20)のようなハンパな状態を見せてはいけないとか)、 これはトランザクションになりますから、トランザクションの終了を宣言する 方法が必要になると思うのですが…… >それは「Diksam言語仕様自体が複雑ではないのか？」と、実は利用者に説明するのは、 >関数と計算式とif,thin,elseif,else,while,continue,break。以外は使わないようにと >説明します。 そうそう、この程度の機能でも、組み込み言語が使えれば便利な局面は多々ありますよね。 Diksamやcrowbarは少なからずこういう用途を想定しているので、使っていただけることは 作者としては嬉しいです。

>新プログラミング言語「BF-BASIC（ここの上カンマ）n」 >上の（ここの上カンマ）の半角記号があると書き込めませんでした。 えっ? ……これはつまりSQLインジェクションが可能なわけで、重大なセキュリティー ホールです。修正しました。ご指摘ありがとうございました。 以下、経緯です。 この掲示板は、↓の注記とか、 http://kmaebashi.com/programmer/bbs_dev/index.html こことかにも書いたとおり、 http://kmaebashi.com/programmer/bbs_dev/newbbs.html PHPのmagic quotesの機能を使用しています。 そして、私が借りているレンタルサーバでは、magic quotesはずっとonに なっていました。 少なくとも今年の1月の時点でシングルクオートを含む投稿に成功しています。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1195&range=1 これがいつの間にかoffにされていたようです。 http://kmaebashi.com/test.php サーバ業者からのお知らせはなかったと思います。以前、PHPを5に上げるという 連絡はありましたがそれもなんだかうやむやになったような(現に今、4で動いてますし)。 # もちろんそれ自体、私を含めてちょっとどうかという話ではありますが。 magic quotesについては、私自身やり方として間違ってるよなあと思いつつ、 郷に入れば郷に従え精神で利用「してしまった」わけですが、当時の私が無知で バカでアホで軽率であったことは認めるとしても、それを前提としたスクリプトは たくさんあるはずで、告知なしにoffにされてはたまったものではないです。 ここはJoe'sウェブホスティングから借りていて、今までさほど大きな問題は なかったと思うのですが、今回の件で過去最大の不信感を持ちました。 ご指摘ありがとうございました。重ねて御礼いたします > 山さん

SQL障害のため書き込めませんでした、どの部分が問題か調べるために2度のテスト書き込みと削除をしています。お騒がせして申し訳ありません。障害点は下記の部分。 新プログラミング言語「BF-BASIC（ここの上カンマ）n」 上の（ここの上カンマ）の半角記号があると書き込めませんでした。 お騒がせしました。

説明不足で申し訳ありません。 >だとすると、配列やオブジェクトのような参照型ではどうなるのでしょう。 配列やオブジェクトのような参照渡しはしないです。と言うかその点をまったく説明していませんでした。非同期の単一のデーターのみを対象にしていす。複数のデータを渡したい場合は、string変数に、","区切りでと考えていました。申し訳ありません。もちろん、パラメータを簡単に構築分解する関数を用意します。非同期渡しなので、送るほうが３回変数を書き換えても、受けは１回か２回しか読めない場合もあります。もし間違いなく渡したい場合は、スレッドセーフなキューシステムを、完全な同期をしたい場合は、それ様のシステムがいりますが。私の目的は、最も簡単な方法だけを提供しそれ以上のことは出来ない、知らなくていい、とても初期の段階のプログラミングを想定しています。 C++熟練者にとっては、最小高速なセマフォーがあればほぼ何でも出来ます。しかしプログラム間で正しく通信するための必要知識は膨大なものが必要です。（それを補間するために、いろいろなライブラリーが作られているが、それがまた複雑さを･･･） まさに「新プログラミング言語「BF-BASIC n」を作ろう」的な構想のアプリケーションです。だから、スレッドセーフな最小限の一方通行情報伝達だけを意識せずに提供できればいいのではないだろうか？との発想で書いています。これで本当に足りるのかは、アプリがある程度出来てこない事には想像がつきません。 決まり事を極力最小にして、複雑さはシステムで吸収できるよう設計したい。そんな目標が有ります。ここで１つ疑問が沸くと思います。それは「Diksam言語仕様自体が複雑ではないのか？」と、実は利用者に説明するのは、関数と計算式とif,thin,elseif,else,while,continue,break。以外は使わないようにと説明します。それ以外は、トラブルがあっても自分で対処回避できる人のみ「Diksam言語仕様」を見てくださいと言う予定です。 　当初は独自で言語を作りはじめましたが、「俺が作りたいのは言語じゃない！！！」との思いが強くなり。いろいろなコンパイラーやインタープリタを調査した結果、Diksamに当たりました。特にしっかりとした言語仕様とVM部分がいいです。この上で複雑さをどれだけ吸収出来るものが作れるのか、がんばってみたいです。 　まだまだ説明不足な点が多々あると思いますが、懲りずによろしくお願いいたします。 >>もっと簡単にしてグローバルは１VM内でのみ有効であるとして、 >>VM間変数と言う特殊な変数を作って、セマフォー処理をしてもいいと思う。 >山さんの投稿を見て私が最初にイメージしたのはこれだったのですが… はい、これがあれば一般的なプログラミングが可能です。しかし複雑な制御知識が必要になってしまいます。なのであえて上記のようなシステムを考えています。 >「変数の値取得用の関数」 変数の形をした、まさにこれなんです。説明不足申し訳ありません。ただ、関数にしてしまうと何度も読んでしまうミスを防げないので、あえて１回のみとしてシステム側で制限を加えたわけです。なぜこうしたかは、出来るだけ問題点をシステム側で見つけ出せるか？（目標）です。

>４．2回目を読みたい時は、変数更新の関数を呼びまた1回のみ読める。 あ、この「変数更新の関数」を呼んでから、変数を読み出すまでの間、 配布元VMでは変数の変更を禁止する(待つ)、ということでしょうか? だとすれば、余計な処理を間に挟めないように、「変数の値取得用の関数」を 用意したほうがよさそうにも思いますが…

>以下が私の考える見えない排他制御です すみません、いまいちよくわかりません。 まず前提として、山さんの案では、複数のVMが、別々のネイティブスレッドで 動作するんですよね? だとしたら、いずれにせよ共有の変数を読み書きする際は きっちりスレッド間でロックの取り合いをしなければならないわけで、この案で どこが簡素化できるのかがどうもよくわからないです。 >１．システム変数は1つのVMのみ読み書きが出来る、配布元VMとする。 また、この「システム変数」は、ユーザプログラムがこれを利用して同期を取るための ものではなく、まさにユーザプログラムがデータとして共有したいものなんですよね? だとすると、配列やオブジェクトのような参照型ではどうなるのでしょう。 int[] a = {1, 2, 3, 4}; という配列を共有したかったとして、 int[] tmp = a; // aを1回だけ読み出し 以後、tmp経由で配列aの中身は触り放題なわけですが、これでよいのでしょうか? >もっと簡単にしてグローバルは１VM内でのみ有効であるとして、 >VM間変数と言う特殊な変数を作って、セマフォー処理をしてもいいと思う。 山さんの投稿を見て私が最初にイメージしたのはこれだったのですが…

以下が私の考える見えない排他制御です １．システム変数は1つのVMのみ読み書きが出来る、配布元VMとする。 ２．他の受信VMは1回のみ変数を読むことが出来る。 　（ローカル変数に代入し各種処理をする） ３．2回目を読もうとすると実行時エラーとなる。 ４．2回目を読みたい時は、変数更新の関数を呼びまた1回のみ読める。 　これで意識しない排他制御が可能になると考えています。 （変数更新を毎回呼んだら意味はありませんが･･･） これが私が実装しようとするスレッド間セーフなシステム変数です。 もしよろしければ、ご意見をお聞かせください。 diksamでスレッドセーフのVMが出来ても、グローバル変数が可能な方法があります。それは、セマフォーグローバル変数を宣言するとともに、ロックとフリーの関数を提供します。C++などでは、変数の排他管理は自分でしろと最小高速なセマフォーがあります。これと同じものを提供すれば、スレッドセーフなVM間の通信制御も可能になります。もちろん、もっと簡単にしてグローバルは１VM内でのみ有効であるとして、VM間変数と言う特殊な変数を作って、セマフォー処理をしてもいいと思う。もしお暇でありましたら、スレッドセーフなVMもご検討ください。 （なにぶんVMもほとんど知らないのに適当なことを言っているのかもしれません、その時は申し訳ありません）

>ここですが、現状のVMでも、DVM_VirtualMachine構造体は複数生成できると >思いますので(試してませんが)、yieldのような予約語を入れて中断できるように >すれば「複数起動され個々がいつでも中断再開できる」という用途は達成できそうに >思います。 はい、まだVM部分はざくっとしか見ていないので、内容のアドバイス大変にうれしいです。イメージ的には複数スレッドでVMが動くを目指しています。なおかつ中断状態をディスクに書き込み、読み出し再開を目指しています。（ちょっと無茶な仕様ですが^^;） Diksam上でのグローバル変数は禁止します。システムが固有に持っているグローバル変数を用いてVM間のコミュニケーションをする予定です。この変数へのアクセスは、理想的にはDiksamの変数と同等に扱えればいいのですが、当面はアクセス関数からのアクセスかな。このシステム変数を使うことでスレッド間排他制御を自動でやりたいと思っています。利用者は排他制御を意識できない、しないレベルにしたい。（目標） >そうではなくて、VMはあくまでひとつで、グローバル変数やヒープを共有し、 >複数のスレッドというかコルーチンというかファイバーというかを立ち上げられる >ようにしようと思ったら、DVM_VirtualMachineのpcやらcurrent_executableやら >current_pcやらをもうすこし整理する必要がありそうです。 今一番簡単にVMを考えるなら、総ての変数領域を、クラスの中にパックしてしまえばグローバル変数がないという条件で、完全なスレッドセーフのVMになるのではないかと思います。その場合、ヒープ領域も指定して持つと言う富豪プログラミングです。 私はまだVMもちらりとしか見ていないので、上記構想がどんなものかの評価が出来ていません。こうしたほうがよりよい等アドバイスが有りましたらよろしくお願いします。 ここ数日、Diksam0.4.01をVC++2005上で動作させることをトライしていましたが、多くのエラーとトラブルに遭遇し、まだ内容もわからずに修正するのは早計であった為、今現在はDiksam0.1を、VC++上に移植して作業をはじめています。0.1は少しの修正で移植できました。

そちらのソースを見たわけでもなく、私が趣旨を誤解している可能性もありますので あくまでご参考としてですが、 >また、VM部分はひとつのclassに入るように修正しようと思っています。 >使用上複数起動され個々がいつでも中断再開できる用途を考えているので、 >1つのまとまりとしてクラス化をして1パッケージで扱えるためにと。 ここですが、現状のVMでも、DVM_VirtualMachine構造体は複数生成できると 思いますので(試してませんが)、yieldのような予約語を入れて中断できるように すれば「複数起動され個々がいつでも中断再開できる」という用途は達成できそうに 思います。 そうではなくて、VMはあくまでひとつで、グローバル変数やヒープを共有し、 複数のスレッドというかコルーチンというかファイバーというかを立ち上げられる ようにしようと思ったら、DVM_VirtualMachineのpcやらcurrent_executableやら current_pcやらをもうすこし整理する必要がありそうです。 また、スレッドを分けるなら、MEMがstaticであるのはそれなりに問題になりそうに 思います。 >いつ完成するかはわかりませんが、何かありましたら必ずここでご報告いたします。 >ある程度めどが出来ましたら、フリーで公開するプログラムになります。 楽しみにしています。 >最後に1つ、「Diksam言語仕様 ver.0.4.01 」のページをパッケージに添付す >ことになると思いますが、その時はよろしくお願いいたします。 これについてもまったく問題ありません(明記しておくべきですね…)。

>Diksamについてですが、mycalc, crowbarと同じで結構です。 とてもありがとうございます。 簡素に現状をご報告いたします。字句解析については日本語関数や日本語の定義や変数を使いたいために、独自で書いています。スピードもそれほど要らない部分ですから。また、VM部分はひとつのclassに入るように修正しようと思っています。使用上複数起動され個々がいつでも中断再開できる用途を考えているので、1つのまとまりとしてクラス化をして1パッケージで扱えるためにと。（私がクラス好きなんでつ）ヒープとGCはまったく別の形でなくすかもしれません。なにぶん趣味で作っているものなので、いつ完成するかはわかりませんが、何かありましたら必ずここでご報告いたします。ある程度めどが出来ましたら、フリーで公開するプログラムになります。 最後に1つ、「Diksam言語仕様 ver.0.4.01 」のページをパッケージに添付すことになると思いますが、その時はよろしくお願いいたします。

>はじめまして、山と言うもので。 はじめまして。 >このページでは、mycalc, crowbar共に、商用、非商用を問わず、自由に複製、改変、 >とプログラム名を指定して記入してあります。私どもは、Diksamを改変し、プログラムの中に組み込もうと思っていますが。ライセンス条項がどこにも見当たりません。 光栄です。 Diksamについてですが、mycalc, crowbarと同じで結構です。このライセンス条件を 書いた時点でDiksamは公開前だったのですが、追加を忘れていました。 さっそくDiksamを追記しておきました。ご指摘ありがとうございます。

はじめまして、山と言うもので。 ライセンスというか使用許諾というかについてお聞き致します。 このページでは、mycalc, crowbar共に、商用、非商用を問わず、自由に複製、改変、 とプログラム名を指定して記入してあります。私どもは、Diksamを改変し、プログラムの中に組み込もうと思っていますが。ライセンス条項がどこにも見当たりません。 よろしければどの様なライセンス条項であるかお聞かせ願えませんでしょうか？ 当初は、同一であると思って作業を進めていましたが、よくよく見るとDiksamの名前がありませんでした。まことに不注意ではあったのですが、よろしくお願いいたします。

こんにちは。 >C言語 FAQ 日本語訳 >http://www.kouno.jp/home/c_faq/ 情報ありがとうございます。修正しておきました。

C言語 FAQ 日本語訳 http://www.kouno.jp/home/c_faq/ リンクが変わっているかも？？ 上が正しい？

はじめまして。書き込みありがとうございます。 最近かなり忙しく返信が遅くなりましてすみません。 >PHP掲示板の勉強をしてみようとぐぐり、(ぱ)さんのページを見つけました。 今にして思うと、言い訳しながらmagic_quote使うくらいなら使うな、とか、 テーブルのレコードには作成日時のフィールドぐらいデフォルトで入れとけ、 とか、ツッコミどころはあるのですが、役に立てたようなら何よりです。 >BF Basic笑いました。 ありがとうございます。 もうじきエイプリルフールですが、今年はネタを仕込むヒマもないなあ…

PHP掲示板の勉強をしてみようとぐぐり、(ぱ)さんのページを見つけました。 テクニカルでかつ気ままな仕様書は読み物としても秀逸。 知りたいこともちゃんと読みとれました。 ありがとうございました。 BF Basic笑いました。

返信、ありがとうございます。 Boostとかいうライブラリに関しても調べてみたのですが、 こちらも優先順位の設定が出来なそうに見えました。 (間違っていたら、すみません)

> pthreadを使用し、Windows上でスレッド優先順位を指定するには、 >どのようにすれば良いのでしょうか? または、そんなことは出来ないのでしょうか? 長々と放置しましてすみません。 私はpthreadは使ったことがないので、有効な助言はできないかと思います。 # ざっとぐぐってみた範囲では、やはり管理者権限がないと優先順位の設定は # できないように思えるのですが。 詳しい方からの情報をお待ちしております。

皆さんこんにちは、tosです。 現在、Windows XPにてpthread-win32 libraryを使用した プログラムの変更を行なっています。 あるスレッドの優先順位を変更する必要があるため調べたところ、 「優先度は、スケジューリングポリシーが SCHED_OTHER の時には意味を持たず、 リアルタイムポリシー SCHED_RR と SCHED_FIFO に対してのみ有効である。」 とのことでした。 スケジューリングポリシーは「SCHED_OTHER」であったため、「SCHED_FIFO」 に変更しようとしたところ、 「リアルタイムスケジューリングポリシーである SCHED_RR と SCHED_FIFO は、 スーパーユーザ権限のプロセスに限って使用できる。」 とのことで、「SCHED_FIFO」を指定することが出来ません。 pthreadを使用し、Windows上でスレッド優先順位を指定するには、 どのようにすれば良いのでしょうか? または、そんなことは出来ないのでしょうか?

>「WindowsのGUIの悪いところは全部Macが起源だ」的な記事を > はてなの日記にでも書こうと思ってました。 楽しみに待っています。 前橋さんは、プログラミングの基礎の構築はバリバリlinuxを使ってるのですね！