K.Maebashi's BBS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>LuaやJavaScriptの方法だと、名前空間が動的になるんですよね。 >環境作ってないので試してませんけど、Luaで「hoge = string」と書くと、 >hoge.sub()で文字列置換ができるようになるんじゃないでしょうか。 試してみたらできました。 静的、動的な違いというのも理解しました。 ありがとうございます。 >また、単なるテーブル(crowbarならオブジェクト)を名前空間に使うと、 >ライブラリ関数が壊せてしまうというのも、問題だと思います。 >Luaでは、string.subに代入できるんですよね? こちらも試してみたらできました。 確かに問題になりそうですね。 >と言いつつ、実は今crowbarに予約語finalを持ち込んで定数を作れるように >したりしてるので、ライブラリ関数のメンバとか名前空間オブジェクトをfinalに >してしまえば、これでもいい気がしてきました。うーん。 crowbarでfinalで定数作れるようにしてたんですね。 よくimmutableなクラスを作るときにはfinalにしないといけないと 書いてあるので、そういう意味ではfinalは必須な気もします。 Luaには定数にする方法はなかったような…。 >これは、Cの関数を抜けた後の話ですよね。レジストリに登録するという。 >crowbarでは、Cの関数の実行中でも、ヒープ関連の関数を呼び出すと >GCが動く可能性がありますから、ひとまずスタックに積まなければなりません。 私はよく分かっていないのですが、このcrowbarのアプローチは メジャーなのですか？ >Luaの仮想スタックって、まさにcrowbarのスタックのような独自スタックでは? >crowbarのような手間がなさそうなところからして、Cの関数の部分だけ、 >Cスタックをスキャンするconservative GCなのかなあ、とも思ったのですが、 >テーブルを確保すると勝手にスタックに積まれること、他の参照型というと >文字列くらいですがCRB_Stringのような型では扱っていないことからして、 >コンサバGCではないようですね。 Luaの仮想スタックは、確かに独自スタックです。 しかし、私の知識不足とLuaのGCのメカニズムは記述がなかったため よく分かりません。 >うーん、CRB_add_native_function()は別にinterface.cの中で呼ぶ必要はないんですが >(実際今はnative.cとかの中で呼んでますし)。実行中でも呼べますから、 >ネイティブ関数内でも登録可能です。 実行中に呼べるのは応用範囲が広がりそうですね。 >これに近いことをするのであれば、(ver.0.4で新設された)CRB_create_closure()で >クロージャ作って、CRB_add_assoc_member()でオブジェクトに登録するなり >CRB_add_global_variable()でグローバル変数に登録するなりもできます。 crowbarのように実際のデータを直接扱えるとコードが分かりやすいと 思います。 Luaみたいに仮想スタック上にデータを作っておいて…みたいのは 分かりにくいです。 >crowbarスクリプトをまったく独立して動かせばよいのなら、インタプリタを >もうひとつ作って実行すればよいです。 >ただ、たぶんこの場合、グローバル変数を共有して動かしたいのだと思います。 >そうだとすれば、外部crowbarスクリプトのトップレベルを動かす方法は >ありません。ただし、外部crowbarスクリプト中の関数であれば、 >CRB_compile()とCRB_call_function()を使えば実行可能です。 外部crowbarスクリプト中の関数を呼べるということは、 データを引数でC側からcrowbarの関数側にプッシュしてあげて、 crowbarスクリプトのglobal変数に保存しておけば、 データの共有はできると思います。 C側に戻したいときもC側から渡す引数につめてあげれば 戻せます。 私は、この(例えば)Cとスクリプトとのデータの共有が一番 重要と思っているのですが、crowbarでも簡単にできそうですね。 だとすれば、既に組み込み言語として十分使えるレベルだと思います。 実は、Luaではこの一番重要な部分が一番面倒くさいです。 >やりたいこと・やるべきことはいろいろあって、その中にはcrowbar以外のことも >含まれます。もう少ししたら、crowbarほっぽりだして別の言語を作り始める >可能性も(かなり高い確率で)あります。企画の趣旨的には、crowbarを実用言語に >するよりも、バイトコードインタプリタのような違う実行形態の言語をもうひとつ >作る、という方が合っている気がしますし。 バイトコードインタプリタはかなり興味深いです。 楽しみにしています。 >ということで、crowbarに期待してくださるのは大変嬉しいことですし、 >私としても励みになるのですが、私の時間が有限である以上お応えできるかどうかは >わからない、ということで、すみませんがご理解ください。 私は、(ぱ)さんの本はほとんど持っていますが、もう少し内容を濃くして 「プログラミング言語を作る」もぜひ出版して欲しいです。 早くていつ頃になりそうですか？ >あと、今だと鬼車のライセンス表記をどこかに含めなければいけませんよね。 >次バージョンで検討します。 ソースの理解は、まず動作が分かってからだと思うので、 とりあえず簡単に動かしてみたいという気持ちはあります。 あと、Cとの連携方法など、ユーザの視点でのcrowbarの使い方 みたいな文章も欲しいところです。 時間がないでしょうが、いつも楽しみにしていますので 頑張ってください。

はじめまして。happieと申します。 以前、拙HPで勝手に(ぱ)さんのページを紹介させていただきました。 また『ポインタの完全制覇』や「疑り深いあなたのためのオブジェクト指向再入門」については、本質的なところを突いているため大変興味深く読ませていただきました。 オブジェクト指向の本質が、マルチプルインスタンスにあるということについても全く同意見です。 ところで、一部のオブジェクト論者の中には、ポリモーフィズムこそがオブジェクト指向の本質で、インターフェースでプログラミングすることが最も重要なことのように謳っています。実際、デザインパターンの解説書ではそのことがたびたび強調されています。 (ぱ)さんは、ポリモーフィズムに関してあまり記述がなかったように思いますが、どのようにお考えですか。

>>もっと言ってしまえば、「クラス」ではなくて「りんご」でも別に良かった…ということ？ > >私は「術語に*過剰な*期待をするのはいかがなものか」と言っているのです。 >「術後にまったく期待するな」などと言った覚えはありません。 何が過剰なのかわからないのです。 「クラス」も「スーパークラス」も、全く過剰だとは思えないので。

>しかし、私はLuaの方法と、モジュールによる名前空間の分割の >本質的な違いを説明することはできません。 LuaやJavaScriptの方法だと、名前空間が動的になるんですよね。 環境作ってないので試してませんけど、Luaで「hoge = string」と書くと、 hoge.sub()で文字列置換ができるようになるんじゃないでしょうか。 Javaなどでもimportでパッケージ指定を省略できたりしますが、その規則は あくまで静的です。これを動的に変えられると、どこで何呼んでるんだか さっぱり、という状態になりそうな気がします。もっとも、 「そんなことしないでしょ」という考え方もありますが。 # でも、s = stringとかしてタイプ量を節約する人はいる気がする。 また、そういう規則では、統合開発環境はお手上げでしょうが、それは 形無し言語全般に言えることかも。 RDEとやらの入力保管機能はどうなってるんだろ、とマニュアルを見てみたら… ううむ。 http://rubyde.sourceforge.net/hiki/ja/Auto%2BComplete.html また、単なるテーブル(crowbarならオブジェクト)を名前空間に使うと、 ライブラリ関数が壊せてしまうというのも、問題だと思います。 Luaでは、string.subに代入できるんですよね? と言いつつ、実は今crowbarに予約語finalを持ち込んで定数を作れるように したりしてるので、ライブラリ関数のメンバとか名前空間オブジェクトをfinalに してしまえば、これでもいい気がしてきました。うーん。 >配列とハッシュが同列なら、配列リテラルがあるので、 >ハッシュリテラルも欲しいところです。 >初期化ができないと不便なので私は必須だと思っています。 ご意見ありがとうございます。 …と言いつつ、やりたいことは他にもあるので、すみませんが優先順位は高くないです。 >(2)に関しては、Luaは、GCされたくなければ、グローバルとして >別に残しておかなければなりません。 これは、Cの関数を抜けた後の話ですよね。レジストリに登録するという。 crowbarでは、Cの関数の実行中でも、ヒープ関連の関数を呼び出すと GCが動く可能性がありますから、ひとまずスタックに積まなければなりません。 >また、LuaがコンサバGCかどうかは不明ですが、 >crowbarのようなcrowbarスタックはLuaには、ないと思います。 Luaの仮想スタックって、まさにcrowbarのスタックのような独自スタックでは? crowbarのような手間がなさそうなところからして、Cの関数の部分だけ、 Cスタックをスキャンするconservative GCなのかなあ、とも思ったのですが、 テーブルを確保すると勝手にスタックに積まれること、他の参照型というと 文字列くらいですがCRB_Stringのような型では扱っていないことからして、 コンサバGCではないようですね。 >現状のCRB_add_native_function()で、ネイティブ関数を登録 >しておかなければならないのは、interface.cのソースを直接 >いじらないといけないので、これはLuaの方が楽だと思います。 うーん、CRB_add_native_function()は別にinterface.cの中で呼ぶ必要はないんですが (実際今はnative.cとかの中で呼んでますし)。実行中でも呼べますから、 ネイティブ関数内でも登録可能です。 >Cで書いた関数(例えば、l_sin()という関数)を、 >lua_pushcfunction(L, l_sin) >lua_setglobal(L, "mysin") >で、登録することによりLuaでmysin()という関数が使えます。 これに近いことをするのであれば、(ver.0.4で新設された)CRB_create_closure()で クロージャ作って、CRB_add_assoc_member()でオブジェクトに登録するなり CRB_add_global_variable()でグローバル変数に登録するなりもできます。 >また、Luaでは、CからLuaのコードを呼ぶ際に、 >Lを、lua_State型の変数とすると、 >lua_dofile(L, "test.lua") >により、test.luaが実行されるのですが、 >crowbarでは、これはどうやればできますか？ crowbarスクリプトをまったく独立して動かせばよいのなら、インタプリタを もうひとつ作って実行すればよいです。 ただ、たぶんこの場合、グローバル変数を共有して動かしたいのだと思います。 そうだとすれば、外部crowbarスクリプトのトップレベルを動かす方法は ありません。ただし、外部crowbarスクリプト中の関数であれば、 CRB_compile()とCRB_call_function()を使えば実行可能です。 >ただのプログラミング練習言語で終わらせるのはもったいないと >思います。 >何か特徴を付けて、存在価値のある言語にして欲しいです。 やりたいこと・やるべきことはいろいろあって、その中にはcrowbar以外のことも 含まれます。もう少ししたら、crowbarほっぽりだして別の言語を作り始める 可能性も(かなり高い確率で)あります。企画の趣旨的には、crowbarを実用言語に するよりも、バイトコードインタプリタのような違う実行形態の言語をもうひとつ 作る、という方が合っている気がしますし。 ということで、crowbarに期待してくださるのは大変嬉しいことですし、 私としても励みになるのですが、私の時間が有限である以上お応えできるかどうかは わからない、ということで、すみませんがご理解ください。 >あと、できれば、Windows版のcrowbar.exeもダウンロード >できるようにして欲しいです。 確かに便利だと思いますし、今まで考えなかったわけでもないのですが、 企画の趣旨的にどうかという気もします。 あと、今だと鬼車のライセンス表記をどこかに含めなければいけませんよね。 次バージョンで検討します。

>もっと言ってしまえば、「クラス」ではなくて「りんご」でも別に良かった…ということ？ 私は「術語に*過剰な*期待をするのはいかがなものか」と言っているのです。 「術後にまったく期待するな」などと言った覚えはありません。 >例示が必要でしょうか？　「is-a」「汎化-特化」の考えは、まさに分類だと思うのですが（「汎化」「特化」という用語を誰が考えたかは知りませんが、いくらこれが術語だからと言って「低機能」「高機能」という意味でないのは明らかでしょう）。 そんな話をした覚えもありません。

>ここを見る限り、stringというテーブルに、いろんなメソッドを >クロージャとして埋め込んでいる、という認識でよいでしょうか? その通りです。 私の表現は間違ってました。 stringテーブルにクロージャが入っているですね。 >ここでのstringの使われ方は、純粋に名前空間としてのものですよね。 >現状のcrowbarには、名前空間を分割する機能がないので、今回はreg_で >逃げたわけです。モジュールによる名前空間の分割はいずれそのうちやろうと >思っていますから、現時点で、Lua的な方法(crowbarでやるなら、グローバルな >stringというオブジェクトにクロージャを格納することになるのでしょう)で >解決しようとは思いません。 おっしゃる通り、名前空間と同じ仕組みです。 事実、Luaにはパッケージという概念がなく、テーブルにより パッケージを表現します。 しかし、私はLuaの方法と、モジュールによる名前空間の分割の 本質的な違いを説明することはできません。 しいて言えば、モジュールが一般的な意味のモジュールであれば、 文法を用意してあげることにより、ソースを見たときの 分かりやすさ(明確さ)は増すような気はします。 Javaみたいな感じだとpackageが名前空間を表していることが明確です。 Rubyのモジュールだと結局Luaと同じになるような気がします。 >crowbarの場合、スコープチェーンは「最上位の関数の中」までで止まっていますが、 >これをグローバルな領域まで広げ、グローバルな名前空間もassocで表現するようにして、 >グローバル変数もそのassocに、またグローバルな関数はクロージャとして >格納するようにすれば、名前空間の考え方が統一されるとともに、 >モジュールが欲しければトップレベルのオブジェクトをモジュールとして考えればよい、 >ということになります。実際JavaScriptはそんな感じになっています。 これもおっしゃる通りです。 Luaでは、グローバルなテーブルというものが、あらかじめ存在し、 stringなどは、その中に登録されています。 >ハッシュはですねえ… >もちろん考えていないことはないのですが、問題は、どの階層で実現するかです。 >言語の外で、ライブラリとして提供しても十分だと思うんですが、 >どうでしょうか(基本型のハッシュキーの取得方法は考えるにしても)。 >ハッシュのリテラル(「{"a" => "hoge"}」みたいなの)って要りますかねえ。 >考えるべきところはたぶんふたつあって、 私のイメージでは、配列(リスト)とハッシュは、同じ階層だと 思っています。 私の中で、リスト、ハッシュ、文字列は基本的なデータ構造だと 思います。 また、Luaでは、Table型により、配列とハッシュの両方を表現可能です。 >a)ハッシュのリテラルを言語仕様として用意するかどうか。 >b)ハッシュのオブジェクトを、(JavaScriptやLuaのように)現状のassocの >　別の見え方として考えるかどうか。 > >私としては、a)はまあやるならやってもいいけど(ただし優先順位は低い)、 >b)は嫌、というところです。 a)に関しては、 配列とハッシュが同列なら、配列リテラルがあるので、 ハッシュリテラルも欲しいところです。 初期化ができないと不便なので私は必須だと思っています。 b)に関しては、 assocの別の見え方にするというより、ハッシュを作り、 それでassocを表現するというイメージだと思いますが、 個人的には分けても統一化してもどちらでも良いと思います。 >ええと、私はLuaを使っていないのでご意見をお聞かせ願いたいわけですが、 >現状で、Luaとcrowbarを比べてみてどうでしょうか? >Luaとcrowbarでネイティブ関数を書くときのことを比較すると、 > >(1)引数や戻り値 >　Lua…スタックを直接操作 >　crowbar…引数や戻り値なので、ちょとはわかりやすいかな。 >(2)GC >　Lua…何もしなくていい(?) Ruby的コンサバGC? >　　lua_newtable()が「新しい空のテーブルを作り、スタックに積む。」そうだから、 >　　スタックにないものは勝手にGCされそうな気もするんですが。 >　crowbar…GCされたくなかったらスタックに積んどけ。 >　　正直、これは面倒くさいです。せめて、最後のスタックの後始末を処理系側で >　　やれば、というか実はそれは造作もないのですが。 >(3)アプリケーション固有データ >　Lua…ユーザデータ >　crowbar…ネイティブポインタ >　　ファイナライザの仕様も含め、そっくりに見えます。また車輪を再設計したか。 (1)に関しては、crowbarの方は、CRB_Valueの構造が一度 分かってしまえば分かりやすいと思います。 Luaでは、常に目に見えない仮想スタックの状態がどうなっているかを 把握しておかないといけないのでかなり分かりづらいです。 (2)に関しては、Luaは、GCされたくなければ、グローバルとして 別に残しておかなければなりません。 また、LuaがコンサバGCかどうかは不明ですが、 crowbarのようなcrowbarスタックはLuaには、ないと思います。 (3)に関しては、Luaの方は、仮想スタック経由で扱うので 関数により抽象化されていて、 crowbarの方は、CRB_Valueで直接アクセスするので、 私個人の考えでは、crowbarの方が、何をやっているのかが 分かりやすいような気もします。 とにかくLuaでは常に仮想スタック経由なので、 そこら辺の仕組みが分かってしまえば良いのですが、 それがメリットなのかはまだ分かっていません。 >いっそ今みたいに特定の引数を持ったネイティブ関数が呼ばれる仕様ではなく、 >また、CRB_add_native_function()で関数を登録する必要もない、というようにして、 >もっと楽にネイティブ関数を書けるようにするというのも考えられますが… >処理系依存のコードはあんまり書きたくないですし。 現状のCRB_add_native_function()で、ネイティブ関数を登録 しておかなければならないのは、interface.cのソースを直接 いじらないといけないので、これはLuaの方が楽だと思います。 Luaでは、ライブラリとして登録するのは同様に面倒ですが、 ただLua側からC側の関数を呼びたいだけなら、 Cで書いた関数(例えば、l_sin()という関数)を、 lua_pushcfunction(L, l_sin) lua_setglobal(L, "mysin") で、登録することによりLuaでmysin()という関数が使えます。 このぐらいの手軽さがないと組み込みとは言えないと思います。 また、Luaでは、CからLuaのコードを呼ぶ際に、 Lを、lua_State型の変数とすると、 lua_dofile(L, "test.lua") により、test.luaが実行されるのですが、 crowbarでは、これはどうやればできますか？ >まあ、別にRubyと張り合う気はないんですけど。 >方向性として、組み込み用スクリプトというのは、[685]にも書いたように >そもそも言語処理系に興味を持った時点からありました。 >ただ、今は別の方向も考えています。こんなの↓とか。 > >http://kmaebashi.com/zakki/zakki0027.html#lang ただのプログラミング練習言語で終わらせるのはもったいないと 思います。 何か特徴を付けて、存在価値のある言語にして欲しいです。 あと、できれば、Windows版のcrowbar.exeもダウンロード できるようにして欲しいです。 新しいバージョンをすぐテストしたいので。 よろしくお願いします。

>「術語に対して」過剰な期待をしてもしょうがないのでは、ということです。 >この議論の最初のほうで、CESさんは > >>例えば、「クラス」という用語の意味は「分類」であって、「原型」ではありませんから、 > >ということを書いています。 >でも、「クラス」という言葉の辞書的定義が「分類」だったからといって、 >術語として使われるときそのままの意味とは限らないし、「クラス」という >言葉を選んだ人が間違えたのかもしれない。だから、その言葉の意味に >過剰な期待をしてもしょうがないのでは、と言っているのです。 ># クラスを分類とする考え方を否定しているわけではありません。 では、極論すれば、辞書的な「分類」という意味と、術語としての「クラス」という用語は切り離して考えるべきだ、ということ？ もっと言ってしまえば、「クラス」ではなくて「りんご」でも別に良かった…ということ？ 「りんご」の辞書的な意味は明らかに違うけれど、術語なんだから、それで通じれば別にいいじゃん…と。 しかし、如何に述語だとは言っても、何の根拠もなく選ばれた言葉であるはずはなし、そして、「クラス」には「分類」という意味があって、オブジェクト指向のクラスを「分類」として捉えると自然なのは事実なんだから、その言葉はそのような意味を持って選ばれたと考えるのは、過剰ではないと思うのですけれど。 本当に「何の根拠もなく選ばれたはずはない」のかどうか、あるいは根拠があったにしても「『分類』という意味を意図して選んだ」のかどうか、その真相はわからないのですが、別に後付けの意味だとしても、それはそれで構わないと思います。意味がないよりはずっといい。 >「それはそうかもしれませんけど」「それほど無理はない」んならいいじゃん、 >術語に過剰な期待をしてもしょうがない、と私は言っているわけです。 「りんご」だったら「それほど無理は無くない」と思うけれど、まぁ極論だからそこに突っ込むのは無し。 >クラスを分類として考えるのがよいとCESさんがお考えなら、それが具体的に >有効であるケースを、例示して主張するのがよいのではないでしょうか。 例示が必要でしょうか？　「is-a」「汎化-特化」の考えは、まさに分類だと思うのですが（「汎化」「特化」という用語を誰が考えたかは知りませんが、いくらこれが術語だからと言って「低機能」「高機能」という意味でないのは明らかでしょう）。

補遺。 >現状のcrowbarには、名前空間を分割する機能がないので、今回はreg_で >逃げたわけです。モジュールによる名前空間の分割はいずれそのうちやろうと >思っていますから、現時点で、Lua的な方法(crowbarでやるなら、グローバルな >stringというオブジェクトにクロージャを格納することになるのでしょう)で >解決しようとは思いません。 crowbarの場合、スコープチェーンは「最上位の関数の中」までで止まっていますが、 これをグローバルな領域まで広げ、グローバルな名前空間もassocで表現するようにして、 グローバル変数もそのassocに、またグローバルな関数はクロージャとして 格納するようにすれば、名前空間の考え方が統一されるとともに、 モジュールが欲しければトップレベルのオブジェクトをモジュールとして考えればよい、 ということになります。実際JavaScriptはそんな感じになっています。 crowbarがそうなっていないのは、ver.0.1からの流れ、というのも否定できないですが、 printに代入できるのはいかがなものか、とか、名前空間はやっぱり静的なほうが わかりやすいんじゃないか、とか、グローバル変数とローカル変数は分けて考える べきじゃないか、とか、いろいろ考えてこうなっています。この選択が正しかったか どうかはよくわかりませんが。 このへんはいずれ「crowbarプログラマのためのJavaScript入門」(仮題)で 書こうかと思っています。 # タイトルはネタなのであまり怒らないように。

>最後の方に、正規表現関連の関数がグローバルということが >書かれていましたが、私は、Pythonは、よく知らないのですが、 >何で正規表現の関数をクロージャに押し込んで提供していないのですか？ >例えば、Luaであれば、Stringというクロージャに入っています。 Luaは以前リファレンスをちょっと眺めたきりなので、 ここで言う「クロージャ」が何であるのかがよくわからないのですが。 http://lua-users.org/wiki/StringLibraryTutorial ここを見る限り、stringというテーブルに、いろんなメソッドを クロージャとして埋め込んでいる、という認識でよいでしょうか? http://www.uri.sakura.ne.jp/~cosmic/yuno/lab/lua5_manual_ja.html#5.3 ここを見ても、 | 文字列ライブラリはすべて、テーブル string 内の関数として提供される。 と書いてあるし。 ここでのstringの使われ方は、純粋に名前空間としてのものですよね。 現状のcrowbarには、名前空間を分割する機能がないので、今回はreg_で 逃げたわけです。モジュールによる名前空間の分割はいずれそのうちやろうと 思っていますから、現時点で、Lua的な方法(crowbarでやるなら、グローバルな stringというオブジェクトにクロージャを格納することになるのでしょう)で 解決しようとは思いません。 >また、crowbarには、まだハッシュを組み込んでなかったと思うのですが、 >ハッシュは組み込まないのですか？ >必須なデータ構造だと思います。 ハッシュはですねえ… もちろん考えていないことはないのですが、問題は、どの階層で実現するかです。 言語の外で、ライブラリとして提供しても十分だと思うんですが、 どうでしょうか(基本型のハッシュキーの取得方法は考えるにしても)。 ハッシュのリテラル(「{"a" => "hoge"}」みたいなの)って要りますかねえ。 考えるべきところはたぶんふたつあって、 a)ハッシュのリテラルを言語仕様として用意するかどうか。 b)ハッシュのオブジェクトを、(JavaScriptやLuaのように)現状のassocの 　別の見え方として考えるかどうか。 私としては、a)はまあやるならやってもいいけど(ただし優先順位は低い)、 b)は嫌、というところです。 >あと、最近、Luaを勉強していて、組み込み言語と謳っている割りに >例えば、LuaとCとのインタフェースを書くのがかなり面倒で >少しがっかりしているのですが、crowbarはぜひとも組み込み部分を強化 >して欲しいです ええと、私はLuaを使っていないのでご意見をお聞かせ願いたいわけですが、 現状で、Luaとcrowbarを比べてみてどうでしょうか? Luaとcrowbarでネイティブ関数を書くときのことを比較すると、 (1)引数や戻り値 　Lua…スタックを直接操作 　crowbar…引数や戻り値なので、ちょとはわかりやすいかな。 (2)GC 　Lua…何もしなくていい(?) Ruby的コンサバGC? 　　lua_newtable()が「新しい空のテーブルを作り、スタックに積む。」そうだから、 　　スタックにないものは勝手にGCされそうな気もするんですが。 　crowbar…GCされたくなかったらスタックに積んどけ。 　　正直、これは面倒くさいです。せめて、最後のスタックの後始末を処理系側で 　　やれば、というか実はそれは造作もないのですが。 (3)アプリケーション固有データ 　Lua…ユーザデータ 　crowbar…ネイティブポインタ 　　ファイナライザの仕様も含め、そっくりに見えます。また車輪を再設計したか。 いっそ今みたいに特定の引数を持ったネイティブ関数が呼ばれる仕様ではなく、 また、CRB_add_native_function()で関数を登録する必要もない、というようにして、 もっと楽にネイティブ関数を書けるようにするというのも考えられますが… 処理系依存のコードはあんまり書きたくないですし。 >鬼車を搭載しても、まともに張り合ったら、Rubyに対抗するのは >難しいと思いますので、組み込み用スクリプトでメジャーなものは >なさそうなので、そういう方向はどうでしょうか？ まあ、別にRubyと張り合う気はないんですけど。 方向性として、組み込み用スクリプトというのは、[685]にも書いたように そもそも言語処理系に興味を持った時点からありました。 ただ、今は別の方向も考えています。こんなの↓とか。 http://kmaebashi.com/zakki/zakki0027.html#lang ていうか、企画本来の主旨であったはずの「プログラミング言語の作り方の紹介」 という観点からすれば、crowbarは、crowbarのような実装方針の言語としては とっくにオーバースペックであり、たぶん私は暴走している状態なわけですが。 ええと誰か止めて。

>私は、ＬＩＮＵＸで動くＣＡＤを作りたいと思っています。 リンク欄のsourceforgeのページから、ホームページを辿って見てみました。 http://sagcad.sourceforge.jp/ 浅学にてSagCADは知らなかったのですが、crowbarよりずっとすごいじゃないですか。 BBS(は見えなかったのですがそのGoogleキャッシュ)を見てみると、ドイツの人とか 英語圏の人とかも巻き込んで開発されているようですし。 実は私は10年くらい前、資料などに使う図を描くドローツールについて、 いいのがないので作りたいと思っていました。当時は、ていうか実は今も UNIX上でTgifを使っていますが使い勝手の点で満足していません。 たとえばシステム構成図などでは、データベースとかを円筒形を斜め上から 見た図で表現することがあります。Word付属のドローツールとかでも この円筒形は描けますが、縦に伸ばすと楕円部分の縦横比まで変わってしまう。 これは美しくないわけで、「中に入る文字列に合わせてサイズは自動調整。 でも楕円部分の縦横比は変わらない」という機能が欲しいわけですが、これを ドローツール本体に組み込むのも美しくない。となるとスクリプト言語が必要かなあ… と言語処理系に興味を持ち始めて今に至るわけです。 以後、いくつも言語を作ろうとして作りかけで放棄してきたわけですが (言語処理系を作りかけた人は誰もがこれをやってると思う)、crowbarは仕様で 無理をしなかったことと、何よりも「公開したこと」により、どうにかここまで こぎつけることができました。 というわけで、CADのマクロとして使うというのは、crowbarの実に正当な使い方と いうか、本来あるべき姿のように思います。バグがあったらすみませんですが、 よろしくお願いいたします。 >ホームページ上では、僕が作ったソースに組み込めるようなことが >描いてありました。まだ試していませんが、試せるところまで進んだら >ぜひ、使わせてください。 CADに組み込む際には、スクリプトから図形を作ったり、図形をスクリプトから 操作したりしなければならないでしょうから、「図形」とか「図面」とかを ネイティブポインタ型で表現することになると思います。 その上でネイティブメソッドをいくつか書けば、CADと連携できるのでは、 と思います。 # 「図形」や「図面」にメソッドを付けるには、今の仕様ではcrowbarの # オブジェクトでラップすることになりますが、ネイティブポインタ型に # 「メソッドもどき」を付ける機能があってもいいかな、とも思っています。 それでは、SagCADにcrowbarが組み込まれる日を楽しみにしています。

>よくわかんなくなってきました。「過剰な期待をするな」とはどういうことですか？ >「違和感を覚えるな」というのは無理な期待だ、ということでしょうか？ 「術語に対して」過剰な期待をしてもしょうがないのでは、ということです。 この議論の最初のほうで、CESさんは >例えば、「クラス」という用語の意味は「分類」であって、「原型」ではありませんから、 ということを書いています。 でも、「クラス」という言葉の辞書的定義が「分類」だったからといって、 術語として使われるときそのままの意味とは限らないし、「クラス」という 言葉を選んだ人が間違えたのかもしれない。だから、その言葉の意味に 過剰な期待をしてもしょうがないのでは、と言っているのです。 # クラスを分類とする考え方を否定しているわけではありません。 CESさんはこうも書いています。 >「クラスとは分類である」という考えをすると、具体的なものはオブジェクトで、 >クラスは全て抽象的なものということになるからです（その点、「抽象クラス」 >ってのは良くないネーミングだと思います）。 私の返答がこう(「スーパークラス」の話は発散するので省略)。 >それはそうかもしれませんけど、具体的なオブジェクトにできないものが >抽象クラスで、具体的なオブジェクトを作れるものがconcrete classってのは、 >それほど無理はないんじゃないでしょうか。 「それはそうかもしれませんけど」「それほど無理はない」んならいいじゃん、 術語に過剰な期待をしてもしょうがない、と私は言っているわけです。 クラスを分類として考えるのがよいとCESさんがお考えなら、それが具体的に 有効であるケースを、例示して主張するのがよいのではないでしょうか。 「そのへんの入門書にある考え方だと、こういう例ではこういうモデリングを してしまいがちだけど、分類として考えればこんなモデリングになって、 こういう拡張をするときのことを考えたらこっちのほうが修正箇所が はるかに少なくてすむよね」とか。 結城浩さんが書いておられるように、「例は嘘をつかない」ですから。 http://www.hyuki.com/dig/eg.html

いつも「プログラミング言語を作る」を楽しく拝見させて頂いています。 早速、「正規表現ライブラリ鬼車の搭載」を拝見させて頂きました。 最後の方に、正規表現関連の関数がグローバルということが 書かれていましたが、私は、Pythonは、よく知らないのですが、 何で正規表現の関数をクロージャに押し込んで提供していないのですか？ 例えば、Luaであれば、Stringというクロージャに入っています。 また、crowbarには、まだハッシュを組み込んでなかったと思うのですが、 ハッシュは組み込まないのですか？ 必須なデータ構造だと思います。 あと、最近、Luaを勉強していて、組み込み言語と謳っている割りに 例えば、LuaとCとのインタフェースを書くのがかなり面倒で 少しがっかりしているのですが、crowbarはぜひとも組み込み部分を強化 して欲しいです (例えば、C側で、LuaのTableをダイレクトに作れず、Luaのスタックを 経由しないとできないので面倒)。 鬼車を搭載しても、まともに張り合ったら、Rubyに対抗するのは 難しいと思いますので、組み込み用スクリプトでメジャーなものは なさそうなので、そういう方向はどうでしょうか？ 私は、D言語やioはあまり知らないですが、組み込み用言語の デファクトスタンダードとか、存在するのでしょうか？

私は、ＬＩＮＵＸで動くＣＡＤを作りたいと思っています。 その中で、マクロのようなものを組み込みたいと思って、 自分で少し考えていたんですが、これは、これで、また新たな 専門的な知識が必要だと感じましたし、ＣＡＤ自体まだまだな 自分には、いつになることかとたまに、どこかにないかなと探 し続けていました。 今回ここにたどり着いて、サンプルを動かしてみました。 すごいですね。 ホームページ上では、僕が作ったソースに組み込めるようなことが 描いてありました。まだ試していませんが、試せるところまで進んだら ぜひ、使わせてください。 僕は、プロでもないし、未熟者ですが、そのときは、いろいろ質問 させてください。 最近、あれもやりたい、これもやりたいと悩んで、ＣＡＤ自体手を付けられない 状態でした。 このサイトに来て、このようなすばらしいものがあるのなら、 今は、マクロについては何も考えず、目標のＣＡＤに専念しようと やる気が起きてきました。ありがとうございます。

>何度も繰り返しますが、私が言っているのは、 >「術語に過剰な期待をするのはいかがなものか」 >ということだけです。 >スーパークラスという言葉を否定した覚えも、スーパークラスは集合論で言えば >スーパーセットである、というのを否定した覚えもありません。 よくわかんなくなってきました。「過剰な期待をするな」とはどういうことですか？ 「違和感を覚えるな」というのは無理な期待だ、ということでしょうか？

旧掲示板として存続してきたOTD版の掲示板ですが、最近は広告書き込みばかりで、 その量も尋常ではないので、閉鎖しました。トップページにも案内を出しましたが、 過去ログは以下のURLから参照できます。 http://kmaebashi.com/bbs/otdindex.html どうでもいいことですが、過去ログは、30件ずつブラウザで表示し、 HTML保存(ここは手作業)したものに対し、crowbarで変換をかけることで 生成しました。crowbarで行ったのは、広告やJavaScriptの削除、前後の ページへのリンクの付加です。 バリバリにうちの掲示板のHTMLに依存したスクリプトなので、そのまま 他の人の役に立つ可能性はゼロですが、数少ないcrowbarのサンプルソースとして 以下に公開しておきます。 http://kmaebashi.com/bbs/conv_crb.html

>ただ、違和感を感じるからといって否定するのでは、何かを学習することはできないでしょう。学習は違和感を覚え、それを解消することによって積み重ねていくものです。 だーかーらー。 いつ誰が、スーパークラス、サブクラスという言葉を否定しましたか? 何度も繰り返しますが、私が言っているのは、 「術語に過剰な期待をするのはいかがなものか」 ということだけです。 スーパークラスという言葉を否定した覚えも、スーパークラスは集合論で言えば スーパーセットである、というのを否定した覚えもありません。

>　私が最初から言っているのは、「術語に過剰な期待をするのはいかがなものか」ということです。 >　集合論で見て、サイヤ人はスーパーサイヤ人のスーパーセットですが、やっぱりスーパーサイヤ人の方に「スーパー」が付いている。そういう言葉の使い方が現実にある以上、「スーパークラス」という言葉に違和感を感じる人もそりゃいるだろうねえ、と言っているだけです。 そうかなぁ、とも思ったのですが、一人で３連投するのもどうかと思ったのでやめときました。 「スーパークラス」という用語に違和感を感じるのは構いませんが、しかし「基底クラス」という言い方はもっとまずいと思うのです。前述したように、クラスは上下関係ではなく包含関係にあるからです。 「スーパーサイヤ人の方がスーパーだ」という考えに固執していると、「サブクラス（に属するオブジェクト）は機能が多いものだ」という誤解を招きます。 「スーパークラス」「サブクラス」という用語を使わなくても、自然に集合論的考え方ができるのであれば、それで結構だと思います。 ただ、違和感を感じるからといって否定するのでは、何かを学習することはできないでしょう。学習は違和感を覚え、それを解消することによって積み重ねていくものです。 前にも言いましたが、「スーパークラスはサブクラスよりも『含むものが多い』という点で集合の能力が上、すなわちスーパーだ」という考え方もできます。そして、「スーパーサイヤ人は機能が多い方がスーパーなのに、集合論は機能が少ないほうがスーパーなんだ。そういうものなんだ」と違和感を感じたまま暗記するよりは、是非、違和感を解消していただきたいと思うのです。 というわけで、俺は「スーパークラス」「サブクラス」という呼び方を布教していきたいと思います。 > で、集合論で考えるなら円は楕円のサブセットなのであって、それを「客観的な視点などというものは存在しません」などと言って否定してしまったら、それこそ数学を全部敵に回すと思うんですが、如何? 「円は楕円のサブセットである」というのは、集合論が決めることではありません。数学（幾何学）が決めることです。 （どんな論理に基づくかは知りませんが）「楕円は円のサブセットである」と言っても、それは幾何学的には間違えているかもしれませんが、集合論的には間違えていません。集合論は集合の関係を提供するのみで、その中身の妥当性にまでは関与しないからです。 そして、数学さえ真理ではありません。かつてはユークリッド幾何学が真理とされていた時代もありましたが、今では「ユークリッド幾何学は、いくつかの都合のいい前提の基にのみ成立する、一面の真実でしかない」ということは広く知られています。

>こんばんは。archerと申します。 >「プログラミング言語を作る」のページの下のほうにある、 >「現状の最新版のダウンロードはこちらから。」のリンクが切れている（Not Found）ようです。 ご報告いただきありがとうございます。修正しました。

こんばんは。archerと申します。 「プログラミング言語を作る」のページの下のほうにある、 「現状の最新版のダウンロードはこちらから。」のリンクが切れている（Not Found）ようです。 とりあえず、報告まで。

>まさにその程度のプログラムにおいて、そしてそこから大きくしていく過程において、のこと >を自分は想定していました。 >for文やif文の学習という過程から、だんだんと大きなプログラムを組んでいく場合において、 >オブジェクト指向をうまく取り入れられないかな、と考えたわけです。 思うのですが、オブジェクト指向は目的ではなく手段なのだから、 for文やif文の学習という過程から、だんだんと大きなプログラムを組んでいく 場合において、「このままでは破綻する」という状況がオブジェクト指向でうまく 回避できる、というのが想像できればよいのではないでしょうか。 ま、とはいえ世の中には「5000行の関数」を書いてしまうツワモノもいるわけで、 力技でもできる奴(どういう意味で「できる」かはアレですが)はやってしまうという のもあります。実際、5000行はともかく数百行程度なら、どんな書き方をしていても なんとかなってしまう、という面はあります。では一万行に挑んで痛い目に遭ってみれば オブジェクト指向のありがたみがわかるのかというと…そうなのかもしれませんが、 それでは痛い目に遭うためのコストが大きすぎますよね。 そのあたりは、「この方法では、もっと規模が大きくなったときどうなるだろう?」と 想像力で補うのがよいのではないかと思います。 >しかし、これだとサブルーチンという考え方だけで大丈夫だという記述もあり、 サブルーチンで大丈夫な範囲ならサブルーチンで大丈夫。 オブジェクト指向の方がよいのなら、サブルーチンに比べて「どこがどうよいのか」が 説明できなければならない、というのが私の言いたかったところです。 >いろいろなオブジェクト指向入門で見た「コードの再利用」というのも、なんだか疑わしい >と思っています。継承することによって再利用というのがしっくりこなかったです。 これはたぶんRqさんの感覚のほうが正しいのではないかと。

>この違和感が「集合論で考えればわかりやすいね」で解決しなくて「いや、どうしても直感的に受け入れられない」ってことだとすると、オブジェクト指向を集合論で考えちゃいけねぇってことになる。それはいくらなんでも横暴じゃないかなぁ…数学を全部敵に回しそうだ。 　私が最初から言っているのは、「術語に過剰な期待をするのはいかがなものか」ということです。 　集合論で見て、サイヤ人はスーパーサイヤ人のスーパーセットですが、やっぱりスーパーサイヤ人の方に「スーパー」が付いている。そういう言葉の使い方が現実にある以上、「スーパークラス」という言葉に違和感を感じる人もそりゃいるだろうねえ、と言っているだけです。 　いつ私が「オブジェクト指向を集合論で考えちゃいけねぇ」と言いましたか? 言っていると思うのなら、その部分を具体的に引用して示してください。 　んで、集合論で考えるなら円は楕円のサブセットなのであって、それを「客観的な視点などというものは存在しません」などと言って否定してしまったら、それこそ数学を全部敵に回すと思うんですが、如何?

遅ればせながら、あけましておめでとうございます。 今年もよろしくお願いいたします。 つーわけでもう元日は終わっていますが壁紙変更。 去年もこれやって微塵も反応なかったんですがめげない。

こんばんは。前回は、はじめてであるのに名乗らずに失礼しました。 自分が浅学なのを暴露してしまうような気がしますが…こういう理解でいいのかな、と 少し確認の意味で書いてみます。 ＣＥＳ さん： >どの程度のことを「大規模」と言うかわかりませんが、オブジェクト指向が適用できない（適用する必要が無い）ほど小規模なものとなると、せいぜい 50 行…いや、20 ～ 30 行程度のプログラムになってしまうかなー、と。 まさにその程度のプログラムにおいて、そしてそこから大きくしていく過程において、のこと を自分は想定していました。 for文やif文の学習という過程から、だんだんと大きなプログラムを組んでいく場合において、 オブジェクト指向をうまく取り入れられないかな、と考えたわけです。 >> ・プログラムを分割することが大切 > >ＹＥＳ。それすげぇ大切。 この部分で、前にタイガーさんがおっしゃっていた >こうすることで、依存関係を親側に集中化でき、単純化できます。 というようなことを実現するために、分割が必要になってくるのだ、と自分は理解しています。 しかし、これだとサブルーチンという考え方だけで大丈夫だという記述もあり、どのように コードを組めばオブジェクト指向プログラミングとなるのか、というところが未だに自分の 中で曖昧になってしまっています。 いろいろなオブジェクト指向入門で見た「コードの再利用」というのも、なんだか疑わしい と思っています。継承することによって再利用というのがしっくりこなかったです。そこで デザインパターンから継承の利点などを見つけれればと思いましたが、自分にはまだ荷が 重かったようでした。 >目的が良くわかんないです。 >まず、「オブジェクト指向」と「手続き型」は対立しません。 >現在主流のオブジェクト指向言語は、手続き型言語に、オブジェクト指向のサポートを加えたものです。 >ですから、「手続き型の中でオブジェクト指向を実践」するということは、立派にオブジェクト指向です。 > >「手続き型の中でオブジェクト指向を実践」とは、どんなことを意図されて書かれたのでしょう？ いろいろな人がオブジェクト指向プログラミングの特徴について書いていますが、 オブジェクト指向プログラミングは、堅牢なコードを書いていく技術であり、そのために データの抽象化や、マルチプルインスタンス（これは堅牢なコードのためじゃないかも しれませんが）があるのかな、と思っています。 そのなかで、技術的なアプローチから入っていこう、とした場合に、まず何を理解して 実践すればいいのかが、現在のオブジェクト指向ではまったくといっていいほど分からない のでは、と思った次第です。 確かに、「再」入門の人々にとっては当たり前なのかもしれませんが、「初」入門の 人にとっては、ということです。（ということで、この質問はかなりこの掲示板の趣旨 からは離れているのかな、と思います。しかし、「初」入門の自分がいろいろな入門を 見てきた中で、一番しっくりきたのがこの「再」入門であったので、何かしらそういう 視点からの助言が得られるのでは…と思い、提示しました（大変参考になりました）。） >まぁ、最初のうちはわからないなりに模索して失敗してみろって事ですね。 >そのうち、だんだんとありがたみがわかってくると思います。 ということなので、今自分が実践できることは、プログラムを分割して、単一の仕事 だけをさせるようにし、責任の所在を分かりやすくしてみることかな、とおもいます。 そして、これから挑戦していくものとして、（ぱ) さんがおっしゃっていた >上に挙げたX-Drawでは、Shape(図形)にdraw()メソッドを付けることで、 >プログラムのあちこちにShapeの種類による分岐(Cならswitch case, Pascalなら >case of文ですか)を書くことを避けることができ、図形の追加が容易にできるので、 >これはまさに上のページやOOSCで挙げている例と合致していると思うのですが… という部分から、if文やcase文を使わないですむコードを書いてみたいと思っています。 具体的すぎる話だけだと、抽象度の高い設計ができないということなので、 データの抽象化というものを具体的にコードにできるようにしたいと思っています。 やってみて考えてみて、経験から分かってくるというのが唯一の正解である、という のは理解できるのですが、具体的にこういう学習をしてみようと思っていると書くこと によって、自分の進んでいるのがオブジェクト指向なのか、それとも間違っているのか について助言が得られたらな、と思っています。

>>「スーパーサイヤ人」がネタに出ましたね。集合で考えればふつうのサイヤ人が >>スーパーサイヤ人のスーパーセットです(悟飯やトランクスは混血だけど…)。 >>集合で考えれば確かにそうなんだけど、「スーパーサイヤ人」の方がスーパーだ、 >>という言葉の使い方も確実にあるわけで、そこに違和感を覚えてることも >>そりゃあるんじゃないかと。 > >＃言うまでもないことだとは思うのですが。 >「スーパーサイヤ人」と、そのスーパーセットである「サイヤ人」では、どっちがすごいか…というのは比べられません。 >「スーパーサイヤ人」と「ノーマルサイヤ人（？）」なら、スーパーサイヤ人の方がすごいですが、これはどちらも「サイヤ人」のサブセットです。 >「サイヤ人＝ノーマルサイヤ人」でないところが罠ですね。違和感の元はここかと。 この違和感が「集合論で考えればわかりやすいね」で解決しなくて「いや、どうしても直感的に受け入れられない」ってことだとすると、オブジェクト指向を集合論で考えちゃいけねぇってことになる。それはいくらなんでも横暴じゃないかなぁ…数学を全部敵に回しそうだ。

>「スーパーサイヤ人」がネタに出ましたね。集合で考えればふつうのサイヤ人が >スーパーサイヤ人のスーパーセットです(悟飯やトランクスは混血だけど…)。 >集合で考えれば確かにそうなんだけど、「スーパーサイヤ人」の方がスーパーだ、 >という言葉の使い方も確実にあるわけで、そこに違和感を覚えてることも >そりゃあるんじゃないかと。 ＃言うまでもないことだとは思うのですが。 「スーパーサイヤ人」と、そのスーパーセットである「サイヤ人」では、どっちがすごいか…というのは比べられません。 「スーパーサイヤ人」と「ノーマルサイヤ人（？）」なら、スーパーサイヤ人の方がすごいですが、これはどちらも「サイヤ人」のサブセットです。 「サイヤ人＝ノーマルサイヤ人」でないところが罠ですね。違和感の元はここかと。

>＃自分で言語を作ったら別の呼び方にしたいけれど。 では言語を作ることをお勧めしますです。 # と思って「プログラミング言語を作る」を続けてるわけですが。 でも、たとえばcrowbarではオブジェクトの要素を「メンバ」と呼んでいますが、 JavaScriptあがりの人があれをプロパティと呼んだり、Selfとかあがりの人が スロットと呼ぶことを妨げようとは思いません。「crowbarにはプロパティはない」とか 言い始めたら、そりゃトンデモです。 だからもちろんJavaにはポインタが…すみません脱線しすぎました。 >集合の「スーパーセット」と「サブセット」に対応すると考えれば、 >じつにしっくり来るです。 この議論は昔JavaHouseでやったことがあるんですが、その時は 「スーパーサイヤ人」がネタに出ましたね。集合で考えればふつうのサイヤ人が スーパーサイヤ人のスーパーセットです(悟飯やトランクスは混血だけど…)。 集合で考えれば確かにそうなんだけど、「スーパーサイヤ人」の方がスーパーだ、 という言葉の使い方も確実にあるわけで、そこに違和感を覚えてることも そりゃあるんじゃないかと。 >C++ 流儀の「基底クラス」は、スーパーの方が下のように聞こえるので直感的？ Straustrupは、そこに違和感を感じたから基底クラス(base class)という言葉にした、 という話を聞いたことがありますが、確か2chで読んだ話だと思うので信憑性は 定かではありません。

>>たとえば「スーパー」クラスの方が「サブ」クラスよりへぼいってのも直感には >>反しますよね。術語は所詮術語なので、あんまり厳密性を求めてもしょうがない >>気がします。 > >集合の「スーパーセット」と「サブセット」に対応すると考えれば、じつにしっくり来るです。 >「上位クラス」「下位クラス」というネーミングも、上の方がショボい気がしてよろしくないですね。 >C++ 流儀の「基底クラス」は、スーパーの方が下のように聞こえるので直感的？ >ただ、機能に注目するとサブクラスの方が多いんですが、スーパーの方が「範囲が広い」という点は優位ですね。 クラスはオブジェクトの集合なのだから、上下関係ではなくて包含関係で見るべき。 だとすれば、「サブクラスがヘボい」んじゃなくて「スーパークラスもサブクラスも同じ機能を持っているんだけど、スーパークラスではその一部に言及されていないだけ」なのだから、機能の比較はできなくて、広さで優位に立つスーパークラスの方がすごい。 こういうところも、論理面から攻めると違和感を無くすことができました、という例。

>>concrete class って何なのか、参考までにお聞きしてもよろしいでしょうか。 > >通常の定義では、abstractでないクラスがconcrete classでしょう。 >Googleしてもいっぱい出ますし。 やっぱりそれですか。 それでいくと、継承できないと問題が出そうな気もしますけど…まぁそれは置いといて。 >それはそうかもしれませんけど、具体的なオブジェクトにできないものが >抽象クラスで、具体的なオブジェクトを作れるものがconcrete classってのは、 >それほど無理はないんじゃないでしょうか。 現状、そのような用法で広く使われておりますので、あえてそれに反旗を翻すような真似はいたしませんです。 ＃自分で言語を作ったら別の呼び方にしたいけれど。 >たとえば「スーパー」クラスの方が「サブ」クラスよりへぼいってのも直感には >反しますよね。術語は所詮術語なので、あんまり厳密性を求めてもしょうがない >気がします。 集合の「スーパーセット」と「サブセット」に対応すると考えれば、じつにしっくり来るです。 「上位クラス」「下位クラス」というネーミングも、上の方がショボい気がしてよろしくないですね。 C++ 流儀の「基底クラス」は、スーパーの方が下のように聞こえるので直感的？ ただ、機能に注目するとサブクラスの方が多いんですが、スーパーの方が「範囲が広い」という点は優位ですね。

>concrete class って何なのか、参考までにお聞きしてもよろしいでしょうか。 通常の定義では、abstractでないクラスがconcrete classでしょう。 Googleしてもいっぱい出ますし。 >「クラスとは分類である」という考えをすると、具体的なものはオブジェクトで、 >クラスは全て抽象的なものということになるからです（その点、「抽象クラス」 >ってのは良くないネーミングだと思います）。 それはそうかもしれませんけど、具体的なオブジェクトにできないものが 抽象クラスで、具体的なオブジェクトを作れるものがconcrete classってのは、 それほど無理はないんじゃないでしょうか。 たとえば「スーパー」クラスの方が「サブ」クラスよりへぼいってのも直感には 反しますよね。術語は所詮術語なので、あんまり厳密性を求めてもしょうがない 気がします。

>class bird { virual void fly()=0; }; >という設計においては「こうもりは鳥」であるし「ダチョウは鳥でない」 これはすごく面白い。深いなぁ。

>以前ここの掲示板でオブジェクト指向のポイントは、以下の >２点であるという結論になっていたと思います。 >1. データの抽象化 >2. マルチプルインスタンス >何ができれば、オブジェクト指向になるのかは難しいと思いますが、 >上記の２点はオブジェクト指向を語る上で重要だと思います。 >あと、データのアクセス制御(制限？)なども重要だと思っています。 アクセス制限は抽象化の範疇だと思います。

>結局設計に万能の「正解」はなく、たとえば拡張に備えるにしても「どんな拡張が >ありそうか」ということをある程度予測してからでないと設計方針は選べないんじゃ >ないかなあ、と思います。つまらない結論かもしれませんけど。 「分析」→「設計」→「実装」の流れで言うならば、万能の唯一解がないのは「分析」でしょうね。 分析が正しくできていれば、正しい設計はおのずと導かれる気がします。 >そうですよね。実のところ私はconcrete classなんざ継承できなくても >よいのでは、と思っていますが、上で出ている例(Note, PUBLICICATION, Shape)は >どれも抽象クラスですし、使用範囲を間違えなければ、有効に使えると思います。 concrete class って何なのか、参考までにお聞きしてもよろしいでしょうか。 「クラスとは分類である」という考えをすると、具体的なものはオブジェクトで、クラスは全て抽象的なものということになるからです（その点、「抽象クラス」ってのは良くないネーミングだと思います）。 ＃実装の再利用のためのクラスはクラスである意味が薄いと思いますし。

＃話が脇にそれてたので源流復帰。 > ・大規模なプログラムの開発でないと効果を発揮しない どの程度のことを「大規模」と言うかわかりませんが、オブジェクト指向が適用できない（適用する必要が無い）ほど小規模なものとなると、せいぜい 50 行…いや、20 ～ 30 行程度のプログラムになってしまうかなー、と。 > ・プログラムを分割することが大切 ＹＥＳ。それすげぇ大切。 > ・デザインパターン（設計）を知らないといけない（？ 知っていて損はないけれど、必須ではないと思う。俺も知らないし。 >そしてここのオブジェクト指向再入門で言っているマルチプルインスタンスというのは オブジェクト指向の一番の基礎はカプセル化です。 カプセル化ってのは、「データと処理をペアにして、このペアを最小単位として考える」ことです。 マルチプルインスタンスってのは、このペアがいっぱいあることです。 >では、ここからが自分の疑問の核心なのですが、手続き型の学習の中で（あるいは小規模すぎるプログラムの中で）でもオブジェクト指向を実践する方法はないだろうか、ということです。 目的が良くわかんないです。 まず、「オブジェクト指向」と「手続き型」は対立しません。 現在主流のオブジェクト指向言語は、手続き型言語に、オブジェクト指向のサポートを加えたものです。 ですから、「手続き型の中でオブジェクト指向を実践」するということは、立派にオブジェクト指向です。 「手続き型の中でオブジェクト指向を実践」とは、どんなことを意図されて書かれたのでしょう？ > ・「開放・閉鎖の原則(OCP:Open-ClosedPrinciple)」 これは「よりよいオブジェクトの設計のための指針」なので、初歩でまず覚えるべきことではないような気がします。 >しかしそのためには手続きを分節化し、プログラムを設計する能力がいるだろう、と思っています。 これはオブジェクト指向でなくとも、多かれ少なかれ必要な能力です。 >このような場合に、デザインパターンが有効なのだと思いますが、具体的にどうプログラムを組むのか、というところで自分は躓いている状況です。 別の掲示板で、素晴らしい言葉を見つけました。この言葉を送ります。 Good judgement comes from experience, and experience comes from bad judgement. （よい判断は経験から来ます。また、経験は悪い判断から来ます。 ） Experience is a wonderful thing. It enables you to recognize a mistake when you make it again. （経験は素晴らしいものです。再びそれを作る場合、それによって誤りを認識することができます。） まぁ、最初のうちはわからないなりに模索して失敗してみろって事ですね。 そのうち、だんだんとありがたみがわかってくると思います。

>分析→設計→実装、の段階のどこのレベルで話をするかがきわめて大事。 そう思います。 私は、ビーム砲の弾からインベーダーへの関連を持つというモデルを正解として 紹介していることをもって「憂鬱なプログラマのためのオブジェクト指向開発講座」を 批判していますが、「分析」のレベルなら、ビーム砲の弾からインベーダーへ 線を引っ張るのもよいのかもしれません。実際、そういう文脈で、私も文章を 批判している記事は見たことがあります。 インベーダーゲームにおいて、ビーム砲の弾がインベーダーを破壊するのは 確かですから、ここに線を引っ張るのは、客先の業務でありがちな「暗黙知」を 明確にするという意味では意味があるのかもしれません。 …が、憂鬱本の場合、「クラスのメンバに相手クラスのポインタを持つということで 実際に関連を張るわけです」と明言している点で、これは完璧に実装の本であり、 結局憂鬱本がトンデモ本であるという評価に揺らぐところはないわけですけど。

>何が言いたいかというと、「円は楕円のサブクラスである」というのは、 >そうであったほうが都合がいい場合にのみ、真実となるわけです。 まったく同意です。私が言いたかったのは、「数学や論理学の世界」を突き詰めると、 円は楕円のサブクラスである、というのを、絶対の真実として突き進んでしまう 危険があるのではないか、ということです。 >「Circle を Ellipse のサブクラスにすることが妥当と思えない」のは >ひとつの真実ですが、絶対の真理ではありません。Circle を Ellipse の >サブクラスにすることが適切な場合もあります。 まあそうかもしれません。(私にはそういう状況が思いつかないというだけで) その意味では、「だからといってCircleをEllipseのサブクラスにすることが 妥当とは思えません」と書いたのは不用意だったかもしれませんね。

もう全面的に御意。 分析→設計→実装、の段階のどこのレベルで話をするかがきわめて大事。 >でも、案件Ａで今書いたコードが、案件Ａ ver2 でも有効なことはすごく大切。それもひとつの再利用性。 ここんところ、鼻血が出るほど御意。 幸い今までのところ ver2 で設計見直しになった例は（俺の担当範囲では）まだないので 「ＯＯって何」に対する俺の理解はそう外れてはいないのだと思われ。 分析→設計のレベルの話を後輩君にするときにはこういう例を出してる。 class bird { virual void fly()=0; }; という設計においては「こうもりは鳥」であるし「ダチョウは鳥でない」 「こうもりは鳥でない」「ダチョウが鳥である」にしたいのなら、先の設計は変。 設計を見直す＝分析のしなおし、だよん。って。

そして、[651] をちょっと補足。 >>こっちの考え方は、突き詰めると数学や論理学の知識が必要になってしまうので、 >>実装面ほど簡単ではありません（私も勉強したいのですが、それらベースと >>なる知識が足りないため足踏みしています）。 >実装面べたべたで行くと、抽象度の高い設計ができずに後ではまるといった >問題があるのかもしれませんが、実装を離れて理論で突っ走っても、結局変なことに >なってしまうように思います。月並みですがバランスが大事、ということでしょうか。 設計段階においてはその通りです。 ただ、ソフトウェアは「設計」「実装」の２段階ではなく、その前に「分析」を加えた３段階で作られます。そして、（本来は）分析なくして設計はなく、設計なくして実装はありえません。 実装の方が触るのは容易なので、実際には「実装→設計→分析」とスキルアップしていくケースが多いのでしょうか。 たぶん「分析」ができないと、オブジェクト指向の真髄を知ったとは言えないだろうなぁ、と思うわけです（実装だけ知っていれば、「オブジェクト指向プログラミング」は極められるかもしれませんが、「オブジェクト指向」を極めるにはそれだけでは足りません）。 当初のタイトルは『オブジェクト指向「初」入門』ですが、これはつまり『オブジェクト指向プログラミング「初」入門』ということですよね。 分析入門もあればいいのになぁ…と思いつつ、最近こんな本を読んでいたり。 http://www.sra.co.jp/people/aoki/IntroductionToOOAOOD/ ただ、「分析」を行うには、論理学を知っていたほうがいいのはあるかもしれませんが、[651] で意図したのはそういうことではありません。 「オブジェクト指向」そのものの数学的、論理学的意味についてです。 たとえば、クラスは分類だと言いましたが、数学的に言えば、クラスはオブジェクトの集合です。派生クラスは部分集合で、多重継承は積集合で…なんて数学の知識は、実務では分析レベルでもそうそう必要ない気がします。 もっと突っ込むと、群論とか圏論といった、ムズカシイ数学が出てきます（勉強したいのですがさっぱりわかりません）。 ちなみに、圏論には「オブジェクト」「クラス」「モルフィズム」というような用語が登場します。…なんとなくオブジェクト指向チックですよね？ こういう方面から攻めるのも併用すると、より理解が深まるんじゃないかな、ってことです。

> えっと、前橋さんとCESさんと結局同じこといってるようにしか見えないのですが気のせい？ > >> 月並みですがバランスが大事 >> 「それをどう見れば都合がいいか」 > 今、やってる案件においてどう設計すれば適切か、バランスとか都合よさとかから決めろ > としか読めん。 たぶん違うこと言ってる。 前橋さんは > 分析レベルでは、確かに「分類」と捉えたほうがよいのかもしれません とも言われているけれど、俺がしている話はどれも分析レベルだったんだ。と、今更気づく。 そこから一段階進んだ「設計」の段階では、確かにバランスが大事。 [653] のレスをつけたのは「円を楕円のサブクラスにすることが間違いとは限らないよ」って言いたかったから。 > 「円と楕円はどっちがスーパークラスか?」という問題で間違った解を選んでしまいそうな気もします。 > 数学や論理学の世界では、円は楕円の特殊形ですが、だからといってCircleをEllipseのサブクラスにすることが妥当とは思えません。 少なくとも、この問題文だけを見て、「円が楕円のサブクラスであるのは間違いだ」とは言えない、ということ。 「常に」という言葉を補って、「Circle を Ellipse のサブクラスにすることが『常に』妥当とは思えません」ということならば、それは正解。 >だから私は「再利用性」って奴にはかなり疑問。 >案件Ａにおいては今書いたコードが適切であっても、それは案件Ｂでは通用しない >ってのはごく普通にありそうですし。 でも、案件Ａで今書いたコードが、案件Ａ ver2 でも有効なことはすごく大切。それもひとつの再利用性。 >>「真実はいつもひとつ！」 >いや、真実はいつもひとつです（と、俺は思う）。 >その真実ってのは、人に理解できるような代物ではなかったりすることもある。 >だから、個々人で理解の仕方が違うってのは普通の話。 ひとつしかないのは「事実」だと思う。 それをどう見るかが「真実」。 でも、「真実」という言葉が「人によって違うもの」という意味に合致するかどうかはどうでもいい（というか、自分でもそういう意味なのかは疑問）。 ただ、「真実は人の数だけある」ってよく聞くから、その言葉を使っただけで、「普遍的に正しいものは無いんだよ」ってことが伝わるなら、「真実」って言葉にこだわる必要はない。

えっと、前橋さんとCESさんと結局同じこといってるようにしか見えないのですが気のせい？ >月並みですがバランスが大事 >「それをどう見れば都合がいいか」 今、やってる案件においてどう設計すれば適切か、バランスとか都合よさとかから決めろ としか読めん。 だから私は「再利用性」って奴にはかなり疑問。 案件Ａにおいては今書いたコードが適切であっても、それは案件Ｂでは通用しない ってのはごく普通にありそうですし。 >「真実はいつもひとつ！」 いや、真実はいつもひとつです（と、俺は思う）。 その真実ってのは、人に理解できるような代物ではなかったりすることもある。 だから、個々人で理解の仕方が違うってのは普通の話。 どの角度から見るかで見え方＝コードの実装が異なるだけです。 同じ真実を違う角度で見れば、違うコードになる。ってただそれだけと思う。

>「円と楕円はどっちがスーパークラスか?」という問題で間違った解を選んで >しまいそうな気もします。 >数学や論理学の世界では、円は楕円の特殊形ですが、だからといってCircleを >Ellipseのサブクラスにすることが妥当とは思えません(ただ、メンバが増えている >からといって、EllipseをCircleのサブクラスにするのが適切とも思えません)。 「真実は人の数だけある」とか、よく言われますよね。 唯一不変の真理なんてものはどこにも無くて、人によって「それをどう見れば都合がいいか」というのが違うわけです（大勢にとって都合がいいことが真理だと勘違いされがちですが…）。 何が言いたいかというと、「円は楕円のサブクラスである」というのは、そうであったほうが都合がいい場合にのみ、真実となるわけです。オブジェクト指向では、よく「正方形は長方形のサブクラスである」という話が問題になりますが、これも同様ですね。 我々の日常でも「リンゴは果物のサブクラスである」というのは一面の真実ですが、唯一の真理ではありません（植物学者には「リンゴはバラ科のサブクラスである」の方が都合がいいでしょうし、スーパーでは「リンゴは商品のサブクラスである」のほうが都合がいいでしょう。これらはどれも真実です）。 客観的な視点などというものは存在しません。 「Circle を Ellipse のサブクラスにすることが妥当と思えない」のはひとつの真実ですが、絶対の真理ではありません。Circle を Ellipse のサブクラスにすることが適切な場合もあります。どちらも正解で、間違いは名探偵のように「真実はいつもひとつ！」だと思うことです。

>例えば、「クラス」という用語の意味は「分類」であって、「原型」では >ありませんから、「クラスからオブジェクトを作る」という言い方は >おかしいのです（実装面からの理解であれば問題ありません）。 たとえばUMLだと、「継承」という言葉よりも「汎化」という言葉を使いますよね。 クラスという言葉の辞書的な定義はともかく(単に用語が不適切であるという可能性も あるので)、分析レベルでは、確かに「分類」と捉えたほうがよいのかもしれません。 >こっちの考え方は、突き詰めると数学や論理学の知識が必要になってしまうので、 >実装面ほど簡単ではありません（私も勉強したいのですが、それらベースと >なる知識が足りないため足踏みしています）。 ただ、そっち方面を突き詰めると、たとえば(よくある例ですが) 「円と楕円はどっちがスーパークラスか?」という問題で間違った解を選んで しまいそうな気もします。 数学や論理学の世界では、円は楕円の特殊形ですが、だからといってCircleを Ellipseのサブクラスにすることが妥当とは思えません(ただ、メンバが増えている からといって、EllipseをCircleのサブクラスにするのが適切とも思えません)。 実装面べたべたで行くと、抽象度の高い設計ができずに後ではまるといった 問題があるのかもしれませんが、実装を離れて理論で突っ走っても、結局変なことに なってしまうように思います。月並みですがバランスが大事、ということでしょうか。

オブジェクト指向を学ぶには、２つのアプローチがあると思います。 ひとつは技術面から、もうひとつは論理面からです。 技術面からというのは、よく言われている「クラス、継承、カプセル化、多態性、OCP」などのキーワードから理解していく方法です。実装面からのアプローチとも言えます。 プログラムをいかにうまく分割し、個々の保守性を上げるかという点が重要です。 論理面は、思想面とも言えるかもしれません。 例えば、「クラス」という用語の意味は「分類」であって、「原型」ではありませんから、「クラスからオブジェクトを作る」という言い方はおかしいのです（実装面からの理解であれば問題ありません）。 オブジェクトは作るのではなく、既にこの現実世界に存在しているのです。それを抽象化して、分類したものがクラスであるというのが、この考え方の第一歩ではないかと思われます。 こっちの考え方は、突き詰めると数学や論理学の知識が必要になってしまうので、実装面ほど簡単ではありません（私も勉強したいのですが、それらベースとなる知識が足りないため足踏みしています）。 技術面の方がわかりやすいのですが、論理面を知らないと、オブジェクト指向の真髄を知っているとは言えないと思います（技術面だけ理解してオブジェクト指向を知った気になっていると、失敗すると思います）。そして、論理面がわかってくると、技術面が、すとんと胸に落ちるように理解できるようになるのではないでしょうか。 オブジェクト指向がこれだけ流行っているのですから、論理面からの入門ももっとあっていいと思うんですけどね…。

こんにちは。 >いろいろなオブジェクト指向入門を見てきて、オブジェクト指向は > ・大規模なプログラムの開発でないと効果を発揮しない > ・プログラムを分割することが大切 > ・デザインパターン（設計）を知らないといけない（？ >という特徴を持っているのではないかと思っています。 私は、上記のどれもオブジェクト指向の特徴を表していないと 思います。 以前ここの掲示板でオブジェクト指向のポイントは、以下の ２点であるという結論になっていたと思います。 1. データの抽象化 2. マルチプルインスタンス 何ができれば、オブジェクト指向になるのかは難しいと思いますが、 上記の２点はオブジェクト指向を語る上で重要だと思います。 あと、データのアクセス制御(制限？)なども重要だと思っています。 >では、ここからが自分の疑問の核心なのですが、手続き型の学習の中で（あるいは小規模すぎるプログラムの中で）でもオブジェクト指向を実践する方法はないだろうか、ということです。 > >今自分が目をつけているのが、 > ・「開放・閉鎖の原則(OCP:Open-ClosedPrinciple)」 >というもので、これにのっとって実践を進めれば今ある機能を追加していくということでオブジェクト指向の利点を理解しやすく、かつ小さなプログラムを大きくしていけるのではないかと考えています。ここでの継承は、コードの再利用ではなく堅実なプログラムを組むため、という理由付けになりオブジェクト指向と呼べるのでは？と思っています。 > >しかしそのためには手続きを分節化し、プログラムを設計する能力がいるだろう、と思っています。 >このような場合に、デザインパターンが有効なのだと思いますが、具体的にどうプログラムを組むのか、というところで自分は躓いている状況です。 私は普段オブジェクト指向言語を使用していないのですが、 オブジェクト指向を意識したプログラミングをしています。 小規模であっても、手続き型言語であってもオブジェクト指向的 発想は可能です。 例えば、GUIのいくつかのパーツがあって、これらが互いに依存しあう 場合、これら同士でお互いを直接呼び出さないようにします。 必ず親(Mediator)を作って、間接的に制御します。 こうすることで、依存関係を親側に集中化でき、単純化できます。 これの本質部分は、全くオブジェクト指向は関係ありません。 GUIパーツ自身は、本来自分がやるべきことのみ やらせるようにします(単一責任の原則)。 あと、OCPにより、小さなプログラムを大きくしていける (コードを再利用する)というのは、私はそんなに単純ではない と思います。 OCPとは、つまり、上側のコードの再利用であり、下側の コード(処理やデータなど)を追加のみするということですが、 それが、そんな単純にうまくいくなら、トップダウンの 開発が重要ということになります。 仕様変更によるプログラムへの影響は多くが、より上側の処理 であり、より下側の処理の方が再利用の確率は高いと 思います。 プログラムを大きくしていく秘訣はいかにプリミティブな 関数など(より下側の処理)を充実していくかとか、 いかにモジュール化により、プログラムを分割していくかに よると思います。 そもそもOCPは、オブジェクト指向言語だけでは不十分で、 例えば、ログの処理やエラー処理が入ると それだけで処理の「汎用性」が失われ、OCPが成立しません (例えば、エラーを出すタイミングを変えるなど)。 アスペクト指向言語があれば十分かは分かりませんが、 あらかじめ仕様変更を予想してOCPが成立するように 再利用可能なコードを組むのは現実的には不可能だと思います。 但し、局所的に(場合によって)は、うまくいく時ももちろんあります。

はじめまして。 >いろいろなオブジェクト指向入門を見てきて、オブジェクト指向は > ・大規模なプログラムの開発でないと効果を発揮しない > ・プログラムを分割することが大切 > ・デザインパターン（設計）を知らないといけない（？ >という特徴を持っているのではないかと思っています。 デザインパターンはOOPの応用例であって、デザインパターンのためには OOPを知らないといけないけど、逆は真ではないのではないでしょうか。 GoFのパターンにはある意味マニアックなものもありますし。 >では、ここからが自分の疑問の核心なのですが、手続き型の学習の中で >（あるいは小規模すぎるプログラムの中で）でもオブジェクト指向を >実践する方法はないだろうか、ということです。 「小規模すぎる」というのがどの程度かわかりませんが、先に例に出した オセロや、以下のページにおいてあるドローツールなどは、趣味でも 十分作成可能な規模だと思いますがどうでしょうか。 ドローツール「X-Draw」のJavaアプレットによる実行例: http://kmaebashi.com/nazojava/xdraw/index.html サンプルソースはこちら: http://kmaebashi.com/nazojava/index.html >今自分が目をつけているのが、 > ・「開放・閉鎖の原則(OCP:Open-ClosedPrinciple)」 >というもので、これにのっとって実践を進めれば今ある機能を追加していくと >いうことでオブジェクト指向の利点を理解しやすく、かつ小さなプログラムを >大きくしていけるのではないかと考えています。 OCPというと、最近Matzにっき経由でこんなページを見つけましたが http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp-2.html ここの例だと音符クラスを使っていますね。 元祖MayerさんのOOSC(第1版)だと出版物(PUBLICIATION)クラスです。 上に挙げたX-Drawでは、Shape(図形)にdraw()メソッドを付けることで、 プログラムのあちこちにShapeの種類による分岐(Cならswitch case, Pascalなら case of文ですか)を書くことを避けることができ、図形の追加が容易にできるので、 これはまさに上のページやOOSCで挙げている例と合致していると思うのですが… ただ、ドローツール程度ではこれでよくても、実際大規模なCADなどでこういう 方法が使えるかといえば、 ・draw()といっても、ウインドウシステム等の違いにより描画方法は異なる。 　ディスプレイリストを保持するシステムを使うなら、そもそも描画はdraw()じゃないぞ。 ・Shapeだからといってdraw()するとは限らない。データをファイルから 　読み込んで解析だけして結果をテキストファイルに吐くようなツールだってあるぞ。 という問題もあるわけでして(あっちこっちに書いてるネタですが)。 結局設計に万能の「正解」はなく、たとえば拡張に備えるにしても「どんな拡張が ありそうか」ということをある程度予測してからでないと設計方針は選べないんじゃ ないかなあ、と思います。つまらない結論かもしれませんけど。 >ここでの継承は、コードの再利用ではなく堅実なプログラムを組むため、 >という理由付けになりオブジェクト指向と呼べるのでは？と思っています。 そうですよね。実のところ私はconcrete classなんざ継承できなくても よいのでは、と思っていますが、上で出ている例(Note, PUBLICICATION, Shape)は どれも抽象クラスですし、使用範囲を間違えなければ、有効に使えると思います。

オブジェクト指向再入門、とても面白く読ませていただきました。その中で ・手続き型言語を習得している「途中」の自分がどのようにオブジェクト指向を実践していけるのだろうか というところで疑問を抱いたので質問したいと思います。ここでのオブジェクト指向議論とは違う疑問なのかもしれませんが、書きたいと思います。 自分は、対象読者とされている「手続き型言語を習得し」た人ではないです。大学に入ってからプログラミングを習っています。使っている言語はDelphiです。 Delphiはオブジェクト指向言語ということだったのですが、学んでいるのは手続き型の勉強なのではないか、と感じました。そこからオブジェクト指向に興味を持ち、調べたもののこの再入門冒頭に書かれていたとおり、挫折しました。そして、もう一度と思っているところです。 いろいろなオブジェクト指向入門を見てきて、オブジェクト指向は ・大規模なプログラムの開発でないと効果を発揮しない ・プログラムを分割することが大切 ・デザインパターン（設計）を知らないといけない（？ という特徴を持っているのではないかと思っています。 そしてここのオブジェクト指向再入門で言っているマルチプルインスタンスというのは、Delphiのコードで言うと Type TStringList = class(TString); でTStringList型が出来て（これが「わけのわからない例え話」だったらすみません…） var Str1,Str2 : TStringList; というPrivate宣言をすることによって Str1 := TStringList.Create; Str2 := TStringList.Create; という具合に、同じ形のものを複数作成できる。そして、 Str1.hogehoge; Str2.hogehoge; というように、命令の主体を明らかにできる、ということが具体的な内容なのかなと考えています。 では、ここからが自分の疑問の核心なのですが、手続き型の学習の中で（あるいは小規模すぎるプログラムの中で）でもオブジェクト指向を実践する方法はないだろうか、ということです。 今自分が目をつけているのが、 ・「開放・閉鎖の原則(OCP:Open-ClosedPrinciple)」 というもので、これにのっとって実践を進めれば今ある機能を追加していくということでオブジェクト指向の利点を理解しやすく、かつ小さなプログラムを大きくしていけるのではないかと考えています。ここでの継承は、コードの再利用ではなく堅実なプログラムを組むため、という理由付けになりオブジェクト指向と呼べるのでは？と思っています。 しかしそのためには手続きを分節化し、プログラムを設計する能力がいるだろう、と思っています。 このような場合に、デザインパターンが有効なのだと思いますが、具体的にどうプログラムを組むのか、というところで自分は躓いている状況です。 しかし、上記のようなオブジェクト指向「初」入門が、オブジェクト指向言語から入った人には必要なのではないか、と思いました。再入門という観点からは不適切かもしれませんが、提起してみました。 乱文失礼いたしました。

>三角格子の各線を(軸でなく)座標値とすれば、隣に行くにはふたつの値を >いじらなければいけませんから、これはNykRさんのものと同じになるのでしょうか。 えーっと、各線に座標値を割り当てて、 　　 ｜　　　　　｜ 　　 x0　　　　　x1 　　 ｜　　　　　｜ 　　／＼　　　　／＼ 　y0　 z0　　y1　　z1 ／　　　 ＼／　　　　＼ 「各マスの中心から、各辺に対して伸ばした線を軸とする」と、 x0＝x1, y0≠y1, z0≠z1 だから 隣に行くためにいじる値は2つになりますね。 私のと同じになるみたいです。 んーと、でも三角格子の各線を軸とする方法もあると思いますよ。 私の方法をもう少しまじめに書きます。 んーと、 上から下へのラインを x軸 右上から左下へのラインを y軸 左上から右下へのラインを z軸 とすると、あるマスから例えば左右のマスへ移動するとき、 x軸方向に0、y軸方向に±1、z軸方向に±1 (× 辺の長さ分) 動かさなきゃいけません。 他の2方向についても2つの値をいじらなきゃいけませんよ、と。 で、この場合は、辺と座標軸が1対1に対応しています。 (ぱ)さんの最初の方法は、本来同一平面上にあるマスを別の平面にある要素(配列の)として表そうとしたところに問題があったのではないかと。

>>各マスの中心から、各辺に対して伸ばした線を軸とする、というイメージです。 > >ええと、あるマスが位置(i, j, k)にあったとします。 >このとき周りのマスは ... >右下 と 右隣の左下 のマスは同一のはずなので、別の場所にあるのはまずいのではないかと。 あれっ? 確かにおっしゃる通りです。よく考えずに書いていました。 いやそのマスと座標値が1:1対応しなきゃいかんよね、とは考えていて、 三角格子の交点をつまんでひっぱり挙げるとついて来る線は3本に決まるから、 1:1対応だよな、とか思っていましたが、この時三角格子の各線は座標値を 表しているのであって、軸を表しているわけではないですからね。 とここまでは実は考えていたつもりなんですが、同じだよな、となぜか (2次元の座標系のイメージにひきずられていたのでしょう)考えて 先の投稿のように書いてしまったわけなんですが、 三角格子の各線を(軸でなく)座標値とすれば、隣に行くにはふたつの値を いじらなければいけませんから、これはNykRさんのものと同じになるのでしょうか。

横から失礼します。 >>>六角オセロの場合は、3次元の配列にすると、はさむところの判定が >>>楽にできるかもしれませんね。各添え字の上限が一定しないですけど。 >> この場合、最初の2次元は私の書いたx,y座標ですか? >> 3つめの座標はどういう方向になるんですか? > >各マスの中心から、各辺に対して伸ばした線を軸とする、というイメージです。 ええと、あるマスが位置(i, j, k)にあったとします。 このとき周りのマスは 右隣 : (i+1, j, k) 右下 : (i, j+1, k) 左下 : (i, j, k+1) 右隣の左下 : (i+1, j, k+1) にあるはずですよね？(とは限りませんけど、気にしないことにします) 右下 と 右隣の左下 のマスは同一のはずなので、別の場所にあるのはまずいのではないかと。 何か勘違いしてたらすいません。 ＃ こんなの思いつきました。直方体を斜めから見たら6角形になることを利用する訳ですが、 ＃ どっち向きでも添字を2つ動かさなければならない・・・。 ／ ＼ ／ ＼ ／ ＼ |＼ ／|＼ ／|＼ ／| ＼|／ ＼|／ ＼|／ ＼ 　 |＼ ／|＼ ／|＼ ／| ／ ＼|／ ＼|／ ＼|／ |＼ ／|＼ ／|＼ ／| ＼|／ ＼|／ ＼|／ ＼ 　 |＼ ／|＼ ／|＼ ／| 　 ＼|／ ＼|／ ＼|／

>>>六角オセロの場合は、3次元の配列にすると、はさむところの判定が >>>楽にできるかもしれませんね。各添え字の上限が一定しないですけど。 >> 3つめの座標はどういう方向になるんですか? >各マスの中心から、各辺に対して伸ばした線を軸とする、というイメージです。 >4角形だと、辺の数が4だから、軸の数は2, >6角形だと、辺の数が6だから、軸の数は3, >この方法だと、ある軸の数値を変化させることで、次々と隣のマスが現れますから、 >はさむところの判定が楽にできるのではないかと。 なるほどぉ。勉強になります。 ありがとうございます。 ...とは言っても実際にゲームを作ったりはしないのですが 何しろ時間がなくて...能力も?(^^;) >>友人や家族でこのゲームを良くやるのですけど、 >>いつもどうやってプログラムするのかなって考えていたりします＜－職業病?(^^;) >>そういう融通が効く人間ってすごいなぁとか思います。 >人間の「知能」って不思議です。 最近、コンピュータなしだとほとんど仕事ができないので 考えるのは全てコンピュータの方で私自身はコンピュータの (特殊な)入力補助装置になりさがっているのではないかなどと 感じ出しているのですが、そう錯覚することが「知能」なのでしょうか。

>>六角オセロの場合は、3次元の配列にすると、はさむところの判定が >>楽にできるかもしれませんね。各添え字の上限が一定しないですけど。 > この場合、最初の2次元は私の書いたx,y座標ですか? > 3つめの座標はどういう方向になるんですか? 各マスの中心から、各辺に対して伸ばした線を軸とする、というイメージです。 ＼ ＼ ＼ ／＼／＼／＼ ―｜00｜01｜02｜ ＼／＼／＼／＼ ― ｜10｜11｜12｜ ／＼／＼／＼／ ―｜20｜21｜22｜ ＼／＼／＼／＼ ― ｜30｜31｜32｜ ＼／＼／＼／ ／　 ／　 ／ 4角形だと、辺の数が4だから、軸の数は2, 6角形だと、辺の数が6だから、軸の数は3, この方法だと、ある軸の数値を変化させることで、次々と隣のマスが現れますから、 はさむところの判定が楽にできるのではないかと。 >友人や家族でこのゲームを良くやるのですけど、 >いつもどうやってプログラムするのかなって考えていたりします＜－職業病?(^^;) >そういう融通が効く人間ってすごいなぁとか思います。 昔は「コンピュータがチェスで人間に勝てたら、そのコンピュータには知能が あるとみなしてよいのではないか」という議論があったそうですが、 今じゃ誰もそんなこと言いませんもんねえ。 人間の「知能」って不思議です。

>>例えば六角形のマスでも >>普通に二次元で値を保持しておけばいいんですね。 >六角オセロの場合は、3次元の配列にすると、はさむところの判定が >楽にできるかもしれませんね。各添え字の上限が一定しないですけど。 この場合、最初の2次元は私の書いたx,y座標ですか? 3つめの座標はどういう方向になるんですか? >>Catanみたいなボードゲームは、どうやって実装するのか、想像できないですけど。 >ミソは、ゲーム板をばらばらにして組みなおせる、ってところでしょうか。 六角形のマス自身における駒もあり、6個の角における駒もあり、 6個の辺における駒もあって、それぞれどのマスに隣接してるかが 重要になるゲームなので、マスだけに2次元座標を与えちゃダメなんでしょうね。 辺や角に座標を与えたら、それこそワケわからんのですけど(@_@) >その場合は、「隣接するマスを知っている」モデルが使えるかもしれませんね。 おそらくそういうモデルを適用するのでしょうけど、 初期化がすごく大変そうです。 友人や家族でこのゲームを良くやるのですけど、 いつもどうやってプログラムするのかなって考えていたりします＜－職業病?(^^;) そういう融通が効く人間ってすごいなぁとか思います。

>例えば六角形のマスでも >普通に二次元で値を保持しておけばいいんですね。 昔ASCIIに載っていた国産初のRPG「アルフガルド」なんかでも、そういう形で 座標を表現していたはずです。ユーザに見せるのがこの形式の座標なので、 内部的にもたぶんそうだったんじゃないかしら。 六角オセロの場合は、3次元の配列にすると、はさむところの判定が 楽にできるかもしれませんね。各添え字の上限が一定しないですけど。 >Catanみたいなボードゲームは、どうやって実装するのか、想像できないですけど。 これですか。 http://www.hanayamatoys.co.jp/catan/index.html ミソは、ゲーム板をばらばらにして組みなおせる、ってところでしょうか。 その場合は、「隣接するマスを知っている」モデルが使えるかもしれませんね。 表示の際の位置決めとか面倒そうですけど。

>六角形や三角形のマスを使うものがあるじゃないですか。 >いったいどう言う形で情報を記憶するんでしょう? >二次元配列じゃ、素直に考えると、うまくない...かな? あ、何か複雑なこと考えすぎていたみたいです。 例えば六角形のマスでも 普通に二次元で値を保持しておけばいいんですね。 ／＼ ｜xy｜として、下の様に座標を与えておいて ＼／ 表示するときに工夫すればいい...のかな? ／＼／＼／＼ ｜00｜01｜02｜ ＼／＼／＼／＼ ｜10｜11｜12｜ ／＼／＼／＼／ ｜20｜21｜22｜ ＼／＼／＼／＼ ｜30｜31｜32｜ ＼／＼／＼／ 隣り合うモノかどうかの計算もちょっとズレるけど 四角形のマスと大きく変わるわけじゃないんですね。 三角形も同じように出来ますね。 Catanみたいなボードゲームは、どうやって実装するのか、想像できないですけど。

全然、話の本筋とは関係ないのですが、オセロみたいなボードゲームに 六角形や三角形のマスを使うものがあるじゃないですか。 あぁいうのをプログラムで実現するとしたら、 いったいどう言う形で情報を記憶するんでしょう? 二次元配列じゃ、素直に考えると、うまくない...かな? 三角形のマスなら二次元目の方向を斜め方向にするのかしら? マス一つ一つがオブジェクトになっていて、 最初に隣り合うマスの情報をマスオブジェクトにあたえるんでしょうか。 初期化や、プレイヤーからの指定が、ちょっとめんどくさそう。

>>　これは結構わざとらしい例だと思いますが、 > >全く本筋と関係ない話ですが、４隅の無いオセロは現実に存在します。 > >http://www.google.co.jp/search?hl=ja&c2coff=1&q=%22%EF%BC%98%EF%BC%98%E3%82%AA%E3%82%BB%E3%83%AD%22&btnG=Google+%E6%A4%9C%E7%B4%A2&lr= ややっ。 知りませんでした。情報ありがとうございます。 盤面の絵とかがなかなか見つからなかったのですが、10×10の盤面で、 4隅の3つのマスが存在しないわけですね。 Javaアプレット版88オセロ： http://www.eb.waseda.ac.jp/murata/~kami/othello/othello.html というわけで、 >>　これは結構わざとらしい例だと思いますが、 この部分に関しては、撤回いたします。

>>「オセロゲームの新しいルールを作ったので、それを反映してください。 >>そのルールとは、４隅が無い物です」 > >　これは結構わざとらしい例だと思いますが、 全く本筋と関係ない話ですが、４隅の無いオセロは現実に存在します。 http://www.google.co.jp/search?hl=ja&c2coff=1&q=%22%EF%BC%98%EF%BC%98%E3%82%AA%E3%82%BB%E3%83%AD%22&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

　はじめまして。ご意見ありがとうございます。 >しかし、オブジェクト指向の世界では「メッセージは非常に重要な要素」ですから、 >この表現では、「オブジェクト指向の世界ではメッセージは重要でない」と >誤解されてしまうおそれがあります。 　何があればオブジェクト指向か、という点についてはいろいろ議論があって、 http://www.shiro.dreamhost.com/scheme/trans/reesoo-j.html | オブジェクト指向というものが動く標的であるため、オブジェクト指向の熱心な | 支持者はこのメニューのうちの適当なサブセットを気まぐれに選んで、それを以って | 他の言語はオブジェクト指向ではないと説得しようとする。 という議論もあったりしますね。Ruby作者のまつもとゆきひろさんによれば、 http://www.rubyist.net/~matz/20030807.html 　『最低限の条件は「アイデンティティがある」こと』だそうですが、これはだいたい 私と同じことを言っているように感じています(違うかもしれないけど)。もっとも私の 説明だとクラスが前提になっているので、まつもとさんの定義の方が範囲が広いですけど。 　オブジェクト指向というものがこのように「動く標的」であるとして、 私が件のページで書いているのは、対象言語をJavaとした範囲のものである、 ということをまずご理解ください。 　さて、その上で、実際のモデリングをどのように行うかですが。 >オセロの例がありますが、「石を置く」「置けるかチェックする」「盤面を >初期化する」「マスの状態を返す」の関数をサンプルとしてありますが、 >これでは不十分です。 >何が足りないかというと、「マスそのもののオブジェクト」です。 マスそのもののオブジェクトを作るかどうかの議論は、かつてこのへんで したことがあります(現在過去ログが読めない状態のようなので、 Internet archiveより)。 http://web.archive.org/web/20041114033519/http://www.ogis-ri.co.jp/otc/otc2/oosquare-ml/Archive/200205.month/2713.html 私の結論は、マスなんぞのクラスを持ち込んでもしょうがない、8×8の列挙の 配列にすべきだ、というものです。 >それでは、次のような話を持ちかけられたらどうしますか？ >「オセロゲームの新しいルールを作ったので、それを反映してください。 >そのルールとは、４隅が無い物です」 　これは結構わざとらしい例だと思いますが、そういう例でも、私が公開している オセロのソースをいじるとして、Board#checkPutPossibility()とBoard#isFull()と reverseDiscs()あたりをちょっと直せば十分なんじゃないかしら…と適当に試したら なんか動いたっぽいです。 なお、(修正前の)ソースはこちらで公開しています http://kmaebashi.com/javaworld/index.html 4隅が(空欄として)存在するのは気に食わないかもしれませんが、そもそものお題が 「４隅が無いオセロ」と定義されているのだからそんなに変とも思えません。 >そう、８ｘ８－４＝６０のマスすべてにメッセージを送るのです。 ... >６０人いる保育所の子供全員に「みんなー！クリアしなさい！」と叫ぶ >先生のようです。 で、結局「先生」は、最低でも「真ん中の4つのマス」を把握していなければ いけません。 石を打つ人は、先生にお願いするのかもしれませんけど、もしそうなら 結局先生はすべての子どもの座標を把握している必要があるでしょう。 そりゃま(x, y)で引けるmapと考えてもいいですが、見るからに格子である あの「盤面」をわざわざそんなふうに捉えることが果たして自然かどうか。 >たとえば、「マスに石が置けるかチェックする」は、自分の８方の隣のマスに >問いかけます。 「8方の隣のマス」という時点で、構造が2次元の格子であることに規定されて いますね。たとえば三角格子や3次元に対応できない点において、sionさんの モデルも二次元配列も似たようなものであるように私には見えます。 ところでもしsionさんのモデルが、各マスが8方の隣のマスへの参照を保持する、 というものであれば、「斜めでは挟めない」という新ルールのオセロにおいて (隅がない、というのよりはありそうなのでは)、無駄になりますよね。 逆もまた真です。 >とても回りくどい、面倒な方法に思われますが、実際のコーディングで表せば、 >一般的なやり方と量はさほど変わりません。 一度ソースを見せていただけないでしょうか。いや、皮肉ではなく。 オセロの盤面は、よっぽど奇妙な拡張を考えない限り、2次元配列で十分だし、 なにしろもとが格子なので2次元配列にするのが自然です。 上で挙げたoosquareの投稿にあるように、以前勉強会でオセロを例にしたときに、 >たとえば、「マスに石が置けるかチェックする」は、自分の８方の隣のマスに >問いかけます。 というモデルで作ってみようとした人はいました。隣のマスを見つける方法が わからなくて挫折してましたけど。 # 彼の名誉のために言っておけば、もちろん全部参照持てばできることは # わかっていたでしょう。「本当にそんなアホなことするの?」と思ったから # やらなかっただけで。 私がああいう文章を書いたのは、オブジェクト指向といえばメッセージだ、 という言葉に惑わされて、そういう変な設計が「オブジェクト指向的」で、 なにやらありがたいものであるかのように思い込まされ、混乱してしまった人が 周囲に結構いたためです。 >たしかにそうです。また、白、黒の他に「赤」という石が追加になったら記述を >追加する必要があります。 >しかし、その追加はオブジェクト（クラス）についてすればよい事になります。 どのクラスについて追加すればよいとお考えでしょうか? >蛇足ですが、２０年以上前から有るＧＰＳＳ等のシミュレーション言語では、 シミュレーションにおいて、actor的なオブジェクト指向がうまくいくケースが あるのは確かでしょう。他にもうまく適用できる分野はあるのかもしれません。 でもたとえば最適値を計算しなければならないようなケースで、こっちのオブジェ クトがちょっと最適じゃないから隣のオブジェクトにメッセージを送って… なんてことやってると、無限ループに陥ることもありますよね。 何事も適材適所。少なくともオセロにおいて、隣のマスにメッセージを送って… などという設計が適切であるとは思えません。

大変な長文失礼します 興味深く読ませていただきました。 世の中の多くの解説は 「クラスとインスタンス、そして継承。及びパッケージ化」があればオブジェクト指向である。それがオブジェクト指向の本質である・・・かのような誤った物が多いです。 クラスや継承、ブラックボックス化は、たしかにオブジェクト指向の重要な構成要素になる「事がある」かもしれませんし、便利な物かもしれませんが、それがすべてではありません。 現在存在するオブジェクト指向言語と呼ばれる物もそういった意味では不十分な物ばかりです。 そのような中で、前橋さんのＨＰの解説はとてもすばらしい物と思いました。 ただ、「なぜわからなくなってしまうか」のページの説明で 「オブジェクト指向をわかりにくいものにしている最大の要因として、「メッセージ」という言葉が挙げられます。」 とあります。 もちろん、これは「現在存在するオブジェクト指向と呼ばれる言語では、実質関数呼び出しなのだからわかりずらい」と言われているのだと思います。 しかし、オブジェクト指向の世界では「メッセージは非常に重要な要素」ですから、この表現では、「オブジェクト指向の世界ではメッセージは重要でない」と誤解されてしまうおそれがあります。 あと、 「カプセル化とは、「実装詳細の隠蔽」のことです。外部に対しては必要最低限のインターフェースのみを公開し、それ以外は隠蔽することで、実装の変更を可能にしたり、そのモジュールを他でも使いまわすことを可能にする、という概念です。」 と有りますが、これは誤りです。 「実装詳細の隠蔽」は、確かに良い事ですし重要ですが、カプセル化の本質は「メッセージのやりとりを行う単位を作成する」ことです。そして、これがオブジェクト指向の根本です。 オセロの例がありますが、「石を置く」「置けるかチェックする」「盤面を初期化する」「マスの状態を返す」の関数をサンプルとしてありますが、これでは不十分です。 何が足りないかというと、「マスそのもののオブジェクト」です。 ８ｘ８＝６４のマスすべてをオブジェクトとする必要があります。 すると、「え？８ｘ８の配列で良いでしょう！？」と思われるかもしれません。 それでは、次のような話を持ちかけられたらどうしますか？ 「オセロゲームの新しいルールを作ったので、それを反映してください。そのルールとは、４隅が無い物です」 実際、４隅が無いオセロなんてつまらない物かもしれませんが、まあ、例と言う事で・・。 このような話が持ちかけられたら、残念ながら前橋さんのサンプルでは大きなプログラム修正が必要になってきます。 たとえば、盤の初期化。 真ん中の４石以外はすべてクリアすると思いますが、おそらくＣ言語的に書くと for (y = 0; y < 8; y++) for (x = 0; x < 8; y++) ban(y,x) = 0 みたいに書くのだと思いますが、これでは、この処理を大きく変更しなければ成りませんね。 何しろ４隅が無いのですから。（まあ、「４隅の分データを無視すれば良いのでは」とか言う話は置いて置いてください。） 石が置けるかチェックする処理なども同じです。 本来のオブジェクト指向の考えでは、たとえば盤のマス一つ一つをオブジェクトにします。 そして、それらのマスに「あなた（たち）の中身をクリア（石がない状態にする）しなさい！」と「メッセージ」を送ればよい事になります。 そう、８ｘ８－４＝６０のマスすべてにメッセージを送るのです。 「結局６０のマスに送るとき、ループ処理するのでは？」と思われるかもしれませんが、それは、現在のオブジェクト指向言語の不備の問題であり、本来のオブジェクト指向の考えでは、６０のオブジェクトに大号令すればよい事になります。 たとえば、　　masu(all): message (CLR)　みたいに。 もちろんこのような例で書ける言語はありません。私の勝手な文法です。 ６０人いる保育所の子供全員に「みんなー！クリアしなさい！」と叫ぶ先生のようです。 この方法だと、盤が８ｘ８だろうが、４隅が欠けていようとも、６ｘ１０のマスであろうが、コーディングを変える必要はなくなります。６０人の子供たちは、必死に自分のマスをクリアする事に専念します。 盤の形の変更はマスの初期配置処理（インスタンス生成）さえ変えればよい事になります。 「石を置けるかどうかチェックする」ルーチンも同じです。 ６０のオブジェクトたちは、互いにメッセージをやりとりしあい、石をひっくり返す事ができるか確かめて答えを返す事になります。 たとえば、「マスに石が置けるかチェックする」は、自分の８方の隣のマスに問いかけます。「今、僕のマスに白を置こうとしているけど、君のところは黒かい？そして、盤が切れるまでの間に、白有るかい？」「僕のところは黒だけど、隣については聞いてみるね」などなど・・・。 この方法だと、たとえ、隣に突然穴があいていたとしても関係有りません。盤の形が変わっても関係有りません。オブジェクト同士がメッセージのやりとりで処理しますから。（もっと根本のルール変更が有ればこのオブジェクトも修正が必要になりますが、修正はこのオブジェクトのみになります。） とても回りくどい、面倒な方法に思われますが、実際のコーディングで表せば、一般的なやり方と量はさほど変わりません。 「’石を置く’、’置けるかチェックする’、’盤面を初期化する’、’マスの状態を返す’の処理を一つにまとめてオブジェクトにしただけで、根本は変わらないのでは？」という声が聞こえてきそうですが、違います。 「マス」というオブジェクト（部品）が作成されています。この部品を利用して、オセロに似た別のゲームができるかもしれません。たとえば、時間とともに盤に穴があくオセロとか・・・。 その例ですと、「時間とともに盤に穴をあける」という処理を追加すればよいだけですが、従来のやり方では、おそらく全面書き直しでしょう。 すると、「結局は穴があくのを前提にマスのオブジェクトを記述しなければならないのでは？」という声が聞こえてきそうです。 たしかにそうです。また、白、黒の他に「赤」という石が追加になったら記述を追加する必要があります。 しかし、その追加はオブジェクト（クラス）についてすればよい事になります。その際は、それこそ「継承」を使って派生クラスを作り、赤石の処理のみを追加すればよいかもしれません。 これで、部品の組み合わせにより「白黒６４マスの昔ながらのオセロ」「４隅のないオセロ」「白黒赤石のある６４マスのオセロ」「時間とともに穴のあくオセロ」など、様々なバリエーションを作る事ができます。 しかし、従来のコーディング技術では、おそらくバリエーションの数だけプログラムを全面書き直す事になるでしょう。もしくは、ｉｆ文の嵐になるでしょう。 今度は、「じゃあ、そのマスを関数やサブルーチンにすれば良いのでは？」と疑問があがるかもしれません。 はい、それでかまいません。オブジェクト指向の「本質」は、クラスやインスタンス、継承やブラックボックス化することではなく、「オブジェクト単位で扱うことの考え方」ですので。 場合によっては、昔ながらのBasicでも、その本質は記述する事はできます。（読みづらいでしょうが） オブジェクト指向におけるオブジェクトとメッセージの重要性、わかっていただけたでしょうか？ なお、この意見は私の個人的な意見ではありません。２０年以上オブジェクト指向に携わってきた経験により他の人からのアドバイス、文献から得た物であります。 ところで、私の文章の中には 「本来のオブジェクト指向の考え」という言葉があります。 「本来の・・・って、誰がいつ考えた物が本来なんだ？」とつっこまれそうですね・・・ただ、現在主流のＯＯＰでは、生産性の向上なんてあり得ない気がするのは確かです。 蛇足ですが、２０年以上前から有るＧＰＳＳ等のシミュレーション言語では、オブジェクトを複数生成してメッセージをやりとりしながら、すべてのオブジェクトが（論理的に）同時進行で処理を行います。 内部的に関数コールでしょ！？って・・・いえ違います。

お返事ありがとうございます。 なるほど、MEM_create_controller で別領域に確保されたMEM_Controllerの初期値を渡してるんですね。 アプリ側では MEM.h をインクルードする前に #define MEM_CONTROLLER apl_ctrlとかで使用する、と言う事ですね。 Alignですが、アライメント用ですか。なるほど気づきませんでした。 K&Rも是非見てみます。 ありがとうございました。 お言葉に甘えて、また質問がありましたら、是非質問させていただきます。

>エイトと申します。 はじめまして。 >MEM.h の、MEM_Controller は、要は各メモリの根っこやエラー時の動作を握ってる >構造体ですよね。 >実体は memory.c に記載され、アプリ側には不確定形で公開していますよね。 >つまりアプリ側にはどうやったって構造が見えない形になってます。 そうです。 >しかし、MMS_CONTROLLER がdefine されると、defineされた値をMEM_xxx_func で >持ちまわる事が可能になるわけですよね。 >これの利点というか、アプリに選択肢を与えてる理由って、なんでしょうか。 おっしゃる通り、MEM_Controllerは、各メモリの根っこやエラー時の動作を握っています。 で、MEMの上位のプログラムが複数の部分(モジュール)から構成されている場合、 モジュールごとに、メモリの根っこやエラー時の動作を変えたいと思うかもしれません。 たとえば、crowbarを組み込んだアプリケーションを作るとして、そのアプリケーション 側でもMEMを使うとしたら、独立したMEM_Controllerを使いたいのではないでしょうか。 たとえばデバッグのためにMEM_dump_blocks()を呼ぶとして、crowbarで使っている メモリの情報まで吐かれても邪魔です。 MEM_Controllerは不完全型でその内容は隠されていますが、MEM_create_controllerで 独立したMEM_Controllerを取得することが出来ます。 また、独立したControllerを使わせたいなら、MEM_malloc()などで引数として MEM_Controllerを渡すという手もありますが、 引数が増えると面倒ですし、実際にはひとつのMEM_Controllerで済むことが 多いでしょうし、独立したMEM_Storageが使いたいという場合でも、たいていは.c単位で 切り替えられれば充分じゃないかなあ、と考えて、こういう実装になっています。 ただし根っこを静的に押さえているのでマルチスレッドなどを考えると問題になる かもしれません。 # ていうかそれ以前に、複数のMEM_Controllerを使うテストはしてないので、 # ちゃんと動くかどうかは定かではないですが f(^^; >MMS_malloc_func 等を個別で呼べなくなるというデメリットはありますが >MEM_Storage に突っ込んで、アプリに見せなくさせるのも一考かなと思ってますが >いかがでしょうか。 うーん、MEM_Storageは使わない関数もあるので、アプリに見えなくするなら mem_default_controllerにstatic指定を付けてmemory.c以外からは見えなくしてしまう ことになるんでしょうけど。 >2. >memory.c 内に定義されているHeader_tag が、union で定義されているのはなぜでしょうか？ >Alignの存在する意味がわからないです。 アライメントを取るためです。 たいていのCPUでは、データ型によって、たとえばdoubleは8バイト刻みの領域にしか 配置できないなどの制限があります。 MEM_malloc()で確保された領域には、何が格納されるかわかりませんから、 MEM_malloc()はもっとも厳しい型で境界調整された領域を返す必要があります。 Alignは、その境界調整を行うための共用体です。 このあたりのことは、「プログラミング言語C」(いわゆるK&R)でサンプル実装している malloc()でも考慮されていますので、K&Rをお持ちであればそちらも参考にしてください。 こんな感じで回答になっていますでしょうか? 追加の疑問点等ありましたらまたお気軽にどうぞ。

エイトと申します。 当HPは自分にとって大変勉強になり、無謀ながらcrowbar の解析をしております。 すいませんが、二点程質問が御座います。どうか宜しくお願いします。 1. MEM.h の、MEM_Controller は、要は各メモリの根っこやエラー時の動作を握ってる構造体ですよね。 実体は memory.c に記載され、アプリ側には不確定形で公開していますよね。 つまりアプリ側にはどうやったって構造が見えない形になってます。 しかし、MMS_CONTROLLER がdefine されると、defineされた値をMEM_xxx_func で持ちまわる事が可能になるわけですよね。 これの利点というか、アプリに選択肢を与えてる理由って、なんでしょうか。 MMS_malloc_func 等を個別で呼べなくなるというデメリットはありますが MEM_Storage に突っ込んで、アプリに見せなくさせるのも一考かなと思ってますがいかがでしょうか。 2. memory.c 内に定義されているHeader_tag が、union で定義されているのはなぜでしょうか？ Alignの存在する意味がわからないです。 お時間ある時で構いませんので、返答の程、どうかよろしくお願いいたします。

>ご指摘ありがとうございます。 > >正誤表に追加しました。チェック漏れが多く申し訳ありません。 > kkkkk

ご指摘ありがとうございます。 正誤表に追加しました。チェック漏れが多く申し訳ありません。

こんにちは。「体当たり学習」の初版第1刷が手元にあるのですが、 まだ正誤表にない誤植がありましたのでお知らせします。 p.125 Fig 3-3 ASCIIコード表 (1) 表中の最右列2段目、正しくは「i 105(69)」と、小文字の「i」であるべきところが 大文字の「I」になってしまっています。 (2) 同列の最下段、チルダの十進表記は「126」なのに「127」になっています。 下の註●も同様です。十六進表記(7E)のほうは合ってますね。 (3) 2つ目の註●で「日本では￥が割り当てられていることが多い」となっていますが、 それならば表中の該当部分は「￥ 92(5C)」ではなく「＼ 92(5C)」と すべきではないでしょうか？ お忙しいとは思いますが、どうぞご確認ください。

レンタルサーバ屋さんより、メンテナンスのため下記期間サーバが止まるという 連絡がありました。 10月31日(月)　午前2時-午前5時 この期間は、kmaebashi.comを閲覧できません。また、この掲示板も使用できません。 ただし、私宛のメール(PXU00211@nifty.ne.jp) および(なぜかケロロ軍曹に乗っ取られた)裏掲示板 http://otd9.jbbs.livedoor.jp/maebashi/bbs_plain は動作します。

説明不足で申し訳ございませんでした。 また、ご指摘いただきましてありがとうございました。 状況はご指摘いただいたとおりでした。　 教えていただいたページで解決できました。 貴重なお時間をいただき本当にありがとうございました。

>PHPを最近いじってるのですが、Locationが動きません。。 「動きません」だけでは何がなんだかわかりません。 おそらくここで「Location」と言っているのは、header()関数でLocationヘッダを 送出しているということなのだと思いますが、だとすれば、Locationはそもそも PHPの機能ですらないですし。 >そのまま書いてるはずですが・・・ 「そのまま」って、何のままですか? >こればっかりは調べようもないし、質問させていただきました。 広告の入るレンタルサービスを使っていると、動作しないことがあるようですけどね。 http://sb.xrea.com/archive/index.php/t-757.html 何しろ「太郎」さんが提供する情報が少なすぎて、何もわかりません。

初めて投稿させていただきます。　よろしくお願いします。 PHPを最近いじってるのですが、Locationが動きません。。　そのまま書いてるはずですが・・・　こればっかりは調べようもないし、質問させていただきました。 多分皆さんからすると、かなりレベルが低いですが、どうぞよろしくお願いいたします。

えー。 >400000です… >くだらないことですいません…。 kitさんの投稿にレスしようとして気付きました。えらく長いこと放置して しまいましてすみません。 わざわざ報告いただきありがとうございます。 だらだらと長いことやってきただけのサイトではありますが、400,000とは、 思えば遠くに来たもんです。作ったばかりのときはねえ… 知人系MLでURL流したら「7ゲット」とか言われたりねえ… 残念ながら、キリ番踏んでもプレゼントとかできるものはありませんけれど。 「前橋の恥ずかしい写真」なんて誰も欲しくないでしょうし。

いつもありがとうございます。お返事が大変遅くなりましてすみません。 >日本語関係は、ISO-C の mbr/wcs 系関数 (1バイトずつ処理するなら >mbrtowc(3)) を使うのはどうですか? >想像だけど、これで Windows なら wchar_t は Unicode になるん >じゃないでしょうか。 やってみました。WindowsXP + MinGWです。 #include <stdio.h> #include <stdlib.h> #include <string.h> #include <locale.h> #include <wchar.h> int SJIStoUCS16(const char *src, wchar_t *dest) { int src_idx, dest_idx; int status; mbstate_t ps; memset(&ps, 0, sizeof(mbstate_t)); for (src_idx = dest_idx = 0; src[src_idx] != '\0'; ) { status = mbrtowc(&dest[dest_idx], &src[src_idx], 2, &ps); dest_idx++; src_idx += status; } return dest_idx; } int main(int argc, char **argv) { const char *src = "abcあいうえお憂鬱"; wchar_t dest[1024]; int size; int i; setlocale(LC_CTYPE, ""); for (i = 0; src[i] != '\0'; i++) { printf("[%02x]", ((unsigned char*)src)[i]); } putchar('\n'); size = SJIStoUCS16(src, dest); for (i = 0; i < size; i++) { printf("[%04x]", dest[i]); } putchar('\n'); return 0; } C:\>gcc sjtoucs16.c -o sjtoucs16 -lmsvcp60 C:\>sjtoucs16 [61][62][63][82][a0][82][a2][82][a4][82][a6][82][a8][97][4a][9f][54] [0061][0062][0063][3042][3044][3046][3048][304a][6182][9b31] UNICODE(UCS-2)に変換できたようです。 コンパイルオプションに-lmsvcp60がないと、mbrtowc()はリンクできません。 しかし、mbtowc()では不要です。よくわかりません。 また、mbsrtowcs()は、いろいろ試しましたが動いてくれませんでした。 setlocale(LC_CTYPE, "")とすると-1を返しますし、setlocale()しなければ 動きますが、戻ってくるのは、元のS-JISをwchar_tに1バイトずつ入れただけのものです。 それをwprint()すると、ちゃんと表示されるのですが。こっちもよくわかりません (Linuxでは動く)。 http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/vclib/html/_crt_setlocale.2c_._wsetlocale.asp | LC_CTYPE | 文字処理関数 (isdigit、isxdigit、mbstowcs、mbtowc の各関数は除く)。 このせい? (全然わかってませんが)

>>あ、はい、そのバグが復活してます。 修正しました。報告いただきありがとうございました。 ># マスターのソースはUNIX側のひとつしかないのに、どうしてこんなことが ># 起きたのか謎です。 この「謎」はすぐ解明できたのですが… あまりにはずかしいので黙秘権を行使させてください (^^; # いくら忙しいからって、あんなことしてちゃこんなことも起きるよなあ…

>あ、はい、そのバグが復活してます。 うわっ。 すみません、今GLOBALかけたソースを見ても、確かにそうなっています。 今日はちょっと無理なので、明日にでも修正させていただきます。 # マスターのソースはUNIX側のひとつしかないのに、どうしてこんなことが # 起きたのか謎です。 ご迷惑をおかけしまして申し訳ありません > 皆様

>>＃ if～elseのバグが… > >　　　　　　　　then側とelse側が同じだというバグ あ、はい、そのバグが復活してます。

レスの順番がむちゃくちゃですみません。 >abort()の前にファイルを閉じないといけませんね どちらかというと、出力のたびにfflush()すべきでしょうね。 デバッグ用出力のファイルポインタをバッファリングするなんて使用者側の問題だ、 と主張することはできるかもしれませんが。次回までには修正を検討します。 >＃ if～elseのバグが… す、すみません、then側とelse側が同じだというバグと、論理型の畳み込みに 関するバグはあって、修正したつもりなのですが、まだ何かありましたでしょうか。 この際恥は何度でもかきますが、バグがあるなら直しておきたいと思いますので。

>avexがわざわざネコのキャラで作成したから話がややこしくなったような。 >まったくネタを知らない人からすればネコである必要性がないわけですから。 当初avexはマイヤヒ公式サイトでも「ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ｯ!!」とかやってましたから、 2ちゃんねらをひっくるめて盛り上げていきたかったんでしょう。 「モナーの兄弟ののまネコが大人気!」と喜んでればよかったのに、それだけの 度量が2ちゃんねら側になかったということじゃないでしょうか。

>どうでもいいですが「ゆんゆん」にはきっちり元ねた？があったのですね。 >あまりにもアレげなので興味のある方はご自分で検索してみてください。 同じ作詞家による別の歌がこちら。 http://www.jona.or.jp/~epic/gekkan/oct99/ あまりにもアレげなのでクリックは自己責任で。

avexがわざわざネコのキャラで作成したから話がややこしくなったような。 まったくネタを知らない人からすればネコである必要性がないわけですから。 # もっとも、「のまねこ」というのは語感・語韻が良いというのもあるでしょうけれど。

どうでもいいですが「ゆんゆん」にはきっちり元ねた？があったのですね。 あまりにもアレげなので興味のある方はご自分で検索してみてください。

>>「世界の中心で愛を叫ぶ」をエヴァの最終話のタイトルからパクって名づけたと思っている人もいるわけですが、 そういや、これ自体は別に誤解でもないですな。

根本的に読解力がない頭が不自由な人なのか、妄想炸裂電波ゆんゆんの頭が気の毒な人なのか… >自分の著作物を勝手に企業に商用利用されたとき、 >裁判をやれば勝てるとあなたは思っているみたいですが、 わたしゃそんなこと言ってないですが。言っていると思うのなら、私の主張から、 その部分を引用して示してください。 >あと、 >「世界の中心で愛を叫ぶ」をエヴァの最終話のタイトルからパクって名づけたと思っている人もいるわけですが、 >すべての誤解を解く方法があるのなら、ぜひご教授願いたいのですが？ｗ ないんじゃないですか? そんな方法があると言った覚えもないですが。 言っていると思うのなら、私の主張から、その部分を引用して示してください。 # 結局、この問題で騒いでいるのって、こんなレベルの電波さんばっかりなのかしら。

自分の著作物を勝手に企業に商用利用されたとき、 裁判をやれば勝てるとあなたは思っているみたいですが、 そもそも裁判にかかる時間や費用を出せなくて泣き寝入りする人もいるでしょう。 仮に裁判に入ったとしても、 ネットにどんな内容のものがいつからいつまでUPされていたのか なんて証拠がどこにあるんですか？ 何年もかかるであろう裁判に、（ずっとではないとは言え） 必要なときに出続けてくれる証人をどうやって探すんですか？ 仮に「勝訴」できたとしても、 元々無料で公開していた物であれば経済的な損害は0円なので 慰謝料として2、300万とれる程度では？ それに、元々お金目当てに作っていたのでなければ、 それは「勝訴」ではあっても勝利ではありませんね。 この問題を危険視している人が皆、 ２ちゃんねるとモナーとエイベックスだけの問題だと 思っているわけではありませんよ？ あと、 「世界の中心で愛を叫ぶ」をエヴァの最終話のタイトルからパクって名づけたと思っている人もいるわけですが、 すべての誤解を解く方法があるのなら、ぜひご教授願いたいのですが？ｗ そして、「モナーが2ch生まれだと誤解されて怒っているあめぞう出身者」の人たちにも 教えてあげたらどうですか？ｗ

レスありがとうございます。色々お知りじゃないですか(笑) それでしたら私からは何もお伝えする事はございませんです。 電凸の件の録音ソースは私も知らないんですが、一応私の知ってる範囲では 9/30現在のAvexコメント後の10/2に電話で聞いても同じ回答だったということだけです。 （ソース無くてホントすみません） 私個人の見解ですが原著作権を主張しているのはやはり気になっています。 たぶんグッズ作成者は作成する時気にするのでは？と思いますし、 黒フラのような状態(指摘されれば引っ込めるが、売ってしまうだろう)を作り出してしまうと思っています。 確かに現状ののまネコは大分形が変わっていますので…。今となっては私も経緯に怒っているだけかもしれません。 Scriptの件も拝見させて戴いて前回の書き込みもさせて戴いたわけですが、 この喩えはおそらく黒フラ作成者「わた」氏の気持ちに近いのでは？とも思いました。 （失礼でしたらすみません） キャラクタ商売はイメージが全てですから。 その意味ではフリーカルチャーは分野によって度合いが違うものだとも思いました。 確かにFlashの文化発展のためには一般の目に触れるイイ機会だったと思います。 それを潰してしまう事は残念というのは同意見です。貴重なご意見をありがとうございました。

>>何で2回？ > >crowbarに付属するデバッグ用ルーチンは、 >・事前に設定したファイルポインタ >・stderr >の両方にエラーメッセージを吐くようになっているようです。 >そして、「事前に設定したファイルポインタ」は、デフォルトでstderrなので、 >デフォルトでは両方に出る… ということです。 …なるほど。了解です。どこでassertが2回も呼ばれてるんだろ？ と見当はずれな疑問を抱いてました abortしてるんだから1回しか呼べないって (汗 >大昔に作ったものなので、今ソースを見て確認しました。ファイル指定の出力の方は >本当に動くかどうかも自信がありません (^^; abort()の前にファイルを閉じないといけませんね ＃ if～elseのバグが… ＃ |ﾐ ｻｯ

>[601]>ところで、閲覧したいメモリは仮想メモリでしょうか? 物理メモリでしょうか? > >仮想アドレスの章：　はい、今　読んでみました。仮想メモリと物理メモリの話ですね。 >閲覧したいのは物理メモリです。仮想メモリもついでに見てみたいです。 特定プロセスの仮想メモリのユーザ空間（32bit OS なら、アドレスが下位 31bit の範囲に収まる部分）は、デバッガを使えば、割と簡単に見ることができます。 上位領域を見る方法をご存知の方がいらっしゃいましたら、教えていただけないでしょうか？ 物理メモリの内容は、/Device/PhysicalMemory というセクションにマップされているようです…と言っても何のことだかわからないと思います。 SysInternals で、ここを覗き見るサンプルが公開されています。 http://www.sysinternals.com/Information/TipsAndTrivia.html#PhysMem

>ここです。誤解される事を嫌がる人が多いという事です。 のまネコについて、avexがゼロから作ったものだ、という誤解というのは、 (もともとあめぞう起源らしい)モナーについて、2ちゃんで生まれたものだ、 という誤解があるのと同様でしょう。 後者の誤解のため、実際にあめぞう掲示板出身の人は怒っていたりするわけですが、 誤解をしている人がいたら、正しい情報を伝えて誤解を解けばよいのですから、 たいした問題ではないと私は考えます。たいした問題だと考える人がいてもいいですが、 その場合、あめぞうな人の主張も受け入れなければフェアではないですね。 のまネコから知る人というのは(定義からして)その時点でモナーを知らないわけですから、 その人たちに「のまネコはモナーを元にしているんだよ」ということを啓蒙できれば、 モナーを知る人の数はむしろ増えるわけです。 >モナーグッズ作成者(イラストやぬいぐるみの作成者が以前よりおります)はパクリの目で見られます。 現実問題としてこれはないでしょう。現在最もメジャーな形ののまネコと、 本来の形のモナーはほとんど似ていません。また、PVの中には(モナーというより) モララーやマダーに近いネコが確かに登場しますが、そんな誤解を懸念するなら、 誤解されないような売り方をすればよいわけです。 エヴァンゲリオンがヒットしたあと、エリスンのアレは書店で平積みになって ましたが、パクリの目で見られましたか? 片山恭一のアレがヒットしたあと、エヴァンゲリオンはパクリの目で見られましたか? >　「Avexに１つ１つ作品を見せていただいて類似性を確認させていただく事になります」 >というのがAvex社の電話回答です。 これのソースはあるでしょうか。 私が知っているのはこれだけです。 http://that3.2ch.net/test/read.cgi/goods/1126073495/28 | ‘私個人がモナーのイラストに描いてネットにアップする際、 | 似てしまうから、違いを教えて欲しい。そしてモナーグッズを個人的に作って | 売る際、著作権にひっかからないのか’ | と avexに電話で聞いてみた所、 | イラストは個人の主観で、個人がモナーを描いたと思うなら問題ない。ただし、 | グッズなどはavexに一つ一つ、聞きにきて欲しい。 | …と言っていた。 もともと私は、avexが「のまネコに関して」独占した権利を主張するのは当たり前だと 思っています(だから2ちゃんの圧力に屈して商標取り下げに至ったのは不当だと思う)。 マイヤヒのCDをひっくるめ、プロモーションには金も労力もかかります。 第三者が、目が「o」で口が「ω」の、明らかにモナーではない方ののまネコを 販売してavexの利益を荒らすのは少なくともよいことではないでしょう。 そこへ、「似てしまうのでどうすりゃいいか」という質問が電話できたら、 「弊社に確認してください」という回答以外ありえないように思います。 上記程度のソースでは、会話の正確な流れがわからないので、もし録音等の ソースをご存知でしたら教えてください、ということです。 | なんでパクッた人にお伺いを立てなくてはいけないのか | 疑問だし、そのうちイラスト、モナー系のフラッシュなども | 制限かけてきそうで怖いですね。 | そういう事しないと、文章で示してもらわないと・・・ で、avexはちゃんと文章で示したわけですよね? http://www.bmybox.com/%7Estudio_u/nomaneko/avex.php | しかし今回出願した商標につきましては、あくまでもグッズとして展開される | キャラクターの「のまネコ」のみであり、当然のことではありますが、わたしたちが、 | モナーの利用に対して権利を主張することは一切ありませんし、他のアスキーアート | （例：しぃ、モララーなど)に対しても同様です。 これ以上何を望むのでしょうか。 >「既存AAはそのまま使っていいけど、新規AAは確認してほしい」 こちらについてもソースの提示をお願いします。 いずれにせよ、電凸(電話で突撃)で聞けるようなコメントは、Webなどでの公式見解が 出ればそれに上書きされるものだと私は思いますが。 >Avex社の対応の仕方に頭にきている者も多い事を付け加えておきます。 avexの対応について、これはどうかと思うところは私もあります。 最新の公式見解なんか、確かに企業が公に発表する文章とは思えません。 しかし、2ちゃんねらの、黒FLASHやマンガAAのような明らかな著作権侵害を容認しておきながら、 のまネコ程度のパクリで著作権がどうのと騒ぎ出すダブルスタンダードっぷりや、 「きみたちのものだったという証拠はあるのかね?」とか 「君たちはもう勝手にこのねこを使ってはいけない」とか、 嘘八百を並べ立てたFLASHで同情を引こうとしたりする卑怯っぷりに http://www.geocities.jp/doronumaneko/ 腹を立てている人も最低ここにひとりはいることを付け加えておきます。 avexという大企業が、黒FLASHまで大目に見て、面白いネタに乗ってきてくれたという 流れをぶち壊してくれたことも、心底残念に思います。

こんにちは。雑記帳読みまして。。 Programingに関係なくてすみません。 私のまネコ反対派です。１個人の意見で申し訳ないですが、だいたいの総意は皆似たようなもんでして、 ･avexがいくら儲けたって、損する人はいないんだから別にいいです。 ･avexがのまネコの著作権を主張しても、モナーが使えなくなるようなことはないです。 これはその通りです。 皆が嫌がってるのは ･そういう誤解が広まることは、私にとって嬉しいことではないですが、 ここです。誤解される事を嫌がる人が多いという事です。 モナーグッズ作成者(イラストやぬいぐるみの作成者が以前よりおります)はパクリの目で見られます。 10/2現在では商標は取り下げて戴けましたがオリジナル主張し商品販売を続けておりまして、モナーグッズを作成する場合は 　「Avexに１つ１つ作品を見せていただいて類似性を確認させていただく事になります」 というのがAvex社の電話回答です。 「既存AAはそのまま使っていいけど、新規AAは確認してほしい」 と言う事もAvexの電話回答で言われております。 怒りの理由をお判りになって戴けたらありがたく思います。 Avex社の対応の仕方に頭にきている者も多い事を付け加えておきます。

こんばんは。 [603]>(B) は静的に確保したいわゆる二次元配列 char a[MX][MY] と完全互換です。 [603]>char a[MX][MY] を渡して欲しいと思っている関数には (B) だけが使えます。 なるほど。 こんど　似たようなコードを書くときには いろろ変えて遊んでみます。 おせわになりました

>ソースのわかりやすさでも、機能性とかバグ回避の点でも >（B）が優れているとは言えないわけですね。 いいえ。必ずしもそうとは言い切れません。 (B) は静的に確保したいわゆる二次元配列 char a[MX][MY] と完全互換です。 char a[MX][MY] を渡して欲しいと思っている関数には (B) だけが使えます。 ＝配列の全要素がメモリ上で連続である必然がある用途に対しては (B) でなければなりません。 fwrite こそしないかもしれませんが memset はしたくなるかもしれませんしね。 仮想記憶の話を書きましたが、容量的に char a[MX][MY] と書いて問題ない状況下に おいては (B) を避ける理由がありませんし、問題が出る状況下ではどっちにせよダメですから。 http://forums.belution.com/ja/cpp/000/000/89s.shtml とかに類似の話題がありますな。とりあえず参照してみてください。 まあ今なら vector の vector を使うほうがお勧めです(A に類似:それでよい用途なら)。 生 new なんぞ使うと delete 忘れのほうが怖いので。

ありがとうございました。 [601]>どちらもpの型はchar**ではないでしょうか。 そうです。すごく初歩的なミスで　はずかしですけど。 [601]>ただし、p[n]を個別に解放したいとか、個別にサイズ変更(realloc)したいとかの [601]>場合には(B)の方法は使えません。 [600]>なので、しょぼい仮想記憶 (というかスワップ機能) を持つOSだと問題が発生しえます。 わかりました。 ソースのわかりやすさでも、機能性とかバグ回避の点でも （B）が優れているとは言えないわけですね。 [601]>ポインタ完全制覇をお持ちなら、「2.1 仮想アドレス」を参照してください。 [601]>ところで、閲覧したいメモリは仮想メモリでしょうか? 物理メモリでしょうか? 仮想アドレスの章：　はい、今　読んでみました。仮想メモリと物理メモリの話ですね。 閲覧したいのは物理メモリです。仮想メモリもついでに見てみたいです。 [600]>VC++ の IDE デバッガとか gdb とか、いろいろデバッガがありますね。 [600]>わざわざ作るまでも無いような気がします。 あ～、なるほど。知りませんでした。 とりあえず、デバッガを使ってみます。 [600]>>上のプログラム（B）のときのメモリ開放は [600]>>delete[] p[0]; [600]>>delete[] p; [600]>正解です。 やっぱり当然ですね。 でも、うっかり次のように書いてしてしまいそうで やっぱり(B)はあんまり良いコーディングではないですね for(y=0;y<yM;y++)delete[] p[y]; delete[] p; 以上　参考になりました。ありがとうございました。

>(A)(B)どっちが良いのでしょうか？ どちらもpの型はchar**ではないでしょうか。 それはさておき、 >ちなみに個人的な意見（というか直感）では >(A)の方がわかりやすいですね。たぶん。 >しかし、 >(B)の方が、例の「どこかの領域」を節約するため効率的と思います。 これはその通りなので、わかりやすさと効率を秤にかければよいと思います。 ただし、p[n]を個別に解放したいとか、個別にサイズ変更(realloc)したいとかの 場合には(B)の方法は使えません。 >fread(p[0],sizeof(char),xM*yM,fp); >と一発で書けて便利と思います。 そうですが、そういうことを始めると一発でデータファイルの互換性が 失われるのでおすすめはできません。 >■メモリー閲覧 >（なければ、私が自分で作ってみたいな...と思っています） 774RRさんがすでにおっしゃっているように、そういうプログラムをデバッガと 言います。 ところで、閲覧したいメモリは仮想メモリでしょうか? 物理メモリでしょうか? 他プロセスの仮想メモリを覗くのも物理メモリを覗くのも、C言語レベルで 標準的な方法は存在しないため、そんなに簡単には作れないと思います。 ポインタ完全制覇をお持ちなら、「2.1 仮想アドレス」を参照してください。

>また、(B)では、連続するデータがメモリー上に連続して確保されるはずなので ですです。 なので、しょぼい仮想記憶 (というかスワップ機能) を持つOSだと問題が発生しえます。 連続するメモリ領域全てをひとかたまりに swap したがるような OS だと、 (A) では連続領域が小さいのに対して (B) は連続領域が大きいので、 (A) より (B) のほうがスラッシングが置きやすいです。 現代OSにはそんなしょぼいものは無いですけど... >fread(p[0],sizeof(char),xM*yM,fp); >と一発で書けて便利と思います。 最近こーいうことしないからなんともいえませんね。 >上のプログラム（B）のときのメモリ開放は >delete[] p[0]; >delete[] p; 正解です。 >■メモリー閲覧 そーいうソフトのことを普通はデバッガと言いますが... VC++ の IDE デバッガとか gdb とか、いろいろデバッガがありますね。 わざわざ作るまでも無いような気がします。 ただメモリが見えるだけではつまらないので。

■delete a[];はエラーか？ >> x=new char[n]; を開放するときは delete x[]; >>という人もいますが、これは間違いではないでしょうか。 > >そもそもそんな書き方ってできましたっけ。 柴田望洋さんとういう方の次のHPには http://www.bohyoh.com/CandCPP/FAQ/FAQ00085.html new/deleteのサンプルリストがあって int *a = new int[no]; /* 確保 */ //中略 delete a[]; /* 解放 */ とあります。 気になったので、今、Borland C++5.5でコンパイルしてみると コンパイルエラーで叱られました。 ＃投稿した後でテストするあたりは、ものぐさなもので、 　すいません。（あ、石投げないで） ■２次元配列の動的確保 ところで、また教えてください。 xM列yM行の２次元の配列p（というか配列もどき）を確保するときは Borland C++5.5　のマニュアルによると （program A） char *p;p=new char *[yM]; for(y=0;y<yM;y++)p[y]=new char[xM]; とあります。これは、次のように書いても良いと思います。 （program B） char *p;p=new char *[yM]; p[0]=new char[xM * yM]; for(y=1;y<yM;y++)p[y]=p[0]+y*xM; (A)(B)どっちが良いのでしょうか？ ちなみに個人的な意見（というか直感）では (A)の方がわかりやすいですね。たぶん。 しかし、 (B)の方が、例の「どこかの領域」を節約するため効率的と思います。 また、(B)では、連続するデータがメモリー上に連続して確保されるはずなので fread/fwriteなどの場合 fread(p[0],sizeof(char),xM*yM,fp); と一発で書けて便利と思います。 この点、みなさん、どうお考えですか。 ■２次元配列の開放 上のプログラム（B）のときのメモリ開放は delete[] p[0]; delete[] p; ですよね。 （初心者なのでなんとなく自信がないです。くだらない質問ですいません。） ■メモリー閲覧 最後に、メモリー操作の結果を確認するソフトというのは 何かありますか？（メモリー閲覧ソフト？） つまり、このソフト自体は指定されたアドレスに常駐させておき キーボードなどでアドレス範囲を指定すると そこのメモリーのデータが10進数で表示される というものです。 （なければ、私が自分で作ってみたいな...と思っています） 以上、お願いします。

はじめまして （と、前回の登校文に書くのを忘れていました）。 （ぱ）さん、774RRさん さっそくのお返事、ありがとうございます。 参考になりました。

あうー explicit_constructor_call が抜けた... for (size_t i=0; i<n; ++i) explicit_constructor_call(&p0->array[i]); を new[] の中に追加しといてください。 # 表記は placement-new および t->~T() ; でもよかったわけだが、まあいいや

すでに完璧な答えが出てますが、一応フォローをば。 >>ところで　delete と delete[] はどう違うのでしょうか。 >>両者を取り違えると不都合があるのでしょうか。 はい、言語仕様上「未定義」つまり、「誤りであり、何が起きても文句は言えない」状態です。 不都合が生じても一向に構いませんし、プログラマの期待通りに動いても構いません。 >> x=new char[n]; の後の delete[] x;　でchar型のn個の領域が開放されますが >>このときのnの値（開放すべきデータのサイズ）は >>メモリのどこに保存されているのでしょうか。 言語仕様は何も定めていません。なのでまさに >「どこかの管理領域」としか言いようがないです が、実装を簡単にするために、こんな手が使われることが多いです。 T* p=new T[n]; は内部で struct anonymous_n_array_of_T { size_t n; // この n の前後に padding が入ることもあります T array[n]; }; anonymous_n_array_of_T* p0=malloc(sizeof(anonymous_n_array_of_T)); p0->n=n; return &p0->array[0]; 同様 delete[] p; の内部処理は anonymous_n_array_of_T* p0=translate_pointer(p); // get p-sizeof(size_t) for (int i=p0->n; i>=0; --i) explicit_destructor_call(&p0->array[i]); free(p0); // 説明のためにいろいろ略:キャストの明示など よって new/delete[] や new[]/delete をしてしまうと、正しく配列要素数が取り出せず 誤動作してしまうのです（デストラクタが呼ばれすぎ・呼ばれないなど）＝未定義動作 VC++ など一部のコンパイラでは POD (plain old data) 型 (char/int など) の new[]/delete[] が単純な malloc/free になっているので new[] を delete しても動いてしまい、問題が発覚しにくくなっています。 その昔、開発中の C++ では delete[n]p; と要素数の指定が必要でした。 これはあまりもアレげなので現在の仕様になった、と D&E にあります。

> x=new char; とした後、これを開放するときは delete x; > x=new char[n]; とした後、これを開放するときは delete[] x; >となっていると思います。 >ところで　delete と delete[] はどう違うのでしょうか。 >両者を取り違えると不都合があるのでしょうか。 C++はさして詳しいわけではないのですが。 仕様上はおそらくこの場合の挙動は不定で、「何が起きても文句は言えない」状態だと 思いますが(ちゃんと調べてませんすみません)。 現実問題としてありそうなのは、charのような基本型でなくクラスの配列の場合、 最初のひとつのオブジェクト以外のデストラクタが呼び出されない、ということでしょう。 >また、もちろん > x=new char[n]; の後の delete[] x;　でchar型のn個の領域が開放されますが >このときのnの値（開放すべきデータのサイズ）は >メモリのどこに保存されているのでしょうか。 「どこかの管理領域」としか言いようがないですが(管理方法によっては、 サイズを直接保持する必要はないかもしれません)。 動的メモリ確保の挙動については、ポインタ完全制覇の2-6-3あたりを参照して ください。C++でも、ずっと下の方では、特に変わるものではありません。 逆に言うと、Cと同レベルのメモリ管理機構の上にC++をのっけてしまったから、 プログラマの側が忘れず[]を付けることを強制されているとも言えるでしょう。 >それから > x=new char[n]; を開放するときは delete x[]; >という人もいますが、これは間違いではないでしょうか。 そもそもそんな書き方ってできましたっけ。 Bjarne本の第3版の構文規則を見ると、 delete-expression: ::opt delete cast-expression ::opt delete [ ] cast-expression とありますが… すみませんどなたか詳しい方の救援をお願いします。

>ダウンロードしようとしたら、UNIX版のtgzファイルがver.0.3.01とver.0.3.02で同じになってました。 … >if (5 < 8) { > print("5 < 8\n"); >} else { > print("5 >= 8\n"); >} > >を実行すると怒られました。 ご指摘ありがとうございます。まぬけなバグで申し訳ありません。 修正してアップロード途中です。最近ネットの調子が悪いようで、 GLOBALをかけたソースの途中で今止まっています。 >| Assertion failure (v->type == CRB_DOUBLE_VALUE) file..create.c line..187 定数同士の比較では、解析木の畳み込みを行うのですが、論理型を追加したときの 修正漏れで、「畳み込んだ式は整数か実数のどちらかだ」というassert()が残っていました。 テスト不足ですみません。 >何で2回？ crowbarに付属するデバッグ用ルーチンは、 ・事前に設定したファイルポインタ ・stderr の両方にエラーメッセージを吐くようになっているようです。 そして、「事前に設定したファイルポインタ」は、デフォルトでstderrなので、 デフォルトでは両方に出る… ということです。 大昔に作ったものなので、今ソースを見て確認しました。ファイル指定の出力の方は 本当に動くかどうかも自信がありません (^^;

>crowbarのver.0.3.02は、9/26中には出します… ： >いやその所詮マイナーバージョンアップなんですが。 ダウンロードしようとしたら、UNIX版のtgzファイルがver.0.3.01とver.0.3.02で同じになってました。 あと、 if (5 < 8) { print("5 < 8\n"); } else { print("5 >= 8\n"); } を実行すると怒られました。 | Assertion failure (v->type == CRB_DOUBLE_VALUE) file..create.c line..187 | v->type..1 | Assertion failure (v->type == CRB_DOUBLE_VALUE) file..create.c line..187 | v->type..1 | アボートしました 何で2回？

前橋さんの「C言語 ポインタ完全制覇」 とても面白かったです。 さて、この本と少ししか関係がないので申し訳ありませんが Cの文法によると、 x=new char; とした後、これを開放するときは delete x; x=new char[n]; とした後、これを開放するときは delete[] x; となっていると思います。 ところで　delete と delete[] はどう違うのでしょうか。 両者を取り違えると不都合があるのでしょうか。 また、もちろん x=new char[n]; の後の delete[] x;　でchar型のn個の領域が開放されますが このときのnの値（開放すべきデータのサイズ）は メモリのどこに保存されているのでしょうか。 それから x=new char[n]; を開放するときは delete x[]; という人もいますが、これは間違いではないでしょうか。 以上、お願いします。

400000です… くだらないことですいません…。

>crowbarのver.0.3.02は、9/26中には出します… 日本語関係は、ISO-C の mbr/wcs 系関数 (1バイトずつ処理するなら mbrtowc(3)) を使うのはどうですか? 想像だけど、これで Windows なら wchar_t は Unicode になるん じゃないでしょうか。(UNIX 系だと wchar_t 表現も locale 依存に なります。Linux の場合は Unicode) これが存在しない古い OS では1バイト文字だけサポートするとか。

crowbarのver.0.3.02は、9/26中には出します… と言っておかないとずるずる遅れていきそうなので (^^: いやその所詮マイナーバージョンアップなんですが。

>さて、リターンした後ですが、main()側は、aとb両方のアドレスを >知っているわけです。なので、bのアドレスをスタックなどに積む必要は >ないのでは、と言いたかったわけですが。 なるほど(^-^;) 了解です。

>>Pascalではprocedureのネストが可能で、 >>呼ばれた側の関数から呼び出し側の関数のローカル変数を参照できるため、 > >C言語に変数引数を追加した言語でも、グローバル変数を使えば同じことが起きませんか？ あ、そりゃそうだ f(^^; いろいろ見逃してましたね。ご指摘ありがとうございます。

>Pascalではprocedureのネストが可能で、 >呼ばれた側の関数から呼び出し側の関数のローカル変数を参照できるため、 C言語に変数引数を追加した言語でも、グローバル変数を使えば同じことが起きませんか？

>>呼び出し側で、通常の値渡しと同じように現状の値をスタックに積み、 >>関数から戻って来たところで、呼び出し側でコピーを行えばよいのでは。 >そうですそうです。 >なので「コピー先（元）がどこ？」って情報がどこかには必要ですよね。 ええと、C(C++?)風擬似言語で、 void hoge(int &a) ←変数引数の宣言 { printf("%d", a); a = 10; } int main() { int b = 20; hoge(b); } と書いたとき、 (1)通常のCの関数呼び出しと同様、main側で、bをスタックに積む。 (2)よって、hoge()のprintf()では、20が表示される。 (3)hoge()内の「a = 10;」により、引数aに10が設定されて、リターン。 さて、リターンした後ですが、main()側は、aとb両方のアドレスを 知っているわけです。なので、bのアドレスをスタックなどに積む必要は ないのでは、と言いたかったわけですが。

>呼び出し側で、通常の値渡しと同じように現状の値をスタックに積み、 >関数から戻って来たところで、呼び出し側でコピーを行えばよいのでは。 そうですそうです。 なので「コピー先（元）がどこ？」って情報がどこかには必要ですよね。

>ただ、その場合でも関数から戻ってきた際のコピー先を引数として渡さなくても、 >暗黙的にはスタックとかに積んでおく必要がありそうですね。 呼び出し側で、通常の値渡しと同じように現状の値をスタックに積み、 関数から戻って来たところで、呼び出し側でコピーを行えばよいのでは。

まずお詫びと訂正ですが、[575]でURLの訂正をしましたけれど、 [576]でまた間違ったほうのURLを貼ってしまいました。正しいのは http://java-house.jp/ml/archive/j-h-b/028873.html#body です。 >話は完全にそれますが、この JavaHouse での記述は誤りですね。 そうでした。(完璧に意識の外でしたが)Pascalではprocedureのネストが可能で、 呼ばれた側の関数から呼び出し側の関数のローカル変数を参照できるため、 呼び出し側の関数のローカル変数がいつ変更されたのかが見えてしまうわけですね。

>|「元の変数を参照 >| している」ということを意識する必要がありません。アドレスが渡されると >| いうのは実装上の都合であって、コピーを渡してリターン時に元のところに >| コピーし戻すという実装でも同じ意味になります (これをcall-by-value- >| resultと呼ぶ)。 > >とあるように、そもそも単なる変数引数であれば「参照値」自体を意識する >必要はないのではないか、ということです。 話は完全にそれますが、この JavaHouse での記述は誤りですね。 var x:integer; procedure hoge(var a: interger); begin a:=1; a:=a+x; end; x:=10; hoge(x); のように、変数引数が alias となるケースでは、参照渡しの場合と、 call-by-value-result 場合とで結果が異なります。 参照渡し: x=2 call-by-value-result: x=11 参照値であるということを意識しないですむとは限りません。

>これが同じ意味になるのは、pascalにコピーコンストラクタのようなものがないからですよね。もしC++だったら別の意味になってしまいます。 なるほど。それはわかります。 >ということで、「コピー渡し」「原本渡し」という言葉を考えてみました。 >従来「値渡し」と呼んでいるものは、たいていの場合スタックにコピーが作られるので「コピー渡し」であると。逆に「参照渡し」と呼んでいるものは「原本渡し」であると。 なんというか憂鬱本の「実体渡し」を彷彿とさせますが… それはさておき。 「変数引数」的なことをやりたいときに、参照渡しだと、実装上面倒なことに なるケースがあるわけです。たとえばJavaでは、素朴なVMでは、ヒープ中の オブジェクトの先頭以外、ポインタが継続して指すことはありませんが、 参照渡しを許すと、ローカル変数やら、オブジェクトのメンバやら、配列の 要素を指すポインタが継続して保持されてしまう。これは、ガベージコレクタの 実装を考えると何かと面倒です。 そのせいかどうかは知りませんが、Javaは変数引数という機能を言語から 捨て去ってしまった。でも、やっぱりそれじゃswap()も作れないし不便だよね、 という時に、call-by-value-resultという実装方法は効果を発揮するわけです。 Pascal的な言語だと、こうやって実装の楽なGCと変数引数が混在できますが、 コピーコンストラクタを好き勝手に書けるC++だと難しそうではあります。 C#では、=でコピーコンストラクタが動くわけではなかったですよね。確か。

>ということで、「コピー渡し」「原本渡し」という言葉を考えてみました。 「shallow copy渡し」「deep copy渡し」とか出てきたりして(^-^;)

>| いうのは実装上の都合であって、コピーを渡してリターン時に元のところに >| コピーし戻すという実装でも同じ意味になります (これをcall-by-value- >| resultと呼ぶ)。 おお、なるほど！ で書かれても実際にはコピーを渡す、という実装のされ方もありえるわけですね。 メモメモ・・・と。 ただ、その場合でも関数から戻ってきた際のコピー先を引数として渡さなくても、 暗黙的にはスタックとかに積んでおく必要がありそうですね。 >アプリケーションプログラムを書くのなら、なるべく上の方の世界に住んでいたいなあ、 >と私は思うわけでして。 あ、これは私も思います。

>| コピーを渡してリターン時に元のところに >| コピーし戻すという実装でも同じ意味になります (これをcall-by-value- >| resultと呼ぶ)。 ここにだけ反応。 これが同じ意味になるのは、pascalにコピーコンストラクタのようなものがないからですよね。もしC++だったら別の意味になってしまいます。 ということで、「コピー渡し」「原本渡し」という言葉を考えてみました。 従来「値渡し」と呼んでいるものは、たいていの場合スタックにコピーが作られるので「コピー渡し」であると。逆に「参照渡し」と呼んでいるものは「原本渡し」であると。 コピーを作るかどうかが意味論上、重要な違いをもつ場合もありますので、 こういう区別って大事だと思うんですが。

>> うーん、これが関数の引数についてであれば、「参照渡し」はあくまで >> 「変数引数」の実装手段に過ぎない、と考えれば、これをそこまで言ってしまうのは >> 実装に過度に踏み込んでいる気もします。 >なるほど。ポインタ値ならぬ、「参照値」を引き出した後のことは実装任せと >いうことですね。 ええ、すみません、リンクを貼り損ねたおかげで誤解させてしまったようです。 私が言いたかったのは、貼りなおしたリンク先に http://java-house.jp/ml/archive/j-h-b/028784.html#body | Pascalなどでは、(C系と違って)aの参照と | しての値(アドレス)をどこか他のところへ代入することはできませから、aと | いう参照値の生存範囲はそのスコープ内に限られます。そのような言語では、 | 変数aは呼出し元の変数と「同一物」と考えれば済みます。「元の変数を参照 | している」ということを意識する必要がありません。アドレスが渡されると | いうのは実装上の都合であって、コピーを渡してリターン時に元のところに | コピーし戻すという実装でも同じ意味になります (これをcall-by-value- | resultと呼ぶ)。 とあるように、そもそも単なる変数引数であれば「参照値」自体を意識する 必要はないのではないか、ということです。 まあ、Pascalはともかく少なくともC++では、そういう引数渡しを言語自体が 「参照渡し」と呼んでいるので、ここまで言ってしまうのも問題かもしれませんが、 アプリケーションプログラムを書くのなら、なるべく上の方の世界に住んでいたいなあ、 と私は思うわけでして。

>うーん、これが関数の引数についてであれば、「参照渡し」はあくまで >「変数引数」の実装手段に過ぎない、と考えれば、これをそこまで言ってしまうのは >実装に過度に踏み込んでいる気もします。 > >参考リンク： >http://java-house.jp/ml/archive/j-h-b/028784.html#body すみません、リンクURL貼り損ねました。正しくはこっちです。 http://java-house.jp/ml/archive/j-h-b/028873.html#body

> 「JVMはアドレスを使うとは限らんからJavaにはポインタはないのだ」 > という批判からすれば、2段階離れたところにいるわけです。 了解です。 > でもそれを前提にしてくれるな、というのが私の言いたかったことなのでした。 Javaプログラマ達さんのいう「ポインタ」の概念が、 K&Rの「ポインタは、他の変数のアドレスを内容とする変数であり」(p.114)の文章を 前提としているなら「Javaにはポインタがない」という主張はあり得ますね。 ただし、その場合は引用なりすべきだと思います。 > うーん、これが関数の引数についてであれば、「参照渡し」はあくまで > 「変数引数」の実装手段に過ぎない、と考えれば、これをそこまで言ってしまうのは > 実装に過度に踏み込んでいる気もします。 なるほど。ポインタ値ならぬ、「参照値」を引き出した後のことは実装任せということですね。 # 私はまだまだこの辺りの線引きがヘタだなぁ・・・

>JVMの仕様書 → 参照はポインタ > >K&R → ポインタはアドレス > >ゆえに参照はアドレス > > >・・・と3段論法にしてしまいますか(^-^;) 私が言っているのは、 ・Javaのポインタ(参照)は「C/C++の」ポインタとは違う(ところがある) 　→Java謎+落とし穴～ 2.1.2「C/C++のポインタとJavaのポインタとの違い」 ・Cのポインタは、必ずしも(生)アドレスである必要はない 　→ポインタ完全制覇 2.9 「言語仕様と実装について」 ということなので、村山さんが言うところの、 「JVMはアドレスを使うとは限らんからJavaにはポインタはないのだ」 という批判からすれば、2段階離れたところにいるわけです。 まあ、村山さんの批判対象は、きっと私以外の誰かなのでしょうが。 >↑は冗談としても、ポインタというのはすべからく「データの在り処を >指し示すもの」でしかないわけで、Javaの「参照」もC言語のような >ポインタではないという風に結論付けてもポインタというのはプログラミング >言語にはついて回る概念だと考えています。 そう思います。ただ、もしポインタについて「データの在り処を指し示すもの」 という定義をとらず、「ポインタとはアドレスのことなのだ」という定義の上で 話すのであれば、「Javaにはポインタがない」という主張はあり得ます (そういうこともJava謎+落とし穴～には書きました)。 でもそれを前提にしてくれるな、というのが私の言いたかったことなのでした。 >　参照渡しについて、値渡しとの違いを説明するときにも「データの在り処を >渡す」としか説明できないのであれば、それはやはりポインタでしかないと思います。 うーん、これが関数の引数についてであれば、「参照渡し」はあくまで 「変数引数」の実装手段に過ぎない、と考えれば、これをそこまで言ってしまうのは 実装に過度に踏み込んでいる気もします。 参考リンク： http://java-house.jp/ml/archive/j-h-b/028784.html#body

JVMの仕様書 → 参照はポインタ K&R → ポインタはアドレス ゆえに参照はアドレス ・・・と3段論法にしてしまいますか(^-^;) ↑は冗談としても、ポインタというのはすべからく「データの在り処を指し示すもの」でしかないわけで、Javaの「参照」もC言語のようなポインタではないという風に結論付けてもポインタというのはプログラミング言語にはついて回る概念だと考えています。 　それがスタックデータへのポインタであれば「スタックポインタ」ですし、インストラクションデータへのポインタであれば「インストラクションポインタ」でしょう。 　参照渡しについて、値渡しとの違いを説明するときにも「データの在り処を渡す」としか説明できないのであれば、それはやはりポインタでしかないと思います。 　オライリー本では「参照型はオブジェクトへのハンドル」と説明していますが、仮にハンドラが存在したとしても最終的にはデータの在り処を知る必要が出てきますよね。 # ついでに「C言語で言うとポインタと考えられるでしょう」とも書いてあります。:-)

>確かにJavaにはポインタがあると考えたほうが理解はしやすいでしょうが、 >やはり「厳密に言えば」無いと思います。 > >まぁ理由はリンクしているページに書いてあるとおりなのですが。 >思います、なんて書いてるのは自身がJava仮想マシン仕様書を読んだことが無いからで・・・ ネットジーンの村山さんの文章ですね。 | Java言語にもJavaVMにも，C言語でいうようなポインタ(pointer) という | 概念は全く存在しない．あるのは参照(reference)であり，参照と | ポインタは異なる概念になる． (中略) | (C言語におけるポインタは単なる「アドレス値を保持する変数」に過ぎない． | Cにおいては配列や文字列さえもポインタ演算で表現されている．これに対して | 参照というのはもっと抽象的な概念で，保持するのがアドレス値であるとは限らない． | 概念が異なるため，例えば「参照どうしの大小関係」や「参照と数値型との相互変換」 | などは，そもそも「定義」することができない． Javaに「アドレス値」としてのポインタは存在しません。そんなことは当たり前で、 そういう意味での「ポインタ」がJavaにあるなどとは誰も主張していないでしょう。 少なくとも私は見たことがありません。村山さんの脳内にはいるのかもしれませんが。 ていうかそもそもCにおいても、ポインタ同士の大小章比較が保証されているのはひとつの 配列内だけだし、ポインタと数値型との相互変換はできますが、それで何が起きるかは 処理系定義なんですが、そういうことをわかって書いてるのかな。 | JavaVMの実装でC言語，及びそのポインタが使われることが多いのは事実だが， (中略) | それは実装依存の話でしかない． 実際、初期の実装では、コンパクションを容易にするために生アドレスではなく オブジェクトハンドルを使っていました。「Java謎+落とし穴」ではそういうことも 書いているわけで(p.131)、私からすれば「だから何?」でしかないです。 | ポインタを「指し示すもの」という一般用語として解釈することも不可能 | ではないが，かなり言い訳じみている． なぜこれが「言い訳じみている」のか、一言も説明してませんね。 PascalやModula2の立場はどうなるのか、とこれも「Java謎+落とし穴～」には 書きました(p.83)。 ところで、村山さんが根拠にしているはずの、JVMの仕様書には以下の記述があります。 http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#29375 | There are three kinds of reference types: the class types (§2.8), the | interface types (§2.13), and the array types (§2.15). An object is a | dynamically created class instance or an array. The reference values | (often just references) are pointers to these objects and a special null | reference, which refers to no object. 参照値はポインタだって書いてあるじゃん。

>「ポインタは最適化できない」ということだと思うのですよ。 >(なぜなら「型」という概念上のものだから) すみません、おっしゃっていることがイマイチ掴めません。 >(なぜなら「型」という概念上のものだから) とのことですが、Javaにも「参照型」という概念がありますよね？

>規格上、Cのポインタの内部表現は実装依存で、必ずしもアドレス値であるとは限らないわけです。 >リンク先のページは僕も以前読んだ事があって、とてもタメになりました。でも、「Cのポインタはアドレス値」を前提にした説明は変だな、って思います。 アドレス値を保持する変数という言い方は確かに正確ではないかもしれませんが、 ここで言いたかったのはそういうことではなくて、 「ポインタは最適化できない」ということだと思うのですよ。 (なぜなら「型」という概念上のものだから) C関係の説明は確かに変ですが、そこは言いたかった本質ではないのではないかと。

>確かにJavaにはポインタがあると考えたほうが理解はしやすいでしょうが、 >やはり「厳密に言えば」無いと思います。 > >まぁ理由はリンクしているページに書いてあるとおりなのですが。 前橋さんのこちらの文章はお読みになりましたか？ http://kmaebashi.com/seiha/hosoku001.html 規格上、Cのポインタの内部表現は実装依存で、必ずしもアドレス値であるとは限らないわけです。 リンク先のページは僕も以前読んだ事があって、とてもタメになりました。でも、「Cのポインタはアドレス値」を前提にした説明は変だな、って思います。

横からすいません。 Java謎+落とし穴読みました。 なかなか面白い本ですが、ポインタについて少し。 確かにJavaにはポインタがあると考えたほうが理解はしやすいでしょうが、 やはり「厳密に言えば」無いと思います。 まぁ理由はリンクしているページに書いてあるとおりなのですが。 思います、なんて書いてるのは自身がJava仮想マシン仕様書を読んだことが無いからで・・・ リンク先のページに間違いがある可能性もありますが、 説得力で言うとリンク先のページのほうが上かな、と。 まぁどちらも大人な感じを受けますので、 どっちでもいいといえば正直どっちでもいいんですがね^^;

あーなんか誤解を招きかねない？のでちょっと修正 malloc 等で得られたポインタ値が prm に入っているとします (仮に 0xabcd としよう) free(prm); する前の時点では prm==0xabcd であり 0xabcd 番地のメモリを使うことができます。 free(prm); した後の時点でも prm==0xabcd ですが 0xabcd 番地のメモリは使えなくなっています。 ってただそれだけの話ですね。 # 厳密に言えば 0xabcd 番地にメモリはあるが、使用権限が無いというべきか。 free(prm); の後に free(prm->cpItem); のような操作をしてはいけません。 free(prm); した時点で prm の指す先は無効となっています。 こういうのをダングリングポインタとか言いますな。

prm が指す先のメモリ領域は正しく開放されます。 その結果 prm 自体は無効なメモリ領域を指すようになるだけです。 まったく一切何の問題もありません。 >引数を変更しても呼び出し元には影響を与えないように思います。 そこのところはまさに御意なのですが、 どこで「prm そのもの」を操作しているのでしょうか？ prm が指す先を操作しているだけです。 ごくふつーに、配列等で行っている処理とまったく同じ事をしていますよ。

>正>void PrmDestroy( typChangePrm *prm) >正>{ >正> int i; >正> >正> if ( prm && prm->cpItem) { >正> for ( i=0; i<prm->itemCount; i++) { >正> free(prm->cpItem[i]); >正> } >正> } >正> if ( prm) free(prm->cpItem); >正> free(prm); >正>} 上記関数のfree(prm);の部分ですが、 この処理でprmはきちんと開放されているのでしょうか。 Cの引数は値渡しなので、（この場合、引数はポインタですが、ポインタも値渡し） 引数を変更しても呼び出し元には影響を与えないように思います。 free(prm->cpItem);のように、ポインタの中身に対する変更は問題ないと思います。

>aaaaaa 上に書いてあるように、テスト書き込みならテスト掲示板の方にお願いします。

>http://kmaebashi.com/programmer/devlang/yacclex.html 上のyaccfile.png >という画像の説明において、mycalc.l → yacc となっているのが気になりました >（mycalc.y → yacc ですよね？間違っていたらゴメンナサイ）。 ご指摘ありがとうございます。 おっしゃるとおり間違っていますので、修正しました。ありがとうございました。

aaaaaa

aaaaaa

はじめまして。 yacc/lex の解説ページを探していてたどり着きました。 説明がわかりやすくて助かります。 http://kmaebashi.com/programmer/devlang/yacclex.html 上のyaccfile.png という画像の説明において、mycalc.l → yacc となっているのが気になりました （mycalc.y → yacc ですよね？間違っていたらゴメンナサイ）。 これからも頑張ってください。

>大変失礼しました。私の能力の低さが露呈してます(T-T) ぐぁっ、私はそこって全然気がつきませんでした(T_T)

>とはいえいわゆる non-ANSI な超古い処理系ではダメなのもあったような記憶がうっすらと。 あ、non-ANSIは知らないです。いわゆる「ぬるぽ」になるかもしれませんね。

>>free() の解説に、空ポインタの場合何もしないとあるので無問題です。 >C89もセーフですよ。 とはいえいわゆる non-ANSI な超古い処理系ではダメなのもあったような記憶がうっすらと。 そーいう化石のようなプラットフォームまで考えるかどうか次第かな。

>>>free() の解説に、空ポインタの場合何もしないとあるので無問題です。 >>C89もセーフですよ。 確かにfree(NULL)は無問題なのですが、以下の※の箇所は大問題でした。 | if ( (prm = malloc( sizeof( typChangePrm))) == NULL) { | fprintf(stderr,"ERROR: memory allocation\n"); | goto LERROR;　←ココ | } (中略) | LERROR: | free( prm->cpItem); ← ※ | free( prm); | return NULL; |} このような箇所は「if ( prm ) free( prm->cpItem);」が必要ですね。 以下の箇所も間違っていますね。 誤>void PrmDestroy( typChangePrm *prm) 誤>{ 誤> int i; 誤> 誤> for ( i=0; i<prm->itemCount; i++) 誤> free(prm->cpItem); 誤> free(prm->cpItem); 誤> free(prm); 誤>} 正>void PrmDestroy( typChangePrm *prm) 正>{ 正> int i; 正> 正> if ( prm && prm->cpItem) { 正> for ( i=0; i<prm->itemCount; i++) { 正> free(prm->cpItem[i]); 正> } 正> } 正> if ( prm) free(prm->cpItem); 正> free(prm); 正>} 大変失礼しました。私の能力の低さが露呈してます(T-T)

>realloc() に失敗する状況でどうリカバリーするかの仕様次第ですけど、 >書かない癖つけたほうがいいと思う。 私もそう思います。 なので私のサンプルはメモリの再配置が多そうだったことも含めて 完全にfree()してしまったりしてます(^-^;)

>free() の解説に、空ポインタの場合何もしないとあるので無問題です。 C89もセーフですよ。

>矢印の箇所でgotoしたとき、prmはNULLだからSegmentation faultになりませんか。 C89 でどうだったかは知りませんが少なくとも C99 では free() の解説に、空ポインタの場合何もしないとあるので無問題です。 MSDN や HPUX11.00 の man にも同一の旨の記述があります。

>typChangePrm *CreatePrm( char *cString, int itemCount) >{ > typChangePrm *prm = NULL; > int i; > > if ( (prm = malloc( sizeof( typChangePrm))) == NULL) { > fprintf(stderr,"ERROR: memory allocation\n"); > goto LERROR;　←ココ > } (中略) > LERROR: > free( prm->cpItem); > free( prm); > return NULL; >} 矢印の箇所でgotoしたとき、prmはNULLだからSegmentation faultになりませんか。

こんな感じかなぁ? 要素追加しちゃったけど。 ---- #include <stdio.h> #include <stdlib.h> #include <string.h> typedef struct{ int itemCount; char cString[50]; char **cpItem; } typChangePrm; typChangePrm *CreatePrm( char *cString, int itemCount) { typChangePrm *prm = NULL; int i; if ( (prm = malloc( sizeof( typChangePrm))) == NULL) { fprintf(stderr,"ERROR: memory allocation\n"); goto LERROR; } if ( strlen( cString) >= 50 ) return NULL; strcpy( prm->cString, cString); prm->itemCount = itemCount; if ( (prm->cpItem = malloc( sizeof(char *) * itemCount )) == NULL) { fprintf(stderr,"ERROR: memory allocation\n"); goto LERROR; } for ( i=0; i<itemCount; i++) prm->cpItem[i] = NULL; return prm; LERROR: free( prm->cpItem); free( prm); return NULL; } void PrmDestroy( typChangePrm *prm) { int i; for ( i=0; i<prm->itemCount; i++) free(prm->cpItem); free(prm->cpItem); free(prm); } void PrmResize( typChangePrm *prm, int itemCount) { char **tmp; int i; if ( prm->itemCount >= itemCount ) { for ( i=itemCount; prm->i<itemCount; i++) free( prm->cpItem[i]); prm->itemCount = itemCount; return; } tmp = prm->cpItem; if ( (tmp = realloc( tmp, sizeof(char *) * itemCount)) == NULL) { fprintf(stderr,"ERROR: memory allocation\n"); goto LERROR; } prm->cpItem = tmp; for ( i=prm->itemCount; i<itemCount; i++) prm->cpItem[i] = NULL; prm->itemCount = itemCount; return; LERROR: free( prm->cpItem); } void PrmSetItem( typChangePrm *prm, int item_no, char *item) { if ( item_no >= prm->itemCount) return; if ( (prm->cpItem[ item_no] = strdup( item)) == NULL) fprintf(stderr,"ERROR:memory allocation\n"); } void PrmShow( typChangePrm *prm) { int i; printf("********************************\n"); printf("Item Count:%d\n",prm->itemCount); printf("cString :%s\n",prm->cString); for ( i=0; i<prm->itemCount; i++) printf("Item[%d]:%s\n",i,((prm->cpItem[i]==NULL)?"NULL":prm->cpItem[i])); } int main(void) { typChangePrm *prm; char *item[] = { "hello", "world", "program"}; if ( (prm = CreatePrm("c-string",2)) == NULL) return 1; PrmSetItem(prm,0,item[0]); PrmSetItem(prm,1,item[1]); PrmShow( prm); PrmResize( prm, 3); PrmSetItem(prm,2,item[2]); PrmShow( prm); PrmResize( prm, 1); PrmShow( prm); PrmDestroy(prm); return 0; }

>data.cpItem[n] = realloc( data.cpItem[n], new_size); 皆さん同じコードをかかれていますけど、これってダメコードですよ。 realloc() に失敗したら、旧 data.cpItem[n] がリークしますね。 # 旧値が失われて復旧の手段が無い。 realloc() に失敗する状況でどうリカバリーするかの仕様次第ですけど、 書かない癖つけたほうがいいと思う。

>要はコダマンさんが、 >　・cpItem自体をreallocしたいのか >　・cpItem[n]のほうをreallocしたいのか >に尽きるんじゃないでしょうか。 要求をちゃんと定義してもらわずに作業を始めると戻り工数が大きくなりますよねー 私は最初「構造体の中のポインタ配列のreallocの方法」と言ってるので typedef struct{ char cString[50]; char *cpItem[]; }typChangePrm; typChangePrm data; data.cpItem[n] = realloc( data.cpItem[n], new_size); の程度のことを質問してると思ってましたが...(^^) 日本語の解釈って色々できるんですね。

要はコダマンさんが、 　・cpItem自体をreallocしたいのか 　・cpItem[n]のほうをreallocしたいのか に尽きるんじゃないでしょうか。 まきじさんのサンプルは前者をrealloc()ですけれど、 後者も行いたい場合はやはりこちらもrealloc()で書いたほうが便利でしょうね。 # あとcpItem自体が縮小した場合の考慮をしないとメモリリークしますね。 # ってここはツッコミ入れなくても大丈夫か(^-^;)

>…が、既にかずまさんからツッコミが入ってますが、まきじさんのコードだと、 >2回目のrealloc()でも第一引数にNULL渡してますね…ケアレスミスだとは思いますが。 よく読んでなかったのでここも修正です… 2回目のrealloc()は別に領域拡張しているわけではなく、単なるmalloc()と 同値なので、上の私の記述は見当外れですね。失礼しました。

>最初から第一引数に定数のNULLを渡すくらいなら、malloc()を使うべきでしょう。 realloc() の質問でしたので、realloc() にしただけです。 特に深い意味、意図はないです。

>>>data.cpItem[i] = malloc(sizeof(char) * 64); > >realloc() の第一引数を、NULL にすれば、malloc() と同じ動作をします。 >よって、realloc(NULL,sizeof(char) * 64); でも問題ありません。 いや、もちろんそれは知っていますが、スタイルとしてどちらを取るかという 問題です。 もともと、realloc()の第一引数をNULLにすればmalloc()と同じ動作をする、 という仕様は、最初のメモリ確保と2回目以降のメモリ確保とで別々のコードを 記述する手間を避けるためのものでしょう。 ですから、この例で言えば、data.cpItemの指す先を確保した際、 その中身を全部NULLに初期化しておけば、 data.cpItem[i] = realloc(data.cpItem[i],sizeof(char) * 64); と書けば、このポインタの指す先にデータが来るかどうかわからないような 時、重複したコードを書かなくてよくなるわけです。 この仕様自体はそれなりに便利なものだとは思うのですが(でもこれも realloc()の仕様としてはオーバースペックだという意見もありうるわけですが)、 最初から第一引数に定数のNULLを渡すくらいなら、malloc()を使うべきでしょう。 …が、既にかずまさんからツッコミが入ってますが、まきじさんのコードだと、 2回目のrealloc()でも第一引数にNULL渡してますね…ケアレスミスだとは思いますが。 これは私は気付いていませんでした。

>最初の 10個の領域とは別に、新たに 20個の領域を確保 *(data.cpItem + i) = realloc(NULL,sizeof(char) * 64); で、要素数が 64 個の char 型配列が新たに、20 個確保されていると云うことですね？ それより前で、10 個確保されているので、第一引数に NULL を指定すると、 新たに 20 個確保され10 個分、余分にメモリを消費する。 だから、解放するか、20 個の内 10 個は、前と同じ内容なので、残りの 新たに確保された領域 10 個に対して、malloc() してやれば良いですね。 data.cpItem[10] から領域を新たに確保という事で for(i = 10;i < 20; i++){ *(data.cpItem + i) = realloc(NULL,sizeof(char) * 64); strcpy(*(data.cpItem + i),str); } でどうでしょうか？

そういうわけで私流に書き直してみるテスト。 --- #include <stdio.h> #include <stdlib.h> #include <string.h> typedef enum { true = (1 == 1), false = !true } boolean; typedef struct{ char cString[50]; char **cpItem; } typChangePrm; void freeMemory(typChangePrm *data) { int i; printf("freeMemory - start\n"); for(i = 0; data->cpItem[i]; i++) { printf(" free(item) : pointer[%p]\n", data->cpItem[i]); free(data->cpItem[i]); } printf(" free(item container) : pointer[%p]\n", data->cpItem); free(data->cpItem); data->cpItem = NULL; printf("freeMemory - end\n"); return; } boolean allocateMemory(typChangePrm *data, size_t itemSize) { char **prevMemory; size_t allocateSize; int i; printf("allocateMemory - start\n"); if (data->cpItem != NULL) { freeMemory(data); } data->cpItem = calloc(itemSize + 1, sizeof(char *)); // +1して番兵をつける printf(" allocate(item container) : pointer[%p]\n", data->cpItem); for(i = 0;i < itemSize; i++){ data->cpItem[i] = calloc(64, sizeof(char)); if (data->cpItem[i] == NULL) { freeMemory(data); // 初期化に失敗したら壊す return false; } printf(" allocate(item) : pointer[%p]\n", data->cpItem[i]); } printf("allocateMemory - end\n"); return true; } int main(void){ typChangePrm data; char str[]="hoge"; size_t allocateSize; size_t itemSize; int i; data.cpItem = NULL; allocateMemory(&data, 10); allocateMemory(&data, 20); freeMemory(&data); return 0; }

ついでに言うと、2回目のアロケートを以下のように書き直しても 　　*(data.cpItem + i) = realloc(*(data.cpItem + i), sizeof(char) * 64); realloc失敗時に*(data.cpItem + i)がNULLになってしまってやはりダメですね。

>realloc() の第一引数を、NULL にすれば、malloc() と同じ動作をします。 >よって、realloc(NULL,sizeof(char) * 64); でも問題ありません。 malloc も realloc も関係ありません。そのプログラム自体に問題があります。 最初の 10個の領域とは別に、新たに 20個の領域を確保していて、最初の 10個の領域は二度と使えません。これをメモリーリークといいます。

>>data.cpItem[i] = malloc(sizeof(char) * 64); realloc() の第一引数を、NULL にすれば、malloc() と同じ動作をします。 よって、realloc(NULL,sizeof(char) * 64); でも問題ありません。

ええと、これはコダマンさんの質問に対するひとつの解答例、ということで よいでしょうか? ところで私なら、 >*(data.cpItem + i) = realloc(NULL,sizeof(char) * 64); この部分はこう書きます。 >data.cpItem[i] = malloc(sizeof(char) * 64);

#include<stdio.h> #include<stdlib.h> typedef struct{ char cString[50]; char **cpItem; /* ポインタのポインタにする*/ }typChangePrm; int main(void){ typChangePrm data; char str[]="hoge"; int i; /* 10 個の要素を持つポインタの配列を確保 */ data.cpItem = realloc(NULL,sizeof(char*) * 10); for(i = 0;i < 10; i++){ /* *(data.cpItem + i) に 64 個 の要素を持つ char 型の配列を確保 */ *(data.cpItem + i) = realloc(NULL,sizeof(char) * 64); strcpy(*(data.cpItem + i),str); } for(i = 0;i < 10; i++) printf("%s\n",*(data.cpItem + i)); strcpy(str,"foo"); /* ポインタの配列の要素数を 20 個に変更 */ data.cpItem = realloc(data.cpItem,sizeof(char*) * 20); for(i = 0;i < 20; i++){ /* *(data.cpItem + i) に 64 個 の要素を持つ char 型の配列を確保 */ *(data.cpItem + i) = realloc(NULL,sizeof(char) * 64); strcpy(*(data.cpItem + i),str); } for(i = 0;i < 20; i++) printf("%s\n",*(data.cpItem + i)); return 0; }

はじめまして。 >typedef struct{ > char cString[50]; > char *cpItem[]; //タイプ/処理名/置換先項目/置換元項目/デフォルト値/ >}typChangePrm; まず質問ですが、コンパイラはなんでしょうか? いわゆるANSI-C (ISO-C89)では上のコードは通りません。 ISO-C99なら通ります。gccにも似たような独自拡張があったような。 >↑のような構造体の中のポインタ配列のreallocの方法がわからず苦戦しております。 で、単にcpItemを可変個確保したいだけなら、このページが参考になるでしょう。 http://seclan.dll.jp/c99d/c99d04.htm#dt19990726 確保するサイズは sizeof(typChangePrm) + sizeof(char*) * num ですね。 ただ、それ以前の問題として、こういう構造体をrealloc()する時は、 「この構造体を指しているポインタはないか」ということを意識する必要があります。 realloc()するとアドレスが変わることがあるため、これを指しているポインタがあると そっちも書き換えてやらなければいけません。 それが難しいのなら、可変長構造体を使うのではなく、この構造体に 可変長配列へのポインタを持たせるべきでしょう。 typedef struct{ char cString[50]; char **cpItem; // この先の領域をrealloc()する。 }typChangePrm; # ところでcpItemの数はどっかで保持してるんでしょうか。

始めまして。 typedef struct{ char cString[50]; char *cpItem[]; //タイプ/処理名/置換先項目/置換元項目/デフォルト値/ }typChangePrm; ↑のような構造体の中のポインタ配列のreallocの方法がわからず苦戦しております。 どなたか、ご存知でしたら教えてください。

ええと、まず目的として、クイックソートなんだから当然再帰を使いたい、 ってのがあって、つまりいかにしてquick_sort_sub()を呼び出すかが 問題なわけですが、 以下の箇所で定義されているふたつのクロージャを、それぞれ c1, c2とすると、 fp_op2(closure(quick_sort_sub) { ←c1 return closure(left, right) { ←c2 c2が、通常のクイックソートの実行部ですが、その中では、 その外周のクロージャであるc1の引数である、quick_sort_sub()が 参照できるわけですね。 c1は、引数としてクロージャを受け取り、戻り値としてc2を返すわけですが、 c1の引数にc2を渡して実行できれば万事解決である、と。 で、これを実現しているのがfp_op2()であるわけですが、 これは以下のように書き換えることが可能で、 function fp_op2(f) { c3 = closure(p) { return p(p); }; c4 = closure(x) { c5 = closure(g, h) { return f(x(x))(g, h); }; return c5; }; return c3(c4); } 最後のreturnでc3が実行されていますが、 c3というのは、クロージャを受け取り、そのクロージャにそれ自身を 渡して実行して返す関数なわけで、で、c3のpに実際に渡されているのは c4なので、つまりこのタイミングでc4が実行される。 c4は引数としてxを受け取りますが、c3の定義からして、 xにはc4自身が格納されている。 そして、c4は、戻り値としてc5を返す。 この戻り値は、c3の戻り値でありすなわちfp_op2()の戻り値でもある。 呼び出し元のquick_sort()関数のほうでは、fp_op2()の戻り値に 引数ふたつ与えて評価して、それがクイックソートの実行となる。 で、そのc5ですが、「f(x(x))」のfはつまりc1であり、 その引数の「x(x)」におけるxはc4なので、fの引数には c4の戻り値が渡されることになる。 c4の戻り値であるc5はつまり、引数をふたつとってc1の戻り値 すなわちc2を実行して返す、という、c2のラッパーなので、 当初の目的である 「c1の引数にc2を渡して実行できれば万事解決である」 というのが実現できている… うーん、ぶすぶす… (頭から煙が出ている音) Paul Grahamの「簡潔さは力なり」の中で、 http://www.shiro.dreamhost.com/scheme/trans/power-j.html 数式を散文で書くと量が増える、なんてことが書いてありますが、 数式の力を持ち合わせていない私が書くとこうなってしまうわけで、 やっぱり勉強不足ですね。

> …頭から煙が出そうになったので、サンプルのソースを読もうとしてみました。 サンプルをそのまま追うと多分死にます。 簡略化してから追うと fp_op2(closure(f) { return closure(x, y) { ... f(a, b) ... }; }) ⇒ Z Z(c, d) ⇒ closure(f) { return closure(x, y) { ... f(a, b) ... }; }(Z)(c, d) ⇒ closure(x, y) { ... Z(a, b) ... }(c, d) こんな感じです。 参考ページ http://lecture.ecc.u-tokyo.ac.jp/~kawai/pub/is/isis2-note.html http://www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/fix.html ＃ 「不動点演算子」じゃなかなか見付からないですね。orz ＃ どうやって見付けたんだろう。 == 私も(crowbarを基に)プログラミング言語を作ろうと思っていますが、 そのときは名前付きのクロージャは入れないで、 Schemeの拡張シンタックスのような機能を付けようと思っています。 んで、 named_closure tag (x, y, ...) { ... } と書けば closure(tag) { tag = closure(x, y, ...) { ... }; return tag; }(null) と展開されるようなものをプログラマが自分で作れるようにしたいな、と(不動点演算子はどこへ行った) ＃ で、ライブラリに入れておく

>はじめまして、「プログラミング言語を作る」楽しく読ませていただいています。 どうも。はじめまして。最近停滞しておりましてすみません。 >crowbarには再帰呼び出しのための名前付きのクロージャがありますが、 >名前のないクロージャでも、不動点演算子を使えば再帰呼び出しは可能です。 知らなかったので、「不動点演算子」をGoogleしてみました。 …頭から煙が出そうになったので、サンプルのソースを読もうとしてみました。 …すみません、今の眠い頭ではちょっと追えそうにないので、後日再挑戦してみます。 興味深いネタの提供ありがとうございました。 # 勉強不足を痛感いたしますです。

はじめまして、「プログラミング言語を作る」楽しく読ませていただいています。 crowbarには再帰呼び出しのための名前付きのクロージャがありますが、名前のないクロージャでも、不動点演算子を使えば再帰呼び出しは可能です。 # 不動点演算子(2引数関数用) function fp_op2(f) { return closure(p) { return p(p); }(closure(x) { return closure(g, h) { return f(x(x))(g, h); }; }); } # 使用例。コードは(ぱ)さんの本にあったクイックソートをそのまま使わせていただきました function quick_sort(data, less) { fp_op2(closure(quick_sort_sub) { return closure(left, right) { pivot = data[(left + right) / 2]; left_index = left; right_index = right; while (left_index <= right_index) { for (; less(data[left_index], pivot); left_index++) {} for (; less(pivot, data[right_index]); right_index--) {} if (left_index <= right_index) { temp = data[left_index]; data[left_index] = data[right_index]; data[right_index] = temp; left_index++; right_index--; } } if (left_index < right) { quick_sort_sub(left_index, right); } if (left < right_index) { quick_sort_sub(left, right_index); } }; })(0, data.size() - 1); return data; } print("" + quick_sort({ 5,6,3,2,1,9,8,0,7,5,3,2,4,3 }, closure(lhs, rhs) { return lhs < rhs; }) + "\n"); # => (0, 1, 2, 2, 3, 3, 3, 4, 5, 5, 6, 7, 8, 9) 名前付きクロージャを使った方が簡単でわかりやすいですが(ついでに効率もいいです)、こういうのもありますよ、ということで投稿しました。 ＃ 既にご存じでしたら申し訳ありません

> | IF LP expression RP block ELSE block > { > $$ = crb_create_if_statement($3, $5, NULL, $7); > } >の間違いではないでしょうか？ ご指摘ありがとうございます。その通りです。(また)まぬけなポカをしており 申し訳ありません。 なぜ気付かなかったんだろう… とtest.crbを見てみたのですが、 elsifを使っているパターンと、else側を通らないパターンでしか テストしてませんね… 論外。 さすがに今日は直せないので、この週末に対処させていただきます。 ご指摘ありがとうございました。

はじめまして．楽しく拝見させていただいております． 「プログラミング言語を作る」のcrowbar ver.0.3.01についてなのですが， crowbar.yのif statementの | IF LP expression RP block ELSE block { $$ = crb_create_if_statement($3, $5, NULL, $5); } は， | IF LP expression RP block ELSE block { $$ = crb_create_if_statement($3, $5, NULL, $7); } の間違いではないでしょうか？ 使っていて気付いたのですが・・・． 既にお気づきor指摘済みかもしれませんが念のため．

ご無沙汰しています。 メモリリークの問題等を解決して何とかプロトタイプが出来ました。 まだ、 1)先手=人プレーヤー 後手=コンピュータプレイヤー　オンリー 2)３手目以降人プレーヤーが打てない。 等の制限はありますが、コンピュータプレイヤーに打たせる事には成功しました。 コンピュータプレイヤーが打つ速度はJava版より速いです。 もっと改良を重ねて、最終的には本将棋ソフトを作成したいと考えています。 ソースを公開しますので、何かご意見があればお聞かせ下さい。 http://revolver.at.infoseek.co.jp/hasami-vc.lzh

アドバイスありがとうございます。 >そんなのはその証券会社にでも問い合わせるのが筋では? 証券の回答：ＳＵＮに問い合わせてください ＳＵＮでは米国に英語で問い合わせてください たらいまわし >いずれにせよこのエラーは、環境の不具合か、VMにバグがあるかしなければ >発生しないエラーです。ユーザ側で対処できることがあるとすれば、 >JRE(できれば少し古いの)を再インストールすることぐらいでしょう 結局：マイクロソフト　ＶＭビルドをインストールすることでＨＰアクセスできるようになりました。

>本屋でJAVA謎+落とし穴徹底解明を見つけました。 だから何? >あまりにも難しい内容ですが今困っていますので教えてください。 >WIN　XPSP2で証券会社のHPにアクセスすると下記ERRで強制終了します。 そんなのはその証券会社にでも問い合わせるのが筋では? あるいは、他のJavaアプレットのあるページ(うちのリバーシなど)も 動かなければ、そちらのブラウザの環境の問題ですし。 うちのリバーシのページ： http://kmaebashi.com/javaworld/reversi.html いずれにせよこのエラーは、環境の不具合か、VMにバグがあるかしなければ 発生しないエラーです。ユーザ側で対処できることがあるとすれば、 JRE(できれば少し古いの)を再インストールすることぐらいでしょう。 >またSUN JAVAコンソールをクイックしても同じERRになります。 クイック… http://www.google.co.jp/search?hl=ja&q=%E3%82%AF%E3%82%A4%E3%83%83%E3%82%AF%E3%81%99%E3%82%8B&btnG=Google+%E6%A4%9C%E7%B4%A2 なるほどねえ。

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

>CESさん自身が挙げられたこのページに、 >http://sumim.no-ip.com:8080/wiki/414 >| Smalltalk（アラン・ケイ）は“オブジェクトへのメッセージ送信”という >| メタファをしてその「オブジェクト指向」と、C++（ストラウストラップ）は >| 抽象データ型からの発展型（あるいはそれとは別のクラスのあり方）をして >| その「オブジェクト指向」と位置づけ、その進化の初期の過程で整備されました。 > >と書いてあるわけですが。読んでいませんか? ふむぅ…読み飛ばしていたような気がします。 やっぱり、C++ 流儀にどっぷりつかった視点では理解しにくいですから。 >また、既に書きましたが、(私が作っているcrowbarのような)タイプベースの言語では、 >そもそもクラスがないので、抽象データ型からは離れているように思います。 crowbar がどのような言語かはまだじっくりと見ていないのですが、クラスが無かろうとも、オブジェクト指向（モジュール指向）であれば、抽象データ型が無いということは無いと思います。 > http://kmaebashi.com/programmer/object/othello.html > ここは読みましたか? 書いてから全編に渡って何度か読み直しました。 結果、読めば読むほど >オブジェクト指向＝モジュール化＋マルチプルインスタンス なんだな、と感じるようになりました。 > 私の「再入門」は、そういう読者をターゲットとしているつもりです。 つまり、 > 「既にモジュール指向は知っている人のためのオブジェクト指向入門」 ということですね。 そういうスタンスだということであれば、私の反論はまったく的外れです。 ご気分を害されましたら、申し訳ございません。 > 「オブジェクト指向もモジュール指向も知らないが、 > マルチプルインスタンスは知っている」人というのは、具体的にどんな経歴(言語 > 経験)で、どんなプログラムを書く人なのでしょうか。 前にも申しましたように、 int i; int j; これで、モジュール指向ではありませんがマルチプルインスタンスです。 モジュール化を知る前の人だって、こういうことは素でやるでしょう。 >> マルチプルインスタンスで、何故再利用性が高まっているのでしょうか。 > strtok()みたいに、よそで使われてないか意識しないと使えないようでは、 > 再利用性が高いとは言えないと思うんですが? うん、確かにそうです。 …何なんでしょう。↑の１行を書くのに１時間悩みました。 たぶんあれです。 私はオブジェクト指向とモジュール指向を混同していたから。 マルチプルインスタンスではなく責務の分離こそオブジェクト指向だと思っていながら、データが１つしかない本当のモジュール指向を全然やってないから、マルチプルインスタンスのありがたみがわかってなかったんじゃないかな、と。 長きに渡お付き合いいただき、ありがとうございました。 ここで頂いたコメントをヒントにして、自分なりにもう少し煮詰めてみたいと思います。

>マルチプルインスタンスで、何故再利用性が高まっているのでしょうか。 >また、その再利用性は、ライブラリの再利用性とどう違うものなのでしょうか。 strtok()みたいに、よそで使われてないか意識しないと使えないようでは、 再利用性が高いとは言えないと思うんですが?

>オブジェクト指向＝モジュール化＋マルチプルインスタンス >ということでよろしいのでしょうか。 >ただ、そうしますと、再入門講座はどうしても不適切だと言わざるを得ません。 http://kmaebashi.com/programmer/object/othello.html ここは読みましたか? ここでは、まず「モジュール」としてboard.cを作り、その後それを複数生成 できるようにしています。 | 以前のboard.cというモジュールは、カプセル化は実現できていましたが、 | 静的にひとつしか存在しませんでした。それが、必要に応じていくつも生成できる | ようになったものがオブジェクトです。そして、このようにオブジェクトを | 必要な数だけ生成し、それに付属した関数を呼び出しながら動作していくという | プログラミングスタイルが、「オブジェクト指向」であるわけです。 つまり、私の説明では、 >オブジェクト指向＝モジュール化＋マルチプルインスタンス まさにこれが前提になっているのであり、なのになぜ不適切といわれるのかが わかりません。 >・マルチプルインスタンスはモジュール指向以前からあった >　→オブジェクト指向もモジュール指向も知らない人でも、これは知っている >・非オブジェクト指向、オブジェクト指向の知名度に比べて、モジュール指向の > 知名度が低い >　（私のように、オブジェクト指向とモジュール指向を混同している可能性が高く、 >　非オブジェクト指向→モジュール指向→オブジェクト指向　という経路ではなく、 >　非オブジェクト指向→オブジェクト指向　という経路を辿ると思っている） …ということは、 「モジュール」→「マルチプルインスタンス」 という説明の順序は逆で、 「マルチプルインスタンス」→「モジュール」 という順序のほうがよい、という主張でしょうか? そうなのかもしれませんが、ではその順序で説明したら、どんな感じの説明に なるのでしょうか。私にはちとイメージがつかめません。 また、上のページでこう書いたように、 | 既に書いたように、board.cはオブジェクト指向とは言えません。 | そして、多くのCプログラマには、「この設計でいったい何がいけないのか?」と | 思えるのではないかと思います。 そこそこ経験を積んだCプログラマなら、「モジュール化」はある程度意識して いるものです。また、オブジェクト指向の入門書を読めば、「カプセル化」の 話はたいてい書いてあります。 結果として、 http://kmaebashi.com/programmer/object/response3.html こちらで示したように、 284 ：デフォルトの名無しさん ：03/09/16 11:45 | データの局所性を高めたり隠蔽するってさ、 | 一データ群を取り扱う関数群を一つのソースにまとめて、データへのアクセスは | 専用のI/O関数を介してやり取りするのと違いはある？ | Cでもこういうのを徹底しとけばいいんでしょ？ こういう誤解をしてしまう可能性が非常に高いわけです。 # 284さんはその後うちの掲示板にも登場されました。 # やはりboard.cのようなものをイメージされていたようです。 私の「再入門」は、そういう読者をターゲットとしているつもりです。 CESさんのおっしゃるような「オブジェクト指向もモジュール指向も知らないが、 マルチプルインスタンスは知っている」人というのは、具体的にどんな経歴(言語 経験)で、どんなプログラムを書く人なのでしょうか。 少なくとも私には、具体的にイメージできません。

>>C++などの流儀のOOは、そう言われることが多いようですね。 > >C++ ファミリーじゃない言語をよく知らないので、よろしければ、 >他の流儀では何がオブジェクト指向だと呼ばれているのか、ご教示願えませんか。 CESさん自身が挙げられたこのページに、 http://sumim.no-ip.com:8080/wiki/414 | Smalltalk（アラン・ケイ）は“オブジェクトへのメッセージ送信”という | メタファをしてその「オブジェクト指向」と、C++（ストラウストラップ）は | 抽象データ型からの発展型（あるいはそれとは別のクラスのあり方）をして | その「オブジェクト指向」と位置づけ、その進化の初期の過程で整備されました。 と書いてあるわけですが。読んでいませんか? また、既に書きましたが、(私が作っているcrowbarのような)タイプベースの言語では、 そもそもクラスがないので、抽象データ型からは離れているように思います。 >「型」がある→「マルチプルインスタンスが前提」という繋がりがよくわかりません。 >「鋳型」「ケーキ型」などは、同じ形のものを量産するためにありますが… >そもそも「型」の語源は「type」ですし、「クラス」という用語もそうですが、 >「分類」というような意味があるんじゃないでしょうか。 実は拙著「Java謎+落とし穴～」ではタイヤキの型を使ってクラスとインスタンスの 説明をしていますが、タイヤキ型がtypeでないことはわかってて注でツッコミ入れたり してます。それはさておき。 typeだから分類だ、という解釈をしたところで、分類というのは、通常ひとつの カテゴリに複数のナニモノカが入るでしょう。 ただ、イメージとしては、プログラミング言語における「型」は、 結構タイヤキの型の方に近いような気もします。インスタンス生成なんて 型にタネとアンコ(メモリ)を詰めてタイヤキ作るイメージそっくり。

>で、リンク先の内容を読み返してみました。 >僕はこの説明で、初心者向けとしても十分足りているように思えるのですが、いかがでしょうか。 うーん…何に足りているのでしょうか？ マルチプルインスタンスの利点はわかりやすく解説されていますが、モジュール指向の説明は相変わらず見当たりませんし、例の「こちら」のリンク元である > ただ、私は、オブジェクト指向によりプログラムの再利用性は高まると思っています。オブジェクト指向の「マルチプルインスタンス」という特性が、「状態」を持つ部品を、プログラムのあちこちで使いまわすことを可能にしているからです。この点についてはこちらで後述します。 という文との関連がわかりません。 マルチプルインスタンスで、何故再利用性が高まっているのでしょうか。 また、その再利用性は、ライブラリの再利用性とどう違うものなのでしょうか。

>の「こちら」については、前橋さんが 2005/07/19 02:12:13 の投稿で > >>おそらくこのリンク先は、 >>http://kmaebashi.com/programmer/object/shigoto.html >>ここのStringTokenizerあたりの説明のことを指しているのだと思います。 >># 既に忘却の彼方です。すみません。 > >とおっしゃられております。 あ、ほんとだ。失礼しました。。 で、リンク先の内容を読み返してみました。 僕はこの説明で、初心者向けとしても十分足りているように思えるのですが、いかがでしょうか。

考えを整理してみると、今、世の中にあふれている「オブジェクト指向」の説明は、その多くが誤解を孕んでいるような気がしてきます。 それはさておき。 >たぶん、例の > >http://kmaebashi.com/programmer/object/naze.html > >の、「この点についてはこちらで後述します。」の箇所で、その説明をされるおつもりだったのではないでしょうか。（予想ですけど） の「こちら」については、前橋さんが 2005/07/19 02:12:13 の投稿で >おそらくこのリンク先は、 >http://kmaebashi.com/programmer/object/shigoto.html >ここのStringTokenizerあたりの説明のことを指しているのだと思います。 ># 既に忘却の彼方です。すみません。 とおっしゃられております。

>しかし、ということはやはり、 > >オブジェクト指向＝モジュール化＋マルチプルインスタンス > >ということでよろしいのでしょうか。 僕は概ね、そう思っています。 でも、前橋さんのご意見がどうであるかは、わからないです。 >ただ、そうしますと、再入門講座はどうしても不適切だと言わざるを得ません。 たぶん、例の http://kmaebashi.com/programmer/object/naze.html の、「この点についてはこちらで後述します。」の箇所で、その説明をされるおつもりだったのではないでしょうか。（予想ですけど）

>あ、すみません。 > [512]を読まずに投稿してしまいました。。（汗） > >失礼しました。 > CESさん いえいえ、お気になさらずに。 しかし、ということはやはり、 オブジェクト指向＝モジュール化＋マルチプルインスタンス ということでよろしいのでしょうか。 ただ、そうしますと、再入門講座はどうしても不適切だと言わざるを得ません。 というのは ・マルチプルインスタンスはモジュール指向以前からあった 　→オブジェクト指向もモジュール指向も知らない人でも、これは知っている ・非オブジェクト指向、オブジェクト指向の知名度に比べて、モジュール指向の知名度が低い 　（私のように、オブジェクト指向とモジュール指向を混同している可能性が高く、 　非オブジェクト指向→モジュール指向→オブジェクト指向　という経路ではなく、 　非オブジェクト指向→オブジェクト指向　という経路を辿ると思っている） ためであり、「オブジェクト指向の最低要件はマルチプルインスタンス」という文面からは、「モジュール指向からオブジェクト指向へ至るまでの差分として最低限必要なものはマルチプルインスタンス」という意味が読み取りにくいためです。 注釈として > 「それは抽象データ型だ」という意見もあるかもしれませんが、抽象データ型はオブジェクト指向に至るためには必須の概念です。 という記述はありますが、そもそも犬がどうのというたとえ話がわかっていない人が、抽象データ型云々と言われてわかるとも思えません。

あ、すみません。 [512]を読まずに投稿してしまいました。。（汗） 失礼しました。 > CESさん

前橋さんが紹介してくださった、まつもとひろゆきさんの日記の「アイデンティティ」という言葉を眺めていて、自分の中で少し整理ができてきました。 >int main() >{ >　int i = 0, j = 0; >　return 0; >} > >これはオブジェクト指向か？　ってことになるです（それ以前に全く意味のないプログラムであることに突っ込んじゃダメ）。 >int 型のマルチプルインスタンスを実現しているし、i と j は識別可能です。 >マルチプルインスタンス「だけ」では、オブジェクト指向とは思えないのですが… >静的だろうが動的だろうが「データ」があって、そのデータの「責務」が明確になっているとき、それはオブジェクト指向、ではないのかな。 おそらく、重要なのは (1) データ構造や振る舞いを、特定の名前に紐付けて定義できる (2) 定義したオブジェクトを、複数生成できる (3) 生成されたインスタンスは、それぞれが個別の状態を持つ (4) それぞれのインスタンスの違いが、識別可能である ということだと思うんです。 いわゆる手続き型言語でも、(1)はそれほど難しい話ではないでしょう。 そしてそれが、CESさんのおっしゃる「責務の明確化」なんだと思います。最初に774RRさんがおっしゃっていた、「自分にできることを自分自身が知っている」というのも(1)でしょう。 でもその責務を持った単位が、 ・ 複数生成できて、それぞれが状態を持ち、かつそれぞれが識別可能（つまり、(2)と(3)と(4)） ということでなければ、それは、「オブジェクト」とは言えないのではないでしょうか。 で、いわゆる手続き型言語では、それらを実装するのが容易ではない、ということなんだと思います。

なんか、えーと。 「それってオブジェクト指向じゃなくてモジュール指向じゃん」ということへの反論にまったくなっていない。 だって私自身「じゃあモジュール指向って呼んでもいいよこの際」って納得してしまっているから。 モジュール指向とオブジェクト指向の違いって何だろう？　マルチプルインスタンスがそれ？ あー、そうか。そういうことか。 > 私は、オブジェクト指向の「本質」と呼ぶべきものは、カプセル化でも継承でもポリモルフィズムでもなく、「マルチプルインスタンス」にあると思っています > 「それは抽象データ型だ」という意見もあるかもしれませんが、抽象データ型はオブジェクト指向に至るためには必須の概念です。 （オブジェクト指向再入門／はじめに　より） マルチプルインスタンスばかり強調されるので、マルチプルインスタンスさえあればモジュール化が無くてもオブジェクト指向かと誤解してしまった。 抽象データ型＋マルチプルインスタンス＝オブジェクト指向？ 「オブジェクト指向の最低要件はマルチプルインスタンス」というのは、「モジュール化はすでにある前提として、オブジェクト指向に至るための差分として何が必要かという最低要件」ということなのだろうか。 しかし、マルチプルインスタンス「だけ」ならば、モジュール指向の前からあったものだし、オブジェクト指向がモジュール指向から派生しているならば、やはりモジュール指向も知っておかねばならんのだろうなぁ。 「オブジェクト指向再入門」が「既にモジュール指向は知っている人のためのオブジェクト指向入門」ならば「マルチプルインスタンス」を説明すればいいわけだが、しかしそうとも思えないしなぁ…

> 最低限の条件は「アイデンティティがある」ことである。アイデンティティとはある「オブジェクト」と別の「オブジェクト」が、同じかそうでないか判定できる、という意味だ。 っていうと、じゃあ int main() { 　int i = 0, j = 0; 　return 0; } これはオブジェクト指向か？　ってことになるです（それ以前に全く意味のないプログラムであることに突っ込んじゃダメ）。 int 型のマルチプルインスタンスを実現しているし、i と j は識別可能です。 マルチプルインスタンス「だけ」では、オブジェクト指向とは思えないのですが… 静的だろうが動的だろうが「データ」があって、そのデータの「責務」が明確になっているとき、それはオブジェクト指向、ではないのかな。 >C++などの流儀のOOは、そう言われることが多いようですね。 C++ ファミリーじゃない言語をよく知らないので、よろしければ、他の流儀では何がオブジェクト指向だと呼ばれているのか、ご教示願えませんか。 ＃ただ、私が「オブジェクト指向」という時、それは暗黙のうちに「C++ ファミリーのオブジェクト指向」を指していますが（だって他の知らないもん）。 >>「型」という概念がない言語もあるだろうから、「抽象データ」かな。 > >型の概念のない言語はそうそうないでしょう。RubyやらSmalltalkやらは >静的な型付けがないだけで、型は立派にあります。 そうでしたか。浅学を晒してしまいました。 >>マルチプルインスタンスは…申し訳ないが、抽象データとはちょっと関係なさそう？ > >そして、「型」がある以上、それを複数生成するのは前提でしょうから、 >マルチプルインスタンスは、少なくともクラスベースのOOでは、外せない本質だと >私は考えているわけです。 「型」がある→「マルチプルインスタンスが前提」という繋がりがよくわかりません。 「鋳型」「ケーキ型」などは、同じ形のものを量産するためにありますが… そもそも「型」の語源は「type」ですし、「クラス」という用語もそうですが、「分類」というような意味があるんじゃないでしょうか。 まず型ありき、ではなくて。 最初は混沌として分類されていなかった「オブジェクト」があり、それを分類するために後から「型」が生まれた…のか？ オブジェクトを分類することによって、似た性質を持つものをひとまとめに扱うことも「抽象化」です。 使う側はその似ている「性質」だけを知ってればいいんであって、似ているけれど「微妙に違う」部分は知らなくてもいいわけですからね。 そうすると「型は責務の分離のためにある」と言えなくもないような。 うーん違う。「型」じゃ意味が広すぎる（int 型にどんな責務があるって言うんだ…）。 「型」は純粋にオブジェクトの分類のためだけにあり、分類に責務を関連付けたのが「オブジェクト指向」か？ これも違う。 オブジェクト指向以前から「型」はあったけれど、オブジェクト指向の「型」は「インターフェイスセット」のことかと。 そのオブジェクトに何ができるのか、でそのオブジェクトを表現したもの。 また、オブジェクトをそのように表現することが「オブジェクト指向」。

>> プログラマに飛躍を感じさせる力を与えるための道具、という見方です。 > >すいません。ちょっとよくわかりませんでした。 すみません。。 ちょっとアルコールが入っているので、意味不明な事を書いてしまいました。 「自分が思っていることを、容易に表現することができる表現力」、それを実現するための道具 みたいな感じのことを言いたかったんです。 # 上記でも意味不明ですね。。

>オブジェクト指向のキモは「抽象データ型」？ C++などの流儀のOOは、そう言われることが多いようですね。 >「型」という概念がない言語もあるだろうから、「抽象データ」かな。 型の概念のない言語はそうそうないでしょう。RubyやらSmalltalkやらは 静的な型付けがないだけで、型は立派にあります。 >マルチプルインスタンスは…申し訳ないが、抽象データとはちょっと関係なさそう？ そして、「型」がある以上、それを複数生成するのは前提でしょうから、 マルチプルインスタンスは、少なくともクラスベースのOOでは、外せない本質だと 私は考えているわけです。 [489]で自分で突っ込んでるように、じゃあプロトタイプベースではどうなるんだ、 という話はありますけどね。

>・ オブジェクトは複数生成できる。 >・ 生成されたオブジェクトは、ユニークである まつもとゆきひろさんがこのように書いていますが、 http://www.rubyist.net/~matz/?date=20030807 | そして、その最低限の条件は「アイデンティティがある」ことである。 | アイデンティティとはある「オブジェクト」と別の「オブジェクト」が、 | 同じかそうでないか判定できる、という意味だ。 これは、keiさんの挙げられたふたつめの条件に合致するでしょうね。

>組み込み系の仕事をしていると「＊＊＊が１つ、△△△が１つ」なんてのは >よくあるのです。 >顧客要望的にも、コスト的にも、２つになることは決してありえない、って状況。 そういう場合は、全メンバがstaticであるクラスを作るなり、 C流にstaticな変数や関数で.cファイルに閉じ込めたりするコードを書くのが 正解だと思います。 でも、それが「オブジェクト指向」かと言うと、それは違うのでは、と私は 思います。 keiさんが別途書いておられるように、それは「モジュール化」では。 モジュール化を意識した言語であるModula2が、オブジェクト指向言語と 呼ばれることはないと思います。 >のように、全メンバが static なクラスってのを使います。 ところで、C++のstaticなメンバってのは、私は機能的に重複したものだと 思っています。staticフィールドはグローバル変数で書けるし、 名前空間の汚染はnamespaceで防げるし、ファイル内でstaticにすれば カプセル化もできるし。staticメソッドは関数で書けるし、 friendがあるから選択的エキスポーともある程度可能だし。 まあ、重複した機能が山ほどあるのはC++ではいつものことですけど。

>マルチプルインスタンス＝オブジェクト指向と言い >切ってしまうと、それはちと問題かなと思います。 誰もそんなことは言っていないのでは? >Javaの仕様でネイティブ >バイナリを吐くコンパイラがほしいです。 >あったらすごい売れそう。 いろいろあるようですが、このへんなんかがメジャーじゃないですかね。 http://www.xlsoft.com/jp/products/jet/index.html ところで、ネイティブコンパイラを使っても、必ずしも性能が上がるとは 限りません。だいたい今時のJVMは結局JITでネイティブコードに変換していますし、 私もいくつかベンチマークもしてみましたが、数値計算とかで、CとJavaで 性能に差が出ることはそうそうありません。現状では、JITはメモリ食いなので、 実際のアプリケーションではそのへんで差が出るのでしょうけど。 上記のJETのページにもありますが、ネイティブコードに落とす重要な理由のひとつは 「Run anywhereを実現するため」なんですね。皮肉なものです。 JREが入ったマシンは少ないが、Windowsならどこにでもあるので。

>逆に言えば、動的結合や多態は、いわゆる「手続き型」言語では、容易には実装できない、と言いたかったのでした。 >極論するならば、全ての言語も対等で、どの言語でも、他の言語で実装可能な機能は、どんな内容でも実装可能なはずです。 > >でも、それが容易であるか容易でないかの違いは、かなり大きいと思います。 まず私は、オブジェクト指向言語を否定しているわけではありません。 ただ、「オブジェクト指向って何だ？」っていうことを考えると、継承も多態性もサポートのひとつでしかなくて、本質ではないと思ったわけです。 本質でなければ要らないということは全く無くて、それらのサポートや、言語にそれらの機能があることによって、より強固なオブジェクトが楽に作れるのは素晴らしいことだと思います。 > プログラマに飛躍を感じさせる力を与えるための道具、という見方です。 すいません。ちょっとよくわかりませんでした。 > それは「モジュール指向」とでも呼ぶべきものであって、オブジェクト指向とは言えないんじゃないかなぁ、と。 「オブジェクト」もそうですけど、「モジュール」ってのも広義な言葉ですよね。 ただ、「モジュール指向」も案外外した言葉ではないような。むしろ「オブジェクト指向」よりわかりやすくないか、それ？ 「モジュール」って、たぶん「それ自体が独立していて、他のものとの依存性が低く、組み換えが可能である部品」みたいな意味ですよね。

>>個人的な考えとしては、動的結合も多態性も、責務の分離をはっきりさせるための手段でしかないと思います。 全くそうだと思うんですが、でもそれも、ひとつの側面に過ぎないのかな、とも思います。 僕個人は、動的結合や多態は、「プログラマが魔法を実現する」ための手段だと思っています。つまり、プログラマに飛躍を感じさせる力を与えるための道具、という見方です。 >つまり、動的結合や多態性がない「オブジェクト指向」があってもいいのではないか、ということです。 で、そういった動的な要素がなければ（つまり、責務の分離だけであれば）、それは「モジュール指向」とでも呼ぶべきものであって、オブジェクト指向とは言えないんじゃないかなぁ、と。 # 僕の見方はかなり偏り過ぎな気もしますが。。

>>そして、それらの側面が無いと、いわゆる「手続き型」と、何も変わりが無いのでは、と思います。つまり、データと手続きをセットにするということ自体は、「手続き型」言語でも容易に可能なわけですから。 > >「手続き型言語」と「手続き型プログラミング」、 >「オブジェクト指向言語」と「オブジェクト指向プログラミング」は分けて考えるべきだと思います。 もちろん、それはそうだと思います。 なので、 >>「手続き型」言語でも容易に可能 と、「容易に」と書いた訳です。 逆に言えば、動的結合や多態は、いわゆる「手続き型」言語では、容易には実装できない、と言いたかったのでした。 極論するならば、全ての言語も対等で、どの言語でも、他の言語で実装可能な機能は、どんな内容でも実装可能なはずです。 でも、それが容易であるか容易でないかの違いは、かなり大きいと思います。

＃追記 >>という側面が無いと、動的結合や多態は、説明できないのではないのかぁ、と思いました。 > >個人的な考えとしては、動的結合も多態性も、責務の分離をはっきりさせるための手段でしかないと思います。 つまり、動的結合や多態性がない「オブジェクト指向」があってもいいのではないか、ということです。

>という側面が無いと、動的結合や多態は、説明できないのではないのかぁ、と思いました。 個人的な考えとしては、動的結合も多態性も、責務の分離をはっきりさせるための手段でしかないと思います。 以前は何でもかんでもバグを減らすための手段と捉えて失敗しましたが、「責務の分離」を目的に置いてみることにしました。 >そして、それらの側面が無いと、いわゆる「手続き型」と、何も変わりが無いのでは、と思います。つまり、データと手続きをセットにするということ自体は、「手続き型」言語でも容易に可能なわけですから。 「手続き型言語」と「手続き型プログラミング」、 「オブジェクト指向言語」と「オブジェクト指向プログラミング」は分けて考えるべきだと思います。 Java 使ってもオブジェクト指向っぽくないプログラムは作れるし、C 言語でもオブジェクト指向プログラミングはできます。 あと、C に端を発する C++ とか Java とかの言語は、「手続き型オブジェクト指向言語」だと思います。 「手続き型言語」の対義語は「関数型言語」らしいので。

# すみません、また発散させてしまいます。。 >「自分にできることを自分自身が知っている」のがＯＯだと思っていますが、違うのでしょうか？ そっかー。 ・ （データや手続きの）所属がはっきりしている というのは、オブジェクト指向の根幹な気がしてきました。目から鱗です。 でも、それからさらに少し考えてみたんですが、 ・ オブジェクトは複数生成できる。 ・ 生成されたオブジェクトは、ユニークである という側面が無いと、動的結合や多態は、説明できないのではないのかぁ、と思いました。 そして、それらの側面が無いと、いわゆる「手続き型」と、何も変わりが無いのでは、と思います。つまり、データと手続きをセットにするということ自体は、「手続き型」言語でも容易に可能なわけですから。

オブジェクト指向では「責務の分離」が大切。 平たく言えば、オブジェクトを使う上で、知っていなければならないこと、知らなくてもいいこと、知っていてはならないことがきちんと分かれていること。 > 「自分にできることを自分自身が知っている」のがＯＯ 自分自身は「何ができるか」と「どうやるか」を知っているけれど、他人には前者だけ教えておけばいい。 うーん…これを一言で言ったものが「抽象化」ということなんだろうか。 オブジェクト指向のキモは「抽象データ型」？ 「型」という概念がない言語もあるだろうから、「抽象データ」かな。 してみるに、カプセル化も継承も多態性も実装隠蔽もメッセージパッシングも、すべてはこれをサポートするためのものでしかないことがわかる。 マルチプルインスタンスは…申し訳ないが、抽象データとはちょっと関係なさそう？ うん、何だか、散々語り尽くされたところに落ち着いてしまった感がある。 現時点でのマイ定義： 「オブジェクト指向とは、データの抽象化によってバグを減らすための技術である」。 私の失敗は、いろんなものを同一視しすぎたこと。 例えば ・類似のコードをサブルーチンに分けるのは、コード修正の際に書き換える箇所を少なくすることによってバグを減らす技術。 ・データの抽象化は、オブジェクトを「使う側」のコードを再利用することによって、修正の必要性を軽減する技術。 ・ほら、この２つは結局同じ（コードを書き換える量を減らすのを目的とした）ことだ。 ここまで一般化してしまったから、わけがわからなくなってしまった。 サブルーチンの切り出しは、責務の分離とまったく関係が無い。だからこれを同一視してはいけなかった。 ＃我ながら、実に「何を今更」だな。 ＃ツッコミお待ちしています。

>発散していてどこにつけていいかわからないので新規投稿。 ここにまとめレス。 > たとえば、以下のページでは、 > http://www.shiro.dreamhost.com/scheme/trans/reesoo-j.html > オブジェクト指向言語の要件を箇条書きにしたうえで、 極論、この一覧の要件をひとつでも満たせば、あるいは、ここに無いけれど何か妥当っぽい特徴を持っていれば、そして、その言語がオブジェクト指向であると主張すれば、それはオブジェクト指向になってしまうのかもしれない。 この一覧には > 全てはオブジェクトなり - 全ての値はオブジェクト。Smalltalkでは真だが、 Javaでは (int等のため) 真ではない。 とある。「オブジェクト」の定義にもブレがあるだろうが、これに従って解釈すると、 > int i; > int j; > これでマルチプルインスタンス、ってのはヒネクレ過ぎ？ これを Java のコードとして見るならば、i や j はインスタンスではあるがオブジェクトではないのだろう（i や j をオブジェクトと呼ぶときの「オブジェクト」と、「オブジェクト指向」の定義を語るときの「オブジェクト」は意味が違うのは明らかだしね）。 > カプセル化のない(今はあるんでしたっけ?)のPythonとか、 > メソッドとオブジェクトを実行時にくっつけるPerlとか、 > メソッドとオブジェクトが直接関連していないCLOSとか… うーん…それらの言語については、というか、C++ / C# / Java あたりの C ファミリーしか私は知らないんですが。 ただ、前に述べたとおり、Win32 API のメッセージアーキテクチャはオブジェクト指向なので、「メソッドとデータの結合」は必須要件ではないんだろう。 > Simulaは、むしろC++に近い言語だという認識です。 コードを見た感じ、そうみたいですね。 どうも私は（偏見というか思いっきり間違いなのですが）Simula と Smalltalk を同一視してしまう。 Smalltalk はオブジェクト指向云々以前に関数型言語なので、C++ や Java とは同列で比較しにくいものがあるけれど。 > 全メンバが static なクラスってのを使います。 > 拡張性０ですがこれも立派なクラスだと思っております。 > 「自分にできることを自分自身が知っている」のがＯＯ 確かに。 でも、（static メンバでもいいから）何らかのデータを持っていないと、それはクラスだけどオブジェクト指向とは言い難いような気がします。 「自分」ってのは「データ」のことだと思うから。

発散していてどこにつけていいかわからないので新規投稿。 マルチプルインスタンスでないオブジェクト指向というか C++ ソースを結構書いている 身としては、マルチプルインスタンスが必須といわれてしまうとちょと悲しいかも。 組み込み系の仕事をしていると「＊＊＊が１つ、△△△が１つ」なんてのはよくあるのです。 顧客要望的にも、コスト的にも、２つになることは決してありえない、って状況。 そーいう場合に＊＊＊の制御を行うクラスとして class ***_t { static int Flags; static void CheckABC(); public: static bool IsXYZ(); }; のように、全メンバが static なクラスってのを使います。 拡張性０ですがこれも立派なクラスだと思っております。 「自分にできることを自分自身が知っている」のがＯＯだと思っていますが、違うのでしょうか？ たまたまその結果として複数インスタンスの利用が簡単になっているのだと考えますが。

「インスタンス」という意味であれば構造体であれ クラスであれmallocしたメモリであれインスタンス には違いないわけです。 マルチプルインスタンス＝オブジェクト指向と言い 切ってしまうと、それはちと問題かなと思います。 まあ実際言葉の定義（オブジェクト指向とは何ぞや） なんかはどうでもよくて、作りやすくてバグが減る のなら何でもいいと個人的には考えています。 そういう「なんでもいいじゃん」的な考え方でいく と、C++の汚い文法よりはJavaなんかのほうが洗練 されていて好みですね。Javaの仕様でネイティブ バイナリを吐くコンパイラがほしいです。 あったらすごい売れそう。

>（あっちから覗かれてないことを祈りつつビクビク書きこむけれど） >Simula っぽくないとオブジェクト指向とは認められない、とか言わないよね… 詳しいわけではないですが、Simulaは、むしろC++に近い言語だという認識です。 http://www.cee.hw.ac.uk/~rjp/bookhtml/chap09.html Example 9.4のあたりを見ると、メソッドは「procedure」として宣言されてますし。

ええと、chatモード? >ところで、C で > >int i; > >と書いたとき、これは（int クラスではないけれど）int 型のインスタンスと >呼べはしまいか。 >int 型のオブジェクトと呼んでも、間違いとは言えまい。 ていうかK&Rでは、これのことをオブジェクトと呼んでますね。 >オブジェクト指向っていうと「データと関数をくっつけたものがオブジェクトです」と >いう説明がなされることが多いが、いわゆるカプセル化というのは必須要件では >ないのだろうか。 カプセル化のない(今はあるんでしたっけ?)のPythonとか、 メソッドとオブジェクトを実行時にくっつけるPerlとか、 メソッドとオブジェクトが直接関連していないCLOSとか…

>| つまり、「オブジェクト指向」というのはちゃんと定義された概念ではない。 ふむ、結局そんなもんなんですか。 >でも、最低限、オブジェクト指向の必要条件(十分条件でないことは承知の上で)を >言うのであれば、「マルチプルインスタンス」は結構外せない線と言えると思います。 >インスタンスとはすなわちオブジェクトであり、オブジェクトがなければ、 >さすがにオブジェクト指向とは呼べないでしょうから。 ところで、C で int i; と書いたとき、これは（int クラスではないけれど）int 型のインスタンスと呼べはしまいか。 int 型のオブジェクトと呼んでも、間違いとは言えまい。 んで int j; これでマルチプルインスタンス、ってのはヒネクレ過ぎ？ オブジェクト指向っていうと「データと関数をくっつけたものがオブジェクトです」という説明がなされることが多いが、いわゆるカプセル化というのは必須要件ではないのだろうか。

>で、私の考えるオブジェクト指向とは、 > >「クラス（部品）を作り、組み合わせてアプリケーションを作る」 これだけだと、「ライブラリ」あるいは「モジュール」と、「クラス」との 区別が曖昧になってしまうのではないでしょうか。 Nさんが、 http://kmaebashi.com/programmer/object/othello.html こちらのページにある、static指定でカプセル化を図ったC版board.cを オブジェクト指向とみなすのであれば別ですが、 静的にひとつしかないboard.cモジュールは非OOで、 create_board()関数により複数のBoardを作ることができる版はOO的である、 ということに同意されるのであれば、マルチプルインスタンスが(すくなくとも クラスベースのOOにとって)必要条件であるということにも同意されるはずだと 思うのですが。 というわけで、 >なので「マルチプルインスタンス＝オブジェクト指向」 >という説にはあえて反対しておきたいと思います。 >そんな大げさなもんではないと私は考えています。 こちらもよくわかりません。しかも、上記のご意見は、その前段に >関数ポインタ（複数）とそれを操作するデータ（構造体） >をパッケージングすることで実現するというのは、 >C++への移行期であった当時は「なるほど」と思った >ものです。 とあります。私の認識では、これは立派なマルチプルインスタンスです。 http://kmaebashi.com/programmer/object/intro.html ここで、C++ FAQから引用し、 | もしCでマルチプルインスタンスが必要なら、プログラマは構造体を使いますが、 | こっちはカプセル化をサポートしません。 と書いているように。

管理人である私のいないところで会話が進んでいくのが、この手の掲示板の あるべき姿だと思ってます。皆様書き込みありがとうございます。 >じゃあ「オブジェクト指向」という言葉の定義は何かというと、詰まってしまって… 用語定義に拘泥するのはあまり意味があるとは思えないんですが、 無意味なことにこだわるのも人間だってことで。 たとえば、以下のページでは、 http://www.shiro.dreamhost.com/scheme/trans/reesoo-j.html オブジェクト指向言語の要件を箇条書きにしたうえで、 | つまり、「オブジェクト指向」というのはちゃんと定義された概念ではない。 | ある人々 (AbelsonとSussman?) はLispはオブジェクト指向だと言うが、それは | {3,4,5,7} に基づく (但し、全ての型はプログラマの頭の中に存在するとする)。 | Javaは {1,2,3,7,8,9} があるからオブジェクト指向だ。 Eは {1,2,3,4,5,7,9} と | 6のほとんどをもつから、もっとオブジェクト指向だと言えるかもしれない。 (中略) | オブジェクト指向というものが動く標的であるため、オブジェクト指向の熱心な | 支持者はこのメニューのうちの適当なサブセットを気まぐれに選んで、 | それを以って他の言語はオブジェクト指向ではないと説得しようとする。 と述べています。実際、その通りだと私も思います。 でも、最低限、オブジェクト指向の必要条件(十分条件でないことは承知の上で)を 言うのであれば、「マルチプルインスタンス」は結構外せない線と言えると思います。 インスタンスとはすなわちオブジェクトであり、オブジェクトがなければ、 さすがにオブジェクト指向とは呼べないでしょうから。 ただ、マルチプルインスタンスという定義自体、クラスベースのOOに特化してないか、 と言われるとそれはそうかもしれず。プロトタイプベースの場合、(ある特定の クラスの)インスタンスが複数生成される、というわけではないですから。 # プロトタイプベースの言語でも、結局クラスっぽいものを作ることが # 多いとは思いますけどね。

>ただ、これは個人的な感性の問題かもしれませんが、僕個人は、抽象化によって得られるメリットは、 > >「バグが減るから嬉しい」 > >よりも、 > >「表現力が高まるから嬉しい」 > >って側面の方が強いように思えます。 > ># 個人の主観の問題に還元しちゃうのは、ちょっとおもしろくないですけど。。 まだ個々人の主観を越える同意が得られる段階ではないんでしょうか？ 決して新しいものではないと思うんですけどね。 >>くだんの再入門にかぎらず、世の多くの「オブジェクト指向入門」が入門の先に見据えているものは、 >>実は、オブジェクト指向なんかじゃなく（実際、ほとんどその説明のために行を割いておらず） >>オブジェクトのメリットを論じたり、オブジェクトを使った効率的なプログラミングをするためのもの >>に過ぎないんじゃないかなぁ…という問題も、もちろんあります。 > >えーっ。 >それじゃ駄目なの？？？ > >って思ってしまいました。 「オブジェクトを使って効率的にプログラミングすること」って「オブジェクト指向」じゃないのかな？ それとも、あくまで「オブジェクト指向とは何か？」っていう説明をせよということなのかしら。 ＃私は知りたいけれど、入門者には必要か？　と思う （あっちから覗かれてないことを祈りつつビクビク書きこむけれど）Simula っぽくないとオブジェクト指向とは認められない、とか言わないよね…

>という話になると、結局、「バグが減るから嬉しい」に帰結するんじゃないでしょうか。 それもありだと思います。 ただ、これは個人的な感性の問題かもしれませんが、僕個人は、抽象化によって得られるメリットは、 「バグが減るから嬉しい」 よりも、 「表現力が高まるから嬉しい」 って側面の方が強いように思えます。 # 個人の主観の問題に還元しちゃうのは、ちょっとおもしろくないですけど。。 >余談になりますが、このサイトの「オブジェクト指向再入門」に言及されているページを見つけました。 >http://sumim.no-ip.com:8080/wiki/755 ↑このリンク先から引用 >くだんの再入門にかぎらず、世の多くの「オブジェクト指向入門」が入門の先に見据えているものは、 >実は、オブジェクト指向なんかじゃなく（実際、ほとんどその説明のために行を割いておらず） >オブジェクトのメリットを論じたり、オブジェクトを使った効率的なプログラミングをするためのもの >に過ぎないんじゃないかなぁ…という問題も、もちろんあります。 えーっ。 それじゃ駄目なの？？？ って思ってしまいました。

突っ込まれると思うので一応言い訳しておくと、 Cでも擬似マルチプルインスタンス的な作り方は 可能です。 とある人の書いたソースでは、typedefした構造体 に関数ポインタを持たせ、同じ機能で複数の状態 を持った「オブジェクト（インスタンス）もどき」 を使って機能を実現していました（某パズルですが）。 関数ポインタ（複数）とそれを操作するデータ（構造体） をパッケージングすることで実現するというのは、 C++への移行期であった当時は「なるほど」と思った ものです。 なので「マルチプルインスタンス＝オブジェクト指向」 という説にはあえて反対しておきたいと思います。 そんな大げさなもんではないと私は考えています。 強いて言うなら「設計概念の１つです」とでも言えば 十分じゃないでしょうか。

はじめまして。面白く読ませていただきました。 思うに、Cなどでは構造化設計に始まり、原始的な オブジェクト指向的設計まである程度踏み込んで いたのではないかと思います。この点は同じ論を 唱えていらっしゃると思います。 ただ、手続き型言語では「オブジェクト指向設計」 とは「呼んでいなかった」だけではないかな、と 個人的には思っています。 Cで言うと、 ・データを持つオブジェクトが操作方法を知っている 　＞より緻密なソースファイル分割 　＞関数名のルール付け 　＞データ操作関数のファイル内限定 ・インターフェースの限定による（使用者から見た）隠蔽 　＞static関数、ファイル内static変数（privateメンバに相当） ・ポリモーフィズム、継承、同じ動作は同じ名前に 　＞これはクラス型言語にしかできない機能ですね これらを、言語仕様面からより便利に使えるように したのがC++なりJavaなりであって、オブジェクト指向 のような概念的なことは（意識するしないをおいて） 近代の開発では行っていたと思います。 で、私の考えるオブジェクト指向とは、 「クラス（部品）を作り、組み合わせてアプリケーションを作る」 ことであると考えています。七面倒くさい用語はそれを 表現するための方便に過ぎないと。 このような（オブジェクト指向的）作り方をすると、手続き 型言語で感じていた以上に、ライブラリ的立場の部品と本来 のアプリケーション的立場の部品をいやでも意識させられる ことになります。 従来であれば、「じゃあこの機能とこの機能は整理して別に ライブラリ化しよう」ということになるのでしょう。それは クラス型言語でも可能だと思いますが、クラス型言語なら、 ライブラリ化という結構エネルギーを使う作業をしなくても クラス単位で再利用という手軽な使い方ができるのは１つの メリットかと思います。 長くなりましたのでこのへんで。

だんだんこちらのサイトのコンテンツの内容と関係なくなってきましたので、タイトル変えました。 >横槍、失礼します。 横槍大歓迎です。 >でも、オブジェクト指向って、再利用だけが利点でしょうか？ >オブジェクト指向に限らず、「抽象化すること」によって得られる利点を、適当につらつらと考えてみましたが、 > >・ 設計の向上（データ構造、モジュール間の関連等） >・ 可読性の向上 >・ 保守性の向上 >・ 意思疎通の向上 > >等々、ちょっと考えただけでも色々出てきそうです。 うん、なるほど。 確かに抽象化と再利用を直結させるのは短絡的ですね。 が、もう一歩突っ込んで、 ・何のために設計をはっきりさせるん？ ・可読性や保守性が向上するとどんなメリットがあるん？ ・意思疎通が円滑になるとどのように嬉しいん？ という話になると、結局、「バグが減るから嬉しい」に帰結するんじゃないでしょうか。 ＃とか言ってるとそのうち「より儲かるから嬉しい」に帰結しそうで、身も蓋もなくなってくるんですが。 はじまりは 「わけわからんたとえ話よりも、『オブジェクト指向を使うと何が嬉しいのか』に重きを置いて説明すべきではないか」 にあります。 C 言語の知識がある前提でオブジェクト指向を教えるとすると、何が嬉しいのかと言えばやっぱり「バグが減る・バグが出にくくなるから嬉しい」んだと思います。 ＃設計がきれいになることによってもたらされるメリットではなく、きれいになること自体が純粋に嬉しい、というのも共感できるところではあるのですが。 もうこうなると、オブジェクト指向のどこがいいのか、バグさえ減るならオブジェクト指向じゃなくたっていいじゃないか、ということになってしまうので、私の意見はやっぱりどこか間違えてるっぽいんですが。 括りすぎ、一般化し過ぎたんでしょうか。 そもそも「オブジェクト指向」という言葉の定義からして統一されたものがない…とも聞きますが。 余談になりますが、このサイトの「オブジェクト指向再入門」に言及されているページを見つけました。 http://sumim.no-ip.com:8080/wiki/755

横槍、失礼します。 >>>バグを減らすにはどうすればいいかというと、極力コードを書き起こす量、 >>>き換える量を減らすことです。 >>>継承や多態性は抽象化のための手段であり、抽象化は再利用のための手段であり、 >>>利用はコードを書く量を減らすための手段であると思います。 (中略) >「オブジェクト指向はバグを減らすための技術である」は真であると思いますが、「バグを減らすための技術はオブジェクト指向である」これは偽です。 (中略) >カプセル化も継承も多態性も「ソースコードを量を減らし、バグを減らすための手段である」と括ってしまうと、「バグを減らすための技術はオブジェクト指向である」が真になってしまうので。 確かに、 1) バグを減らすには、コード量を減らすことである 2) オブジェクト指向による抽象化は、再利用のための手段である 3) 再利用によってコード量が減る 4) コード量が減れば、バグが減る 5) オブジェクト指向は、バグを減らすための技法である という論理の筋は、理解できます。 でも、オブジェクト指向って、再利用だけが利点でしょうか？ オブジェクト指向に限らず、「抽象化すること」によって得られる利点を、適当につらつらと考えてみましたが、 ・ 設計の向上（データ構造、モジュール間の関連等） ・ 可読性の向上 ・ 保守性の向上 ・ 意思疎通の向上 等々、ちょっと考えただけでも色々出てきそうです。 なので、「オブジェクト指向はバグを減らす技術」っていうのは、確かに真かもしれないのですけど、それはひとつの側面に過ぎないんじゃないかな、と思いました。 以上、横槍というか、茶々でした。

>>バグを減らすにはどうすればいいかというと、極力コードを書き起こす量、 >>き換える量を減らすことです。 >>継承や多態性は抽象化のための手段であり、抽象化は再利用のための手段であり、 >>利用はコードを書く量を減らすための手段であると思います。 > >そこまで一般化してしまえばそうかもしれませんが。 それが悩みと言えば悩みで。 「オブジェクト指向はバグを減らすための技術である」は真であると思いますが、「バグを減らすための技術はオブジェクト指向である」これは偽です。 じゃあ「オブジェクト指向」という言葉の定義は何かというと、詰まってしまって… カプセル化も継承も多態性も「ソースコードを量を減らし、バグを減らすための手段である」と括ってしまうと、「バグを減らすための技術はオブジェクト指向である」が真になってしまうので。 「カプセル化を中核とし、それにバグ軽減のための様々な技法を付随させたものである」という定義を試みたこともありましたが、カプセル化だけ特別扱いするのもどうかと思いますし… >たとえば、interfaceを使うのと継承を使うのとでは、短期的には継承を使う方が >ソースは短くなるものですが、それでもinterfaceを使おう、というのが >最近の風潮ですし。 ただ闇雲にソースを短くすればいいというわけではありません。 そもそも、オブジェクト指向を使えば、どうしたってソースは肥大化すると思います。 一時的にはそうであっても、将来的に、トータルで見て書く量を減らそう、ということです。 >一例ですけど、StrutsのActionがinterfaceでなくクラスなのが気になって >しょうがないのです。私の場合。 Struts については（というか、Java 自体）よく知らないので、コメントは控えさせていただきます。

>これについては、 >「Smalltalk に端を発する、『オブジェクト同士のコミュニケーションは > メッセージパッシングだ』とする派と、C++ 流儀の『メッセージパッシングとは > 要するに関数呼び出しのことだ』とする派、２通りの『オブジェクト指向』が > 存在し、それがごっちゃになって受け取られているためだ」 そういうことなら、C++やJavaを使いたい人には、ことさらメッセージ云々と 説明するのは有害だということになりそうです。違う流儀なのですから。 >>すみません、ちなみにその本は何という本でしょうか。 >>よろしければ教えてください。 > >http://www.amazon.co.jp/exec/obidos/ASIN/4894711885/ あ、やっぱり。この本は読みました。 >バグを減らすにはどうすればいいかというと、極力コードを書き起こす量、 >き換える量を減らすことです。 >継承や多態性は抽象化のための手段であり、抽象化は再利用のための手段であり、 >利用はコードを書く量を減らすための手段であると思います。 そこまで一般化してしまえばそうかもしれませんが。 たとえば、interfaceを使うのと継承を使うのとでは、短期的には継承を使う方が ソースは短くなるものですが、それでもinterfaceを使おう、というのが 最近の風潮ですし。 一例ですけど、StrutsのActionがinterfaceでなくクラスなのが気になって しょうがないのです。私の場合。

レスありがとうございます。CES です。 >SDKでウィンドウプロシージャを書く人は、「メッセージ」のディスパッチを >特に苦労なく学べるんじゃないかと思っています。まあイベントドリブンへの >発想の転換は必要でしょうが、メッセージの受け渡しそのものは別に難しくない。 >Cの知識そのままでいけます。 >でも、「オブジェクト指向ではオブジェクト同士がメッセージを～」という >説明では混乱する人が出てくる。これは、「メッセージパッシングは >関数呼び出しとは異なるものだ」という説明があるせいだろうと思うわけです。 これについては、 「Smalltalk に端を発する、『オブジェクト同士のコミュニケーションはメッセージパッシングだ』とする派と、C++ 流儀の『メッセージパッシングとは要するに関数呼び出しのことだ』とする派、２通りの『オブジェクト指向』が存在し、それがごっちゃになって受け取られているためだ」 という記述を見つけました。 http://sumim.no-ip.com:8080/wiki/414 私は C++ 流しか知らないので、やはりオブジェクト指向の源流を理解するためには、Smalltalk（というか Simula？）を学ぶべきなのかな、と思います。 >>「オブジェクト指向で再利用性は高まるか?」 >> >>高まると思いますが、マルチプルインスタンスについて論じているらしい >>「こちら」のリンクが切れているので、先がすごく気になります… > >や、すみません。リンク先のURLにNOREFと書いてあるので、いずれ続きを書くつもり >だったんだろうと思います。 >で、当初書くつもりだったことは既に書いたつもりですので、 >おそらくこのリンク先は、 >http://kmaebashi.com/programmer/object/shigoto.html >ここのStringTokenizerあたりの説明のことを指しているのだと思います。 ># 既に忘却の彼方です。すみません。 了解いたしました。後ほど読ませていただきます。 >>まぁ、この Eiffel 本は「だから C++ はダメな言語だ。さぁ、皆で >>Eiffel を使おう！」とか言い出しそうな勢いですが。 > >すみません、ちなみにその本は何という本でしょうか。 >よろしければ教えてください。 http://www.amazon.co.jp/exec/obidos/ASIN/4894711885/ コイツです。 >私が書いたのは、「継承は、(ソースであれなんであれ)再利用の手段ではない」 >ということです。継承は抽象化の手段だと思っています。 「継承はコードを書かないための技術である」というのも、あながちハズレではない気がしています。 結局、オブジェクト指向とは何のために存在するのかというと、突き詰めれば「バグを減らすため」だと思います。 バグを減らすにはどうすればいいかというと、極力コードを書き起こす量、書き換える量を減らすことです。 継承や多態性は抽象化のための手段であり、抽象化は再利用のための手段であり、再利用はコードを書く量を減らすための手段であると思います。

どうも。はじめまして。 >しかし、それでも難しいという印象を持たれているのは、「どういうものか」は >頑張って説明するけれど、「どのようにありがたいのか」が伝わらないためでは >ないでしょうか。 そう思います。ていうかプログラミング言語はもちろん、プログラミングパラダイム まで含めても所詮「道具」に過ぎないわけで、道具なら、何の役に立つのかが わからなければならないはずです。 >「メッセージ」というと、ぱっと思いつくのが「（WM_CREATE などの）Window > メッセージ」ですが、Windows のアーキテクチャというのは、まさに > オブジェクト指向なのだと痛感させられます。 … >が、MFC なんぞ使わず SDK でウィンドウプロシージャを書いている人は、 >非オブジェクト指向言語を使っているんだなぁ、と思うと、何だか妙な気分です。 SDKでウィンドウプロシージャを書く人は、「メッセージ」のディスパッチを 特に苦労なく学べるんじゃないかと思っています。まあイベントドリブンへの 発想の転換は必要でしょうが、メッセージの受け渡しそのものは別に難しくない。 Cの知識そのままでいけます。 でも、「オブジェクト指向ではオブジェクト同士がメッセージを～」という 説明では混乱する人が出てくる。これは、「メッセージパッシングは 関数呼び出しとは異なるものだ」という説明があるせいだろうと思うわけです。 >「オブジェクト指向で再利用性は高まるか?」 > >高まると思いますが、マルチプルインスタンスについて論じているらしい >「こちら」のリンクが切れているので、先がすごく気になります… や、すみません。リンク先のURLにNOREFと書いてあるので、いずれ続きを書くつもり だったんだろうと思います。 で、当初書くつもりだったことは既に書いたつもりですので、 おそらくこのリンク先は、 http://kmaebashi.com/programmer/object/shigoto.html ここのStringTokenizerあたりの説明のことを指しているのだと思います。 # 既に忘却の彼方です。すみません。 >それは Eiffel が「外部から書き込み可能な public 変数」という概念を >持たないから言えることであって、その保護機能がない C++ では、 >変数を private にして getter のみ実装することは、Eiffel 風に言えば >「公開」であると思います。 もうひとつ重要なのは、Eiffelでは引数無しのメソッド呼び出しでは()が 不要だということですね。 >まぁ、この Eiffel 本は「だから C++ はダメな言語だ。さぁ、皆で >Eiffel を使おう！」とか言い出しそうな勢いですが。 すみません、ちなみにその本は何という本でしょうか。 よろしければ教えてください。 >> 継承は、ソースの再利用の手段ではないということです。 > >うーん…結局、ソース以外の何を再利用するんだろう、と思います。 >いや、言わんとすることはわかるんですが、突き詰めると、ソースの >再利用じゃん、と。 私が書いたのは、「継承は、(ソースであれなんであれ)再利用の手段ではない」 ということです。継承は抽象化の手段だと思っています。 >最後にひとつ、感じたことを言わせていただくと… >この再入門講座は「オブジェクト指向とは何であるか」ではなく >「オブジェクト指向とは何でないか」を説明していることが多いように >思えたのでした。 まあこれはそうでしょうねえ。 既存の説明について、ちょっとそれはないんじゃないか、というコンセプトで 書いてますから。

>１００ページの７および１０行目に出てくる macro.c というファイルは >４行目の cpp.c の書き間違いということで宜しいでしょうか。 書き間違いです。昔のことなのでさすがに記憶が曖昧ですが、このファイル名を cpp.cにするかmacro.cにするか迷っていて、最終的にはcpp.cにしたものの、 いくつか直し忘れがあった、ということだと思います。 こんなポカがいまだに残っているとは思いませんでした。 正誤表に追加しておきました。ご指摘ありがとうございました。 >なお当方の環境（Mac OS X 10.2.8 + gcc-3.1）で、cpp cpp.c と >gcc -E cpp.c を実行したところ以下のようになりました。 gcc -Eの方では、どうもCコンパイラが動いているように見えますね。 うちのgcc gcc (GCC) 3.4.2 (mingw-special) では再現していません。 Mac OS X をお持ちの方の情報をお待ちしております。

はじめまして。 なんか最近、自前のプログラミング言語を作りたくなって来たのであちこちフラフラしていて、こちらに流れ着きました。 「プログラミング言語を作る」のコーナーは、後ほどじっくり読ませていただきます。 さて、今回は一言「オブジェクト指向再入門」に物申させて頂きに参上仕りました。 文句ばっかりでなく、賛同とか感想の方が多いかもしれませんが… 「いい加減、わけのわからない「たとえ話」はやめよう」 賛成です。 この「わけのわからないたとえ話」というのは、「オブジェクト指向とはどういうものであるか」を、筆者なりに精一杯噛み砕いて説明しようとしたものだと思います。 しかし、それでも難しいという印象を持たれているのは、「どういうものか」は頑張って説明するけれど、「どのようにありがたいのか」が伝わらないためではないでしょうか。 「オブジェクトに「メッセージ」を送って…」 > 「メッセージ送出」と呼ばれているのは、たいていのオブジェクト指向言語では実のところ一種の関数呼び出しです。 重箱の隅を突っつくような指摘をお許しください。 オブジェクト指向で言うところの「メッセージ送出」が、大抵の（メジャーな）オブジェクト指向言語において「関数呼び出し」という形をとっているのは、確かにその通りです。 が、「オブジェクト指向」と「オブジェクト指向言語」は別のものであることは（非「オブジェクト指向言語」で「オブジェクト指向」を実現されている管理人様ならば）周知のことであると存じます。 「メッセージ」というと、ぱっと思いつくのが「（WM_CREATE などの）Window メッセージ」ですが、Windows のアーキテクチャというのは、まさにオブジェクト指向なのだと痛感させられます。 ウィンドウの原型を定義するウィンドウ「クラス」があり、個々のインスタンスであるウィンドウはそのクラスから作られ、振る舞いをカスタマイズしたい場合は「サブクラス化」し、「メッセージ」を送ると、同じメッセージであってもウィンドウごとに「多態的」な動作をする。 が、MFC なんぞ使わず SDK でウィンドウプロシージャを書いている人は、非オブジェクト指向言語を使っているんだなぁ、と思うと、何だか妙な気分です。 「オブジェクト指向で再利用性は高まるか?」 高まると思いますが、マルチプルインスタンスについて論じているらしい「こちら」のリンクが切れているので、先がすごく気になります… 「それは「カプセル化」なのか?」 > データ隠蔽ではなく実装隠蔽だ、という言葉があって、まあこれも > 言葉遊びの匂いがしないでもないですが、同様のことを言っているように > 思います。 （皆様からのご意見(2)より） そういう文句を、ある Eiffel 本で見ました。 確かに、C++ でいうクラスで private にするものには「そのクラスがカプセル化するデータ」と「実装のために必要なデータ」の２種類があり、これを区別することは有用であると思います。 が、この Eiffel 本は「データを隠蔽してしまったら誰も触れなくなる。データは公開せよ」というわけのわからんことを言います。 それは Eiffel が「外部から書き込み可能な public 変数」という概念を持たないから言えることであって、その保護機能がない C++ では、変数を private にして getter のみ実装することは、Eiffel 風に言えば「公開」であると思います。 まぁ、この Eiffel 本は「だから C++ はダメな言語だ。さぁ、皆で Eiffel を使おう！」とか言い出しそうな勢いですが。 「継承について」 > 継承は、ソースの再利用の手段ではないということです。 うーん…結局、ソース以外の何を再利用するんだろう、と思います。 いや、言わんとすることはわかるんですが、突き詰めると、ソースの再利用じゃん、と。 「オブジェクト指向言語によるサポート」 > こんなの見た目が変わっただけじゃないか! > 全くそのとおり。継承を考えない限りにおいては、オブジェクト指向言語といってもその程度のものです。 オブジェクト指向とは、ある日、何の前触れも無くぽっと生まれたものではなく、それ以前の歴史を脈々と受け継いだ上に、生まれるべくして生まれたものだと思います。 そして、「オブジェクト指向言語」とは、非オブジェクト指向言語よりもオブジェクト指向を「それっぽく書ける」だけの代物であって、正に「サポート」程度の役割しかないものだと思います。 オブジェクト指向の三本柱は「カプセル化」「継承」「多態性」だなんて、いったい誰が言ったんでしょうか。 結局のところ、（最初にも書きましたが）その三本柱が「何の役に立つのか」が見えないとダメなんだと思います。 C 言語で継承や多態性を実現するのは難しいですが、継承や多態性によって「何を成し遂げたいのか」がわかっているなら、きっと C でも素晴らしいプログラムが書けることでしょう。 もっと言ってしまうと、「オブジェクト指向」って、結局何なんだかよくわからなくなってきます。 おそらくそれは「オブジェクト思考」みたいなもんであって、「これ」というはっきりした形が無い「考え方」なんだと思います。 でも「じゃあ、その考え方に則っていればなんでもオブジェクト指向なのか」というとそんなことは無くて。…何なんでしょうね、オブジェクト指向って。 最後にひとつ、感じたことを言わせていただくと… この再入門講座は「オブジェクト指向とは何であるか」ではなく「オブジェクト指向とは何でないか」を説明していることが多いように思えたのでした。

『Ｃ言語体当たり学習徹底入門』（第２刷）を読み返していたときに気が付いたのですが、１００ページの７および１０行目に出てくる macro.c というファイルは４行目の cpp.c の書き間違いということで宜しいでしょうか。なお当方の環境（Mac OS X 10.2.8 + gcc-3.1）で、cpp cpp.c と gcc -E cpp.c を実行したところ以下のようになりました。これに関しては処理系の違いによるものと考えておいて良いのでしょうか。cpp.c と cpp.h は９９ページの例に従っています。 % cpp cpp.c | cat -n 1 # 1 "cpp.c" 2 # 1 "cpp.h" 1 3 hogehoge 4 hogehoge 5 hogehoge 6 # 2 "cpp.c" 2 7 8 9 10 hogehoge piyopiyo 100. % gcc -E cpp.c | cat -n cpp.h:1: undefined type, found `hogehoge' cpp.h:2: illegal external declaration, missing `;' after `hogehoge' cpp.c:5: undefined type, found `hogehoge' cpp.c:5: illegal external declaration, missing `;' after `piyopiyo' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode 1 # 1 "cpp.c" 2 3 # 1 "cpp.h" 1 4 hogehoge 5 hogehoge 6 hogehoge 7 # 1 "cpp.c" 2 /* 上の例と少し違います */ 8 9 10 11 12 hogehoge piyopiyo 100 .

>心ならずもトリガーになってしまった者として >一言お詫びさせて頂きます。 いやそんな、これはどうひっくり返っても竹内さんに責任があるような話では ありませんので、お気になさりませんよう。 >掲示板での(本来の)議論を楽しみにしておりますので、 >今後とも宜しくお願い致します。 私も最近むやみやたらと忙しく、更新が滞っておりましてすみません。 こちらこそ今後ともよろしくお願いいたします。

ヨルダンの竹内です。 最初の投稿以来、ちょっと忙しかった事もあり、掲示板を参照してませんでした。 その後の迷惑投稿について、私の最初の投稿が切っ掛けになっているらしい状況を知り、 何だか申し訳ない気持ちです。 >6/12 16:24 問題の書き込みがあった。「国際協力、掲示板」でGoogleして >　　　　　たどり着いた模様。 心ならずもトリガーになってしまった者として 一言お詫びさせて頂きます。 この手の不心得者は至る所に居て、やりきれない気持ちになりますが、 掲示板での(本来の)議論を楽しみにしておりますので、 今後とも宜しくお願い致します。

★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★ ★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★★☆★ ☆★☆ ★☆★　ライブチャット検索チャットレディ情報　無料ポータルサイト ☆★☆ ★☆★ ライブチャットひろば 　http://livechat-hiroba.com/ ☆★☆ ★☆★　ライブチャット人気サイトも、無料お試しサイトも、 ☆★☆　新規オープンも一目でわかる！ ★☆★　2005年の ライブチャットひろばでは、数あるライブチャットサイトを ☆★☆　独自の視点でて紹介しています！ ★☆★　サイト探しに苦労なさってるライブチャットファンの皆様に、 ☆★☆　少しでもお役に立てればと管理人が厳選したサイトをご紹介いたします。 ★☆★ また、出会い系サイトのご紹介や、相互リンクも随時募集しております。 ☆★☆　お気軽に御覧下さい。 ★☆★　もちろん無料で情報をゲットしてください。 ☆★☆　 ★☆★ ☆★☆ http://livechat-hiroba.com/ http://livechat-hiroba.com/

おお、ビンゴでしたか。 該当スレッドをいろんな形式で表示してみたり、 「PHP & MySQL」のコンテンツでデータ構造を調べたりして、 パズルを解くように推理して楽しんでました。 生データに手を入れて整合性を壊してしまうという落とし穴には私もよくハマります。 冗長なデータ構造(ここではmessage.top)をあえて導入している場合は特に注意が必要ですよね。 (ぱ)さんの掲示板は実用重視でシンプルに洗練されてますね。 お役に立てて何よりです。

>レスの練習です 練習の投稿ならテスト用掲示板 http://kmaebashi.com/bbs/list.php?boardid=testbbs の方でお願いします。 また、この掲示板では、HTMLソースの中に「REMOTEHOST_ID」という形で 投稿元のIPアドレスをハッシュした値を埋め込んでいるので、 同一人物が複数回投稿すると、ハンドル名を変えても、それが同一人物による 投稿であることが誰の目にもバレてしまうのでよろしく。

このところ客先に詰めていて帰りが遅かったため、対処が遅れましてすみません。 まさにそれが原因だったようです。修正しました。ご指摘ありがとうございます。 >以前、スレッドのトップに位置するメッセージの親IDが >NULLであるべきところが0になっていたのを修正した際、 こういう修正を行ったこと自体、きれいさっぱり忘れていたので、 「この掲示板は最初からスレッド表示をサポートしていたし、 　初期の投稿はそれこそ何度もスレッド表示で見たはずなんだけどなあ」 と悩んでいました。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&thread=303 この対応のことですね。このときもご指摘いただきありがとうございました。

>というわけで早速テストです。 >変換指定子に「#」があるのを知りませんでした。_no > >#include <stdio.h> > >int main(void) { > int hoge = 4095; > printf("%#010x\n", hoge); > > return 0; >} > >ただ、「0x」の大文字小文字変換もそのうしろの >変換指定子「x」依存なのがちょっと嫌かも。 >もっとも普段からリテラルで0X00000FFFなどと書かないから >見慣れないというだけでしょうが・・・ レスの練習です

以前、スレッドのトップに位置するメッセージの親IDが NULLであるべきところが0になっていたのを修正した際、 本当にメッセージ[0]の子であった メッセージ[1]の親IDまでNULLにしてしまっていませんか？ 一度D/Bをご確認ください。

あのー、これは何でしょう… と見ているうち、「みつ」さんの意図はわかりませんが、ひとつこの掲示板の バグを見つけました。「みつ」さんの投稿から、 「この投稿を含むスレッドを表示」しても、ひとつの投稿しか表示されないようです。 今はまったく余裕がない状況なので、後ほど対処します。

>http://6029.teacup.com/scjv/bbs >ここなんかだと、完全に本人の投稿だとみなされて叱責されてますね。 いや、ぶっちゃけ本人の投稿ではないと決まったわけでもないと思いますがね。 ご本人がこれほど明確に否定している以上、あまり迂闊なことは言えませんが、 以下、事実だけを記します。 6/12 16:24 問題の書き込みがあった。「国際協力、掲示板」でGoogleして 　　　　　たどり着いた模様。 6/17 02:25 私から山本氏にメールを送る。当然そこにはうちの掲示板のURLを書いた。 6/17 06:38 例の書き込みと同じIPアドレスからふたたびアクセス。 また、http://www.ets-org.jp/contact.htmlを見ると、山本敏晴氏の メールアドレスは toshi＠zar.att.ne.jp であり、ドメインがspammerのそれと 一致しています。 もちろん、「spammerはたまたま山本敏晴氏と同じatt.ne.jpを使用していて、 たまたま5日ぶりに書き込みのその後が気になって掲示板を確認しに来た」という 可能性が否定できるものではありません。 しかし…

>仕様について簡単に説明します。 > >・発言内容は全て<pre>で囲まれます。ソースリストを載せるのに便利にするためです。 >　適当な位置で改行を入れてください。 >・でもやっぱり改行を入れ忘れる人もいるので、プレビュー表示をつけました。 >　確認してから「送信」をクリックしてください。 >・タグは全無効です。<font color="red">ほらね</font> >・クリッカブルURLの機能があります。 >　http://kmaebashi.com >　タグは無効なので<a>タグは書けません。 >・現状では削除機能がないので削除用パスワードは単なるお飾りです。 >・スレッド表示時、スレッドトップの「▼」をクリックすると、そのスレッドの >　発言を一覧表示します。 >・一画面あたりの表示数は以下の通りです。 >　- 日付順表示…30 >　- 日付順インデックス…50 >　- スレッド表示…20スレッド >

http://6029.teacup.com/scjv/bbs ここなんかだと、完全に本人の投稿だとみなされて叱責されてますね。 # 「善意」で名前を騙られちゃたまりません。 暇に任せて調べたら、以前にも同じようなことが行なわれてたようです。 http://www.google.co.jp/search?hl=ja&c2coff=1&rls=GGLD%2CGGLD%3A2004-51%2CGGLD%3Aja&q=%22%E5%B1%B1%E6%9C%AC%E6%95%8F%E6%99%B4%22+%22%E5%BE%85%E6%9C%9B%E3%81%AE%E7%AC%AC%E4%BA%8C%E5%BC%BE%22&lr= まぁ本人が「待望の第二弾、満を持して登場！」なんて書かないか(^^;)

返事が遅くなりましてすみません。 >本人以外が勝手にやってるなら消した方がいいし、 >たとえ本人がやってる場合も、掲示版spamの一種なので >消した方がいいんじゃないですかね。 > >問い合わせをした方がいいかどうかは迷うところですが。 問い合わせをするのであれば、少なくとも先方がこの書き込みを 確認するまでは削除できないと考えます。 この書き込みは、住所や電話番号なども含まれていますが、 もともと公開情報ですから急いで消さなければいけないものではないでしょう。 というわけで、(しばし迷いましたが)問い合わせメールを出しました。 回答によっては削除いたします。

>なので、まさかご本人がやっているはずはないと思うんですが… >問い合わせメールでも出してみますかね。 本人以外が勝手にやってるなら消した方がいいし、 たとえ本人がやってる場合も、掲示版spamの一種なので 消した方がいいんじゃないですかね。 問い合わせをした方がいいかどうかは迷うところですが。

さて。どうしたものでしょうか。 リンク先を見ると、「山本敏晴」という人は、何冊も本を出してたり、 講演会や写真展などの活動をされている方のようです。 そういう、社会的な立場もある人が、 　「無差別宣伝掲示板書き込み」 という迷惑行為を、実名出してやるとは、ちと私には信じがたいところがあります。 # 少なくとも私にとって、[640]の投稿は、よくあるアダルトサイトなどの広告書き込み # よりも数段不快です。 なので、まさかご本人がやっているはずはないと思うんですが… 問い合わせメールでも出してみますかね。

新刊の紹介です。 カンボジアの写真絵本を出版しました。 題名 「あなたのたいせつなものはなんですか？ 　・・・カンボジアより」 小学館刊 山本敏晴写真・文 定価１５００円プラス税 「あなたのたいせつなものは、なんですか？」 カンボジアの子供達にこの質問をし、 それを絵に描いてもらってきました。 また絵に描いてもらった後に、 必ずその子の家に行き、 その子の住んでいる家の写真、 家族の写真、 その村の風景写真などを撮影させてもらいました。 こうした取材を行っている理由は、 様々な国の様々な文化を紹介し、 世界の多様性を皆様にご覧頂きたいと思っているからです。 絵を描いてもらうだけではなく、 暮らしている様子を取材しているのは、 「これこれこういう社会背景に住んでいる人が、 　こういうものを大切だと思っている・・」 というその流れを理解して頂きたく思うからです。 今回、カンボジアの子供達が描いた「たいせつなもの」は、 多岐にわたっています。 明るい絵、暗い絵、よくわからないもの・・・。 そうした彼らの考え方とその生活している背景をご覧頂き、 様々な国に、様々な考え方の人達がいることを、 まずは見て頂ければ嬉しく思います。 そして、どんなに変わった考え方をしている人達にも、 必ず一緒に暮らしている家族がいて、 大切な友達がいることを知って頂ければ幸いです。 NPO法人　宇宙船地球号 Earth the Spaceship : ETS 事務局長　山本敏晴 108-0014 東京都港区芝5-20-7-504 電話　 03-5443-8969 ファックス 　03-6400-5949 http://www.ets-org.jp

>伊藤と申します。 はじめまして。 >yacc,lex以外にbison,flexというのがあり、 >そっちのほうが新しいと聞いた記憶ありなのですが、 >例の企画では、なぜyacc,lexなんでしょうか？？ bison とflexは、GNUプロジェクトが開発したyacc/lexの互換品ですね。 ですから、「bison/flexではなくyacc/lexを使った」というわけではなく、 基本的にはどちらも同じものです。 実際、crowbarのUNIX版はLinuxに付属していたyacc/lexでmakeしていますが、 Windows版はbison/flexを使用しています(配布しているMakefileを使う場合)。 bison/flexは、(GNUのやることなので当然のように)yacc/lexの上位互換に なっていて、いろいろ機能追加がなされています。しかし、今回の要件では 特に不要なので、それなら低機能なほうに合わせたほうが使える人も増えるのでは、 と考えて、UNIX版はyacc/lexでmakeしているわけです。

伊藤と申します。 yacc,lex以外にbison,flexというのがあり、 そっちのほうが新しいと聞いた記憶ありなのですが、 例の企画では、なぜyacc,lexなんでしょうか？？ 素朴な疑問です(^^

>すみません、そのように実行しても'外部シンボル_mainが未解決'というエラーが出ます。 このエラーメッセージは、その名前の関数なりグローバル変数なりの定義が 見つからないときに出ます。つまりmain関数がないということです。 main関数を書いてない(mainを書いた.cファイルをリンクしていない)か、 mainと書いたつもりでスペルを間違えたとかでしょう。

竹内です。 >はい。まったく問題ありませんので、ご自由にお使いください。 >わかりにくいところ等ありましたら、また掲示板の方にでも書き込んでください。 ありがとうございます。また書き込みさせて頂きます。 >何かと大変な状況かと思いますが、ご活躍を期待しております。 上記リンクにヨルダン日記等も書いておりますので、 お暇な時にでも見てみて下さい。

すみません、そのように実行しても'外部シンボル_mainが未解決'というエラーが出ます。

>エラー_外部シンボル'get_word'が未解決 リンクしていないからでしょう。 BorlandのCコンパイラを使っているのなら、たとえば bcc32 hoge.c とやればhoge.exeという実行形式ができますが、単語の出現頻度のプログラムは、 main.c, get_word.c, initialize.c, add_word.c, dump_word.c, finailze.cを リンクしてひとつの実行形式になります。個別に bcc32 main.c などとやっていれば当然上記のエラーが出ます。 bcc32 -owordmanage main.c get_word.c initialize.c add_word.c dump_word.c finalize.c のように書けば「wordmanage.exe」というひとつの実行形式ができるはずです。

管理人様、スペースお借りします。 C言語ポインタ完全制覇を熟読中ですが、単語の出現頻度を表示するプログラムに関してOSはXP、コンパイラはboland5.5を使っているのですが、本の記載されてる通り実行したところ、エラー_外部シンボル'get_word'が未解決(以下initialize,add_word,dump_word,finalizeも同様のエラーが出ます)というエラーができ実行できません。全く原因が分からないんですがどうかアドバイスをお願いします。

>始めまして。竹内敏彦と申します。 はじめまして。 >私は現在、国際協力機構のシニア海外ボランティアとして >中東の国ヨルダンのアル・フセイン大学(http://www.new.ahu.edu.jo/) >のコンピュータ・エンジニアリング＆IT学部にて学生の面倒を見ています。 遠いところから興味を持っていただきありがとうございます。 それにしてもヨルダンとは。うちのページも(日本語しかないくせに)ずいぶん グローバルになったものだと喜びつつも驚いております。 >とりあえず、HPからダウンロードさせて頂いたドキュメント、ソースコード等を、 >学生の学習参考資料として使わせて頂こうと思っています。 はい。まったく問題ありませんので、ご自由にお使いください。 わかりにくいところ等ありましたら、また掲示板の方にでも書き込んでください。 何かと大変な状況かと思いますが、ご活躍を期待しております。

始めまして。竹内敏彦と申します。 専門的な会話に突然割り込む様で申し訳ないのですが、 メールよりも掲示板へ、という記述がありましたので、 こちらへ投稿させて頂きました。 私は現在、国際協力機構のシニア海外ボランティアとして 中東の国ヨルダンのアル・フセイン大学(http://www.new.ahu.edu.jo/) のコンピュータ・エンジニアリング＆IT学部にて学生の面倒を見ています。 (まだ着任１ヶ月目で、言葉の問題等もあり、実際に教えるところまでは行っていません。) 学生の中に、プログラミング言語が作ってみたいという者がおり、 私自身に知識が無いので、学生に示す具定例があった方が良いと思い WEBで検索していたところ、前橋さんのページにたどり着きました。 crowbarのソースやドキュメントを参考にして、 私自身の勉強も兼ねて学生に紹介したいと思っています。 「プログラミング言語を作る」のページには、断り無く勝手に使って良い との記述がありましたが、念の為、一言お断わりしてからと思った次第です。 とりあえず、HPからダウンロードさせて頂いたドキュメント、ソースコード等を、 学生の学習参考資料として使わせて頂こうと思っています。 アラビア語しか話せない学生が多いので、私の翻訳・説明で どこまで解ってくれるか判りませんが、内容の理解が出来れば それを土台にして、新しい言語を作成出来たら良いな、とも考えております。 (理解するまで行けるかどうかも現時点では不安なのですが．．．。) 唐突にお邪魔して申し訳ありませんでした。では、失礼致します。

>条件の判断を言語の文法として導入せず、アプリケーション側で >判断してもらう場合、上に伝搬させたい例外の throw を忘れやす >そうな気もします。Java に慣れている人だと、finally 節の中 >では普通 throw を行わないので、特に危ないかも。 確かにそうですね。私自身「Java謎+落とし穴～」にそんなことを書いてました。 >欲しい機能のが OR 条件だけなら、catch の後に例外を羅列でき >るような文法にするんですかねえ… ひとまずORがあれば、そのcatch節の中で処理の振り分けはできそうなので (できるように作ればですが)、よさそうな手に思えます。 try { 　… } catch (HogeException, PiyoException: ex) { 　… } とかですかねえ…

> (1)例外の種類の区別を、言語レベルで提供するか、ライブラリ > 　レベルで提供するか、規約レベルの話にするか。 ゼロ除算や、浮動小数点関係のエラーのような例外は、言語処理系 の側で投げて欲しいので、完全にライブラリレベルだけってわけに はいきませんよね。 利用者側で例外の種類を拡張できないようにするのも不便そうだし、 結局、折衷策にせざるをえないような気がします。 > (2)例外の種類別catchを、言語レベルで提供するか、アプリケー > 　ションで判断してもらうか。 > > Javaのように、catchを例外の種類ごとに書く方法だと、OR条件 > (この例外とこの例外の時にはこうする)のようなものが書きにく > くて、なんとかならんもんかと常々思っているのですが… 条件の判断を言語の文法として導入せず、アプリケーション側で 判断してもらう場合、上に伝搬させたい例外の throw を忘れやす そうな気もします。Java に慣れている人だと、finally 節の中 では普通 throw を行わないので、特に危ないかも。 欲しい機能のが OR 条件だけなら、catch の後に例外を羅列でき るような文法にするんですかねえ…

[446] >JDK1.0ベースで記述されているためです。Javaは1.1になったときイベントの扱いが >一新され、古い流儀のプログラムでは、上記の警告が出るようになりました。 [447] >確認ですが、警告が出るだけで、コンパイルは通ってクラスファイルもできていて、 >しかるべきHTMLファイルをつければ動くわけですよね? >うちのWebページをネット上で見たときしか動かない、というわけではなく。 はい。警告が出るだけで、それ以外はすべてOKです。 大変な作業になるのかと思い、提供されるかもしれない修正版と比較しようと思っていましたが、Eclipse 3.1 の力(ちから)を借りて、問題となる部分を書き換えました。 お騒がせしました。 反省: 先ず自分でやれぇー。( 他の初心者は困っていないのだろうか。大きなお世話 ) 反省: 件名の扱いを JavaHouse で知りました。

書き忘れました。 確認ですが、警告が出るだけで、コンパイルは通ってクラスファイルもできていて、 しかるべきHTMLファイルをつければ動くわけですよね? うちのWebページをネット上で見たときしか動かない、というわけではなく。

>"注: Puzzle16Applet.java は推奨されない API を使用またはオーバーライドしています。" これが出るのは、「パズル16」はなにしろ7年も前に書いたものなので、 JDK1.0ベースで記述されているためです。Javaは1.1になったときイベントの扱いが 一新され、古い流儀のプログラムでは、上記の警告が出るようになりました。 >"警告"の出ないソースを提供していただけないでしょうか。 さすがに今更あのプログラムを直す気にはなれませんし、JDK1.0のプログラムと しては「正しい」わけですから、すみませんがこちらで修正版を提供する つもりはありません。ご了承ください。

>Java や C++ の例外の場合、例外の受け手は直接指定せず、受け手が >存在しない場合はトップレベルまで伝搬するわけですが、こういう風に >書くと、それとはだいぶ意味的に違うものになりそうです。 う。確かに私の書いたのだと、トップレベルまで伝搬しませんし、 例外の種類に関わらずcatch節に流れ込みますね。 例外の種類に関わらずcatchに流れ込むことについては、 「自分が知らない例外だったらcatch節で投げ直してよ」という方法で いけそうな気がしますが(ていうかクラス階層という概念がないcrowbarでは、 別途例外階層を定義する手段を提供しない限りそうなってしまいそうですが)、 catch節で例外を投げなおしたときには、上位がさらにtryで囲まれていれば そっちのtryのcatch節に流れ込むように思います(というかそう作らなければ 面白くない)。ただ、catch節で例外を投げなおすためには、上位のtry用の クロージャを持っていなければいけないので、何かと面倒そうではあります。 >また、例外の伝搬を >実装するために、クロージャのリストも管理することになるんじゃ >ないかな… こういうことですかね。 >でも Lisp みたいなマクロがないと、文法的に結構面倒くさそうなので、 >言語レベルで定義しちゃった方が、むしろ好ましいかもしれませんね。 ということで言語レベルで定義しようとせこせこ弄り回しているわけですが、 上に書いたように、crowbarにはクラス階層の概念がないので、どうやって catchしたものか考えているところです。 Common Lispの例外処理は、ちょっとぐぐって以下のページを見つけたのですが、 http://www.geocities.jp/m_hiroi/xyzzy_lisp/abclisp16.html やっぱり階層構造を(おそらくライブラリレベルで)実現していますね。 上に書いたような「なんでもcatchに流れ込むから、あとはアプリケーションで 投げ直してくれ」という戦略をとるにせよ、なんらかの方法で識別がつかないと そもそもアプリケーションでも区別がつきませんから、どうしようかと 考えているところです。 (1)例外の種類の区別を、言語レベルで提供するか、ライブラリレベルで提供するか、 　規約レベルの話にするか。 (2)例外の種類別catchを、言語レベルで提供するか、アプリケーションで 　判断してもらうか。 Javaのように、catchを例外の種類ごとに書く方法だと、OR条件(この例外と この例外の時にはこうする)のようなものが書きにくくて、なんとかならんもんかと 常々思っているのですが…

プログラマなページ -> 超手抜きJavaパズル -> パズル16 のソースを javac Puzzle16Applet.java した処、次のようなメッセージが出ました。 "注: Puzzle16Applet.java は推奨されない API を使用またはオーバーライドしています。" 更に、javac のメッセージを手がかりに詳細を見ると"警告"が三つありました。 "警告"の出ないソースを提供していただけないでしょうか。 ブラウザ上では作動しています。 以上

> こういうtry関数をライブラリで用意することで、アプリケーション側では > こう書けるのかなあ、と。 ははあ、なるほど。 Java や C++ の例外の場合、例外の受け手は直接指定せず、受け手が 存在しない場合はトップレベルまで伝搬するわけですが、こういう風に 書くと、それとはだいぶ意味的に違うものになりそうです。 Java や C++ の例外処理機構と意味的に同じものは、ラベル指定の break 機能と、Lisp で言う unwind-protect (Java の finally) があり、処理系 側がトップレベルで break に使うラベルを何か定義してくれれば、 一応ライブラリレベルで、実装はできるとは思います。 ただ、その場合、例外の種類を表すものはグローバル変数 (あるいは スレッドローカル変数) で保持することになり、また、例外の伝搬を 実装するために、クロージャのリストも管理することになるんじゃ ないかな… 例外の catch は、finally 節内で、例外の種類を保持する グローバル変数を参照するだけで、できそうです。 でも Lisp みたいなマクロがないと、文法的に結構面倒くさそうなので、 言語レベルで定義しちゃった方が、むしろ好ましいかもしれませんね。 > Lispはレキシカルスコープでもクロージャの受け渡しができるわけでしょうか。 > Lispのマクロは、「コードを示すリストをプログラムからいじること」という > レベルでしか理解していないです。throwに相当するシンボルをさくっと > 置き換えればよいのかな。 catch & throw は、throw する先を表すキーとしてシンボルを 使うわけですが、このキーとクロージャの対応を管理する連想 リストは、関数呼びだしのネストに従って、スタック式に管理 します。この連想リストは、言語が提供するものではなく、 ライブラリが内部的に管理する単なるデータ構造に過ぎないので、 レキシカルスコープとは関係ないわけです。

さっそくの返信、ありがとうございます :-) 「回避策」については、動的確保の Board *create_board() {} から調べ直してみます。イメージが index に固執していたようです。 java.util.LinkedList は初めて見ました。APIをちょっと読んでみましたが、分かったような分からないような。色々と実験して、プログラムに取り込もうかと思います。 掲示板の以前の内容もとても参考になります。 つくづく思います。通りすがりにリンクを保存しておいてよかったと。 さっ、きょうも日蝕を仰ぎ見つつお勉強。(Eclipse 3.1) では。 追伸: まだ、朝。早く本屋開かないかなぁー。楽しみ。

>「オブジェクト指向再入門」。なるほどー。そうですか。面白かった。ためになった。 はじめまして。面白く読んでいただけたようで何よりです。 >>※2 もし、board.cの中で「たくさんの盤面」を配列で管理しているのなら、 >>board_create()の戻り値はintかもしれません。 しかし、戻り値をintにしてしまう >>と、いざ盤面の数に制限をなくそうとして malloc()による動的確保に切り替えたと >>き困ります。 逆に、最初から「Boardへのポインタ」にしておけば、 配列で実装し >>ている場合にも困りません。&board[index]を返せばよいからです。 > >ここで、&board[index] の index には何を使うのでしょうか。 >整数(int)を使うと、引用文二行目の int と同じ制限がかかってしまうと思うのですが。 まず、board.cの中で「たくさんの盤面」を配列で管理しているのなら、 おそらく盤面の数には制限ができることでしょう(回避策は後述)。 Cの配列は基本的に固定長だからです。 ただ、その場合でも、board_create()の戻り値をBoard*にしておけば、 将来的にmalloc()による動的確保に切り替えたとき、利用者側に影響を与えなくて 済む、というのが上の注の主旨です。 &board[index]のindexは、board.cが内部的に保持しているだけであり、 アプリケーションには見せません。簡略化して書くとこんな感じです。 static Board board[BOARD_MAX]; static int board_count = 0; Board *create_board() { return &board[board_count++]; } 実際にはfree_board(Board *b)も要るので、そういう場合はポインタ比較しながら ループを回すことになるのでしょう。 昔、SunOS4か何かのfopen()が、10個くらいまではFILEの固定長配列の中から FILE*を返すようになっていたと思います。それ以上オープンするときは動的に 確保するわけです(これが上で書いた「回避策」)。 >質問: 「どのオブジェクトに仕事をさせるのか」の具体例は。 > >連続的に部分拡大をしていく画像(マンデルブロ集合)を表示する JFrame を沢山作っ >ているのですが、或る画像の JFrame にアクセスする場合、配列を使う事しか思い浮 >かびません。( JFrame[] win = new JFrame[100]; // 100: ∞は可 ??? ) 状況がよくわからないのですが、配列を使う方法でも、 「この画像のJFrameにアクセスしたい!」と思ったときには、そのインデックスが わかっていなければいけないわけですよね?] どうせインデックスを保持しなければならないのなら、代わりにJFrameの参照を 保持しても同じことではないのでしょうか。 もし、「すべてのJFrame」をどこかで保持する必要があるのであれば、 java.util.LinkedListなりを使えばよいと思います。 >答えてもらいたいから云うのではないが、「センス・オブ・プログラミング！」と >「Java謎+落とし穴 徹底解明」の目次を技術評論社サイトで見ましたが、とても良さ >そうですね。買うしかないか。また日曜プログラムが遅れる(-L-) や、どうぞよろしくお願いいたします(_o_)

>>try(closure(throw) { >> }, >> closure() { >> }); > >この例はちょっと意味が良く分かりませんでした。 説明不足ですみません。これ全体がJavaでいうところのtry catchになっており、 ライブラリ関数tryの第1引数にtry節、第2引数にcatch節のclosureを渡します。 また、catch節側にも引数が要りますね。 function try(c1, c2) { exception = null; toplevel: { throw = closure(ex) { exception = ex; break toplevel; }; c1(throw); } if (exception != null) { c2(exception); } } こういうtry関数をライブラリで用意することで、アプリケーション側では try(closure(throw) { # try節 }, closure(exception) { # catch節 }); こう書けるのかなあ、と。 >Common Lisp 等にある return/return-from の機能は、もっと >原始的な感じで、むしろ C の setjmp/longjmp に近いレベルに >なります。たとえば、break にラベル指定ができるとすると、 >(Lisp 風じゃなくて crowbar 風に書くと) こういう感じになる >と思います。 … >for (;;) { > toplevel: { > exit_to_toplevel = closure() { break toplevel; }; > command = キー入力; > do_it(command); > } >} breakの機能自体は、同じものを想定していると思っています。 >上のように書くにしても、ユーザーが明示的に closure を変数に >セーブするのではなく、closure は catch & throw マクロに >付随する連想リストの中に隠されて、ユーザの目には見えなくなります。 crowbarで上記try関数を書くとして、もしローカル変数がダイナミックスコープに なっていれば、throwのクロージャを引数で渡さなくてよさそうなんですが、 ダイナミックスコープは混乱しそうなので付ける気はないわけでして、 Lispはレキシカルスコープでもクロージャの受け渡しができるわけでしょうか。 Lispのマクロは、「コードを示すリストをプログラムからいじること」という レベルでしか理解していないです。throwに相当するシンボルをさくっと 置き換えればよいのかな。

「オブジェクト指向再入門」。なるほどー。そうですか。面白かった。ためになった。 疑問点と質問(受け付けてくれるのかな?)です。 疑問点: "オセロを例に考える" の文末。 >※2 もし、board.cの中で「たくさんの盤面」を配列で管理しているのなら、 >board_create()の戻り値はintかもしれません。 しかし、戻り値をintにしてしまう >と、いざ盤面の数に制限をなくそうとして malloc()による動的確保に切り替えたと >き困ります。 逆に、最初から「Boardへのポインタ」にしておけば、 配列で実装し >ている場合にも困りません。&board[index]を返せばよいからです。 ここで、&board[index] の index には何を使うのでしょうか。 整数(int)を使うと、引用文二行目の int と同じ制限がかかってしまうと思うのですが。 "盤面の数に制限をなくそうとして" とありますが、限りなく無限に近く拡張できる index とはどのようなものなのでしょうか。 質問: 「どのオブジェクトに仕事をさせるのか」の具体例は。 連続的に部分拡大をしていく画像(マンデルブロ集合)を表示する JFrame を沢山作っ ているのですが、或る画像の JFrame にアクセスする場合、配列を使う事しか思い浮 かびません。( JFrame[] win = new JFrame[100]; // 100: ∞は可 ??? ) 他に何か方法があれば教えて頂けないでしょうか。 以上 追伸: ( 管理者権限で削除可 ) 答えてもらいたいから云うのではないが、「センス・オブ・プログラミング！」と 「Java謎+落とし穴 徹底解明」の目次を技術評論社サイトで見ましたが、とても良さ そうですね。買うしかないか。また日曜プログラムが遅れる(-L-)

> (Java風に考えれば)こんな感じですかね。 >try(closure(throw) { > }, > closure() { > }); この例はちょっと意味が良く分かりませんでした。 Common Lisp 等にある return/return-from の機能は、もっと 原始的な感じで、むしろ C の setjmp/longjmp に近いレベルに なります。たとえば、break にラベル指定ができるとすると、 (Lisp 風じゃなくて crowbar 風に書くと) こういう感じになる と思います。 exit_to_toplevel = null; function subroutine() { ... 中略 ... if (致命的エラーが起きたら) { exit_to_toplevel(); } ... 中略 ... } function do_it(command) { ... 中略 ... subroutine(); ... 中略 ... } for (;;) { toplevel: { exit_to_toplevel = closure() { break toplevel; }; command = キー入力; do_it(command); } } あるいは、関数名を指定した return (return_from) があれば、 こんな感じです。 function subroutine(do_exit) { ... 中略 ... if (致命的エラーが起きたら) { do_exit(false); } ... 中略 ... return 1234; } function do_it(command) { do_exit = closure(result) { return_from do_it result; }; ... 中略 ... value = subroutine(do_exit); ... 中略 ... return true; } for (;;) { command = キー入力; if (!do_it(command)) { print("error happend\n"); } } もっとも、Lisp でこういうプリミティブなスタイルのプログラミング が良く行われているというわけではないですが… 上のように書くにし ても、ユーザーが明示的に closure を変数にセーブするのではなく、 closure は catch & throw マクロに付随する連想リストの中に隠されて、 ユーザの目には見えなくなります。 また、いまどきは、もっと Java 等に似たスタイルが使われているようです。 http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html

>あと、素朴な疑問なんですが、現在 && や || が短絡演算になってない >のは単なる手抜きの結果とのことなんですが、これはやはり将来的には >短絡演算になると期待していていいんでしょうか？ あ、それはすぐできるのでやります。すっかり忘れてました。 >さらに妄想ですが、ラベル指定の break/return 文に関して、字面的に >ネストした内側のクロージャから、外側の関数のラベルを指定して脱出 >できると、ライブラリレベルで Lisp 風の catch & throw が書けて楽 >しいと思います。 なるほど… 勉強になります。 (Java風に考えれば)こんな感じですかね。 try(closure(throw) { }, closure() { }); throwには脱出用のclosureが入っているつもりなんですが、これはやっぱり 引数で渡すことになるんでしょうか? ただまあ例外処理については、今のところふつうの(?) try catch finallyを 付けようかと思ってますけど。

どうもです。はじめまして。 >そのときに 感じたのは PHP の オブジェクト指向は 後付で Ruby に 比べると >美しくないなと。 すみません、私はPHPはPHP4でこの掲示板を書いたぐらいで、 とりわけオブジェクト指向的なところには詳しくないです。 ただ、PHP4の、オブジェクトをデフォルトで値として扱うアプローチは、 変だなあとは思ってました。参照の代入などがどこまで使えるものなのかは 知りません。 >でも PHP も PHP 5 となり　かなり 変わってきたのではないかと 思っています。 ちょっと見てみました。 http://www.atmarkit.co.jp/flinux/special/php5/php5a.html まるっきりJavaなような。 >オブジェクト指向としてみた場合の PHP は Ruby と 比べて どうなんでしょうか。 「○○の方がよりオブジェクト指向的である」という比較に意味があるとは 私は思いません。すべてがメソッドでなくても、関数があったっていいじゃないか、 と思います。 でも、機能ごとに、それぞれがどんな形で実現しているかを比較するのは 面白そうではありますけど。

っと簡単に書きましたが、大域脱出ができるようになると、 Lisp の unwind-protect、Java の finally 節相当の機能が どうしても欲しくなり、さらにその向こうにもっと深い淵が 待ってるような気もしますね。(NaClにはunwind-protect も ありました。)

> 一応つけました。 : > 動いたものを貼っておきます。 素早い… どうもありがとうございます。 あと、素朴な疑問なんですが、現在 && や || が短絡演算になってない のは単なる手抜きの結果とのことなんですが、これはやはり将来的には 短絡演算になると期待していていいんでしょうか？ さらに妄想ですが、ラベル指定の break/return 文に関して、字面的に ネストした内側のクロージャから、外側の関数のラベルを指定して脱出 できると、ライブラリレベルで Lisp 風の catch & throw が書けて楽 しいと思います。(returnするだけのクロージャを作っておいて、必要 な時に呼び出すと大域脱出できる。実際 Common Lisp はそういう言語 規格になってます。っていうか内輪の話になりますが、昔NJSのNaClに 対して、そういうcatch & throw の実装をマクロで書いて遊んでいたの でした。)

ちょっと 脱線していると思うのですが 戯言に お付き合いを。 おととし わざわざ東京まで Lightweight Language Saturday に 行ってきました。 そのときに 感じたのは PHP の オブジェクト指向は 後付で Ruby に 比べると 美しくないなと。 でも PHP も PHP 5 となり　かなり 変わってきたのではないかと 思っています。 オブジェクト指向としてみた場合の PHP は Ruby と 比べて どうなんでしょうか。

>http://kmaebashi.com/programmer/devlang/index.html >のページに、最新版への配布ページへのリンクがあると、 >多少はこういう間違いが減るかもしれません… 一応つけました。 ただ、crowbarはまだいろいろな意味で未完成品なので、 いかにもな「ダウンロードページ」はまだ作りたくないところです。 ver.0.3.01の修正でkitさんのプログラムが動くようになりましたので、 動いたものを貼っておきます。 function ArrayIterator(anArray) { this = new_object(); index = 0; this.first = closure() { index = 0; }; this.next = closure() { index++; }; this.isDone = closure() { return index >= anArray.size(); }; this.currentItem = closure() { return anArray[index]; }; return this; } function compare(i, j) { for (; !i.isDone() && !j.isDone(); i.next(), j.next()) { if (i.currentItem() < j.currentItem()) { return -1; } if (i.currentItem() > j.currentItem()) { return 1; } } if (i.isDone() && j.isDone()) { return 0; } if (i.isDone()) { return -1; } else { return 1; } } a = {1, 2, 3, 4, 5, 6, 7, 8}; b = {1, 2, 3, 4, 5, 6, 7, 9}; print("compare.." + compare(ArrayIterator(a), ArrayIterator(b)) + "\n"); for (i = ArrayIterator(a); !i.isDone(); i.next()) { print("" + i.currentItem() + " "); } print("\n");

>本質的には同じことですよね。多重度の問題。UMLで「0..*」とか書くやつです。 >先のタイガーさんの「方法1.」だと、コレクションが唯一のイテレータを >保持していると言えますから、多重度は1です。 > >コレクションそのものが複数作れますから、イテレータも複数作れるには >違いないけれど、ひとつのコレクションに対してはひとつだから先に書いたような >問題が発生します。 > >インスタンス自体がひとつしかないケースは、なんというか「地面」があって、 >そこからそのオブジェクトに線が引いてあって、地面のところに「多重度1」の >指定があるようなイメージを持っています。私の場合。 > >で、その線の根元というのは要するにstaticな変数なのであって、 >私はあまりたくさんのオブジェクトが地面にくくりつけられているモデルは >好きじゃないので、staticに冷淡だったりするわけです。 概念とかを説明するときに、そういったイメージとかの説明があると 理解しやすくて分かりやすいですね。 今回マルチプルインスタンスとか多重度が重要というのが分かりました。 1つのデータ(オブジェクト)の個数を考えるのは簡単ですが、 2つ以上のデータ、つまりある1つのデータの個数に対して、 それに関連するデータの個数が複数必要なのか、1つで良いのかとか、 それが多重度ということですね。 >ええと、Javaのようにイテレータの生成メソッドをコレクションに付けた上で、 >それぞれオーバーロードというか、別のクロージャを割り当てれば、if文は >出てこないのでは? おっしゃる通りだと思います。確かにJavaではそうなっていますし、 Javaのやり方は、うまいやり方だと思います。 Iterator(処理)は、ArrayList(データ)を知らないといけない訳ですし。 ただ、単一責任の原則というのがあって、1つのオブジェクト(クラス)は、 それぞれ1つの役割のみを持つようにするということで、 Iteratorの生成をArrayList自身に持たせるというのは、どうなのでしょうか？ ただ逆に、生成部分を他に分けたからといってメリットがあるわけではないですし、 むしろ、ArrayList自身に持たせてしまった方がすっきりする気がします。 ただ、Javaの設計がベストなのかは分かりません。 あと、「プログラミング言語を作る」が書籍化されることを期待しています。 ありがとうございました。

>ところでこれって、(ぱ)さんの言われているマルチプルインスタンスの問題ですか？ この部分にレスつけ忘れてました。 本質的には同じことですよね。多重度の問題。UMLで「0..*」とか書くやつです。 先のタイガーさんの「方法1.」だと、コレクションが唯一のイテレータを 保持していると言えますから、多重度は1です。 コレクションそのものが複数作れますから、イテレータも複数作れるには 違いないけれど、ひとつのコレクションに対してはひとつだから先に書いたような 問題が発生します。 インスタンス自体がひとつしかないケースは、なんというか「地面」があって、 そこからそのオブジェクトに線が引いてあって、地面のところに「多重度1」の 指定があるようなイメージを持っています。私の場合。 で、その線の根元というのは要するにstaticな変数なのであって、 私はあまりたくさんのオブジェクトが地面にくくりつけられているモデルは 好きじゃないので、staticに冷淡だったりするわけです。

>あと方法2ですが、よく考えてみたらArrayとLinkedの区別をIteratorクラスに隠す >のは良くないですね。if～elseが出てくるので。 ええと、Javaのようにイテレータの生成メソッドをコレクションに付けた上で、 それぞれオーバーロードというか、別のクロージャを割り当てれば、if文は 出てこないのでは? ところで、現行の実装では、配列にはメンバを追加できないので、配列から イテレータを取得できるようにするにはeval.cをいじって「メソッドもどき」を 追加しなきゃいけないわけですが、まあこれはこれでいいんじゃないかと 私としては思っています。「すべてがオブジェクト」とか主張したいわけでは ないですので。

>これはまずいのでは。たとえば「コレクション中に同じ要素がないかどうか」を >二重ループでチェックするような場合、コレクションそのものが位置を保持していると >ひとつしか持てないので困ります。 確かにその通りですね。良くない設計ですね。 結局、外部Iteratorしかなさそうですね...。 ところでこれって、(ぱ)さんの言われているマルチプルインスタンスの問題ですか？ >方法2. Iteratorクラスを作る。ArrayクラスとLinkedクラスの区別は、 > Iteratorクラスの中に隠す。 > compare()に、Iteratorのインスタンスを渡す。 あと方法2ですが、よく考えてみたらArrayとLinkedの区別をIteratorクラスに隠す のは良くないですね。if～elseが出てくるので。 ArrayIteratorとLinkedIteratorの両方を用意して、利用者側(クライアント側)が それを使うしかないですね。クラスの生成部分を抽象化したければJavaみたいに Factoryで隠せば良いですので。 今回色々勉強になりました。ありがとうございました。

>はじめまして。 はじめまして... と言いつつ、TRIPLEさんのblogは少し前から読んでました。 「プログラミング言語を作る」でGoogleしたらひっかかりましたので (^^; # 書いた方としては反応が気になるわけです。やっぱり。 >"JavaScriptの実装に似ている" >という印象を受けましたが、"Hawksさん"のサイトも参考にされていたのですね。 です。あのページにはお世話になりました。 こういう、どちらかというとマイナーな機能をcrowbarに組み込むのは、 企画の趣旨的にどうかとも思いましたが(どうせ言語の作り方を説明するなら、 対象読者がいつも使ってる言語の方が目的が絞れるように思うので)、 Hawksさんのページを含め、JavaScriptについていろいろ調べてたら、 「うおお、これは作ってみたい」と思ったのでこうなりました。 それでは今後ともよろしくお願いいたします。

私は常々Javaとかで外部イテレータを使うたび、「めんどくせー」と思ってました。 なので、Ruby式のイテレータいいじゃん、と思っていましたが、 確かにkitさんのおっしゃるようなケースで困りますね。 (Javaのように)コレクションがIteratorを返すようになっていれば、 ライブラリ関数のforeachとクロージャで、C#のforeachみたいなものは作れるから、 その方面でいくのがよさそうですね。 >方法1. ArrayとLinkedの両方に共通なメソッドで、各要素を先頭から順に > 取り出せる関数(インターフェース)を定義する。 これはまずいのでは。たとえば「コレクション中に同じ要素がないかどうか」を 二重ループでチェックするような場合、コレクションそのものが位置を保持していると ひとつしか持てないので困ります。 コレクションにeachメソッドを付けるやり方では、位置を押さえているのは eachメソッドのローカル変数なので問題にならないですけど。

Rubyで、kitさんのcompare()メソッドを実装するにはどうすれば実現可能か考えてみました。 まず、Array(配列を表す)クラスの他にLinked(リンクリストを表す)クラスが あると過程して、この２つのクラス両方がcompare()に区別なく渡せるような実装を考えます。 方法1. ArrayとLinkedの両方に共通なメソッドで、各要素を先頭から順に 取り出せる関数(インターフェース)を定義する。 つまり、next()、isDone()、currentItem()を両方のクラスに実装する。 compare()に、ArrayやLinkedのインスタンスを渡し、 このメソッドを使って実装する。 方法2. Iteratorクラスを作る。ArrayクラスとLinkedクラスの区別は、 Iteratorクラスの中に隠す。 compare()に、Iteratorのインスタンスを渡す。 方法3. Linkedにも(Arrayクラスの様な)to_aメソッドを実装し、 to_aで、全要素を配列にして1つずつ比較。 私はあまりRubyに精通していないので、以上の単純な方法を考えました。 まず、方法3ですが、実現はできてもcompare()の実装の「ロジック」が ストレートな表現ではないため、良い方法とは思えません。同様に 特殊なことで実現できたとしても同じ意味で良くないです。 方法1は、「データ構造」クラスの中に(2つのクラスに共通な、つまり抽象的な) データのアクセサをつけることで実現します。 方法2は、kitさんと同様にIteratorクラスで表現する方法です。 方法1と方法2の比較ですが、どちらが良いのかは難しいですが、 Arrayクラスをあまりよごしたくないので、直感的にはIteratorクラスを 作成する方が良いように思えます。 >しかし、記述力というか、制御構造の自由度という点では >ArrayIterator 的なやり方の方が優れていますから、もしもどちらか その通りかもしれません。 >実際のところは、たいていの言語のコレクションライブラリが、each >メソッド式と、ArrayIterator 的方法の両方の機能を提供しているよ >うな気がします。 RubyはIteratorクラスがありません。observer(Observableモジュールを使う) とかはあるみたいなので、Iteratorも標準で入れて欲しいです。 >この場合、ArrayIterator() 式を外部 Iterator、each メソッド式を >内部 Iterator と呼んで区別するようです。 結局、データ構造のクラスの中に入れるか、別のクラスにするかという 感じでしょうか。 私もIteratorと言うと外部の方が思い浮かびます。Javaのイメージで。 crowbarは、Rubyのイメージだったので内部の方の実装をイメージしてました。

> GoF のデザインパターンをはじめ、Iterator という名称を用いた > 時には、ArrayIterator() が生成するような、繰り返し用のオブジェ > クトを指すことの方が多いんじゃないでしょうか。 念のため確認してみたんですが、GoF の場合、クラス図では ArrayIterator() 式のやり方しか記載してないんですが、 文章の方では、ruby の each メソッド式のやり方も紹介してました。 この場合、ArrayIterator() 式を外部 Iterator、each メソッド式を 内部 Iterator と呼んで区別するようです。 読んだのははるか昔なので、さっぱり忘れてました。 失礼しました。

> 利用者側がclosureを作るのが面倒というのは、 : > iterate()というメソッドの中にループ処理を隠している分、 > Iteratorを使うよりも記述はシンプルだと思います。 確かに、「面倒」というのは、あまり適切じゃない形容詞でしたね。 each メソッドのような方法は、できる能力が限られている分、むし ろArrayIterator 的なやり方よりも短い表現で済むのが (crowbar を 含めて) 普通だと思います。 > Iteratorのご紹介ありがとうございます。ただIteratorは良い方法 > だと思いますが、Array自身にeachメソッドを付ける方法とどちら > が良いかはよく分かりません。 誤解を与えて申し訳ないです。Ruby でいう each メソッドのような 方法が悪いと言ってるわけではありません。each メソッド式のやり 方で十分な場合は、記述が短いという点で優れているわけですから、 そちらを使った方がいいことの方が多いでしょう。 しかし、記述力というか、制御構造の自由度という点では ArrayIterator 的なやり方の方が優れていますから、もしもどちらか 片方だけしか提供しないから選べと言われたら、ArrayIterator 的方 法がいいんじゃないでしょうか。 実際のところは、たいていの言語のコレクションライブラリが、each メソッド式と、ArrayIterator 的方法の両方の機能を提供しているよ うな気がします。 ただ、Iterator という言い方をした時に、each メソッドのような 方法が最初に出てくることには若干違和感があります。 GoF のデザインパターンをはじめ、Iterator という名称を用いた時 には、ArrayIterator() が生成するような、繰り返し用のオブジェク トを指すことの方が多いんじゃないでしょうか。

はじめまして。 "プログラミング言語を作る"の"オブジェクトとクロージャ"の実装を見て "JavaScriptの実装に似ている" という印象を受けましたが、"Hawksさん"のサイトも参考にされていたのですね。 私もJavaScriptの変数のスコープや配列の機能、"functionの使い方"で悩んでいたときに、"Hawks"のサイトをみて疑問が解消されましたし。 JavaScriptは"小技集"みたいなサイトはたくさんあるのですが、"言語仕様"をわかりやすく解説したサイトはあまりなく、とても重宝しています。 そういえば、JavaScriptも型のない言語なのですが、他の人が書いたソースをデバックしているときキレそうになったことがあります。 その人が書いたソース、コメントが何一つなく、関数の引数に何を渡しているのかさっぱりわかりませんでしたから。 その時、"Javaの謎+落とし穴"の"Javaにgenericがないのは欠陥だ"という意味が実感できたような気がしますが(笑)

>えーと、iterator は、iterator 自体がオブジェクトであるような >作りにした方が便利だと思います。iterator を利用する側が >必ず closure を作るのは面倒くさいですし、なにより、 利用者側がclosureを作るのが面倒というのは、Ruby風の a1.iterate() { |i| print("" + i + " "); } という書き方ができないからであって、iterate()というメソッドの 中にループ処理を隠している分、Iteratorを使うよりも 記述はシンプルだと思います。 ただ逆に、慣れてないとループしているというのが分かりづらくなっています。 >複数のコレクションを、複数の iterator を使って同時に並行して >アクセスするようなプログラム、たとえばコレクションどうしの >大小比較: >function compare(i, j) { ... >} >print(compare(ArrayIterator(a), ArrayIterator(b)) + "\n"); >みたいなことをしようとすると、eachメソッド方式では困っちゃいます。 Iteratorのご紹介ありがとうございます。ただIteratorは良い方法だと思いますが、 Array自身にeachメソッドを付ける方法とどちらが良いかはよく分かりません。 Arrayみたいな「データ構造」を表すクラス(もどき)にリスト(の要素)をイテレートするという 「処理」を表すメソッドを持たせるのは、真面目に考えればよくないのかもしれませんが、 頻繁にでてくる処理なので、Arrayに持たせるのはバランス的に自然なのかもしれません。 ただ、compare()みたいなのをどう表現するのかは、調べてみます。 (ぱ)さんへ >ひとつのクラスのconstructorで10個のpointが作られた時、 >「クラスフィールド」はひとつしかないので、ただのインスタンス変数とは違うでしょう。 よく考えたらその通りでした。すいません。 closureの特性をうまく利用した方法だと思います。

取り急ぎ。 >で、コンパイルしてみると、 >1. 単項の「!」演算子がない。(これは欲しいです) >2. C言語の「,」演算子がないので、for 文の3番目の項の > 「i.next(), j.next()」でエラー ... >実行すると > 33:面面面面民藥算劼boolean型には使えません。 >となります。これはなぜでしょうね。 これは、エラーメッセージ生成部分がバグっているようで、本来は 「33:==はboolean型には使えません。」 と出るべきものです(メッセージの可変部が先頭にあるとだめらしい)。 で、==がなぜbooleanに使えないかというと、単に実装してないためです(^^; eval.cのeval_binary_booleanにelse ifを書き足すだけのはずですが、 すみません忘れてました。 http://kmaebashi.com/programmer/devlang/crowbar_src_0_3/S/10.html#280 booleanの比較なんてそうそうするもんじゃない、という考え方もありますが、 その上単項の!もないのではどないせいっちゅうんだ、という話ですね。 いろいろ仕様のポカ、テスト漏れがありましてすみません。次バージョンで直します。 報告ありがとうございました。

いろいろ訂正… > で、コンパイルしてみると、 「コンパイルしてみる」じゃなくて「実行してみる」ですね。(^^;) コンパイラ言語ばかり使っている癖でつい… > this.next = closure() { this.index = this.index++; }; ここは編集間違いで this.next = closure() { this.index++; }; でした。 あと、this.theArray と this.index をユーザに公開するのは 良くないので、ArrayIterator() の実装は function ArrayIterator(anArray) { this = new_object(); index = 0; this.first = closure() { index = 0; }; this.next = closure() { index++; }; this.isDone = closure() { return index >= anArray.size(); }; this.currentItem = closure() { return anArray[index]; }; return this; } とした方がいいですね。 > 実行すると > 33:面面面面民藥算劼boolean型には使えません。 > となります。これはなぜでしょうね。 これは調べてません。

> と、ここまで書いて、実際に動作するプログラムかどうか試そうとしたら、 > 文法エラーになっちゃいました。 実装をちらっと見たら、すぐ原因が分かりました。 最新版である crowbar 0.3 ではなくて、crowbar 0.1.01 を使っていた のが原因でした。(大汗;;;) 大変失礼しました。 http://kmaebashi.com/programmer/devlang/index.html のページに、最新版への配布ページへのリンクがあると、 多少はこういう間違いが減るかもしれません… で、コンパイルしてみると、 1. 単項の「!」演算子がない。(これは欲しいです) 2. C言語の「,」演算子がないので、for 文の3番目の項の 「i.next(), j.next()」でエラー 3. closure() への代入文で「;」を忘れていた といった問題がありました。 直してみたものが以下の通りなんですが、 実行すると 33:面面面面民藥算劼boolean型には使えません。 となります。これはなぜでしょうね。 function ArrayIterator(anArray) { this = new_object(); this.theArray = anArray; this.index = 0; this.first = closure() { this.index = 0; }; this.next = closure() { this.index = this.index++; }; this.isDone = closure() { return this.index >= this.theArray.size(); }; this.currentItem = closure() { return this.theArray[this.index]; }; return this; } function compare(i, j) { while (i.isDone() == false && j.isDone() == false) { if (i.currentItem() < j.currentItem()) { return -1; } if (i.currentItem() > j.currentItem()) { return 1; } i.next(); j.next(); } if (i.isDone() && j.isdone()) { return 0; } if (i.isDone()) { return -1; } else { return 1; } } a = {1, 2, 3, 4, 5, 6, 7, 8}; for (i = ArrayIterator(a); i.isDone() == false; i.next()) { print("" + i.currentItem(), " "); } print("\n");

> >あと、制御構造の抽象化としてiteratorのようなものを表現する場合、 > >Ruby(のeachメソッド)みたいにクロージャをメソッドに渡す形でサンプルを > >書いてみたのですが、 > >もっとうまいやり方がありますか？ > これでよいのではないでしょうか。 えーと、iterator は、iterator 自体がオブジェクトであるような 作りにした方が便利だと思います。iterator を利用する側が 必ず closure を作るのは面倒くさいですし、なにより、 複数のコレクションを、複数の iterator を使って同時に並行して アクセスするようなプログラム、たとえばコレクションどうしの 大小比較: function compare(i, j) { for (; !i.isDone() && !j.isDone(); i.next(), j.next()) { if (i.currentItem() < j.currentItem()) return -1; if (i.currentItem() > j.currentItem()) return 1; } if (i.isDone() && j.isdone()) return 0; if (i.isDone()) return -1; else return 1; } print(compare(ArrayIterator(a), ArrayIterator(b)) + "\n"); みたいなことをしようとすると、eachメソッド方式では困っちゃいます。 なので、たぶん次のような設計の方がいいと思います。 function ArrayIterator(anArray) { this = new_object(); this.theArray = anArray; this.index = 0; this.first = closure() { this.index = 0; } this.next = closure() { this.index++; } this.isDone = closure() { return this.index >= this.theArray.size(); } this.currentItem() = closure() { return this.theArray[this.index]; } return this; } と、ここまで書いて、実際に動作するプログラムかどうか試そうとしたら、 文法エラーになっちゃいました。UNIX版をコンパイルしてみたんですが、 次のような1行だけのプログラムで a = {1,2}; 1:文法エラー({付近) となります。 また、次のような2行だけのプログラムでも a = new_object(); a.hoge = 1; 2:不正な文字(.) となります。 crowbarの実装の中身は全然見てないんですが、UNIX版だけの問題なんでしょうか？

>>うーん、私が狙ったのは、複数のpointオブジェクトから共通に参照できる >>ひとつのクラスフィールド、です。 ... >それだとprivateなインスタンス変数な気がします...。間違ってたらすいません。 ひとつのクラスのconstructorで10個のpointが作られた時、 「クラスフィールド」はひとつしかないので、ただのインスタンス変数とは違うでしょう。 >あと、制御構造の抽象化としてiteratorのようなものを表現する場合、 >Ruby(のeachメソッド)みたいにクロージャをメソッドに渡す形でサンプルを >書いてみたのですが、 >もっとうまいやり方がありますか？ これでよいのではないでしょうか。私もやるとすればこういう形だと思っていました。 >あと、C#のforeachやJava5の拡張forのようなものを実装する予定はありますか？ 予定は未定ですが、文法としてそういうものを実装するつもりはありません。 言語仕様がライブラリに依存するのはあまり美しくないと思っていますので。

>うーん、私が狙ったのは、複数のpointオブジェクトから共通に参照できる >ひとつのクラスフィールド、です。 >まあ、create_point_class()を複数回呼んでしまえば複数作れてしまいますが、 >それは利用者側の問題にしてよいのではないかと。 それだとprivateなインスタンス変数な気がします...。間違ってたらすいません。 但し、パフォーマンスはともかく、利用者側から見れば、 やりたいことは実現できますので現時点では十分かもしれません。 >あくまで「静的な」(ひとつしかない)データが、グローバル変数以外の方法で必要だ、 >ということであれば、Cのstatic指定したローカル変数のようなものを付けると >いうのはひとつの手かもしれませんが。 staticのローカル変数でも実現可能ですね。どう設計するかですね。 あと、制御構造の抽象化としてiteratorのようなものを表現する場合、 Ruby(のeachメソッド)みたいにクロージャをメソッドに渡す形でサンプルを書いてみたのですが、 もっとうまいやり方がありますか？ あと、C#のforeachやJava5の拡張forのようなものを実装する予定はありますか？ function Array(arr_data) { this = new_object(); this.arr_data = arr_data; this.iterate = closure(c) { for (i = 0; i < this.arr_data.size(); i = i + 1) { c(this.arr_data[i]); } }; return this; } a = {1, 2, 3, 4, 5, 6, 7, 8}; c1 = closure(i) { print("" + i + " "); }; a1 = Array(a); a1.iterate(c1);

>>ずいぶん昔、私もマルチスレッドではないのですが、複数のCPUで一つのデバイスに >>アクセスするようなプログラムではまったことがあって、その原因はこんな行でした。 >> x |= y; >なんかモロにマルチスレッドのように思うんですが… (^^; 全く異なる複数のCPU上で動作する2つのプロセスが同じリソースにアクセスする様なものも「マルチスレッド」と言うのかどうか、ちとわからんのですが、 >でも、組み込みなどだとまた事情が違いそうですね。 組み込みの癖に複数のCPUがあるなんていう贅沢な組み込み環境なのですが、複数のCPUがあるくせに排他制御や割り込みをあげるハードウエアがプア...というか、存在しなくて(CPUは汎用品だけど、CPU間をつなぐ部分が社内製だった)、しかたなく同時にアクセスできるメモリにフラグを立てる形で実現していたとかいう状況だったりします。 で、フラグが何種類か必要なので、ビット対応にした(だからORしてる)というなんとも間抜けな設計でスタートしていて。 そもそも通信をガシガシやる部分だったので「ほとんどの情報は共有されてる」ために「複数のスレッドで共有するオブジェクトを限定する」っていうのは意味がなくて「入り口に管理用のオブジェクトを置くとかしてちゃんと管理する」のまさに管理用のオブジェクトが、こんなのだったんですね。あのころは若かったと言い訳して...(^^;)

>ずいぶん昔、私もマルチスレッドではないのですが、複数のCPUで一つのデバイスに >アクセスするようなプログラムではまったことがあって、その原因はこんな行でした。 > > x |= y; なんかモロにマルチスレッドのように思うんですが… (^^; これぐらいミクロなレベルでバグを入れてしまうと、もうたいていはデバッグどころか 再現するのも不可能でどうしようもなくなりますから、Webアプリケーションなんかでは、 ・そもそも複数のスレッドで共有するオブジェクトを限定する。 ・それでも共有するオブジェクトは、入り口に管理用のオブジェクトを 　置くとかしてちゃんと管理する。 ってことだと私は思っています。 でも、組み込みなどだとまた事情が違いそうですね。

>ソースの5行目は、 >this.constructor = closure() { >でなく、 >class.constructor = closure() { >だと思います。 です。すみません間違えました。 あと、「closure(x, y) {」のように引数が必要ですね。 >上のコードでは、new_object()でオブジェクトを作成しないと >「#このへん」の変数を参照できないと思いますので、 >結局インスタンス変数に見えるような気がします。 うーん、私が狙ったのは、複数のpointオブジェクトから共通に参照できる ひとつのクラスフィールド、です。 まあ、create_point_class()を複数回呼んでしまえば複数作れてしまいますが、 それは利用者側の問題にしてよいのではないかと。 あくまで「静的な」(ひとつしかない)データが、グローバル変数以外の方法で必要だ、 ということであれば、Cのstatic指定したローカル変数のようなものを付けると いうのはひとつの手かもしれませんが。

こんにちは。 >「今の(crowbarの)仕様」ということだと、そもそもクラスがないのに、 >クラスメソッド、クラス変数とは何ぞや? という話になるかと思いますが、 確かにその通りですね。クラス「らしきもの」ですね。 >function create_point_class() { > class = new_object(); > # このへん > > this.constructor = closure() { > this = new_object(); > this.x = x; > this.y = y; > > this.print = closure() { > print("(" + this.x + ", " + this.y + ")\n"); > }; > … > return this; > }; > return class; >} > >とか書けばできそうに思うのですが、どうでしょうか(すみません試してないです)。 >「#このへん」で作ったローカル変数や、ローカル変数に代入したクロージャは、 >コンストラクタの中で定義されているメソッドからだけ参照できるはずです。 ソースの5行目は、 this.constructor = closure() { でなく、 class.constructor = closure() { だと思います。 上のコードで名前空間らしきものが表現できているように思いますが、 私の考えていたのは、オブジェクトを作らないでグローバルと名前空間が違う、 でも静的な寿命を持つ変数が使えるかを考えていました。 上のコードでは、new_object()でオブジェクトを作成しないと 「#このへん」の変数を参照できないと思いますので、 結局インスタンス変数に見えるような気がします。 >私としては、クラス変数やクラスメソッドというものに、わざわざ言語仕様で >対応するだけの価値を感じていません。 >crowbarにはそもそもクラスがないですが、クラスベースのOO言語を作るとしても、 >クラス変数やクラスメソッドはつけず、グローバル変数のようなものにして、 >名前空間を選択的に開示できるような形にすると思います。 たぶんその辺は言語の特徴になってくると思いますので、クラス変数らしきものを どう表現するのか(あるいはしないのか)は難しいかもしれません。 ただ、Javaとかに慣れているとクラス変数はストレートで分かりやすい気がします。

>◎getとsetが分かれていたり… ～中略～ >ふたつのスレッドA, Bが以下のようにxをインクリメントしようとすると、 > x = p.getX(); // スレッドA ←(1) > x = p.getX(); // スレッドB ←(2) > p.setX(x+1); // スレッドA ←(3) > p.setX(x+1); // スレッドB ←(4) ～中略～ >結局、マルチスレッドで正しくプログラムを動かしたいのであれば、 >Pointのような低レベルなクラスで、個々のメソッドに機械的にsynchronizedを >つけても意味がなく、アプリケーションのレベルで対処しなければなりません。 ～中略～ >あんまり理解されてないことなんですかねえ。 こういうのって、マルチスレッド プログラムで再現性の低いバグで悩んだ経験がないとなかなか思いつかないことかもしれませんね。 ずいぶん昔、私もマルチスレッドではないのですが、複数のCPUで一つのデバイスにアクセスするようなプログラムではまったことがあって、その原因はこんな行でした。 x |= y; xの値をCPUレジスタに読み出して、その値にyの値を加えたものを、xに書き込む...前に別のCPUからxに書き込みがあったんです。 このときは高い確率で再現できるプログラムが偶然用意できたのが幸いでしたが。

>「プログラミング言語を作る」をいつも楽しみにしています。 ありがとうございます。 >クラスメソッドとクラス変数は、今の仕様で実現は可能ですか？ 「今の(crowbarの)仕様」ということだと、そもそもクラスがないのに、 クラスメソッド、クラス変数とは何ぞや? という話になるかと思いますが、 現在、create_point()のような関数を作ることでクラスじみたことを 実現しているように、何とか似たことを実現したい、ということであれば、 「クラスもまたオブジェクトである」 「インスタンスは、クラスのconstructorメソッドで生成する」 ということにして、 function create_point_class() { class = new_object(); # このへん this.constructor = closure() { this = new_object(); this.x = x; this.y = y; this.print = closure() { print("(" + this.x + ", " + this.y + ")\n"); }; … return this; }; return class; } とか書けばできそうに思うのですが、どうでしょうか(すみません試してないです)。 「#このへん」で作ったローカル変数や、ローカル変数に代入したクロージャは、 コンストラクタの中で定義されているメソッドからだけ参照できるはずです。 >また、実現不可能な場合、追加の仕様としてはどういうのを考えていますか？ >グローバル変数で代用するのはちょっと…と思います。 私としては、クラス変数やクラスメソッドというものに、わざわざ言語仕様で 対応するだけの価値を感じていません。 crowbarにはそもそもクラスがないですが、クラスベースのOO言語を作るとしても、 クラス変数やクラスメソッドはつけず、グローバル変数のようなものにして、 名前空間を選択的に開示できるような形にすると思います。

こんにちは。 「プログラミング言語を作る」をいつも楽しみにしています。 個人的には、オブジェクトとクロージャ辺りからだんだん面白くなってきたと思います。 まだ機能的に色々追加していくのだと思いますが、クラスメソッドとクラス変数は、今の仕様で実現は可能ですか？色々考えたのですが、思いつきません。 また、実現不可能な場合、追加の仕様としてはどういうのを考えていますか？ グローバル変数で代用するのはちょっと…と思います。

>こんにちは。はじめまして。 はじめまして。書き込みありがとうございます。 >もしよろしければ、可能性として起こりうる"変なこと"をご教示願えませんでしょうか？ >getとsetが分かれていたり、setのXとYが分かれていたりしていたのでは、 というのが一応ヒントというか根拠のつもりです。 簡単な方から。 ◎setのXとYが分かれていたりしていたのでは… 現在(100, 100)であるPointを、(200, 200)に移動させたかったとしましょう。 そのために、 p.setX(200); p.setY(200); と書くと、setX()してからsetY()するまでの間、一時的に(200, 100)という状態になり、 この状態が他スレッドから見えてしまいます。 ◎getとsetが分かれていたり… ふたつのスレッドA, Bが以下のようにxをインクリメントしようとすると、 x = p.getX(); // スレッドA ←(1) x = p.getX(); // スレッドB ←(2) p.setX(x+1); // スレッドA ←(3) p.setX(x+1); // スレッドB ←(4) (3)でスレッドAがインクリメントした結果が(4)で上書きされてしまい、 ふたつのスレッドがひとつずつインクリメントしているはずなのに、 結局xは1しか増えないことになります。 ひとつめの問題は仕様だと言い張ることも可能かもしれませんが、 ふたつめの問題はおそらく致命的でしょう。 結局、マルチスレッドで正しくプログラムを動かしたいのであれば、 Pointのような低レベルなクラスで、個々のメソッドに機械的にsynchronizedを つけても意味がなく、アプリケーションのレベルで対処しなければなりません。 この手の問題は標準のクラスライブラリにもあって、古いコレクションクラス (Vectorなど)は、メソッドごとにちまちまとsynchronizedを付けていますが、 現実問題としてこれは無意味であり、後継のArrayListなどでは外されたわけです。 // ループが回っている間に別スレッドでremove()とかされると例外が発生する size = v.size(); for (int i = 0; i < size; i++) { Object o = v.get(i); } でも今Googleしてみたら、「シングルスレッドでよいときは効率向上のために ArrayListを使い、スレッドセーフにしたければVectorを使うべし」と解説している ページの多いこと… あんまり理解されてないことなんですかねえ。

こんにちは。はじめまして。 楽しく拝読させて頂いております。 「オブジェクト指向再入門/なぜわからなくなってしまうのか？」の中の記述に判らないところがありましたのでご質問させてください。 ～引用ここから～ ところで「Javaの格言」という本では、 Pointのx, yをprivateにするメリットとして、マルチスレッド時の排他制御を挙げています。しかし、getX(), getY(), setX(), setY() を作ってそれぞれをsynchronizedにしたところで、この仕様ではマルチスレッドには対応できません。ちょっと考えてみればわかるように、 getとsetが分かれていたり、setのXとYが分かれていたりしていたのでは、複数のスレッドで実行されたら結局変なことが起きます。 ～引用ここまで～ synchronizedメソッドをコールすると、コールしたスレッドがインスタンス(メソッドのレシーバ)のモニタを取得するために、別スレッドが当該インスタンスのsynchronizedメソッドを呼び出しても安全(スレッドセーフ)であると認識しております。 上記の引用のなかの"変なこと"というのが、私の認識であるところの"スレッドセーフ"でないことを指すのか、または別のことを指すのか判りませんでした。 もしよろしければ、可能性として起こりうる"変なこと"をご教示願えませんでしょうか？ よろしくお願いします。

はじめまして。 >前橋さんのリンク先にある >「中野康明の雑学ペ－ジ(2003/11/30追加)」 >は下記に移動しました。 わざわざご連絡いただきありがとうございます。修正しておきました。

前橋さんのリンク先にある 「中野康明の雑学ペ－ジ(2003/11/30追加)」 は下記に移動しました。 http://www001.upp.so-net.ne.jp/yasuaki/misc.htm その関連で引かれている「チョン」についての雑文のページも移動しました。 http://www001.upp.so-net.ne.jp/yasuaki/misc/lang/lang35.htm 修正戴ければ幸いです。

>これは、「Linkable」の定義に対する修正ですから、ひとつめの方です。 >Linkableは、その前のページのFig.5-15におけるLinkableShapeに対応する型で、 >ポインタを3つ持ち、双方向連結リストを構成します。 > >こちらは、双方向連結リストの先頭と末尾を保持することで、「リスト全体」を >表現する構造体です。 > これらが間違っていないのであれば、 私の勉強不足だとわかりました。 じっくりと勉強していきます。 >int a; >int *p; >p = &a; > >とあったとき、pに1加算するだけなら問題ないが、2加算すると規格違反である、 >という意味です。 ># ただし、たいていの処理系では、2だろうと3だろうと、加算するだけなら動きます。 わかりました。 ありがとうございました。

>>まず、「クラスのポインタ」が何を指すのか不明です。 >「Board* board = new Board()」の様にnewしたポインタ変数の事です。 クラスとインスタンスは別物なので、その違いは強く意識したほうがよいかと。 new Board()ではBoardクラスのインスタンスが生成(new)され、 「new Board()」という式はそのインスタンスへのポインタを返します。 上の「board」にはそれが代入されるわけですから、boardは、 インスタンスへのポインタであって、「クラスのポインタ」ではありません。 また、「newしたポインタ変数の事です」とのことですが、上の例にある ポインタ型の変数といえば「board」ですが、ここではboardがnewされている わけではありません。 細かいことを言うようですが、 「わかっている人が、厳密さを求められない局面で、適当に省略しながら話す」 のと、 「本当にわかってない」 のでは大違いですので一応念のため。 >僕の憶測ですが、Javaのリバーシゲームでthisを多用していますが、 >これは特に使用しなくていいんですね。 はい。インスタンスフィールドとローカル変数の区別をつけるため、 私はthis.をつけるようにしている、というだけです。 言語がthisを強制していてくれれば、こういう事故も起きないんですけどねえ。 http://d.hatena.ne.jp/higepon/20050329

>こんにちは、はじめまして。 はじめまして。ミスが多く申し訳ありません。 >「 >p.285 >誤 > > typedef struct Linkable_tag { > void *object; > Shape *prev; > Shape *next; > } Linkable; > >正 > > typedef struct Linkable_tag { > void *object; > struct Linkable_tag *prev; > struct Linkable_tag *next; > } Linkable; >」 >とあります。 >しかし、P285にあるプログラムは２つあるのですが、 これは、「Linkable」の定義に対する修正ですから、ひとつめの方です。 Linkableは、その前のページのFig.5-15におけるLinkableShapeに対応する型で、 ポインタを3つ持ち、双方向連結リストを構成します。 >となっていて、２つめは >「 >typedef struct{ > Linkable *head; /* 先頭の要素 */ > Linkable *tail; /* 末尾の要素 */ >}LinkedList; >」 こちらは、双方向連結リストの先頭と末尾を保持することで、「リスト全体」を 表現する構造体です。 >それと、P43のところで、正誤表では、 >「 >と書いてありますので、ふたつ超えた所に向けない限り問題なさそうです。 >」 >となっていますが、本では、 >「 >と書いてありますので、２以上加算しないかぎり問題なさそうですが。 >」 >とあります。 同じ意味のつもりで書いていますが… int a; int *p; p = &a; とあったとき、pに1加算するだけなら問題ないが、2加算すると規格違反である、 という意味です。 # ただし、たいていの処理系では、2だろうと3だろうと、加算するだけなら動きます。

>「静的コール」というのが何を指しているのかわかりませんが、 「Board::move(～)」の様な呼び出しの事を指しています。名称は間違ってるかも知れません。 >まず、「クラスのポインタ」が何を指すのか不明です。 「Board* board = new Board()」の様にnewしたポインタ変数の事です。 「オブジェクトに仕事をさせる、ということ」を読ませて貰って、上記の様に一々ポインタ変数をnewせずにパラメータにポインタ変数を持たせて引き継がせればいい事が分かりました。 僕の憶測ですが、Javaのリバーシゲームでthisを多用していますが、これは特に使用しなくていいんですね。 現在、はさみ将棋プログラムに修正をかけていますが、まだまだメモリリークが起きている状態です。 指摘された修正をほぼ全て行なってメモリリークが起きるかどうかテストしたいと思います。 ご回答の程ありがとうございました。

こんにちは、はじめまして。 早速ですが、「C言語 ポインタ 完全制覇」を購入して 読んでいるのですが、正誤表を見てみると、 「 p.285 誤 typedef struct Linkable_tag { void *object; Shape *prev; Shape *next; } Linkable; 正 typedef struct Linkable_tag { void *object; struct Linkable_tag *prev; struct Linkable_tag *next; } Linkable; 」 とあります。 しかし、P285にあるプログラムは２つあるのですが、 １つめは、 「 typedef struct{ void *object; Shape *prev; Shape *next; }Linkable; 」 となっていて、２つめは 「 typedef struct{ Linkable *head; /* 先頭の要素 */ Linkable *tail; /* 末尾の要素 */ }LinkedList; 」 となっていてどこをどのように訂正すればいいかわかりません。 それと、P43のところで、正誤表では、 「 と書いてありますので、ふたつ超えた所に向けない限り問題なさそうです。 」 となっていますが、本では、 「 と書いてありますので、２以上加算しないかぎり問題なさそうですが。 」 とあります。 どちらが正しいのでしょうか？ すべてをみたわけではありませんので、ほかはどうなっているのかわかりません。 出版は平成１５年７月１日　初版　第７刷発行です。

>VC++はメソッドの静的コールをしようとすると怒られるので、 「静的コール」というのが何を指しているのかわかりませんが、 staticメソッド以外は、インスタンスがなければ呼び出すことはできないでしょう (Javaと同じです)。 >メソッドを呼び出す場合、そのクラスのポインタをnewしてますが、 >それがマズイ様です。 まず、「クラスのポインタ」が何を指すのか不明です。 Boardなりのクラスの「インスタンスのポインタ」の意味であるとすれば、 「メソッドを呼び出す場合、そのクラスのポインタをnewしてます」 というのは、私がこっちのページに書いた新人君の失敗と同じ失敗を しているように見えます。 http://kmaebashi.com/programmer/object/shigoto.html | そして、とある新人君は、(AWTの)Canvasに線を引きたい、という時、 | その場でCanvasをnewしてそのCanvasに線を引いてくれました。 | もちろんそのCanvasと、実際に画面に貼られているCanvasは違う | Canvasですから、画面に線は表示されず、彼は悩んでいたわけです。 | また別の新人君は、描画した図形を保持する「ShapeCollection」という | クラスについて、画面の再描画のため必要になったところでいきなりnewして | くれました。当然、新たに作り出されたShapeCollectionは空っぽなので、 | 画面には何も描画されませんでしたけど ※4。 手前味噌ですが、一度通して読んでみてはいかがでしょうか。 >クラスのポインタ変数を使用せずにこのプログラムを構築することは >出来るのでしょうか。 インスタンスへのポインタを使わずにこのプログラムを構築することは、 対戦用のBoardを静的に1個だけ持つようにして、先読み用のBoardを スタックに確保するようにすれば、不可能ではないでしょう。 でも、「対戦用のBoardを静的に1個だけ持つ」というのではせっかくの OO言語のメリットを捨てることになるので、あまりお勧めはしません。

指摘のあったcppをインクルードするのをやめ、プレイヤーもBoardのポインタを持つ様にしたのですが、メモリリークを起こしてしまってます。 VC++はメソッドの静的コールをしようとすると怒られるので、メソッドを呼び出す場合、そのクラスのポインタをnewしてますが、それがマズイ様です。 クラスのポインタ変数を使用せずにこのプログラムを構築することは出来るのでしょうか。 ご回答の程よろしくお願いします。

はじめまして。 >「配列とポインタの完全制覇」のページを見ていたところ、 >“技術評論社さんによる書籍案内はこちら”のリンク先が移動しているようです。 ご指摘ありがとうございます。修正しました。 センス・オブ・プログラミング以外すべて貼り替えですね。 # ASPをPHPに切り替えたのか…

「配列とポインタの完全制覇」のページを見ていたところ、 “技術評論社さんによる書籍案内はこちら”のリンク先が移動しているようです。 http://www2.gihyo.co.jp/books/bookinfo.asp?ID=4-7741-1142-2 だったのが、 http://www.gihyo.co.jp/books/syoseki.php/4-7741-1142-2 に、移動したようですね、、、

>>ところで、「配列とガベージコレクタ」の「配列は参照型である」の説明で、 >>コードと図の配列の添字の値が食い違っているみたいです。 修正しました。 ついで…と言ってはなんですが、[329]で教えていただいた「ほげほっぽ」の件を、 「ほげを考えるページ」に追記しました。すっかり忘れていまして、対応が 遅くなりまして申し訳ありません (_o_)

>オレンジニュースというサイトで、crowbarが紹介されていました。 > >http://secure.ddo.jp/~kaku/tdiary/20050426.html 情報ありがとうございます…が、さっきから試してますが、あっちのサーバが コケてるようですね。 >ところで、「配列とガベージコレクタ」の「配列は参照型である」の説明で、 >コードと図の配列の添字の値が食い違っているみたいです。 ご指摘ありがとうございます。 すみません、ちょっと今すぐは直せないので、連休に入ったら修正しておきます。 # 私も「1から数える」呪縛から開放されてないようです。

オレンジニュースというサイトで、crowbarが紹介されていました。 http://secure.ddo.jp/~kaku/tdiary/20050426.html > ■ 前橋和弥氏、新プログラミング言語「crowbar」を作る(現在ver.0.2) > http://kmaebashi.com/programmer/devlang/index.html ところで、「配列とガベージコレクタ」の「配列は参照型である」の説明で、 コードと図の配列の添字の値が食い違っているみたいです。

>C++ は「必ずしもオブジェクト指向である必然が無い言語」ですからね。 >better C として使っても一向に構わないわけで。 > >template なんかも「オブジェクト指向」とはまったく反対方向からの >generic programming を目指す代物ですし。 > >std::vector<char> v; >std::copy(std::istreambuf_iterator(is), std::istreambuf_iterator(), std::back_inserter(v)); >とかなんとか。 >ジェネリック関数＋ジェネリック部品、ってのはオブジェクト指向とは言いがたいし。 なるほど。あまり意識してなかったのですが、genericの機能は、オブジェクト指向とはあまり関係ないのかもしれませんね。 上記のリストのデータをトラバースするのにiteratorを使うのは、少なからずオブジェクト指向的であると思いますが、「genericの機能の部分」がオブジェクト指向であるとは言えないかもしれません。 でも、オブジェクト指向と連携すると強力な機能だと思います。 774RRさんのご指摘のように、オブジェクト指向を意識しない使い方でも、C++はかなり使えそうですね。 逆に私は、例えばCを使うときにはモジュール化を意識して、オブジェクト指向風なプログラミングをしています。

C++ は「必ずしもオブジェクト指向である必然が無い言語」ですからね。 better C として使っても一向に構わないわけで。 template なんかも「オブジェクト指向」とはまったく反対方向からの generic programming を目指す代物ですし。 std::vector<char> v; std::copy(std::istreambuf_iterator(is), std::istreambuf_iterator(), std::back_inserter(v)); とかなんとか。 ジェネリック関数＋ジェネリック部品、ってのはオブジェクト指向とは言いがたいし。

>Ｃ言語上級ＰＧですが、ＶＣ＋＋を使い始め、オブジェクト指向のさわりを勉強して >いる最中ですが、今までなかなか理解できませんでしたが、こちらのホームページを >穴が開くほど見つめて（＝読んで）みたところ、一行一行、激しく首を振りながら、 >やっと理解し始めました。同時に、今まで読んでいた入門書、解説書等に腹が立って >きました。ただし、もう、それらの入門書、解説書を読んでもすらすらと読めるよう >になると思います。ありがとうございます。 C++関連の書籍では、オブジェクト指向の考え方を分かりやすく解説した本があまりありません。 どちらかと言うと、文法や実装面での解説の本が多いような気がします。 余計なお世話かもしれませんが、オブジェクト指向の基本を勉強したいのであれば、C++でもJavaでもオブジェクト指向の知識は同じなので、(ぱ)さんの書かれた、「Java謎+落とし穴徹底解明」をお勧めします。この本は、実装は確かにJava言語ですが、オブジェクト指向の基本的な考え方を扱っていると思います。 例えば、「Effective C++」では、オブジェクト指向を体系的に解説していないため、オブジェクト指向の基本を身につけるのは難しいかもしれません。 GoF本でも同様だと思います。 ちなみに、匿名さんが読まれた入門書、解説書は何というタイトルの本ですか？

Ｃ言語上級ＰＧですが、ＶＣ＋＋を使い始め、オブジェクト指向のさわりを勉強して いる最中ですが、今までなかなか理解できませんでしたが、こちらのホームページを 穴が開くほど見つめて（＝読んで）みたところ、一行一行、激しく首を振りながら、 やっと理解し始めました。同時に、今まで読んでいた入門書、解説書等に腹が立って きました。ただし、もう、それらの入門書、解説書を読んでもすらすらと読めるよう になると思います。ありがとうございます。

>ｈｈ なんでしょう。これ。 テスト書き込みならテスト用掲示板のほうにお願いします。 http://kmaebashi.com/bbs/list.php?boardid=testbbs

ｈｈ

ｈｈ

>>>この4/1に発表されたPhthonのエイプリルフールネタ >>空白文字の使い方に厳しい「新言語」が出来たのか！と思ってしまうまでした。 修正しました。 ううう。typoをネタにされてしまった… (;_;) 関係ないけど「思ってしまうま」でGoogleすると結構ひっかかりますね。 「思ってしまう。ま、…」ってのも多いですけど。 >新言語ってわけでもなさそうですよ。 > Phthon >http://www.google.co.jp/search?q=Phthon&start=0&start=0&hl=ja&lr=lang_ja&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:ja-JP:official とまあこのように誰にもでもあるポカということでひとつ。

>>この4/1に発表されたPhthonのエイプリルフールネタ >空白文字の使い方に厳しい「新言語」が出来たのか！と思ってしまうまでした。 > 新言語ってわけでもなさそうですよ。 > Phthon http://www.google.co.jp/search?q=Phthon&start=0&start=0&hl=ja&lr=lang_ja&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:ja-JP:official

>この4/1に発表されたPhthonのエイプリルフールネタ 空白文字の使い方に厳しい「新言語」が出来たのか！と思ってしまうまでした。

>使用していただく分にはまったく問題ありません。あのソースのライセンスは、 >NYSL↓と思っていただいて結構です。 >http://www.kmonos.net/nysl/ > >ただし、Webページに乗っているものは、いろいろなバージョンが混在していますから、 >単純に貼っただけでは動かないと思います。その点はご承知おきください。 > レスありがとうございました。 確かに、貼り付けただけでは動きませんね＾＾； 自分のトコロに合わせてカスタマイズしたら動きだしました。 これから勉強しつつやっていこうと思います。 ありがとうございました。

>M4sugar requires GNU M4. Install it before installing M4sugar or >bison: I/O error >set the M4 environment variable to its path name やや、うちではcygwinが入っているので気付きませんでした。 MinGWを使うなら、おそらくcygwinではなくてMSYSを使うのが普通なのでしょう。 後ほど書き加えておきます。情報ありがとうございました。