K.Maebashi's BBS

>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を使うのが普通なのでしょう。 後ほど書き加えておきます。情報ありがとうございました。

>>m4をインストールして、M4環境変数を設定したらできました。 >前者があれば、後者はたぶん不要です。 >後者（環境変数 M4 を設定）が必要なのは m4 が標準でないところにインストールされている場合。 >cygwin setup で単純にインストールしたら標準ディレクトリに配置されるはずで、 >よって後者は不要のはずです (ウチではそうなっています) cygwinは、インストールしたことなく分からなかったので、 m4を単体でインストールしました。 デフォルトのパスで、C:\Program Files\GnuWin32\bin\m4.exe にインストールされました。 bison.exeも同一フォルダに入っています。 MinGWは、C:\MinGWにインストールしたのですが、この場合 m4をインストールすべき標準ディレクトリは、どこになるのでしょうか？ C:\MinGW\binにm4.exeをコピーしても駄目でした。 初心者なので基本的な質問ですいません。

>m4をインストールして、M4環境変数を設定したらできました。 前者があれば、後者はたぶん不要です。 後者（環境変数 M4 を設定）が必要なのは m4 が標準でないところにインストールされている場合。 cygwin setup で単純にインストールしたら標準ディレクトリに配置されるはずで、 よって後者は不要のはずです (ウチではそうなっています)

>>M4sugar requires GNU M4. Install it before installing M4sugar or >のメッセージを見れば一目瞭然なような気がしますが何がわからないでしょうか。 >Cygwin Setup で m4 を追加インストールしてください。 m4をインストールして、M4環境変数を設定したらできました。 ありがとうございました。

>M4sugar requires GNU M4. Install it before installing M4sugar or のメッセージを見れば一目瞭然なような気がしますが何がわからないでしょうか。 Cygwin Setup で m4 を追加インストールしてください。

はじめまして。タイガーです。 「プログラミング言語を作る」のページで、Windows版のソースをダウンロードし、MinGW、bison、flexをインストールして、binのパスを追加したのですが、gmakeを実行すると、以下のエラーが出ます。 M4sugar requires GNU M4. Install it before installing M4sugar or bison: I/O error set the M4 environment variable to its path name 環境は、Windows XP SP1で、「bison crowbar.y」を実行すると同様のエラーが発生します。 なぜこのエラーが発生するのですか？回避方法があれば教えてください。

引用の順序を変更しています。 > ただ、「PlayerがBoardの実体を保持していてはいかんでしょ > う。」といった話をするときには、「実体」またはそれに類 > する言葉が要るのではないかと思っています。 そうですね。 念のために言うと、僕も、実体という言葉に対して(ぱ)さんと 同じ感覚を持っています。 > > Python プログラマで一人、"call by object reference" > > のことを指して "call by object" と呼んでいる例が見つ > > かりましたが、これだと、日本語と英語で意味が逆になり > > ますし。 > > 日本人でも、「オブジェクト==参照」という解釈の人もいる > ようですから、「日本語と英語で意味が逆」になるわけでも > ないような気がします。 以下の松本さんの例もそうなんですね。 > http://www.rubyist.net/~matz/?date=20030730 > | もっとも多くの言語には「オブジェクト」でない「値」も > | ある。またCの例を出すと、構造体はオブジェクトではな > | い。代入によってコピーが発生するからだ。 BASICの文字 > | 列もオブジェクトではない。 > 最初読んだとき、かなり違和感がありました。「参照」と > 「値」の話ならその通りですが、上記の文を読む限り、「オ > ブジェクト」が「参照」とほぼ同義で使われているからです。 まったく同様な違和感があります。 > >http://aspn.activestate.com/ASPN/Mail/Message/python-Tutor/509290 > ざっと読みました。 > | (2) there is no pointer type in Python, so you > | *can't* pass "a reference" to an object > Pythonは(Javaと同様)なんでもかんでも参照だと思っていま > したが、 それで合ってると思います。 > これはどういう意味でしょう。変数への参照が取れないって > ことかなあ。 参照への参照が取れないってことでしょうね。 > # でも「you *can't* pass "a reference" to an 『object』」 > # だしなあ。 > ## 私がPythonについて誤解しているようでしたらご指摘く > ## ださいませ。 上の記事の著者である Tim Peters が言う "object" というの は、松本さんの言う object と同じもの、すなわち我々の感じ るところの「object への参照」のことなので、特に矛盾はな いと思います。 Smalltalk や Ruby など、全ての型が object である言語で育 つと、自然にこういう感覚になるのかもしれませんが、機械語 による実装を見て意味を理解するタイプの人間からすると、 ちょっとついていけない感じですね。 で、我々の感覚でいう「オブジェクトへの参照の値渡し (call by object reference)」は、Tim Peters や松本さんのような 感覚を持つ人にとっては、 実体渡し == "call by object" となるわけです。 結局、以下の懸念は、まったく当たっており、注釈をつけたの は正解だということになると思います。 > おっしゃるとおり、術語としてちゃんと定義されてな > さそうなので、誤解を招く可能性があると思うのです > が。そのために、先の投稿で注釈をつけたわけです。 同様に、 > 参照渡しを実体渡しと読んでいるのはその本(および > その本に言及したWebページ)以外では、私は見たこと > ないです。そんなの広く使われてるじゃん、という方 > は情報よろしくお願いします。 についても、(少なくとも Python の世界では?) 広く使われている と考えた方がいいのかもしれません。Tim Peters 氏は、Python の 世界では結構な有名人のようですし。 以下は余談です。 > >ただ、Java を含む多くの GC つき言語では、参照の値 > >渡しをするわけで、この術語は使えませんね。 > ええと、少なくともJavaやCなら「値渡ししかない」で済み > そうな気がするのですけど。 もちろんそうです。 ただ、C++ でオブジェクトを参照渡しすることと、まあだいた い等価なことは、Java でも当然行なわれていることなわけで、 C++ と Java に関する話をするときに、これを意味する術語が 欲しいように思います。 で、これを "call by object" と呼びたくない派の人間として は、"call by object reference" のように呼びたくなるわけ です。 もっとも google によると "call by object reference" の 用例は230件しかないそうなので、こういう欲求は、非常に マイナーなのかもしれませんが。

>「参照渡し (call/passing by reference)」と「値渡し >(call/passing by value)」が標準的な術語だと思うの >で、言葉としては、これを使うのがいいような気がする >んですが。言語も C++ ですし。 同意します。私自身、「ポインタ完全制覇」でも「Java謎+落とし穴～」でも、 「値渡し」という言葉を使用しています(どこかで「実体渡し」という言葉を 使っているかもしれませんが…)。 ただ、「PlayerがBoardの実体を保持していてはいかんでしょう。」といった 話をするときには、「実体」またはそれに類する言葉が要るのではないかと 思っています。 おっしゃるとおり、術語としてちゃんと定義されてなさそうなので、誤解を 招く可能性があると思うのですが。そのために、先の投稿で注釈をつけたわけです。 >ただ、Java を含む多くの GC つき言語では、参照の値 >渡しをするわけで、この術語は使えませんね。 ええと、少なくともJavaやCなら「値渡ししかない」で済みそうな気がするのですけど。 >Python プログラマで一人、"call by object reference" >のことを指して "call by object" と呼んでいる例が見 >つかりましたが、これだと、日本語と英語で意味が逆に >なりますし。 日本人でも、「オブジェクト==参照」という解釈の人もいるようですから、 「日本語と英語で意味が逆」になるわけでもないような気がします。 http://www.rubyist.net/~matz/?date=20030730 | もっとも多くの言語には「オブジェクト」でない「値」もある。 | またCの例を出すと、構造体はオブジェクトではない。代入によって | コピーが発生するからだ。 BASICの文字列もオブジェクトではない。 最初読んだとき、かなり違和感がありました。「参照」と「値」の話なら その通りですが、上記の文を読む限り、「オブジェクト」が「参照」と ほぼ同義で使われているからです。 >http://aspn.activestate.com/ASPN/Mail/Message/python-Tutor/509290 ざっと読みました。 | (2) there is no pointer type in Python, so you *can't* pass "a | reference" to an object Pythonは(Javaと同様)なんでもかんでも参照だと思っていましたが、 これはどういう意味でしょう。変数への参照が取れないってことかなあ。 # でも「you *can't* pass "a reference" to an 『object』」だしなあ。 ## 私がPythonについて誤解しているようでしたらご指摘くださいませ。

話題がそれるので、件名を変更しました。 「参照渡し (call/passing by reference)」と「値渡し (call/passing by value)」が標準的な術語だと思うの で、言葉としては、これを使うのがいいような気がする んですが。言語も C++ ですし。 ただ、Java を含む多くの GC つき言語では、参照の値 渡しをするわけで、この術語は使えませんね。Java と C++ で共通に使える用語としては、「オブジェクト参照 渡し (call/passing by object reference)」と「コピー 渡し (call/passing by copy)」が分かりやすいような 気がします。が、google で探すと、使っている例が少 ないなあ… 特に日本語で「オブジェクト参照渡し」を 使っている例が少ないです。あと、コピー渡しは、値渡 しと同じ意味なので、この対比は実は対称じゃないのも イマイチかも。 「実体渡し」に関しては、google で探して上位に出る サイトでは、「コピー渡し」の意味で使っているサイト ばかりのようですね。でも実体渡しって、日本以外でも 使われている用語なんでしょうか？ Python プログラマで一人、"call by object reference" のことを指して "call by object" と呼んでいる例が見 つかりましたが、これだと、日本語と英語で意味が逆に なりますし。 http://aspn.activestate.com/ASPN/Mail/Message/python-Tutor/509290 「実体渡し」を英語に訳すとすると、どうなるんでしょう？

>ソースの半分くらいしか理解できてませんが、読んだ感じだとDBフィールド用意して、あのソースを貼り付けるだけで出来そうなんですが（笑） >使用してもよいでしょうか？ 使用していただく分にはまったく問題ありません。あのソースのライセンスは、 NYSL↓と思っていただいて結構です。 http://www.kmonos.net/nysl/ ただし、Webページに乗っているものは、いろいろなバージョンが混在していますから、 単純に貼っただけでは動かないと思います。その点はご承知おきください。

>http://revolver.at.infoseek.co.jp/hasami-vc.lzh 　まず、うちにはVC++をコンパイルする環境はないですし、デバッグまで するつもりもないので、ざっと眺めた感想ですが。 　BoardがBoard.cppで定義されていて、#include "Board.cpp"してるとかは さておくとしても、PlayerがBoardの実体を保持していてはいかんでしょう。 Playerがふたりいるとき、それぞれがBoardを抱え込んでいては、ゲームに なりません。 　先読みのときBoardをヒープにclone()するのなら、以後それはポインタで 持ち歩いたほうがよさそうに思うのですが、実体で引数渡ししていますし。 Boardの中のcellは、実体で持ってよさそうですがポインタで保持してますし、 にもかかわらずBoardにコピーコンストラクタがありません。 　それぞれがaccess violationの原因になるかどうかはさておき、 C++を使うのなら、ポインタと実体の区別を意識するのが重要だと思います。 Javaにはポインタしかないので、Javaから移植するのなら、なんでもかんでも ポインタにするのが楽かもしれません(メモリリークを起こしそうですが)。 なお、ここでは「実体」という言葉を、「ポインタではないデータそのもの」 という意味で使っています。 以前読んだC++本では、引数の参照渡しを「実体渡し」と呼んでてびっくりしました。 「コピーではなく、それそのものを渡す」という意味で「実体渡し」なんだろうと 思いますが、一般的かなあ… 私のように「ポインタではないデータそのもの」の意味で「実体」という言葉を 使うのもさほど一般的ではないかもしれませんが、参照渡しを実体渡しと読んでいるのは その本(およびその本に言及したWebページ)以外では、私は見たことないです。 そんなの広く使われてるじゃん、という方は情報よろしくお願いします。

前回貼った圧縮ファイルには、圧縮前のフォルダだけ圧縮されていた様です。 たびたびすみません。 http://revolver.at.infoseek.co.jp/hasami-vc.lzh

掲示板を読んでいたらなんとなく「さぽせん」ホームページを思い出しました。 ... っていやそれだけ。

はじめまして。 ここ数日サイトに訪れさせてもらっています。 最近（ここ2、3年）ですがSQL＋PHPで仕事することが多く、それまで無知だった自分がいつのまにやら基本構文（？）を覚えてしまい、無料サーバーを借りてDB組み込みつつ動的なものを作り始めました。 さしあたって、簡単な雑記帳やカウンターなどは楽にできました（それでも丸三日はかかりました）が、BBSはどうしたもんかなーとgoogleで回っていたら。このサイトに来ました。 ソースの半分くらいしか理解できてませんが、読んだ感じだとDBフィールド用意して、あのソースを貼り付けるだけで出来そうなんですが（笑） 使用してもよいでしょうか？

>http://revolver.at.infoseek.co.jp/hasami-vc.lzh 　このリンクから.lzhファイルをダウンロードすることはできました。サイズは301バイト。 　解凍してみたら、ショートカットのファイルがひとつだけあらわれました。

当方がＷｅｂについて良く知らないため、ダウンロードして貰えなくてすみません。 今回もうまくいかないかも知れませんが、とりあえず貼って見ます。 http://revolver.at.infoseek.co.jp/hasami-vc.lzh

>　それだとおっしゃるとおりチェック漏れを起こすと思います。どういうわけか、 また、ボケた質問しているんじゃないかと思って、ドキドキしてましたが、 今回はあってたみたいで安心しました。 >というわけで、私はこの通りポカもミスも人並み以上にしますので、 >全然たいしたことはないです f(^^;;; いえいえ、これからも前橋さんのソースで勉強させていただきます。 ありがとうございました。

>実装を始めて気がついたのですが、goto文って実はもっとも単純だと >思っていたのですが、実は難しいのですね。 　です。crowbarにgotoがないのはそのためです(w。かろうじてbreakとcontinueは ありますが、これも戻り値でちまちま返すことになってしまっています。 # Rubyはこのへんをsetjmpとlongjmpでやっているようですが。 >というように、状況に応じて改行を文の区切り文字と認識したりあるいは >無視したりしています。Ruby では Lex などの字句解析機を使わずに自前の >実装を使われているそうなので、ありものの字句解析機を利用しなかったのは、 >利用できなかったからなのでは？と勝手に想像しています。 　いきなり答をばらす行為になるのかもしれませんが、Rubyの実装については、 以下のページに詳細な説明があります。 http://i.loveruby.net/ja/rhg/index.html 　「状態付きスキャナ」にも、1章が割り当てられています。

>はじめまして。 　どうもです。 　ここを見ている第三者のために経緯を説明すると、SFファンさんは 既にJavaWorld誌経由で質問されていて、私からも一度回答を返しています。 ただあまり編集さんを煩わせるのもなんですし、よろしければ掲示板の方へ、 と私が書いたので、こちらで質問されたようです。 >そこでVC++への移植を試みました。しかし時々盤オブジェクトの参照で >アクセスバイオレーションが起きてしまいます。 >Java版と同じ様に盤（cell）をnewしていますが、別クラスもしくは >Boardクラスの他のメソッドから見れていない様です。 >この件についてJavaWorld経由で前橋氏から解答を貰いましたが >盤オブジェクトは構造体にしなければいけない様な事が書いてありました。 　そういうことを書いた覚えはないですが… 　私が書いたのは、以下の通りです。 # その他、本当にC++にすれば速くなるかは疑問、という趣旨のことも書きましたが。 >可能性としては、以下のようなことが考えられるでしょうか。 > >・メンバにアクセス修飾子を付けない場合のデフォルトの意味が、JavaとC++では >　異なる(Javaはデフォルトでパッケージ内丸見えだがC++はデフォルトでprivate)。 >・高速化を狙ったのなら、1手先読みするたびにBoardを毎回newするのではなく、 >　Boardをスタック上に確保するような変更を加えたのでしょうか? >　もしそうだとして、盤面の配列部分をJava版と同じようにヒープに確保して >　いるとすれば、コピーコンストラクタを正しく書かないと動作しません。 >　# Boardをスタックに置いておきながら、盤面の配列をヒープに取るようなことは >　# 普通しないと思うので、この可能性は薄そうですが。 　ひとまず「アクセスバイオレーション」とのことなので、コンパイル時のエラー ではなく実行時のエラーなのでしょう。よってひとつめの可能性は排除できます。 　「Java版と同じ様に盤（cell）をnewしていますが」とありますが、もしこれが、 「Boardはスタックにとっているのに2次元配列cellはヒープにとっている」という ことなら、ふたつめの可能性は考慮する価値があるかもしれませんが… 私のソースを直接C++で書き直したのなら、Boardこそヒープに取るでしょうし、 やっぱり可能性は薄いように思います。 >http://revolver.at.infoseek.co.jp/hasami-vc 　403 Forbiddenです。

> とはならず、「(char*)&header[1] - (char*)header->s.mark)とMARK_SIZEの隙間」 >の方が先に壊れるような気がするのですが、違いますでしょうか? 　すみません、勘違いしていました。tosさんが心配しておられるのは、 アプリケーションに返す領域の「前の」MARK部分なのですね。 　それだとおっしゃるとおりチェック漏れを起こすと思います。どういうわけか、 後ろのMARKのことだとばかり思い込んでいました。 　ご指摘ありがとうございました。次のバージョンで直します。 >ただ、私は前橋さんを勝手に師匠と思って、ソースを勉強させていただいて >いますので、もう少しお付き合いください。 というわけで、私はこの通りポカもミスも人並み以上にしますので、 全然たいしたことはないです f(^^;;;

>>>・制御構文はとりあえずifとgotoのみ（とほほ・・・） >>>・他の制御構文はifとgotoで実装してライブラリ提供 >> >>　どのような形式で実行する言語を想定しておられますでしょうか。 > >むむっ、実はあまり考えていません。あれこれ空想する際には、アセンブリのイメージで考えていて、無条件ジャンプと条件ジャンプがあればとりあえず事足りるかな、という風に思って上記のように書きました。 実装を始めて気がついたのですが、goto文って実はもっとも単純だと思っていたのですが、実は難しいのですね。 今はソースを読み込んだら即構文木を作って評価するインタープリタを作っているのですが、今のインタープリタにgoto文を実装するとすると、上方向にジャンプする場合も下方向にジャンプする場合も、入力ストリームをラベル位置まで巻き戻したりスキップしたりしなければなりません。BASICのgoto文ってどういう実装になっているか調べてみようかと思っています。 >>>b, a = a, b #スワップ 他にも難しい実装に気がつきました。Ruby のように文の区切り文字を省略させたいのですが、これがまたかなり難しいです。Ruby だと 1 + 2 # 1+2 と評価される 1 # 1 と評価される + 2 # +2 と評価される 1 # 1 と評価される + # この時点では式が継続するものと予測されるので評価しない 2 # 上の行と合わせて +2 と評価される 1 + # そういえばこのケースは試してないですが、 2 # 多分 1+2 と評価されるのでは？ というように、状況に応じて改行を文の区切り文字と認識したりあるいは無視したりしています。Ruby では Lex などの字句解析機を使わずに自前の実装を使われているそうなので、ありものの字句解析機を利用しなかったのは、利用できなかったからなのでは？と勝手に想像しています。 というのも、上記のような改行仕様を flex で実装しようとしたところ、状態遷移だけでかなり複雑になってしまい、私ではお手上げでした。

はじめまして。 「JavaWorld」２００３年３月号掲載の前橋氏作のリバーシゲームをはさみ将棋に改造しました。 しかし３手読みが限界で強くありません。 そこでVC++への移植を試みました。しかし時々盤オブジェクトの参照でアクセスバイオレーションが起きてしまいます。 Java版と同じ様に盤（cell）をnewしていますが、別クラスもしくはBoardクラスの他のメソッドから見れていない様です。 この件についてJavaWorld経由で前橋氏から解答を貰いましたが盤オブジェクトは構造体にしなければいけない様な事が書いてありました。 以前作りかけていたはさみ将棋に前橋氏作のリバーシゲームを改造したものを上乗せしたので、まだ構造的におかしいですが、問題点があればご指摘をお願いします。 http://revolver.at.infoseek.co.jp/hasami-vc

細かい突っ込みで時間を取っていただき、申し訳ありません。 ただ、私は前橋さんを勝手に師匠と思って、ソースを勉強させていただいて いますので、もう少しお付き合いください。 (char*)&header[1] - (char*)header->s.markがパディングを考慮したものだとすると、 (char*)&header[1] - (char*)header->s.markの値は、MARK_SIZEよりも大きい場合が あると思います。 そうすると、 >しかし、このへんが壊れるのはほとんど配列のオーバランで、もしそうなら、 >(char*)&header[1] - (char*)header->s.mark)とMARK_SIZEの隙間より先に、 >MARK_SIZEでチェックしている部分が壊れるはずです。 とはならず、「(char*)&header[1] - (char*)header->s.mark)とMARK_SIZEの隙間」 の方が先に壊れるような気がするのですが、違いますでしょうか?

>check_mark_sub(unsigned char *mark) ... >でチェックしているのは、MARK_SIZEのようです。 はい。これは単に、アプリケーションに返す領域の「前に入れたマーク」と 「後ろに入れたマーク」で同じcheck_mark_sub()を使いたかったため …だったと思います。要するに単なる手抜きです。 関連するソースはこのへん： http://kmaebashi.com/programmer/devlang/crowbar_src_0_1_01/S/5.html#148 >これだと、(char*)&header[1] - (char*)header->s.mark)がMARK_SIZEでは無かった場合、 >チェック漏れが起きてしまいそうな気がするのですが、あっていますでしょうか?(ヨワヨワです) (char*)&header[1] - (char*)header->s.mark)とMARK_SIZEの差にあたる部分を 選択的に破壊するようなバグがあれば、確かにチェック漏れを起こすはずです。 しかし、このへんが壊れるのはほとんど配列のオーバランで、もしそうなら、 (char*)&header[1] - (char*)header->s.mark)とMARK_SIZEの隙間より先に、 MARK_SIZEでチェックしている部分が壊れるはずです。 MEMでできるのはどっちみち確率的なチェックでしかありません。たとえば たまたま0xCDでマーク部分を破壊されたら気付きませんし、MEMで保持している 連結リストをぶっ壊されたら原因の究明は困難になってしまいます。 そう考えれば、この程度のチェックの甘さは許容範囲かなあ、と思っています。 だったら0xCDを詰めるのも、最初からMARKのサイズだけでいいじゃん、という ツッコミはもちろんあり得るわけですが、そんなことでたいして速度が稼げる わけじゃなし、どうでもいいんじゃないかなあ、と。 ただし、もちろんmark_check_head()とmark_check_tail()を別々に 作ってもたいした手間ではありません。チェックの甘さはさておき、 ソースの統一感という点からすると、修正したほうがよいかもしれませんね。 正直、あまり優先度は高くないですが、気が向いたら直しておきます。

皆さんこんにちは、tosです。 crowbarのMEMモジュールに関して質問があります。 memory.cの void set_header(Header *header, int size, char *filename, int line) { . . . memset(header->s.mark, MARK, (char*)&header[1] - (char*)header->s.mark); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ } でmemsetのサイズとしてMARK_SIZEでは無く、上記のようなサイズを設定しているのは、 パディングを考慮してのことなのかなと思いますが、 void check_mark_sub(unsigned char *mark) { int i; for (i = 0; i < MARK_SIZE; i++) { if (mark[i] != MARK) { fprintf(stderr, "bad mark\n"); abort(); } } } でチェックしているのは、MARK_SIZEのようです。 これだと、(char*)&header[1] - (char*)header->s.mark)がMARK_SIZEでは無かった場合、 チェック漏れが起きてしまいそうな気がするのですが、あっていますでしょうか?(ヨワヨワです)

>クロージャがネストするたびに、配列の要素が増えるのではなく、配列が >増えるわけですよね。つまり2次元配列(配列の配列)が渡ることになる、と。 >あるいは、ネストが増えるたびに引数の数そのものが増えるのかも >しれませんね。 引数の数が増える方を想定していました。２次元配列の方だと、クロージャから 外側の環境の変数にアクセスするたびに２次元配列にアクセスすることになる分、 性能が低下しそうなので。 > >どちらにせよ、それなら納得です。 > >最近本格的に時間がなくて、断片的な疑問の提示しかできなかったため >余計なお手間を取らせてしまいました。すみません。 いえ、こちらこそ、説明が足りなかったせいで余計な手間を取らせてすいません でした。

>foreach と using を分けた C# もそれはそれで偉い、というか >何でもクロージャよりそっちのほうが個人的にはまっとうな >考え方という気が現在はしていますけどね。 私も基本的にはそう思うんですが、時々思うのは、 「言語仕様がライブラリに依存しているのはなんかヘン」ってことです。 foreachはIEnumerableに依存していますよね。 まあでもそれを言えばピュアなOO言語は数値などのリテラルもクラスの インスタンスですし、Cだってexit()に依存しているとは言えるので、 気にするほうがおかしいのかもしれません。 crowbarも、配列の生成は、配列リテラルを除きネイティブ関数に頼るつもりですし。

>すいません。説明不足でした。前の例で配列を１つしかクロージャに渡して >いないのは、あの例ではクロージャがネストしていないため、そうなっている >だけで、クロージャのネストが増えるごとに、クロージャに渡される配列の数 >は１つずつ増えて行く仕組みになっています。つまり、クロージャがn段ネスト >した場合、n個の配列がクロージャに渡されることになります。 クロージャがネストするたびに、配列の要素が増えるのではなく、配列が 増えるわけですよね。つまり2次元配列(配列の配列)が渡ることになる、と。 あるいは、ネストが増えるたびに引数の数そのものが増えるのかも しれませんね。 どちらにせよ、それなら納得です。 最近本格的に時間がなくて、断片的な疑問の提示しかできなかったため 余計なお手間を取らせてしまいました。すみません。

>まず前提として、 > >・クロージャはそれ自体が式なので、クロージャの中にも書けるはず。 >　よって、クロージャはネスト可能。 >・ということは、内側のクロージャは、外側のクロージャの環境と、 >　さらにその外側(普通の関数)の両方の環境が見えなければならない。 > >というのがあって、mizuさんの案だと配列をひとつしか渡していないので、 >いいのかな、と思ったわけです。 すいません。説明不足でした。前の例で配列を１つしかクロージャに渡して いないのは、あの例ではクロージャがネストしていないため、そうなっている だけで、クロージャのネストが増えるごとに、クロージャに渡される配列の数 は１つずつ増えて行く仕組みになっています。つまり、クロージャがn段ネスト した場合、n個の配列がクロージャに渡されることになります。 >　再帰がなければ静的にインデックス計算することも可能でしょうが、 >再帰を許すと、インデックスが動的に変化することになりませんか、 >というのが先の投稿の意図です。 ># 私はクロージャ初心者なので何か勘違いしている可能性はありますが… クロージャのネスト段数は静的に決定され、かつ、クロージャから 参照されている変数がどのクロージャ(関数)のものであるかは、静的に決定 可能なので、再帰の有無に関わらず、(クロージャから参照される)変数の インデックスは静的に計算できるはずだと思うのですが…。何か勘違いしている のかもしれませんので、もう少し考えてみます。

>>　foreach(collection, function(item) { >> print(item); >> }); >> >>こんな感じだと読みにくいですかねえ。 > >そんなことはないですよ。むしろ読みやすいと思います。 Ruby なら collection.foreach { |item| print item } なわけで、メソッド/クロージャによるライブラリ的実装の ほうがよっぽど読みやすいとは言えそうですねぇ。 # 他のに多様な仕組みとの共通性という意味で これはクロージャの構文の勝利ですね。 foreach と using を分けた C# もそれはそれで偉い、というか 何でもクロージャよりそっちのほうが個人的にはまっとうな 考え方という気が現在はしていますけどね。 # Net::HTTP.start(host) { |http| ... } みたいに # 後始末のためにクロージャを使うのってなんか変な感じがしている

>>　ええと、クロージャが再帰した時はどうなるのでしょうか。Pascalの >>スタティックリンクのような仕掛けがないと困るような気が… >>すみませんよぱらいなので頭動いてないです。 まず前提として、 ・クロージャはそれ自体が式なので、クロージャの中にも書けるはず。 　よって、クロージャはネスト可能。 ・ということは、内側のクロージャは、外側のクロージャの環境と、 　さらにその外側(普通の関数)の両方の環境が見えなければならない。 というのがあって、mizuさんの案だと配列をひとつしか渡していないので、 いいのかな、と思ったわけです。 　再帰がなければ静的にインデックス計算することも可能でしょうが、 再帰を許すと、インデックスが動的に変化することになりませんか、 というのが先の投稿の意図です。 # 私はクロージャ初心者なので何か勘違いしている可能性はありますが… >あと、Pascalはよく知らないのですが、Pascalのスタティックリンクとは >どのようなものなのでしょうか？ 　Pascalは関数のネストができるので、内側の関数からは外側の関数の ローカル変数が参照できます。かつ再帰を許すため、現状のスタックの トップからの、外側の関数のローカル変数の位置は静的には決まりません。 そこで、最新の環境に、外周の関数の環境へのポインタを保持していて それをスタティックリンクと呼びます。 # Pascalの処理系を読んだわけではないので、「エキスパートCプログラミング」の # 受け売りですが。 >とすると、変数のルックアップは、ある環境を探索して、見つからなければ >外側の環境へのリンクをたどって…という風に行われるのでしょうか。 そのつもりです。JavaScriptではこんな感じらしいですし。 http://www.hawk.34sp.com/stdpls/jsnotes/jssinso/ 　ただ、グローバル変数を単なる再外周の環境として扱うか、特別扱いするかは 現在悩んでいるところです。

>　うーん、私はLispはEmacs Lispやxyzzy Lispで遊んだ程度ですので、 >Lispそのものについては何も言いませんが(Paul Grahamのエッセイは日本語訳された >範囲ではたぶん全部読んでますし、Lispを悪く言うつもりはないですが)、 私も、Lispは、Schemeとかで遊んだ程度なので、あまり偉そうには言えないです。 >コンパイラコンパイラが使える環境なら、多少の構文の複雑さは問題にならない >はずです。 確かにそうだと思います。しかし、構文を少しずつ拡張していくという作業は、 いかにパーザジェネレータを使っていても、面倒ではあります。その点、Lisp系なら 一度S式パーサを書いておけば、基本的にはパーザをいじらなくても構文を拡張 できる(まあ、S式で書けるものしか基本的には書けませんが)というのは、嬉しい気が します。それが初心者にとって、どれだけ嬉しいかはわかりませんが。 >だとすれば、初心者さんにとって、馴染みの薄いLispの勉強と、 >言語処理系の作成というふたつのことを同時に勉強させるのは酷というものでは >ないでしょうか。 Lispの核となる概念自体はかなりシンプル(だと思う)なので、覚えるべき事柄は そう多く無い気もします。もちろん、Common LispなりSchemeなりを実装しようと 思うと、勉強しなければならないことがたくさんあるはずですが、処理系作成の 勉強としては、「Lispのようなもの」を作れれば十分ですし。ただ、馴染みが 薄いため、取っ付きが悪いというのはありそうです。 >　もっとも、何かを理解しようと思ったら、それを作ってみるのが一番手っ取り早い >とは思っていまして、Lispを勉強したい人に「じゃあLispを作ってみようよ」という >提案は有効だと思います。でも、言語処理系を作ってみたい、という人が、 >本当に作りたいのは、Lispなんでしょうか。 たぶん(多くの人にとっては)違うと思います。しかし、とりあえず練習として 作ってみることで、言語処理系の作成に必要な基礎知識が身につくという効果は あると思います。どうせ、初めて作る言語で、いきなり自分の欲しい言語を作る なんてのは無理ですし。 >>基本的なアイデアとしては、いわゆる「単純委譲」をコンパイラが自動生成する > >　了解です。 >　ところで、この形式で、MyListはArrayListなんでしょうか。 >　そうだとすれば、多重継承を許そうとすると、「ArrayListインタフェース」のような >インタフェースをたくさん作らなければならないような気がします。 いえ。あくまで委譲コードの自動生成なので、型としては、ArrayListと MyListは何ら関係がありません。ですから、型の継承関係を作りたけ れば、別途クラスを継承するか、インタフェースを実装します。 例えば、MouseListenerとWindowListenerのインタフェースを多重継承して、 それぞれの実装をMouseAdapterとWindowAdapterに委譲するコードは、 class MouseAndWindowAdapter implements MouseListener, WindowListener { /*MouseListenerインタフェースに対する呼び出しを委譲*/ forward MouseListener mouseListener_ = new MouseAdapter(); /*WindowListenerインタフェースに対する呼び出しを委譲*/ forward WindowListener windowListener_ = new WindowAdapter(); } と書けます。 >>で、問題になっている環境へのアクセス方法ですが、クロージャから外側の >>環境にアクセスしていることをコンパイラが検出したら、外側の環境での変数 >>へのアクセスをObject型配列の要素に対するアクセスに変換して、Object型配列 >>への参照を、クロージャに渡すという方法を取ります。 > >　ええと、クロージャが再帰した時はどうなるのでしょうか。Pascalの >スタティックリンクのような仕掛けがないと困るような気が… >すみませんよぱらいなので頭動いてないです。 クロージャの中で、自分を再帰的に呼び出したときということでしょうか。 それなら、おそらく問題無いと思います。 例えば、以下のような再帰でフィボナッチ数列を計算するクロージャfibが あったとして(これだと、クロージャにする意味があまりありませんが)、 interface UnaryIntegerFunction { int call(int arg); } class Hoge{ public static void main(String[] args){ UnaryIntegerFunction fib = #(int n){ if(n == 1 || n == 2){ return 1; }else{ return fib.call(n - 1) + fib.call(n - 2); } }; System.out.println(fib.call(3)); } } これは、 class UnaryIntegerFunction$1 implements UnaryIntegerFunction { private Object[] environment_; UnaryIntegerFunction(Object[] environment){ environment_ = environment; } public int call(int n){ if(n < 2){ return 1; }else{ return ((UnaryIntegerFunction)environment_[1]).call(n - 1) + ((UnaryIntegerFunction)environment_[1]).call(n - 2); } } } class Hoge { public static void main(String[] args){ Object[] environment = new Object[2]; environment[0] = args; environment[1] = new UnaryIntegerFunction$1(environment); System.out.println("fib(3) = " + ((UnaryIntegerFunction)environment[1]).call(3)); } } というコードに変換されます(先の投稿の例では、引数をenvironment 配列に入れるのを忘れていたので、若干先の例とは変換のされ方が違っています)。 このコードは問題無く動くと思うのですが、何か勘違いしているでしょうか？ あと、Pascalはよく知らないのですが、Pascalのスタティックリンクとは どのようなものなのでしょうか？ >　ちなみにですが、crowbarはJavaScript的に環境ごとに連想配列を持ち、 > 外側環境へのリンクを持とうと思っています。 とすると、変数のルックアップは、ある環境を探索して、見つからなければ 外側の環境へのリンクをたどって…という風に行われるのでしょうか。

>簡単に実装するなら、Lisp系言語などが楽でいいのではと思いましたが、 >どうでしょうか。普通の言語に比べて、構文がちょっと特殊ですが、機能 >拡張がわりと容易ですし、言語設計の面白さは十分に味わうことができるの >ではないかと思います。 　うーん、私はLispはEmacs Lispやxyzzy Lispで遊んだ程度ですので、 Lispそのものについては何も言いませんが(Paul Grahamのエッセイは日本語訳された 範囲ではたぶん全部読んでますし、Lispを悪く言うつもりはないですが)、 いわゆる「普通のプログラマ」に馴染みが薄いというのは確かだと思うわけです。 　んで、この辺のスレ http://pc8.2ch.net/test/read.cgi/tech/1106129164/ とか見るにつけ、「Lispなら処理系作るの簡単だよ」というアドバイスがちょくちょく あって、それはそれで嘘ではないと思うのですが、yaccなりJavaCCなりの コンパイラコンパイラが使える環境なら、多少の構文の複雑さは問題にならない はずです。だとすれば、初心者さんにとって、馴染みの薄いLispの勉強と、 言語処理系の作成というふたつのことを同時に勉強させるのは酷というものでは ないでしょうか。 　もっとも、何かを理解しようと思ったら、それを作ってみるのが一番手っ取り早い とは思っていまして、Lispを勉強したい人に「じゃあLispを作ってみようよ」という 提案は有効だと思います。でも、言語処理系を作ってみたい、という人が、 本当に作りたいのは、Lispなんでしょうか。 >基本的なアイデアとしては、いわゆる「単純委譲」をコンパイラが自動生成する 　了解です。 　ところで、この形式で、MyListはArrayListなんでしょうか。 　そうだとすれば、多重継承を許そうとすると、「ArrayListインタフェース」のような インタフェースをたくさん作らなければならないような気がします。 >で、問題になっている環境へのアクセス方法ですが、クロージャから外側の >環境にアクセスしていることをコンパイラが検出したら、外側の環境での変数 >へのアクセスをObject型配列の要素に対するアクセスに変換して、Object型配列 >への参照を、クロージャに渡すという方法を取ります。 　ええと、クロージャが再帰した時はどうなるのでしょうか。Pascalの スタティックリンクのような仕掛けがないと困るような気が… すみませんよぱらいなので頭動いてないです。 　ちなみにですが、crowbarはJavaScript的に環境ごとに連想配列を持ち、 外側環境へのリンクを持とうと思っています。

今回の投稿は、説明の都合上、大分長くなってしまいました。迷惑でしたら、 すいません。 >やってみるとそんなに難しくはないんですよね。実際、今回の企画はそれを >示そうと思ってはじめました。時間がなくてなかなか思うに任せていませんが。 ># そんなに難しくはない、ということを示したいんだから、あっという間に ># 実装できた方が説得力あるんでしょうけどねえ。 簡単に実装するなら、Lisp系言語などが楽でいいのではと思いましたが、 どうでしょうか。普通の言語に比べて、構文がちょっと特殊ですが、機能 拡張がわりと容易ですし、言語設計の面白さは十分に味わうことができるの ではないかと思います。 >・委譲の言語仕様とか、 基本的なアイデアとしては、いわゆる「単純委譲」をコンパイラが自動生成する というもので、Java風に書くと、 class MyList{ forward List list_ = new ArrayList();//委譲宣言 } というコードから、 class MyList{ List list_ = new ArrayList(); public void add(Object o){ list_.add(o); public Object get(index i){ return list_.get(i); } } というコードをコンパイラが生成します。もちろん、これだけだと メソッド名が衝突したときに問題が発生しますが、経験から言って、 そのような衝突は、おそらくさほど頻度は高くないだろうと思われるので、 コンパイルエラーにして、衝突したメソッドのみ、プログラマにどのフィールドに 委譲するか(あるいはそもそも委譲せず、そのメソッドを新たに定義するか)を 選択させれば良いと考えています。 あと、全部のメソッドを委譲するだけでは不便なので、委譲したくないメソッドを 列挙する機能も必要かなと考えていますが、これはまだ実装するかどうかわかり ません。 >・クロージャの実装方法(環境へのアクセス方法)とか、 実は、クロージャの部分はまだ実装できていないのですが、仕様は大体決まって いて、クロージャは、新たなデータ型を導入するのではなく、インタフェース の実装クラスのインスタンスとして、クロージャを生成するという方法を 取ろうと思っています。 ActionListener n = #(ActionEvent event){ System.out.println("actionPerformed"); }; というコード(#以降がクロージャの定義で、eventはクロージャの仮引数です)は、 class ActionListener$1 implements ActionListener { public void actionPerformed(ActionEvent event){ System.out.println("actionPerformed"); } } ... ActionListener n = new ActionListener$1(); というコードにコンパイルされます。 ここでは、ActionListenerがメソッドを１つしか持っていないため、クロージャ の定義では、メソッド名を指定する必要はありませんが、メソッドを複数持った インタフェースの場合、対応するメソッドを指定する構文を用意しようかと 思っています。 で、問題になっている環境へのアクセス方法ですが、クロージャから外側の 環境にアクセスしていることをコンパイラが検出したら、外側の環境での変数 へのアクセスをObject型配列の要素に対するアクセスに変換して、Object型配列 への参照を、クロージャに渡すという方法を取ります。例えば、 class Hoge{ public static void main(String[] args){ int n = 0; ActionListener listener = #(ActionEvent event){ n++; }; listener.actionPerformed(null); System.out.println("n: " + n); } } というコードは、 class ActionListener$1 implements ActionListener { private Object[] environment_; ActionListener(Object[] environment){ environment_ = environment; } public void actionPerformed(ActionEvent event){ environment_[0] = new Integer(((Integer)environment_[0]).intValue() + 1); } } class Hoge{ public static void main(String[] args){ Object[] environment = new Object[1]; ActionListener listener = new ActionListener$1(environment); listener.actionPerformed(null); System.out.println("n: " + ((Integer)environment[0]).intValue()); } } というコードにコンパイルされます。このようなクロージャの実装方式は、 クロージャを新たなデータ型として導入するのに比べて、正直使い勝手は 悪いですが、既存のライブラリを活用するという点では、この方式の方が 良いのではないかと思っています。 >・型宣言を省略する方法とか(静的型とのことなので、レキシカルな最初の代入から推測?) その通りです。例えば、以下の代入があったとして、 n = 1; 代入があった時点でのスコープで、nが宣言されてされていなければ、それは int n = 1; という宣言とみなされます。代入される値の型が参照型の場合も、同じですが、 nullが代入される場合だけやや特殊で、 n = null; は、 Object n = null; とみなされます。この機能があれば、例えば、よくある String line; while((line = reader.readLine()) != null){ .. } というコードが、変数宣言無しで、 while((line = reader.readLine()) != null){ .. } だけで書けるようになります(lineのスコープはwhile文で閉じています)。 以上、長々と説明を書かせていただきましたが、よろしければツッコミや 意見をいただければ幸いです。 >　公開される日を楽しみにしています。 どうも有難うございます。頑張って開発を進めたいと思います。

>プログラミング言語を作るというと、 >やはり「難しそう」というイメージがあるのか、敬遠されることが >多いです。 やってみるとそんなに難しくはないんですよね。実際、今回の企画はそれを 示そうと思ってはじめました。時間がなくてなかなか思うに任せていませんが。 # そんなに難しくはない、ということを示したいんだから、あっという間に # 実装できた方が説得力あるんでしょうけどねえ。 >実は私も新しいプログラミング言語をJavaCCで作っていまして、近いうちに >公開しようかと考えているところです。 おお、すばらしい。 >どんな言語かと言いますと、Java VMのバイトコードを吐く、静的型の >オブジェクト指向言語で、JavaのOOP機能に、委譲やクロージャなどを備えた言語 >です。既にほとんどの機能のコンパイルができる所まで完成していて、今少しずつ >ドキュメントを書いているところです。 > >一応、特色としては、Javaライクな静的型オブジェクト指向言語でありながら、 >スクリプト言語のようにトップレベルにスクリプトがかけたり、型宣言が省略可能 >な辺りでしょうか。 ・委譲の言語仕様とか、 ・クロージャの実装方法(環境へのアクセス方法)とか、 ・型宣言を省略する方法とか(静的型とのことなので、レキシカルな最初の代入から推測?) 　等に興味があります。 　公開される日を楽しみにしています。

こんにちは。 新企画「プログラミング言語を作る」楽しみにしています。私はよく 友達(もちろん、一応プログラミング経験者の)に、「言語作ろうぜ。 面白いよ」とよく言っているのですが、プログラミング言語を作るというと、 やはり「難しそう」というイメージがあるのか、敬遠されることが 多いです。 こういうページを見て、「俺言語を作ってやろう」という人が増えるなら、 プログラミング言語好きとしては、嬉しいので、頑張ってください。もちろん、 無理をされない程度に。 ------------------------ 以下、ちょっと宣伝です。 実は私も新しいプログラミング言語をJavaCCで作っていまして、近いうちに 公開しようかと考えているところです。 どんな言語かと言いますと、Java VMのバイトコードを吐く、静的型の オブジェクト指向言語で、JavaのOOP機能に、委譲やクロージャなどを備えた言語 です。既にほとんどの機能のコンパイルができる所まで完成していて、今少しずつ ドキュメントを書いているところです。 一応、特色としては、Javaライクな静的型オブジェクト指向言語でありながら、 スクリプト言語のようにトップレベルにスクリプトがかけたり、型宣言が省略可能 な辺りでしょうか。

>>・制御構文はとりあえずifとgotoのみ（とほほ・・・） >>・他の制御構文はifとgotoで実装してライブラリ提供 > >　どのような形式で実行する言語を想定しておられますでしょうか。 むむっ、実はあまり考えていません。あれこれ空想する際には、アセンブリのイメージで考えていて、無条件ジャンプと条件ジャンプがあればとりあえず事足りるかな、という風に思って上記のように書きました。 中間コードを吐くタイプにしようかと考えていて、中間コードはXMLにしようかとも思っています。 >　foreach(collection, function(item) { > print(item); > }); > >こんな感じだと読みにくいですかねえ。 そんなことはないですよ。むしろ読みやすいと思います。 >> return x + y, x * y #戻り値の数は任意個数 >>b, a = a, b #スワップ > >これはおそらくリストのような概念を導入し、コンマで区切った式でリストが >生成され、代入時左辺がリストで区切られていると、対応する要素に代入される、 >ということですよね。 >関数呼び出しの際も引数がコンマで区切られていますが、これも、リストとして >渡されて、仮引数に代入される、ということでしょうか。面白そうだと思います。 すごい考察です。僕はそこまで考えていませんでした(^-^;

>・制御構文はとりあえずifとgotoのみ（とほほ・・・） >・他の制御構文はifとgotoで実装してライブラリ提供 　どのような形式で実行する言語を想定しておられますでしょうか。 　gotoって、現状のcrowbarのような、解析木実行形式の言語だと、結構実装が 難しいと思っています。バイトコード実行形式だと楽なんですが。 　制御構造をライブラリで提供する、というのは、crowbarでも考えてはいて、 クロージャで実現できると思ってはいますが… 　foreach(collection, function(item) { print(item); }); こんな感じだと読みにくいですかねえ。 > return x + y, x * y #戻り値の数は任意個数 >b, a = a, b #スワップ これはおそらくリストのような概念を導入し、コンマで区切った式でリストが 生成され、代入時左辺がリストで区切られていると、対応する要素に代入される、 ということですよね。 関数呼び出しの際も引数がコンマで区切られていますが、これも、リストとして 渡されて、仮引数に代入される、ということでしょうか。面白そうだと思います。

>>Java並みとはいわないまでも、Digital Marsにはもうちょっとがんばって、 >>標準ライブラリをもう少し整えてもらいたいものです。 > >　むむ。言語作りかけの身としてはプレッシャーです (^^; うっ、墓穴だったかも(^-^;; でも思うに、言語仕様はシンプルで、機能はライブラリとして実現するのがやっぱり移植性とかメンテナンスとかを考えるとベストなので、ライブラリ作りは必須ですよね。でも、それこそシェアを握っている言語のライブラリ相当をそろえるのは不可能なので、 >いっそWindowsに特化してゲームとかを楽に作れる言語にしようか、とか >考えているところです。 特定用途に特化したライブラリでテリトリーを構築するのはよい案ですね。かくいう僕はターゲットはまだ決めてないんですが、プロトタイプはこんな言語にしようと考えています。 ・いわゆる型なし ・制御構文はとりあえずifとgotoのみ（とほほ・・・） ・他の制御構文はifとgotoで実装してライブラリ提供 def foo(x, y) { #関数宣言 return x + y, x * y #戻り値の数は任意個数 } a, b = foo(10, 20) #セミコロン不要 b, a = a, b #スワップ print(b, " ", a) 上記コードで 30 200 と表示されるような。

>前橋さんもおっしゃってましたけど、DはCやJavaに比べて決定的にライブラリや >ツールが不足していて、言語仕様的には同等あるいは勝っているにも関わらず、 >ちょっと大き目のコードを書こうと思うととたんに苦しくなります。 　なるほど。 　でも、Cと比べれば、これだけ揃ってればまあそこそこ、という気もします。 　http://www.kmonos.net/alang/d/phobos.html 　GUIはWindowsのAPIを叩けるわけですよね。 >Java並みとはいわないまでも、Digital Marsにはもうちょっとがんばって、 >標準ライブラリをもう少し整えてもらいたいものです。 　むむ。言語作りかけの身としてはプレッシャーです (^^; 　言語そのものの機能が一通り揃ったら、鬼車でもくっつけるか、 いっそWindowsに特化してゲームとかを楽に作れる言語にしようか、とか 考えているところです。

　さっき私も、繋がらないなあ、と思っていたのですが、復旧したようです。 　レンタルサーバ屋さんのお知らせより。 >上位回線プロバイダIDCの管理下にあるレイヤ3ファイアウォールルータの障害により、 >本日12:10頃より13:00頃の間、一時的にサーバーに接続できない状態となっておりま >した。 >現在は復旧いたしましたので、アクセス可能となっております。 >この度は障害によりご迷惑をお掛けし、誠に申し訳ございませんでした。

>「フロンティア」は「あがり」なのか「ババをひく」係なのか… >いやその第三者的には是非ともがんばっていただきたく(ひでぇ) 前橋さんもおっしゃってましたけど、DはCやJavaに比べて決定的にライブラリやツールが不足していて、言語仕様的には同等あるいは勝っているにも関わらず、ちょっと大き目のコードを書こうと思うととたんに苦しくなります。 Java並みとはいわないまでも、Digital Marsにはもうちょっとがんばって、標準ライブラリをもう少し整えてもらいたいものです。

>lex/yaccで独自言語を作った場合、gccのフロントエンドにして各種Linuxディストリ >ビューションに標準で組み込まれるのが、もっともよいあがりですか。 現状で、個人作の独自言語で成功しているものというと、私としては PerlとかRubyとかPythonとかが浮かぶわけですが、このへんはたいてい ネイティブコードに落とさずインタプリタで実行していますよね。 # Dは違いますけど。 でも、多少なりとも速度を求めるのなら、JITでJavaやC#に勝負を挑むのは無謀なので、 gccのバックエンドを使ってネイティブコードを吐かせるというのは妥当な手段の ような気もします。というわけで自分用のメモ。 GCC Frontend HOWTO http://www.tldp.org/HOWTO/GCC-Frontend-HOWTO.html >JavaCCの場合は、Java VM上で動くようなバイトコードを吐いてWrite Once, >Run Anywhereなんでしょうか。 JVMのバイトコードを吐くのは簡単だと思うのですが、JVMはJavaの言語仕様に 強く依存しているのがなんとも… CLRはよく知らないのですが、JVMより制限が緩いようなら、勉強しようという 気になります。 >Dで独自にパースする場合は、D言語フロンティアになる、ってところでしょうか。 「フロンティア」は「あがり」なのか「ババをひく」係なのか… いやその第三者的には是非ともがんばっていただきたく(ひでぇ) >まだlex/yaccかJavaCCか確定していませんが、理解度からすると8:2でlex/yaccですね。 了解です。もしよろしければ公開を希望、という意思表示だけしときます、 ということにさせていただきたく存じますです。

こんばんは。緒方です。 >>前橋さんがlex/yaccで作られるので、やっぱりそうかぁ～、ということで >>僕もそうしようと思います。 > >いやどうせならここは敢えて違う方法をとってみるということでひとつ。 ># 別にプレッシャーかけるつもりはないですが… (^^; それぞれで作った場合の「あがり」について考えるわけです。「あがり」というのはサラリーマンなら社長、政治家なら総理大臣、フリーターなら発明家、という人生ゲームのそれです。 lex/yaccで独自言語を作った場合、gccのフロントエンドにして各種Linuxディストリビューションに標準で組み込まれるのが、もっともよいあがりですか。 JavaCCの場合は、Java VM上で動くようなバイトコードを吐いてWrite Once, Run Anywhereなんでしょうか。 Dで独自にパースする場合は、D言語フロンティアになる、ってところでしょうか。 他にもSmalltalkで書いてSmalltalk VM上で動作するようにしようかとか、C#で書いて.NET上で動作するようにしようかとかも考えたのですが、現実的なのはコンパイラコンパイラで作る方法なので、というかフルスクラッチはさすがにげんなりですね。 まだlex/yaccかJavaCCか確定していませんが、理解度からすると8:2でlex/yaccですね。

>こんばんは、はじめまして。緒方と申します。 　どうも。はじめまして。書き込みありがとうございます。 >新しく始められた「プログラミング言語を作る」は僕にとってすごく >タイムリーな話題です。僕も今年に入ってから独自言語の「構想」を練っています。 　独自言語の構想を練るのも楽しいですよね。 　欲張りすぎると発散するケースが多いのですが… (経験上) >前橋さんがlex/yaccで作られるので、やっぱりそうかぁ～、ということで >僕もそうしようと思います。 いやどうせならここは敢えて違う方法をとってみるということでひとつ。 # 別にプレッシャーかけるつもりはないですが… (^^; >連載楽しみにしています。 　それがその、最近体調が優れないのと、仕事のほうがアレなので、あまり時間が 避けそうにない状況です。 　ただ、まぬけなバグが2件、残ったままになっているのは気持ちが悪いので、マイナー バージョンアップ版(配列なしでbooleanとネイティブポインタ型を組み込んだ版)を、 さっさと出そうと思います。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ディスカバリーネットのSOHOアルバイター急募要項 ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ 夢のパソコンライフで副収入を得てみませんか？ ノルマやペナルティーはなく、１日３０分から１時間程度のお仕事です！ 風俗的、反社会的な業務を委託することは一切ございません。 一攫千金は無理ですが、少しずつ確実に収入を得たい方は必見です！ ディスカバリーネットは、SOHOで高収入を得るお手伝いをいたします！ お申し込みの際には紹介者ＩＤ【ＨＳ‐８７】が必要になります。 ↓このHPに登録してみましょう！(詳細はこちら) http://discovery.sub.jp/

こんばんは、はじめまして。緒方と申します。 新しく始められた「プログラミング言語を作る」は僕にとってすごくタイムリーな話題です。僕も今年に入ってから独自言語の「構想」を練っています。 lex/yaccを使用するか（この場合実装はC/C++）JavaCCを使用するか（これなら実装はJava）、それとも構文解析機は手書きするか（だとすると実装はD）、かなり長い間悩みました（電卓がいくつか出来上がりました^^;）。前橋さんがlex/yaccで作られるので、やっぱりそうかぁ～、ということで僕もそうしようと思います。 連載楽しみにしています。

>「センス・オブ・プログラミング」購入しました。 どうもです。お買い上げいただきありがとうございます。 >ところがこの本は違う！いわば企画モノですがパワーがあります。 (たぶん)おほめいただきありがとうございます。 企画モノAV…　いや別に嫌いなわけじゃないですが(ぉぃ >きちんと読み込みたいです。Cの本も読んでみます。 こちらもよろしくお願いします。

>ほげほっぽなる麦焼酎があるようです。仕事の後に、ほげほっぽ。 　風邪引いて寝込んでいます。返事が遅くなりましてすみません。 　情報ありがとうございました。今やる体力はないですが、後ほど 「ほげを考えるページ」に追記しておきます。

マエバシさん はじめまして。 「センス・オブ・プログラミング」購入しました。 かなり良い本ですね～！！ 書店でぱっと手にとって、つい買ってしまいました。 初心者向けにもかかわらずかなり高度な内容が書かれていて グッジョブ！です。 日経BPに似たようなサイズの本がありますが、あちらはいわば 有名AV女優のようなもの。 なんかお高くとまってイマイチ・・・な気がしていました。 ところがこの本は違う！いわば企画モノですがパワーがあります。 そしてなにより愛がある！！ 技術的に普段どうなんだろうね・・と思っていた点にも明快に 書かれていて非常にコ気味良かった（ハンガリアン表記法など）。 そしてこれだけ笑える技術書というのも珍しい！ 「おかしい・・・・どこもおかしくない」は爆笑す！ ワタクシデビューが遅く小さなシステム屋でaccessVBAでシコシコ作ってました。 このたび、けっこう大きめのところに開発で入ることになり 本格的に勉強せねばと思い本を買いあさっていたところです。 きちんと読み込みたいです。Cの本も読んでみます。 ありがとうございました～。

ほげ症候群から抜け出せません。気が付くと、ほげほげしてしまいます。 ほげほっぽなる麦焼酎があるようです。仕事の後に、ほげほっぽ。

ご回答有難うございます。 遅くなりまして申し訳有りません。 > その mingw\stdio.h は使われていないからです。 > cygwin の gcc のデフォルトは -mcygwin であり mingw ではありません。 > とりあえず gcc -mno-cygwin test5.c とすればコンパイル通るような気もします。 これで出来ました。 実行結果も同じになりました。 「-mno-cygwin」オプションはMinGWランタイムライブラリを使用せよリンクの為のオプションなのですね。 ランタイム…関連するヘッダファイルと対応するライブラリの総称 > ちょっと調べれば判る程度の問題だと思うのですが、聞く前に調べましたか？ 文法エラーとばかり思い込んでいました。 > ただ、\cygwin\usr\include\mingw\stdio.hを見つけることができたなら、 > \cygwin\usr\include\stdio.hを先に見つけてそうですし、ふたつあるなら > どっちか片方が使われているはずで、デフォルトで使われるのは、 > パスの短い方(\cygwin\usr\include\stdio.h)と推論するのが普通じゃないかなあ、 > とは思います。 そういわれてみればそうですよね。 スイマセン。二つあるのもそんなものなのかなと思って疑問視してませんでした。 > \cygwin\usr\include\stdio.hそのものにFILEの定義はないかもしれないですが、 > そこから#includeしているファイルの中にあるはずです。 \cygwin\usr\include\stdio.h内に typedef __FILE FILE; を見つけ ↓ \cygwin\usr\include\sys\reent.h内に typedef struct __sFILE __FILE; を見つけ ↓ \cygwin\usr\include\sys\reent.h内に struct __sFILE { unsigned char *_p; /* current position in (some) buffer */ int _r; /* read space left for getc() */ int _w; /* write space left for putc() */ short _flags; /* flags, below; this FILE is free if 0 */ short _file; /* fileno, if Unix descriptor, else -1 */ struct __sbuf _bf; /* the buffer (at least 1 byte, if !NULL) */ int _lbfsize; /* 0 or -_bf._size, for inline putc */ #ifdef _REENT_SMALL struct _reent *_data; #endif /* operations */ _PTR _cookie; /* cookie passed to io functions */ _READ_WRITE_RETURN_TYPE _EXFUN((*_read),(_PTR _cookie, char *_buf, int _n)); _READ_WRITE_RETURN_TYPE _EXFUN((*_write),(_PTR _cookie, const char *_buf, int _n)); _fpos_t _EXFUN((*_seek),(_PTR _cookie, _fpos_t _offset, int _whence)); int _EXFUN((*_close),(_PTR _cookie)); /* separate buffer for long sequences of ungetc() */ struct __sbuf _ub; /* ungetc buffer */ unsigned char *_up; /* saved _p when _p is doing ungetc data */ int _ur; /* saved _r when _r is counting ungetc data */ /* tricks to meet minimum requirements even when malloc() fails */ unsigned char _ubuf[3]; /* guarantee an ungetc() buffer */ unsigned char _nbuf[1]; /* guarantee a getc() buffer */ /* separate buffer for fgetline() when line crosses buffer boundary */ struct __sbuf _lb; /* buffer for fgetline() */ /* Unix stdio files get aligned to block boundaries on fseek() */ int _blksize; /* stat.st_blksize (may be != _bf._size) */ int _offset; /* current lseek offset */ #ifndef _REENT_SMALL struct _reent *_data; /* Here for binary compatibility? Remove? */ #endif #ifndef __SINGLE_THREAD__ _flock_t _lock; /* for thread-safety locking */ #endif }; を見つけました。

時間がないのでちょっとだけ。 >ちょっと調べれば判る程度の問題だと思うのですが、聞く前に調べましたか？ MinGWとcygwinの関係とかに関する知識がないと、そっち方向を調べることを 思いつかなくても不思議はないかもしれません。 ただ、\cygwin\usr\include\mingw\stdio.hを見つけることができたなら、 \cygwin\usr\include\stdio.hを先に見つけてそうですし、ふたつあるなら どっちか片方が使われているはずで、デフォルトで使われるのは、 パスの短い方(\cygwin\usr\include\stdio.h)と推論するのが普通じゃないかなあ、 とは思います。 \cygwin\usr\include\stdio.hそのものにFILEの定義はないかもしれないですが、 そこから#includeしているファイルの中にあるはずです。

その mingw\stdio.h は使われていないからです。 cygwin の gcc のデフォルトは -mcygwin であり mingw ではありません。 とりあえず gcc -mno-cygwin test5.c とすればコンパイル通るような気もします。 ちょっと調べれば判る程度の問題だと思うのですが、聞く前に調べましたか？

遅くなりまして申し訳有りません。 > というわけで修正プログラムです。 ： > return 0; > } 大変有難うございます。 でもコンパイルすると $ gcc -o test5 test5.c test5.c: In function `dump_buffer': test5.c:7: error: structure has no member named `_cnt' test5.c:8: error: structure has no member named `_ptr' test5.c:11: error: structure has no member named `_ptr' となってしまい、プログラム実行できずじまいです。 cygwinのを(\cygwin\usr\include\mingw\stdio.h)調べてみましたら #ifndef _FILE_DEFINED #define _FILE_DEFINED typedef struct _iobuf { char* _ptr; int _cnt; char* _base; int _flag; int _file; int _charbuf; int _bufsiz; char* _tmpfname; } FILE; となってました。 うーん、どうしてコンパイルエラーになってしまうんでしょうか?

まず前回のコードにポカがあったので再掲します。ついでに色々いじりました。 >　_baseがバッファの根元を押さえ、_cntが現在格納されているデータのサイズだと >想像し(外しているかも)、こんなプログラムを書いてみました。 baseはおそらくバッファの根元を押さえているのでしょうが、バッファから 1文字消費されるたびに中身を移動させていくとは思えないので、 おそらく環状バッファか何かになっていて、現在バッファリングされている 内容の先頭は_ptrが抑えているのでしょう。 というわけで修正プログラムです。 #include <stdio.h> void dump_buffer(FILE *fp) { int i; printf("["); for (i = 0; i < fp->_cnt; i++) { if (fp->_ptr[i] == '\n') { printf("<\\n>"); } else { putchar(fp->_ptr[i]); } } printf("]\n"); } int main(void) { int c; for (;;) { dump_buffer(stdin); c = getchar(); if (c == EOF) break; putchar(c); } return 0; } うちの環境での実行結果。 C:\ctest>buffer [] abcdefg a[bcdefg<\n>] b[cdefg<\n>] c[defg<\n>] d[efg<\n>] e[fg<\n>] f[g<\n>] g[<\n>] [] さて、 >> C:\ctest>buffertest >> aaa >これはエコーバックですよね。 そうです。 >> [aaa] >これはdump_buffer関数でのputchar、printf出力ですね。 そうです。 >> a[aa] >aが一回だけ入力されているのにこのようになるのですかね?? ここに誤解があります。ここで左端に出ている[]に入らないaは、 エコーバックではなく、main()の中でputchar()されている文字です。 つまり、手で「aaa」と入力すると、バッファから1文字ずつ消費しながら putchar()している、という様子を示しているわけです。 # でも、前回のプログラムに「abc」と入れると、変な出方をするのでした(^^;

ご回答大変有難うございます。 > 掲示板では一般にマルチポストは嫌われます。 マルチだと思われたのならお詫び致します。ｍ(＿ ＿)ｍ > 　ただ、今回の例だと、時期がずれていて、質問内容も違うので、マルチポストに > 当たるかどうかはわかりません。 そう思っていただければ大変助かります。ｍ(＿ ＿)ｍ > が、この手の掲示板を見ている人は、同じような > ジャンルの掲示板は見ていることが多い、ということは意識している必要があると > 思います。かずまさんも、たまにこの掲示板にも登場されます。 今後、誤解が生じませぬよう成るべく異なるサンプルリストを提示するよう心がけま す。 >>select関数についての振舞いについて調べています。 > 端末ドライババッファとstdinバッファの振舞いについて調べるのに、 > わざわざselectを使う必要があるのでしょうか。もちろん別にselectでもいいです > が、 > getchar()とputchar()でもよいような。 そうですか。参考にしてみます。ただ、最近、select関数を知ったのでちょっと使っ てみたくなりまして。 > 　端末ドライバのバッファは覗けないと思います(少なくとも標準的な方法では)。 > 　標準入力のバッファは、FILE構造体に紐づいていますから、stdio.hから > 調べればよいでしょう。 > 　私の環境(gcc (GCC) 3.4.2 (mingw-special))ではこうなっていました。 ： > > [実行結果] > C:\ctest>buffertest > aaa これはエコーバックですよね。 > [aaa] これはdump_buffer関数でのputchar、printf出力ですね。 > a[aa] aが一回だけ入力されているのにこのようになるのですかね??

　はじめまして。 >　それはさておいて、なんとなしに同書の正誤表を見ていたら「賭け網」と書かれた >箇所に気づきました。「賭け」でよかったのかな、と思ったもので。ちなみにGoogleで >検索するとこちらのサイトがトップ３にランクインしてました。 　ご指摘ありがとうございます。まぬけなポカでした。修正しました。

　貴著「センス・オブ・プログラミング！」が図書館にあったので今度借りようと思っている者です（著者さんとしてはうれしさ半減？）。 　それはさておいて、なんとなしに同書の正誤表を見ていたら「賭け網」と書かれた箇所に気づきました。「賭け」でよかったのかな、と思ったもので。ちなみにGoogleで検索するとこちらのサイトがトップ３にランクインしてました。

　掲示板では一般にマルチポストは嫌われます。 　ただ、今回の例だと、時期がずれていて、質問内容も違うので、マルチポストに 当たるかどうかはわかりません。が、この手の掲示板を見ている人は、同じような ジャンルの掲示板は見ていることが多い、ということは意識している必要があると 思います。かずまさんも、たまにこの掲示板にも登場されます。 >select関数についての振舞いについて調べています。 端末ドライババッファとstdinバッファの振舞いについて調べるのに、 わざわざselectを使う必要があるのでしょうか。もちろん別にselectでもいいですが、 getchar()とputchar()でもよいような。 ... >端末ドライバのバッファやstdinバッファの中身を覗くにはどうすれば >いいのでしょうか? 　端末ドライバのバッファは覗けないと思います(少なくとも標準的な方法では)。 　標準入力のバッファは、FILE構造体に紐づいていますから、stdio.hから 調べればよいでしょう。 　私の環境(gcc (GCC) 3.4.2 (mingw-special))ではこうなっていました。 typedef struct _iobuf { char* _ptr; int _cnt; char* _base; int _flag; int _file; int _charbuf; int _bufsiz; char* _tmpfname; } FILE; 　_baseがバッファの根元を押さえ、_cntが現在格納されているデータのサイズだと 想像し(外しているかも)、こんなプログラムを書いてみました。 #include <stdio.h> void dump_buffer(FILE *fp) { int i; printf("["); for (i = 0; i < fp->_cnt; i++) { putchar(fp->_base[i]); } printf("]\n"); } int main(void) { int c; while ((c = getchar()) != EOF) { dump_buffer(stdin); putchar(c); } } [実行結果] C:\ctest>buffertest aaa [aaa] a[aa] a[a] a[] bbb [bbb] b[bb] b[b] b[] 　それっぽく動いているように見えます。 　重要なのは、標準入出力ライブラリの関数は、そのバッファリングのメカニズムを 含め、普通にCで、システムコールの上に実装されている、ということです。 実装を想像すると、理解が深まると思います。

http://www3.realint.com/cgi-bin/tarticles.cgi?pointc2+3409 ここの人ですか？ せっかく「とても適切でわかりやすい」回答があるのですから、 １００回くらい繰り返して読むべきです。

select関数についての振舞いについて調べています。 (Win2k+Cygwin) #include <stdio.h> #include <string.h> #include <stdlib.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h> #include <sys/types.h> #include <curses.h> #include <signal.h> #include <unistd.h> //=================== void session_loop(){ fd_set mask; FD_ZERO(&mask); FD_SET(0,&mask); fd_set readOK; int width=1; char c; printf("う\n"); while(1){ printf("あ\n"); readOK=mask; printf("こwidth=%d\n",width); select(width,(fd_set *)&readOK,NULL,NULL,NULL); printf("け\n"); if ( FD_ISSET(0, &readOK ) ){ printf("い\n"); c=getchar(); //getcharはバッファリングあり関数 printf("c=%c\n",c); printf("さ\n"); } } } //================= int main(void){ session_loop(); return 0; } というリストで 端末ドライババッファやstdinバッファの振舞いについて学習しています。 端末ドライバにバッファリングされた文字群がgetchar関数のread要求とかでstdinバッファに排出される様子や stdinバッファの文字群がgetchar関数の読込み毎に減っていく様子を垣間見たく思っています。 端末ドライバのバッファやstdinバッファの中身を覗くにはどうすればいいのでしょうか?

>　ゲームプログラマじゃないですって(^-^;) ありゃりゃ、すみません。旧掲示板でゲームのフレームワークの話をしておられたので ゲーム系の人かと思ってました。失礼しました。 >　あとは「僧侶が使うと魔法が発動するが、勇者が使うと武器になる」とか >「フィールドによっては効果が封印されてしまう」など作り込み次第で例外は >いくらでもありそうです。 … >　あとはリフレクトされるカウンターなんかがあると更に面倒になるのでしょうね。 >そしてそのカウンターに「反応」できるとなると・・・考えるだけで目が回りそう >です。 うわあ。なるほど。 これで、武器や職業の種類が少なければ、いっそif文べたべたでやってしまえという ことになりそうですが、おそらくそうでもないんでしょうね。 大筋はポリモルフィズムで、例外的なのはif文で場合分け、とかするのかな。 何にせよ大変そうです。

　ゲームプログラマじゃないですって(^-^;) 大昔に書いたと思いますがバリバリC/S系です。 # 確かに趣味ではゲーム作ってますけど・・・ 　Cでも関数は書き方、作り方にある程度の定石がありますが、結局のところは適材適所になって例外はいくらでもあるわけで、この辺りは悩みどころかもしれませんね。CADに関してはやったことないのであまり深く言及できませんが、ShapeのZオーダだけで単純に判定できなそう、くらいの認識です。 >　このへんは、ダブルディスパッチ(いや、Character→Arm→Enemyのトリプル >ディスパッチかな)でいけそうな気がしますが、どうなんでしょうか。 　そうですね・・・アイテム攻撃でも「武器を選択すれば殴れる」ような場合とか「魔法が発動してしまう」場合もあるのでもう1回くらいディスパッチが必要になるかもしれませんね。 　あとは「僧侶が使うと魔法が発動するが、勇者が使うと武器になる」とか「フィールドによっては効果が封印されてしまう」など作り込み次第で例外はいくらでもありそうです。 　ひと昔前のRPGであれば、攻撃が0、魔法が1などになっていて、引数でどの武器、どの魔法なんて指定していましたが、それをしっかりOOPで纏めるほどディスパッチの回数が多くなりそうな気がします。 　あとはリフレクトされるカウンターなんかがあると更に面倒になるのでしょうね。そしてそのカウンターに「反応」できるとなると・・・考えるだけで目が回りそうです。

>使う側は全体魔法の場合は、こう書く...かなぁ? > for( i=0; i<number_of_enermy; i++) Attack( enermy[i], magic); 「全体魔法の場合は」というif文が出てくるのが、本来は美しくないんでしょうけど。 現実問題そこの場合分けなしではうまく書けないのかもしれませんし。 >でも、やっぱりattack()がintを返すのは問題かなぁ。 >enermyのステータスなり何なりに効果を与えるのが自然...かな？ ということで、条件分岐は避けられないとするのなら、いっそget_attack_point() にして後の判断は上位に任せるという方法もあるかとは思います。OO的ではないですが。 もちろん、そのメソッド名が「attack()」では全然ダメですけどね。

私はそもそもRPGをろくすっぽやったこともないんですが。 # 家庭用ゲーム機持ってないもんで… # 大昔、PC1500版labyrinthを作ろうとして挫折した記憶が(以下略) >　これもまた面倒で、明らかに敵のグループを選択して魔法を撃つ場合と、 > フィールド上で「ボカーン！」と爆発する魔法を撃つ場合を考えないと > いけないでしょうね。（後者は味方の巻き添えもありえますし） 　プロのゲームプログラマさんの投稿ありがとうございます。 　こういうのは、いわゆる「教科書的なOO」が適用できないケースですよね。 RPGに限らず、CADなどでも、例外的な事象はいくらでもあるわけで。 　ユーザが画面上である座標をクリックしたとき、最寄の図形を選択したいわけですが、 ・「折れ線」の上に「中間点(vertex)」がある場合、vertexを優先して検出したい。 ・せっかく直線を選択したのなら、クリックした座標から下ろした垂線の足も 　検出したい。 　とかの要望も出てきて、 　Shape#distance(double x, double y) 　をいろんなShapeでオーバーライドすれば完璧! とはなかなかならないのが現実です。 >　ですからAttackTo(Enemy)と書いた場合でも、内部的にはEnemy.DamageFrom(This)と >書いて、Enemy側で「その攻撃が本当にダメージになるか」などを判断する必要が >あるのじゃないかと思います。 　このへんは、ダブルディスパッチ(いや、Character→Arm→Enemyのトリプル ディスパッチかな)でいけそうな気がしますが、どうなんでしょうか。

>「はてな」で書くときの癖で改行入れるの忘れました・・・orz これなんですが、この掲示板では当初発言内容をすべて<pre>で囲んでいたため、 手で改行を入れないと改行されなかったのですが、 現在は、<tt>で囲み、かつ空白を&nbsp;に置換することで、 改行を行いつつ、ソースを貼っても極端にインデントが崩れないようにしています。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=25&range=1 # 要するに、OTDの時は<pre>で囲む以外手がなかったんだけど、今はスクリプト # 自体が自作なんだから、空白を&nbsp;に置換することなんて簡単なのに # しばらくそれに気付かなかった私がアホだったわけで。 よって、現在は、ことさら手作業で改行を入れる必要はなくなっています。 私は、返信の際にうまく「>」が入るように、改行を入れていますけど。 ということでお気になさらず。

>　・・・などとOOPでRPGを作成したことがないので自信なしですが(^-^;) 作成したことのある人のほうが少なそうに思えますが。さて。 >　あとはGetAttckPoint()メソッドを作る場合でも、内部ステータス的にアイテム攻撃になる場合もありますし、アンデッドのように属性で効果が変わる場合もあります。 攻撃の効果が相手によって変わるなんてのは 関数Attack()の実装を オブジェクト(攻撃対象)によって 異なる様に記述したいのだから、 継承なり仮想関数なりを使うのが自然なんでしょうかねぇ。 使う側は全体魔法の場合は、こう書く...かなぁ? for( i=0; i<number_of_enermy; i++) Attack( enermy[i], magic); なんかちょっと違う気がする...よーく考えないとあかんかなぁ。 でも、やっぱりattack()がintを返すのは問題かなぁ。 enermyのステータスなり何なりに効果を与えるのが自然...かな？

「はてな」で書くときの癖で改行入れるの忘れました・・・orz

>　Shapeと違ってCharacterは、そのRPGでしか使わないから、attack(Enemy)でも >良いような気もしますが、RPGではきっと「周囲にいる複数の敵にいっせいに >ダメージを与える技」ってのがありそうですし。 　これもまた面倒で、明らかに敵のグループを選択して魔法を撃つ場合と、フィールド上で「ボカーン！」と爆発する魔法を撃つ場合を考えないといけないでしょうね。（後者は味方の巻き添えもありえますし） 　前者も炎とかを出すのであれば後者のルーチンと共通化した関数にすることができそうですが、マインドアタックなどの場合は直接効果を与える処理（ステータスなども弄る処理）になるでしょうし。 　あとはGetAttckPoint()メソッドを作る場合でも、内部ステータス的にアイテム攻撃になる場合もありますし、アンデッドのように属性で効果が変わる場合もあります。 　ですからAttackTo(Enemy)と書いた場合でも、内部的にはEnemy.DamageFrom(This)と書いて、Enemy側で「その攻撃が本当にダメージになるか」などを判断する必要があるのじゃないかと思います。 　・・・などとOOPでRPGを作成したことがないので自信なしですが(^-^;)

>int get_attack_point() const { return power+weapon; } >int get_defence_point() const { return vitality+armor; } >ならとりあえず許します。 　これは同意です。 　私があちこちに書いている「Shapeにdraw()メソッドを入れてはいけない原則」に 則れば、attack(Enemy)よりもget_attack_point()の方が良いような気もします。 　Shapeと違ってCharacterは、そのRPGでしか使わないから、attack(Enemy)でも 良いような気もしますが、RPGではきっと「周囲にいる複数の敵にいっせいに ダメージを与える技」ってのがありそうですし。

attack() を動詞ととるなら確かに「設計がヘン」です。 こんな設計見せられたら、私も却下します。 int get_attack_point() const { return power+weapon; } int get_defence_point() const { return vitality+armor; } ならとりあえず許します。 初心者に最初に見せるサンプルというのはきわめて大事です。 「適切なサンプル」を見せるのなら良い。 「テキトーなサンプル」は見せるだけ有害です。 孵ったばかりの雛鳥と同じく、そのサンプルが刷り込まれてしまいます。 トンデモ系の設計を刷り込まれてしまった初心者のコードは手がつけられなくなります。

>単刀直入に言うと >「ゴチャゴチャ長ったらしい。いずれわかるものを余計にわからなくしてるんじゃないか」 繰り返し確認ですが(3回目くらいかしら)、これは、私が書いた 「疑り深いあなたのためのオブジェクト指向再入門」 http://kmaebashi.com/programmer/object/index.html に関する言及ですか? (Y/N) >で、ちょっとこう説明すればいいんじゃないかってのを書いたんで見てください >http://kill.s31.xrea.com/object.html で、こっちの説明のほうが、「疑りぶかい～」の説明よりも優れている、という 主張であると。 まあねえ、初心者向けにどんな説明がよいか、なんてことは、実際に初心者を大量に 連れてきてアンケートでもしないとわからないことなので、どっちが優れているかは 私にはなんとも言えませんが。 まあ、初心者としての感想は初心者の人に任せるとして、一応初心者ではないつもりの 私の目から、norgeさんの説明を見ると。 >結論：クラスは構造体としても使える 12～13年前のC++の入門書では、こういうふうに、クラスを構造体の拡張として 説明しているものが多かったですね。 で、getterとsetterをつけて、「ほらカプセル化できてるでしょ」とやるわけです。 が、この説明じゃ、norgeさん自身が書いているように、 >実際はこんなバカな事は誰もやらないだろうが、 と思われるだけでしょう。ていうか私がPointの例で言っているように、 setterを解放しといてカプセル化もクソもないもんだ。 おそらくnorgeさん自身そう思うからこそ、getter/setterの話より先に、 >構造体ではなくクラスを使う意味 として、 >public int attack() { > return power + weapon; //攻撃力と武器の攻撃力の和を返す >} これを出したんでしょうが… 「なぜattackすると整数値が返ってくるの?」 [258]の例: >public int run (int gas) { >　return (gas * this.mileage); >} 「なぜrunすると整数値が返ってくるの?」 「オブジェクト指向的に考えてこんなメソッドはおかしい」的な議論は私自身 嫌いなわけですが、そんな私から見ても、こんな設計、仮に仕事で若いのが書いてきたら コードレビューの段階で却下します。 void attack(Enemy) ならともかく。 だいたい、attack()みたいなメソッドをCharcterに入れるのは、ポリモルフィズムを 期待するのでもない限り無意味で、「char1.power + char.weapon」をあちこちに 分散させるのが嫌なら void attack(Character, Enemy) という「関数」を作ってもいいはずだから、「 >結論：簡単に記述できるようになる にはなりませんね。

どうもどうも、返事がアレだけだったんでしばらく見てなかった 単刀直入に言うと 「ゴチャゴチャ長ったらしい。いずれわかるものを余計にわからなくしてるんじゃないか」 と思ったもんで で、ちょっとこう説明すればいいんじゃないかってのを書いたんで見てください http://kill.s31.xrea.com/object.html あくまで「こんな感じに説明すればいいんじゃないか」というわけなんで実際に初心者に見せるときはもうちょい細かくわかりやすく書いた方がいいと思う

>細かいことを言えば、復活した新規投稿の投稿時刻が一律 >「2005/2/10 02:26:00」 >になってしまっているという問題が残っていますね。 言われて初めて気が付きました… 今回変更された6本の投稿について、日付が変わってしまったのは申し訳ないですが しょうがないとして(すみません)、 ・データ構造上、日付を保持するフィールドがposteddateしかないこと。 ・それがTIMESTAMP型であること。 ・よって、削除などを行った場合にも、posteddateが変更されてしまうこと。 は、仕様としてかなりどうかと思うので、いずれ修正しようと思います。 これまたご指摘ありがとうございました。

>D/Bを復元すると共に、スクリプトも修正しました。 ありがとうございます。 細かいことを言えば、復活した新規投稿の投稿時刻が一律 「2005/2/10 02:26:00」 になってしまっているという問題が残っていますね。 日付順のソートに影響があるわけでもないし、 大きな問題ではないとは思いますが……。 ともあれ、迅速に対応していただいてありがとうございました。

テストを兼ねて、敢えて返信ではなく新規投稿にしています。 >「スレッド順インデックス」の表示にすると、 >[292] 投稿者により削除されました >が一番上に表示され、 >それよりも後に立てられたスレッドが全く表示されなくなっていませんか？ D/Bを確認したところ、この掲示板では、新規投稿はparent(親投稿のID)がNULLに ならなければならないところ、すべてゼロになっていました。 結果として、全て投稿番号0の子になっていました。 saltがらみでスクリプトを修正した際、SQLをsprintf()で組み立てるところを 直していてポカしたようです。 >各投稿を「日付順インデックス」からたどって「この投稿を含むスレッドを表示」すると、 >どれも上の[292]に属しているような扱いになっている模様です。 これは、上記D/Bの崩れにより発生した問題のようです。 D/Bを復元すると共に、スクリプトも修正しました。 ご指摘ありがとうございました。テストが不十分ですみませんでした。

はじめまして。 ご著書、特に「ポインタ完全制覇」を愛読しております。 この掲示板の動作について疑問があるのですが、 「スレッド順インデックス」の表示にすると、 [292] 投稿者により削除されました が一番上に表示され、 それよりも後に立てられたスレッドが全く表示されなくなっていませんか？ 各投稿を「日付順インデックス」からたどって「この投稿を含むスレッドを表示」すると、 どれも上の[292]に属しているような扱いになっている模様です。 お時間がありましたらご確認ください。

(ぱ)さんへ。 hiroです。 先ほどの件、ファイヤーウォールが接続を制限していた為に 生じたものだったようです。 解除し、無事localhostへ繋がりました。 ご協力頂いて、有難うございました。

>>ERROR 2003: Can't connect to MYSQL server on 'localhost' >>(10061) >パスを通そうとして、上記エラーが出ることはないはずです。 > >mysqlのクライアントを立ち上げようとした時にこのエラーが出るのなら >わかりますが。 > >もし、コマンドプロンプトから「mysql」とタイプして上記メッセージが出るのなら、 >MySQLのサーバが起動していないのでしょう。サービスに登録するか、 >mysqldを実行する必要があります。 > >ウェルノウンポートでないだけで、65535までのポート番号は存在しうるでしょう。 > こんにちわ。 （ぱ）さん、ありがとうございます。 パスの件、クライアントを立ち上げようと思った、の間違いでした。すみません。 OSはおっしゃる通りWindowsなのですが、テキスト通り C:\mysql\bin\mysql -u root というコマンドを入力しても、サーバーには接続されないという上記のメッセージ が表示されてしまいます。 コマンドプロンプトからユーザー名やパスワードを確認し、起動したいのですが、 どうすれば接続できるのでしょうか？ ちなみにサービスは登録されており、「mysql」は管理ツールから開始できる状態です。 お手数ですが、アドバイスを宜しくお願いいたします。

>ほとんど文脈無視ですが_o_、salt として本文を使うってのはどうですかね？ むにゃ。もう直しちゃいましたし (^^; saltとして本文を使うということは、D/B流出がなくてもsalt漏れまくり、 ということですから、秘密の文字列を併用しなければだめでしょうけど、 それ前提なら使える手かとは思います。 でも、複数の投稿に同じsaltが振られる可能性がそこそこありますし、 別にフィールドを増やすことは可能なので、本文を使う必然性はないですよね。

>>最近Ｃ言語を始めたのですが、この問題がどうしても解けません。誰かといてください。お願いします（＞＿＜） > >　宿題は自分でやるべきでしょう。 初めまして、どぅと申します。 前橋さまの「C言語 ポインタ完全制覇」と「Java謎+落とし穴徹底解明」によって蒙を啓かれた者です。まだ理解できていないところもありますが、この二冊には大変お世話になっております（現在進行形）。 さて、本題ですが、宿題は自分でやるべきで、それがマキバオーさんの為だと思いますし、それゆえ(ぱ)さまは流石思いやりのある対応をされたなぁと思うのですが、残念ながら私は利己的で、マキバオーさんの為にはならないと知りながら、申し訳ないけど自分の興味の為に課題をやってしまいました。情けは人の為ならず（←ダブルミーニング！）。尤も正しい答えに到達しているかは分かりませんが。 この手の問題は、半分数学ですね。より正確に言うと、ドコまで数学で解いて、ドコからプログラムにやらせるか。これは連続的にスペクトルをなしていて、一方の端が、「全部人間様が数学を駆使して計算する」反対側の端が「全部プログラムにしてコンピュータが計算する」になってます。つまり大ざっぱにいうと、 １．全部数学で人間様がやる。 ２．半分数学で人間様がやって、半分プログラムにしてコンピュータがやる。 ３．全部プログラムにしてでコンピュータがやる。 の３パターンに分かれると思います。おそらく出題者は２を期待してるんじゃないかなーと思いますが、どうなんでしょ？１で解くと多分ダメなんでしょうね＾＾；とりあえず「おそらくこんな解が期待されてるんだろうなぁ」てな２の解を示して、その次に３の解を書いてみます。 ■パターン２ まず、n期目で残高があれば良い。そんで、n期目の残高は、nとmとb（と利率1.05)で決まりますね。つまりn期目の残高はn, m, bの関数になるので Z(n, m, b)と書けると。それが残っていると言うことは、 Z(n, m, b) > 0 となると。この不等式をbについて解けば良いわけですね。じゃあZ(n, m, b)って何なのよ？ こういうのはとりあえず普通１期目、２期目、３期目、ぐらいまで具体的に求めてみると何か見えてくる可能性があります。と言うわけで、各期の残高を求めてみると。。。 １期目：1.05(b - m) = 1.05b - 1.05m ２期目：1.05(1.05b - 1.05m - m) = 1.05^2b - 1.05(2.05)m ３期目：1.05(1.05^2b - 1.05(2.05)m - m) = 1.05^3b - 1.05(1.05(2.05) + 1)m ここら辺までくると何かが見えてきますね！？つまりi期目の残高は、 1.05^ib - ???m となりそうです。???のところをよーく見ると、 ???は、前期の???に1を足して、1.05倍する となってそうです。つまり、i期の???をY(i)とすると、 Y(i+1) = 1.05(Y(i) + 1) Y(1) = 1.05 と言えそうです。これ、漸化式ってやつだけど、どうやら解くのは面倒そうですね。。 ＃根性入れれば解けるので、そうすれば「１」のパターンになる！！ とりあえず、Y(i)はそのまま（1から順番にやれば求まりそうだし）とすると、i期における残高は、 X(i)b - Y(i)m ただし、X(i) ,Y(i)は次の通り、 X(i) = 1.05^i Y(i)は、次の漸化式を満たす Y(i+1) = 1.05(Y(i) + 1) Y(1) = 1.05 で表されます。これがn期で残っていると言うことは、 X(n)b - Y(n)m > 0 と言うことになりますので、bについて解くと(X(n) > 0に注意して) b > Y(n)m / X(n) となります。Y(n)は漸化式にしたがって1から順番に計算していけば求まりますが、めんどいなぁ。誰かやってくれないかなぁ。。。人間様が考えるのはここまで。あとはコンピュータにやってもらいまひょ。ついでにX(n) = 1.05^nも計算してもらいます。 で、プログラムは次の通り。解に自信がなかったので、求まったbの値で本当に良いのか、各期残高を順に表示して検算もしてます。求まるbはぎりぎりの値なので、n年目には残高が0円になってしまいますが、bはそれより大きければ良いということで。。。 ちなみに、銀行でどの有効桁数で情報を持っているのか、つまり0.1銭とかにも利子が付くのか！？は気にしてません。doubleの有効桁数の範囲で計算してます。 あと、math.hが入ってますので、コンパイル時に-lmを忘れずに！（←なんて親切なんだ！？） #include <stdio.h> #include <math.h> #include <stdlib.h> int main(int argc, char** argv){ int n = 0; int m = 0; double x_n = 0.0; double y_n = 1.05; double b = 0.0; double zandaka = 0.0; int ii; /* パラメータチェック */ if ( argc != 3 ){ printf("usage %s n m\nn:期間 m:引き出し額\n", argv[0]); return 0; } /* パラメータ取得 */ n = atoi(argv[1]); /* 期間 n */ m = atoi(argv[2]); /* 引き出し額 m */ /* i期における残高: ( X(i) * b ) - ( Y(i) * m ) * ただし、 * X(i) = 1.05^i, * Y(i) : Y(i+1) = 1.05 * ( Y(i) + 1 ), Y(1) = 1.05 * n期において0円以上あるためには * (X(n) * b) - (Y(n) * m) > 0 * これを bについて解くと、 * b > Y(n) * m / X(n) */ /* X(n)を求める */ x_n = pow(1.05, n ); /* Y(n)を求める。ここがキモ */ for ( ii = 2; ii <= n; ii++ ){ y_n = 1.05 * ( y_n + 1 ); } /* b(の下限)を求める */ b = (y_n * m) / x_n; /* 残高の変化の様子を表示(検算) */ zandaka = b; for (ii = 1 ; ii <= n; ii++){ zandaka = 1.05 * ( zandaka - m ); printf("%3d: %f\n", ii, zandaka); } /* 表示 */ /* printf("X(n) = %f\n", x_n); */ /* printf("Y(n) = %f\n", y_n); */ printf("n = %d\n", n); printf("m = %d\n", m); printf("b > %f\n", b); return 0; } ■パターン３ 次に、人間様は何も考えないで、全部プログラムでコンピュータにやらせるパターンをやってみます。 b=1万円から初めて、n期目でも残高が残っているまで、bを1万円ずつインクリメントしていきます。なので、精度が1万円単位になってます。1円単位の精度が欲しい場合は0.0001万円から初めて0.0001ずつインクリメントすれば良いでしょう。10000倍遅くなりますが・・・ 言うまでもなく、このアルゴリズムは余りにバカ正直で（特に1円単位なると影響大）、普通はちょっと工夫すると思いますが、「人間様は何も考えない」パターンということで。 これをどうやって高速化するか（スペクトルをちょっと人間様寄りにする）は、マキバオーさんの宿題と言うことで。。。もしかしたらそれが求められている解かも？ #include <stdio.h> #include <stdlib.h> int main(int argc, char** argv){ double b = 0; int n = 0; int m = 0; double zandaka; int ii; if ( argc != 3 ){ printf("usage %s n m\nn:期間 m:引き出し額\n", argv[0]); return 0; } n = atoi(argv[1]); /* 期間 n */ m = atoi(argv[2]); /* 引き出し額 m */ /* n期目でも残高が残るまでbをインクリメントしていく */ for ( b = 1 ;zandaka <= 0 ; b += 1){ /* 残高を、残っている限り、最大n期目まで求める*/ zandaka = b; for (ii = 1 ; ii <= n && zandaka > 0; ii++){ zandaka = 1.05 * ( zandaka - m ); } } /* 残高の変化の様子を表示(検算) */ zandaka = b; for (ii = 1 ; ii <= n && zandaka > 0; ii++){ zandaka = 1.05 * ( zandaka - m ); printf("%3d:%f\n", ii, zandaka); } /* 表示 */ printf("n = %d\n", n); printf("m = %d\n", m); printf("b > %f\n", b); return 0; } ソースは無保証です！！！ ただ、バグのご指摘、ご批評など頂ければ幸いです。

>>これを気にするのであれば、salt とプログラム埋め込みのsecret >>の両方を使うのが良いと思います。どちらか片方だけであれば、 >>salt の方を選ぶのが良い習慣だと思います。 > >両方使うようにして、今までの分はsaltを空文字にしておけば、 >今までの投稿については、以前のパスワードが変わらず使えるかなあ、と >一瞬考えたのですが、D/B流出の時にパスワードがばれる危険性を考えて >いるのだからそれじゃ本末転倒ですね (^^; > >今までの投稿が削除できなくなってもおそらく誰も困らないでしょうから >(いまさら「しくじったので書き直し」はないでしょうから)、今度時間が >できたときに修正しておきます。 ほとんど文脈無視ですが_o_、salt として本文を使うってのはどうですかね？ 管理者による本文の修正は出来なくなりますけどね。

>最近Ｃ言語を始めたのですが、この問題がどうしても解けません。誰かといてください。お願いします（＞＿＜） 　宿題は自分でやるべきでしょう。

最近Ｃ言語を始めたのですが、この問題がどうしても解けません。誰かといてください。お願いします（＞＿＜） １．ある銀行では毎期末に預金残高に対して５％の利率で利息がつく．この銀行に，例えばa万円を一期間預金すると，期末には1.05×a万円の預金残高になる． 第1期の初めに，Ａさんはこの銀行にb万円の預金を持っている．Ａさんは，まずb万円から第1期分m万円を引き出す．残りの預金に対し第1期末に５％の利息がつく．ここで，b > mとする．第２期目からも毎期初めにこの預金からm万円ずつを引き出す．ただし，預金残高がm万円に満たないときには，その全額を引き出すものとする． Ａさんの預金残高がn期間にわたって0円とならないために必要な第1期初めの預金額「b」を計算したい．期間「n」と毎期の引き出し額「m」を入力して，上の条件を満たす最小の「b」を求めるプログラムを作れ．なお，単位は「万円」とする．また，n ＞＝ 2 とする．

　kitさんのご指摘を受けまして、パスワード認証にsaltを使うようプログラムを 修正しました。 　これに伴い、この投稿以前に設定した削除用パスワードは使えなくなっています。 あしからずご了承ください。 # ここで力尽きたので、解説記事の修正はまだ…

>MYSQLのことで、ご質問させて頂きます。 >インストール後に、コマンドプロンプトで >パスを通そうとしたところ、以下のエラーが表示されてしまいました。 > >ERROR 2003: Can't connect to MYSQL server on 'localhost' >(10061) Windowsでパスを通すとき通常コマンドプロンプトは使わないと思うし、 パスを通そうとして、上記エラーが出ることはないはずです。 mysqlのクライアントを立ち上げようとした時にこのエラーが出るのなら わかりますが。 もし、コマンドプロンプトから「mysql」とタイプして上記メッセージが出るのなら、 MySQLのサーバが起動していないのでしょう。サービスに登録するか、 mysqldを実行する必要があります。 >10061というポート番号は存在しないのは、理解しています。 ウェルノウンポートでないだけで、65535までのポート番号は存在しうるでしょう。

MYSQLのことで、ご質問させて頂きます。 インストール後に、コマンドプロンプトで パスを通そうとしたところ、以下のエラーが表示されてしまいました。 ERROR 2003: Can't connect to MYSQL server on 'localhost' (10061) 10061というポート番号は存在しないのは、理解しています。 なるべく具体的にどこのファイルをどう変更すると助言頂けると 助かります。 宜しくお願い致します。

>僕は大学生なのですが、プログラムの先生がhogeを多様していました。 ひょっとして WIDE 関係のネットワークの先生だったりしません？ >それどころかfugaなるものをも使用していました。 hoge, fuga は結構よく見ます。 hoge, huga という変種もあるようです。 google で探すと hoge, piyo より多いです。 hoge のページに記載してもいいですよねえ。

はじめまして。 むつかしい議論をしている最中恐縮ではありますが・・・ 僕は大学生なのですが、プログラムの先生がhogeを多様していました。 それどころかfugaなるものをも使用していました。 これはほげ学に新風を巻き起こすのでは、と思い、書き込みをしました。 よければ参考にしてください。

>で、そーいう入門段階を既に過ぎた人でないと >| 継承は確たる「設計思想」が無い場合、スーパークラスが単なる「ごみ置き場」 >| と化していることが多いようです。 >なんて議論は理解できないでしょう。 これはそう思います。 ># 今この場では「入門」の話に限定、していい？のですよね。 了解です。 ちょうどoosquare-mlで継承の話が出てたので[283]のように書きましたけど、 「継承の問題点」のような話は入門者にわかりにくいのは確かだと思いますので、 そういう話は別スレ立てることにして、今この場は「入門」の話に限定、しておきましょう。 まあ入門者相手でも、継承が「ソースの再利用のためのテクニック」だと言われれば それは変だと思いますが、774RRさんの出されている >「ほらほら、『使うほう』はその実体が具体的に何であるか気にしなくていいんだよ」 という例は、継承の使い方としてまっとうだと思いますし。

仕事中の現実逃避で、前橋さんが紹介されたoosquare-mlを読んでました。 読んだ感想なんですが、僕の中では、ただ単に「手抜きのために継承は使うな」って いうだけのような気がします。（考えなさ過ぎ？） 委譲を使ったとしても、やたらと関連が集中しているクラスを作ってしまったら、 結局ごみ置き場になってしまいますし。 > 「ぴゅあＯＯ」を学んでも、それが明日役立つか、って言われるとキツイものがあります。 > 「入門者でも即、目に見える価値」が無いと教える側としては困るのです。 僕はそれほど教える立場にはいないんですけど、確かにそれは感じますね。 2年ほど前にあったSun Super Tech DaysのBOFを覗いた時、どなたかが 「インドではプログラマを養成する際、UMLなどを使用して、まずオブジェクト指向から 叩き込む。実際のプログラムを教えるのはその後。日本のIT業界もそうでなければ。」 といった趣旨の発言をされていました。 その時は、「あー、そーなんだー。」ぐらいに思っていたんですけど、今になって 思えば、全然そんな事はないんじゃないかと。プログラマなんだから、まずプログラムを 覚えろと。 オブジェクト指向が有効かどうかという判断は、その後なんじゃないかと、最近では 思います。 例えばデザインパターンなんて教えるものじゃなくて、試行錯誤や見よう見真似で、 「気が付いたら使ってた」ぐらいが理想だよなぁ、なんて思ったりします。 で、教える側は、そこに到ることの出来る基礎を身につけさせてあげれば良いのでは、 そしてその基礎というものは、オブジェクト指向というよりも、「プログラムを組む ための地力」となる知識と経験なのでは、と思います。

飴と鞭、って鞭ぢゃないですけど、既に kei さまが [278] で述べられているとおり > 結局、「それが出来ると何がうれしいのか」ってことを実感してからじゃないと、 これが端的に直感できるのが「使うほうは基底クラス、実装するほうは派生クラス」 だと *個人的には* 思います。 飴が無ければ、鞭で叩かれないと新しい知識の勉強なんてしないでしょ？ # そーいうのに興味が無い人の場合。放っておいていい子は教えなくても勝手にやってるし。 C++ の場合 <algorithm> だけでも学ぶ価値＆即戦力になる実力があるのですが 「ぴゅあＯＯ」を学んでも、それが明日役立つか、って言われるとキツイものがあります。 「入門者でも即、目に見える価値」が無いと教える側としては困るのです。 で、そーいう入門段階を既に過ぎた人でないと | 継承は確たる「設計思想」が無い場合、スーパークラスが単なる「ごみ置き場」 | と化していることが多いようです。 なんて議論は理解できないでしょう。 # 今この場では「入門」の話に限定、していい？のですよね。

>従って、あらかじめ辞書を記憶媒体に作成するのは不可能で、全ての >メッセージについて、試行するしかありません。 >これに要する計算コストは、O(M*D) となり、M が大きければ、 >O(N) や O(D) よりも有意に大きな値になります。 納得しました。計算量はM倍ですよね。 うちの掲示板ではMがそんなに大きくないので、「全てのsaltに対応する 辞書を作成する」というのが現実的と思えず、「探索空間が salt のビット数分 広がる」のところで混乱していました。 丁寧な説明ありがとうございました。

>とりあえず俺的には入門者に最初に教えたいのが継承派生です。 ちょうど今、oosquare-mlで継承の是非に関する議論が白熱しています。 http://www.ogis-ri.co.jp/otc/otc2/oosquare-ml/Archive/thread.html なんかもう、「言葉の上だけの議論は空しい」状態になってる気もしますが… まあ継承には色々な問題があると私も思うんですが、一連の議論の中で、 http://www.ogis-ri.co.jp/otc/otc2/oosquare-ml/Archive/200501.month/4468.html | 継承は確たる「設計思想」が無い場合、スーパークラスが単なる「ごみ置き場」 | と化していることが多いようです。 これ、具体的にはどういう例なんだろう… あるクラス群が共通に使うメソッドを、それらのクラスのスーパークラスに 山ほど押し込んでいる、ってことかなあ。 スーパークラスには「外から見て」そのクラスに必要なメソッドが入っていれば よいわけで、サブクラスが共通に使うメソッドなんか持つ必要はないと 思うんですが。共通処理があるのなら、Utility.javaみたいな「関数」を 書けばいい。 >「ほらほら、『使うほう』はその実体が具体的に何であるか気にしなくていいんだよ」 >ある程度プログラム経験がある人だと、これで結構ぐらぐらしてくれます。 これはJavaならinterfaceですよね。 ただ、interfaceには実装がまったく書けないので、やっぱりデフォルトの挙動が 欲しい、とか思ったときに、DefaultHogeとかSimpleHogeとかAbstractHogeとか 作っちゃうわけで… これがよいのかどうか。 http://struts.apache.org/api/org/apache/struts/action/Action.html これなんかはどうなんだろう。私なら、こういうのは反射的にinterfaceにしますが。 クラスにした結果、結構ごみ置き場になってるような気も。

> また、異なるメッセージであっても、同一ユーザーは同じパスワードを > 使い回すと仮定します。 この仮定は本質的ではないので、N==M とおいて、 Sとして十分大きなビット数を用いると、辞書攻撃に必要な計算量が、 min(M*D/M, M*D/D) == min(D, M) 倍程度になるわけです。 と書いた方が分かりやすかったですね。

> saltがばれてる状態では、「探索空間が salt のビット数分広がる」 > ことはないように思いますが…まだ何か勘違いしてますでしょうか。 D: 辞書のサイズ S: salt のビット数 N: ユーザ数 M: メッセージ数 とします。 ここで、一つのMD5ハッシュ値から辞書を引いてパスワードを得るコスト を O(1) とします。 また、異なるメッセージであっても、同一ユーザーは同じパスワードを 使い回すと仮定します。 なお、2^S は、M より有意に大きいため、ほぼ全てのメッセージについて、 異なる salt が使われているものとします。 ここで、salt なしの場合、辞書作成に必要なコストは O(D)、辞書攻撃に 必要なコストは O(N) です。 では、salt ありの場合は、どうでしょう。 全てのありうる salt に対して辞書を作成するのに必要な計算コスト および記憶コストは O(D * 2^S) ですが、これは S が十分大きければ (例えば S=64) 計算量的にも、あるいは記憶容量的にも実現不能になります。 従って、あらかじめ辞書を記憶媒体に作成するのは不可能で、全ての メッセージについて、試行するしかありません。 これに要する計算コストは、O(M*D) となり、M が大きければ、 O(N) や O(D) よりも有意に大きな値になります。 すなわち、Sとして十分大きなビット数を用いると、辞書攻撃に必要な 計算量が、min(M*D/N, M*D/D) == min(M*D/N, M) 倍程度になるわけです。

なんだかすごく初心者な発言をしている気がしますが、聞くは一時の恥ということで。 >データベース中には複数のMD5化されたパスワードが存在する >わけですが、salt がないと、単一の辞書を使って、全ての >パスワードに対する試行を行うことができます。これに対し、 >salt があると、2 の salt のビット数乗 の辞書が必要になる >わけです。 つまりこういうことでしょうか。 ・パスワード候補となりうる文字列に「秘密」を連結し、MD5ハッシュ値を算出する。 　大量の文字列に対してこれを行い、辞書を作る。 ・辞書が何らかの記憶媒体に載るとしたら、ハッシュ値がばれればパスワードもばれる。 　ハッシュ値の方から逆引きできるようなしかけにしておけば一瞬。 ・辞書を作るにはひとつのパスワードを抜くのと同じ計算量が必要だけど、 　「秘密」方式では、その計算量で、全てのパスワードがばれる。 うーん、でも、 >salt があると、探索空間が salt のビット数分広がるため、 saltがばれてる状態では、「探索空間が salt のビット数分広がる」ことはない ように思いますが…まだ何か勘違いしてますでしょうか。 >これを気にするのであれば、salt とプログラム埋め込みのsecret >の両方を使うのが良いと思います。どちらか片方だけであれば、 >salt の方を選ぶのが良い習慣だと思います。 両方使うようにして、今までの分はsaltを空文字にしておけば、 今までの投稿については、以前のパスワードが変わらず使えるかなあ、と 一瞬考えたのですが、D/B流出の時にパスワードがばれる危険性を考えて いるのだからそれじゃ本末転倒ですね (^^; 今までの投稿が削除できなくなってもおそらく誰も困らないでしょうから (いまさら「しくじったので書き直し」はないでしょうから)、今度時間が できたときに修正しておきます。

http://cpan.org/ に行って「PDF」で検索してみるのもよいかも。

# どこにぶら下げようか迷いました。。 僕の職場の新人研修は、いきなりJavaです。 会社的には「今はJavaの案件が一番多いから」ぐらいの理由で選んでいるんだと 思います（情けない。。） で、そんな新人研修をしてきた後輩を見る限り、「オブジェクト指向から入れば 簡単」ということでは無さそうです。 確かに、概念的な部分の吸収は早いように感じます。 でもそれって、ただ単に「何も疑問を持たないから」ってだけなんですよね。 しかも、実際のコードでは、オブジェクト指向を「使えない or 使わない」んです。 結局、「それが出来ると何がうれしいのか」ってことを実感してからじゃないと、 使いこなすことが出来ないんじゃないかと思います。

>とりあえず俺的には入門者に最初に教えたいのが継承派生です。 あ、ここでの「入門者」は「プログラム経験があって、でもオブジェクト指向は入門者」です。 今年の新入社員君がプログラム経験無いようなら、いきなり C++ など逝ってみたいと思います。

ウチは組み込み屋さんなのでアセンブラ経験はほぼ全員が、C 経験は半数が、もっています。 C++ を本格的に使っているのは俺だけです。 次のプロジェクトでは後輩君に C を飛ばして C++ をいきなり使わせようとたくらみ中です。 # どうなることやら... とりあえず俺的には入門者に最初に教えたいのが継承派生です。 「ほらほら、『使うほう』はその実体が具体的に何であるか気にしなくていいんだよ」 ある程度プログラム経験がある人だと、これで結構ぐらぐらしてくれます。

あら、私のネタ振りから別スレッドに。 前橋さん> 自分自身がオブジェクト指向から入った人、またはそういう人を身近にたくさん 前橋さん> 見てきた人の経験を聞いてみたいです。 サンプルが少なくて申し訳ないですが、友人に 1 人、Java から本格的にプログラミングを始めた人がおります。 それ以前も C 言語を触ったことがあるのですが、"Hello, World." 程度でした。 私>「プログラミングは Java が初めて」という人ならこういう経験をしなくて済むかもしれません。 私> 何しろ邪魔する前知識が無いですから。 実はこれ、その友人のことなんです。 今度彼と会う機会があるので、もっと詳しくインタビューしてみますね。

> これですが、辞書攻撃を、Webで稼動中の掲示板に対して行うことを想定して > いますでしょうか。それとも、既にテーブル内容が流出していることを > 前提に、辞書攻撃でパスワードを解析しよう、というお話でしょうか。 テーブル内容が流出していることを前提にしています。 > 後者だとすると、テーブルが流出した時点でsaltはだだ漏れです。 そうです。 > これは、ひとつのパスワードがばれても、同じハッシュになっている他の > パスワードが芋づる式にばれることはない、ということでしょうか? 違います。辞書攻撃に必要な計算量が増えるという意味です。 > 同時間で、ほぼ同数のパスワードが抜かれてしまいそうに思う > のですが。 salt があると、探索空間が salt のビット数分広がるため、 辞書攻撃に要する時間が長くなります。以下のページにも、 同様な示唆があります。 http://www.itmedia.co.jp/enterprise/0307/24/epn09.html http://www.microsoft.com/japan/msdn/library/ja/f_and_m/html/vxconprotectingpasswordcredentials.asp データベース中には複数のMD5化されたパスワードが存在する わけですが、salt がないと、単一の辞書を使って、全ての パスワードに対する試行を行うことができます。これに対し、 salt があると、2 の salt のビット数乗 の辞書が必要になる わけです。 > 別の場所に置いてあるだけ"秘密"の方がまだマシかも。 これを気にするのであれば、salt とプログラム埋め込みのsecret の両方を使うのが良いと思います。どちらか片方だけであれば、 salt の方を選ぶのが良い習慣だと思います。

すみません、風呂の中で考えてたらちょっとわからなくなりました。 >今のやり方だと、仮に異なるユーザが同一のパス >ワードを利用していた場合、その事実を管理者は >知ることができるわけですが、salt を使えばその >心配もありません。 これはその通りだと思います。また、クラッカーにD/Bを継続的に監視されて いる場合、いろいろなパスワードで書き込んでみることで、パスワードを 推測することもできることになります。 >また、仮に "秘密" や salt が洩れた場合に、辞書 >攻撃への耐性が若干高くなります。(salt があると、 >同じ辞書は一つのメッセージにしか使えないため、 >探索空間が広くなる) これですが、辞書攻撃を、Webで稼動中の掲示板に対して行うことを想定して いますでしょうか。それとも、既にテーブル内容が流出していることを 前提に、辞書攻撃でパスワードを解析しよう、というお話でしょうか。 前者だとすると、"秘密"やsaltが漏れていようがいまいが関係なさそうですし (そもそもレンタルサーバ業者にプロセス止められそうですが)、 後者だとすると、テーブルが流出した時点でsaltはだだ漏れです。 別の場所に置いてあるだけ"秘密"の方がまだマシかも。 >同じ辞書は一つのメッセージにしか使えないため、 >探索空間が広くなる) これは、ひとつのパスワードがばれても、同じハッシュになっている他の パスワードが芋づる式にばれることはない、ということでしょうか? しかし、実際問題こんな掲示板の投稿が消されてもさしたる実害はないわけで、 問題は「お金が絡むようなところと共通のパスワードを使う人がいたケース」だと 思っています。 そんなユーザは投稿ごとにパスワードを変えたりしそうにないですし(そんな ユーザに限らずともそうなんじゃないかと思いますが)、同一ハンドルの人は 1回しか調べない、程度のことで、同時間で、ほぼ同数のパスワードが抜かれて しまいそうに思うのですが。 どちらが安全か、という問題以前に、まず私の認識は合ってますでしょうか?

便乗して・・・ Javaを教えるほうにC言語などを知らないで育った方が 一体どれくらいいるのかも知りたいかも。 （あくまで参考として）

まったく違う話題にシフトします。件名とスレッド変えました。 >「プログラミングは Java が初めて」という人ならこういう経験をしなくて済むかもしれません。 >何しろ邪魔する前知識が無いですから。 「Cなどの言語を知っている人は、今までの知識が邪魔をしてオブジェクト指向の習得が 難しいけど、最初からオブジェクト指向を覚えるのなら簡単だ」 とたまに聞きますけど、これはどの程度事実なんでしょうか。 たまに、上の言葉の後ろに「なにしろオブジェクト指向は自然だから～」というのが 続いたりすると、どうも眉に唾をつけたくなります。私の場合。 古い知識が邪魔をするという傾向はもちろんありますが(FORTRAN屋やCOBOL屋が設計した Cプログラムにどれほど泣かされたことか)、じゃあまったくの初心者がJavaから 入門したとして、最初に動かすプログラムがhello, world. だったら、結局のところ 手続き指向→オブジェクト指向の流れで習得することになるように思います。 Javaの場合、hello, world.といってもアプレットから入るんでしょうか。 その場合、#include <stdio.h>なんかとは比べ物にならないくらい「とりあえず こう書いとけ」的な記述が増えてしまいますが、まあ、それは「いずれ分かる」と 言っておけばよいでしょう。 んで、ただブラウザにhello, world.と表示されるだけのプログラムから 順次発展していく場合、どの辺で「オブジェクト指向」を意識することになるんでしょうか。 クラスがアプレットしかなければ、メソッドも単なる関数ですし、インスタンスフィールドは グローバル変数と同じです。 GUIのボタンを作ったりするところは、「決まり文句」としか思ってもらえない気も するんですが、こういうところから、だんだんオブジェクト指向になじんでいったり するのかな。 私自身はBASICから入ったクチですし、新人にJavaを教えたことは何度となくありますが うちの会社では新人はまずCの研修を受けてくるので、「オブジェクト指向から入門」 した人の観察例が私にはほとんどありません。 自分自身がオブジェクト指向から入った人、またはそういう人を身近にたくさん 見てきた人の経験を聞いてみたいです。

>つまり、"秘密" はソース埋め込みにせず、メッ >セージごとに乱数で生成することにし、salt 自体も >message表に記録しておくわけです。 毎度ながらご指摘ありがとうございます。 掲示板のパスワードとしてどこまでの仕様が必要であるかはさておき、 この記事を読んで「パスワードの暗号化はこうすれば万全なんだ」と思ってしまう人が いるとまずいので、取り急ぎ注釈をつけました。

PHPとMySQLで掲示板を作る / 削除 / 削除系ソース の hash_user_password() ですが、"秘密" は、 UNIX パスワードなどで使われている salt の やり方にするのはどうですか？ つまり、"秘密" はソース埋め込みにせず、メッ セージごとに乱数で生成することにし、salt 自体も message表に記録しておくわけです。 今のやり方だと、仮に異なるユーザが同一のパス ワードを利用していた場合、その事実を管理者は 知ることができるわけですが、salt を使えばその 心配もありません。 また、仮に "秘密" や salt が洩れた場合に、辞書 攻撃への耐性が若干高くなります。(salt があると、 同じ辞書は一つのメッセージにしか使えないため、 探索空間が広くなる)

私も横からすんません。 norge さんは「プログラミング自体初めての人」と「オブジェクト指向は初めての人」を一緒くたにしちゃって るんだと思うんですけど。推測ですが。 まぁ、「Java (オブジェクト指向言語) を学ぶ前に、C 言語 (手続き指向言語) で得た知識は一度きれいに忘れ てください」って入門書もあったりしますし、私も読んだことがあります。 そういうやり方も、アリかなぁとは思うのですが。一応書けるようにはなるし。 でもですねぇ…、Java で得た知識と C 言語で得た知識がきれいに結びつかないのは苦痛でした。 入門書を読み、サンプルをグジグジいじくっては、覚えているだけで 3 回は挫折してしまいました。 とにかく、自分が何をやっているのかを、感覚としてさっぱり捕まえられなかった。 # こういう感覚はプログラマとして「まっとう」だと思ってます。 # 挫折しといてナンですが…。 「プログラミングは Java が初めて」という人ならこういう経験をしなくて済むかもしれません。 何しろ邪魔する前知識が無いですから。 かと言って、C 言語経験者を「古い知識に縛られたロートル」だとも思いません。 低レベルな概念と高レベルな概念がきれいに結びついた知識体系を獲得した時、飛躍的に応用が利くようになる からです (ちょっと大げさかな…)。 # アセンブラ上がりの高級言語プログラマであれば、また違ったセンスや発想を持っているように思います。 知識というのは、互いに結び付けられて意識下で体系化されてこそ意味を持ちうるわけで、その結びつきを強化 したり手繰り寄せたりしないと、新しい知識や発想に行き着けないと思ってます。私。 あれ、これ、前橋さんの意見の要約にしかなってないかも…。

>プログラムを始めたばかりのものです。 >Perlで作成する事になりました。 >PDFを表示する仕様があります。 >どの様にすればよいかわかりません。 >教えて頂ければありがたいです。 私はPerlにもPDFにも詳しくないですが… PerlとPDFをキーワードに、Googleで検索しました(日本語限定)。 http://www.google.co.jp/search?hl=ja&q=Perl+PDF&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja 1件目がこれ。 http://www.warpstream.co.jp/package_pdfserver.html?afl=cgirescue1 商品のようです。 お金を出すのが嫌なら、2件目がこれ。 http://hp1.jonex.ne.jp/~nakajima.yasushi/ PDFJというモジュールがあるようです。 PDFJでGoogleすると、結構有名なようですね。 ただ、ざっと見て、ライセンスの規定がよくわかりませんが… また、1件目のページの中に >PDFLibなどのライブラリで作成することはできますが、 とありますから、PDFLibとPerlでGoogleするのも手です。これも商品のようですが。

>>そこらへんどうなんですか？ > >いずれ分かる 　これだけではあんまりなのでちょっと書き足しときますか。 　根拠も挙げず、イカれたレコードか何かのように、「いずれ分かる」と言い続ける だけなら、バカにでもできるわけです。 　まあ、それでもnorgeさんの最初の投稿には、 >Ｃの#include<stdio.h>がいい例じゃないすかね と書いてあったから、私はこれを 「Cの#include <stdio.h>は『とりあえずこう書いとけ』と言われても理解できたでしょ? 　だからクラスを書くことについても、同様に『とりあえずこう書いとけ』と 　言ってもいずれ理解できるのではないか」 という意味だと解釈しました。つまり「#include <stdio.h>」が、 「とりあえずこう書いとけ」と教えればよいというnorgeさんの主張の根拠であると 解釈したわけです。 そう解釈した上で、反論を書きました。[253]はわかりにくかったようなので、 [255]で改めて説明しています。それでもまだわかりにくかったとか、 再反論があるとか、あるいは最初の私の解釈が間違っていたとかなら拝聴いたしますが、 norgeさんはあいかわらず >そのうち分かるからとりあえずそうしときなさい と繰り返すばかり。だから、 >対話する気がないのなら、掲示板なんぞに出てこないで、自分でWebページでも >立てて好きなことを言っていればいいでしょう。 と言っているのです。 それからね、 >>でも、「クラスを作る」のケースでは、すぐにわかる見返りがないでしょう。 >いずれ分かる んで、こんなクラスを書かせるわけ? > class Car { > 　private int mileage > 　public Car(int mil) { > 　　this.mileage = mil; > 　} > 　//引数：ガソリン注入 > 　public int run (int gas) { > 　　return (gas * this.mileage); > 　} > } 「先生! 書けました」 「ではjavacでコンパイルしてください」 「Car.classってファイルができたんですけど、これってなんですか?」 「いずれ分かる」 ( ﾟдﾟ)ﾎﾟｶｰﾝ そもそもこのCarクラスってのは、いったい何をするためのプログラム(の一部?) なんですかね? 何をするためのクラスでもない、というのなら、私が 「疑り深い～」で批判している「犬」や「猫」のクラスと同じです。 私は「疑り深い～」において「犬」「猫」でクラスを説明することを批判して いますが、それを批判したいのなら、そう書けばいい。もちろん根拠を挙げた上で。 ついでに書いといきますと、句読点の使い方の変な文章は、ﾃﾞﾑﾊﾟに見えますぜ。

>他の掲示板にＤ言語って書いたら、そんなのねーよって言われた。 　で? 　対話をする気もなく、言いたいことを一方的に書き散らすだけなら、掲示板なんぞに 出てこないでください。

他の掲示板にＤ言語って書いたら、そんなのねーよって言われた。

プログラムを始めたばかりのものです。 Perlで作成する事になりました。 PDFを表示する仕様があります。 どの様にすればよいかわかりません。 教えて頂ければありがたいです。

横槍失礼します。 プログラミングセンスを上達させるには、ある種の悟り体験というか、 「あー、そういうことなのか！」っていう感動を覚える体験が必要なんだと 思います。 norgeさんがおっしゃるように、本当にセンスのある奴は放っておいても、 そういった悟りを開くのかもしれないですけど。 「そのうちわかる」的教え方では、僕のようなその他大勢のへっぽこ コード書きは、感動を覚える前に挫折していってしまうのが目に見えています。 そういったへっぽこであっても、ある程度はセンスを磨くことのできる教え方 ってものもあるはずです。 前橋さんの本やこのサイトのドキュメントは、まさに「それだ」と感じます。 導入部分で、感動の一端が垣間見れるように導いてあげるのが、一番良い教え方 だと思うのですが。

D言語万歳

>いずれ分かると言っても納得してもらえないのか、 >ちゃんと最初に説明しないといずれもクソも分からないのか、 … >そこらへんどうなんですか？ いずれ分かる

なんか分かってないっつーか理解力がないっつーか。。 「なんでこんなことしなきゃいかんの？」 っていう人に対して 「とりあえずそうやっとけばいずれ分かる」 って言えばいい、って２回も言ったのにそれに対して何も返事が返ってきてない 下にコピーした返事らしきものがあるけど、ちゃんとした答えじゃない >でも、「クラスを作る」のケースでは、すぐにわかる見返りがないでしょう。 いずれ分かる >なにせCとかに慣れた人なら、staticメソッドの塊で何でも書いちゃうでしょうから。 最初は黙ってpublicとかいときなさい >だから、「なんでこんなことしなきゃいかんの?」という疑問に答える必要がある、 それもいずれ分かる いずれ分かると言っても納得してもらえないのか、 ちゃんと最初に説明しないといずれもクソも分からないのか、 単に意地で最初から説明したいのか、 そこらへんどうなんですか？ ちなみに例としてはこんなん class Car { 　private int mileage 　public Car(int mil) { 　　this.mileage = mil; 　} 　//引数：ガソリン注入 　public int run (int gas) { 　　return (gas * this.mileage); 　} }

で、結局何が言いたいんですか? >結局問題なのはマルチプルインスタンスによる、多様性、つまりコンストラクタ等で設定した値によって振る舞いが違うと >ならそれの超簡単版でも作ればいいんじゃないかな 具体的には? >>だから、「なんでこんなことしなきゃいかんの?」という疑問に答える必要がある >前も言った気がするけど、そのうち分かるからとりあえずそうしときなさい >じゃまずいっすかね で、それに対する私の意見は書いたわけで、さらに反論があるのなら書けばいいし、 ないのならそれでいい。あるいは私の言っていることが意味不明だというのなら それも、そう書けばいい。 >VC++のSDKとかいちいち全部説明してたら死ぬし VC++のSDKをいちいち全部説明しろ、と誰か言っていますか? 対話する気がないのなら、掲示板なんぞに出てこないで、自分でWebページでも 立てて好きなことを言っていればいいでしょう。

結局問題なのはマルチプルインスタンスによる、多様性、つまりコンストラクタ等で設定した値によって振る舞いが違うと ならそれの超簡単版でも作ればいいんじゃないかな >だから、「なんでこんなことしなきゃいかんの?」という疑問に答える必要がある 前も言った気がするけど、そのうち分かるからとりあえずそうしときなさい じゃまずいっすかね VC++のSDKとかいちいち全部説明してたら死ぬし やっぱ最初は「そのうち分かるからとりあえずこういう風にやっとけばいい」 これの一言に尽きると思う

で、結局何をおっしゃりたいんでしょうか? この部分にレスが付いたって事は、「疑り深い～」に対する反論や感想の類と 思っていいのかなあ。 >>いざインスタンスを作るときには、やっぱり「なんでこんなことしなきゃ >>いかんの?」という疑問を持つはずで、それには答えなきゃいかんと思うんですがねえ。 > >とりあえずそうしときなさい、いずれ分かるから >ってことじゃダメっすかね たとえば「hello, world.」を表示するときの#include <stdio.h>は、 「とりあえずそうしときなさい。ほら、hello, world.って表示されたでしょ」 と言えます。この例では、「とりあえずそうしとく」ことで、 hello, world.が表示されるという短期的な見返りがあるわけです。 でも、「クラスを作る」のケースでは、すぐにわかる見返りがないでしょう。 なにせCとかに慣れた人なら、staticメソッドの塊で何でも書いちゃうでしょうから。 だから、「なんでこんなことしなきゃいかんの?」という疑問に答える必要がある、 と私は考えています。

>いざインスタンスを作るときには、やっぱり「なんでこんなことしなきゃ >いかんの?」という疑問を持つはずで、それには答えなきゃいかんと思うんですがねえ。 とりあえずそうしときなさい、いずれ分かるから ってことじゃダメっすかね 実際オレがそうだったし それでも分からんやつは才能がないと諦めた方がいいんじゃないの

　件名付けました。 >ここで言っても仕方ない事かもしれないけど、理解するのはあとだと思う >あーだこーだ説明されるよりまず、こう書けばクラスが作れるっていう書き方が重要 >書き方覚えてあとから理解した方がいい >Ｃの#include<stdio.h>がいい例じゃないすかね 　いや、私はまったく同意するんですが(実際、体当たり学習～では、#include <stdio.h> について、そういうことを書いてるし)。 　唐突にこう言われても何がなんだかわからないんですが、いったい何を おっしゃりたいんでしょうか? 「疑り深い～」に対する反論なのかなあ。 ただ、これについて言えば、CプログラマにJava教えるとき、 なんでもstaticメソッドで書かせればすぐ理解できると思うけど、 いざインスタンスを作るときには、やっぱり「なんでこんなことしなきゃ いかんの?」という疑問を持つはずで、それには答えなきゃいかんと思うんですがねえ。

ここで言っても仕方ない事かもしれないけど、理解するのはあとだと思う あーだこーだ説明されるよりまず、こう書けばクラスが作れるっていう書き方が重要 書き方覚えてあとから理解した方がいい Ｃの#include<stdio.h>がいい例じゃないすかね

>お陰様で風邪も良くなりまして、また勉強に励んでおります。 　ええと、ご無理されませんように。 >そんな中で、J2EE は一定の成果を上げることができた、と。 　EJBなんか本当に必要なのか? という声はなくもないですが。 　ただ、EJBを使おうが使うまいが、Webアプリケーションでは、何らかの「型」を決めて アプリケーションを開発する傾向はあります。Strutsなどは「型」を提供してくれますし、 たいていプロジェクトごとにさらに細かい型を決めます。 　実際、それで生産性は上がりますし、品質もある程度均一化できると思うのですが、 考えてみれば、「どこ見ても同じようなパターンで書いてある」というのは、 「同じことを複数の箇所に書いてはいけない原則」に反するのではないかと 思うこともあります。 　アスペクト指向ってのはそのへんをどうにかしようという発想なのだと思うのですが、 私はちゃんと追えてません。 >で、ツールの制限の話なのですが、実は私、色々な所で悪口を聞く COBOL を嫌いになれません。 >COBOL の持つ記述上の制約は、「誰でも、それなりに実用に耐えうるソースを書ける」と信じられていた時代な >らではのものだからです。 　すみません、私はCOBOLはやったことないです(入門書をみた程度)。 「誰が書いても似たようなコードになる」という話はよく聞きますけれど。 　一時期、TeXに凝っていた頃、「マクロでどうにでも化ける言語ってすごいじゃん」と 思ってしまったことがありますが、読むほうからするとむしろたまったもんじゃ ないんですよね。C++は、演算子のオーバロードで結構いかようにも化けますが、 おかげで、読む方は、そのクラスの仕様がわからなければ手が出せない。 たとえば文字列のクラスがあったとして、それが実体として扱われるのか参照として 扱われるのかはC++の文法からだけではわからないわけです。 # STLのstringの話をしているわけではないですからね。念のため。 　その点、Javaなら参照しかないので迷いようがない。こういうのは結構重要かなあ、 とも思ったりしてます。 　ちなみに、そういう発想にはおそらく真っ向から反するのがこちら。 「簡潔さは力なり」 http://www.shiro.dreamhost.com/scheme/trans/power-j.html

お世話になっております、けろ助でございます。 お陰様で風邪も良くなりまして、また勉強に励んでおります。 > あのディレクトリ構成は実際「Web アプリに限定したからこそ」だと思います。 > ていうか私はあれを最初に見たとき、こんなことをフレームワークで決めて欲しくない、 > と思いました。が、ユーザとしては無限の自由度を欲しがりますが、それがかえって > 混乱を招くこともあるわけで、あれはあれでよいのかもしれません。 つたない考えなのですが、これって「『今対象としている問題の領域』をどこに限定し、いかにモデル化する か」というテーマに帰着していくんだと思うんですね。 オブジェクト指向設計の用語では「ドメイン」と呼ぶそうですが。 ドメインの決定とモデル化を上手く行うことが、結局のところ良い設計となる…ということになるのでしょう。 「アルゴリズムとデータ構造」といった、割と枯れたテーマなら、ノウハウや経験則の蓄積も豊富で体系的にま とめられた書籍を気軽に入手して勉強できる程の環境にあると思いますが、上に挙げたテーマは「まだこなれて ないジャンル」であるだけにまだ模索状態なような気がします。 そんな中で、J2EE は一定の成果を上げることができた、と。 今のところ、私はそんな解釈をしています。 > Cが、もし最初から、インデントがいわゆる「K&Rスタイル」になっていないものを > コンパイラのレベルで文法エラーで弾いていたら、スタイルにまつわる宗教戦争は > 発生しなかったわけで。 > # でも、そういうことをツールの設計者がガチガチに決めてしまうと、なんか > # 普及しなさそう、という気もします。 ええ。そういう意味なら、C 言語は、上手いことユーザーのニーズに (今も) マッチした言語ですね。 制限と自由のさじ加減が非常にバランスが良い言語だと思ってます (除：宣言構文)。 「C 言語ポインタ完全制覇」を最初に読んだ時は「殴るんなら James Gosling より Dennis Ritchie だろ」と 思っていた私ですが、Java を本格的に書き始めた今では考えが全く逆ですから (汗)。 で、ツールの制限の話なのですが、実は私、色々な所で悪口を聞く COBOL を嫌いになれません。 COBOL の持つ記述上の制約は、「誰でも、それなりに実用に耐えうるソースを書ける」と信じられていた時代な らではのものだからです。 # 実は私、前の会社でホスト系言語 (COBOL、PLI/I、JCL …等々) の解析プログラムをメンテしてました。 # COBOL はソース記述開始位置等に非常な制約がある言語です。 # また、今では「変態言語」の名は Perl が欲しいままにしていますが、私ならその称号を PL/I に与えたい。 話それました。すみません。 要は、「『作者の設定した自由と制約』が時代やユーザーのニーズとどれだけマッチしているか」、が一番重要 な事項になのだろう、と思った、ということです。 流行る言語なり、ツールなりは、時代に見出されただけであって、後々まで残る方法論とはまた別なのだ、って 事なんです。 前向きに考えるなら「今からでもソフトウェア工学の根本的進歩を目の当たりにできる」と思えるでしょうし、 後ろ向きに考えるなら「なんだ、ソフトウェア工学ってこの程度なのか…」と思える混沌とした時代なのかな…。

>またぞろ風邪がぶり返してきそうです… (鼻水と咳が止まらない…) 何でだろ。 無理されないように。ゆっくり休んでください。 >そうですねぇ…、J2EE は、役割 (ロール) を含め、かなりきっちりとした規定があるようですが、「Web アプ >リに限定したからこそ」という印象が、私にはあるのです。 あのディレクトリ構成は実際「Web アプリに限定したからこそ」だと思います。 ていうか私はあれを最初に見たとき、こんなことをフレームワークで決めて欲しくない、 と思いました。が、ユーザとしては無限の自由度を欲しがりますが、それがかえって 混乱を招くこともあるわけで、あれはあれでよいのかもしれません。 Cが、もし最初から、インデントがいわゆる「K&Rスタイル」になっていないものを コンパイラのレベルで文法エラーで弾いていたら、スタイルにまつわる宗教戦争は 発生しなかったわけで。 # でも、そういうことをツールの設計者がガチガチに決めてしまうと、なんか # 普及しなさそう、という気もします。 > 名前しか知りませんが、Mavenてそーゆーのには役に立たないんでしょーか? これは私も知りませんでした(Jakartaもなんか多すぎ)。勉強しておきます。

前橋さん、iWA さん、早速のレスありがとうございます。 またぞろ風邪がぶり返してきそうです… (鼻水と咳が止まらない…) 何でだろ。 前橋さん> ディレクトリ階層ということなら、JavaによるWebアプリケーションなら、 前橋さん> J2EEによる規定がありますよね。 前橋さん> その他のアプリケーションだと、confとかetcとかdocとか、よく使うディレクトリ名は 前橋さん> ありますが… きっちり規定されたルールというと… どうでしょうか。 そうですねぇ…、J2EE は、役割 (ロール) を含め、かなりきっちりとした規定があるようですが、「Web アプ リに限定したからこそ」という印象が、私にはあるのです。 J2EE はやたら敷居が高いので本をパラパラと読んだだけでの感想ですが…。 前橋さん> プロパティファイルは読みにくいので、今ならXMLの方がよく使われている気がします。 なるほど。Properties クラスの名前空間は階層的ではないですし、そちらが主流なのは良く解ります。 質問の件に限らず、ずっと思っていたことがありまして、今回改めてそれを確認した思いがします。 それは、「言語にせよ、ツールにせよ、その設計思想を体得しないことには充分に力を引き出せない」というこ とです。 言語やツールの成長を初期から追いかけるか、時間と労力を割いて慣れ親しむかしないといけないのでしょうね。 個人的には、作者にその辺りの説明責任があると思うのですが…。 私の場合、C + Make という環境でいたのですが、同じ UNIX 発祥とはいえ、Java + Ant では考え方が随分違う のでかなり面食らいました。 Win + VB から移行するよりは楽なのでしょうけど。 iWA さん> 名前しか知りませんが、Mavenてそーゆーのには役に立たないんでしょーか? さっそく調べてみました。プロジェクト管理ツールだそうですね。 [Jakarta Project のページ] http://www.ingrid.org/jajakarta/turbine/jp/turbine/maven/index.html [Maven を取り上げているサイト・1] http://www.02.246.ne.jp/~torutk/index.html [Maven を取り上げているサイト・2] http://www-6.ibm.com/jp/developerworks/java/030613/j_j-maven.html Eclipse にすら挫折した (手を出すには時期尚早だと感じた) 私ですので、今すぐ Maven を活用できる訳では ないのですが、Maven が持つ「プロジェクトの標準ディレクトリ構成」はかなり参考になりました。 自分でグジグジ環境をいじってたらこのレベルに辿りつくのに半年じゃ効かんですわ…。 レスを下さった皆様、どうもありがとうございました。 Java に関しては完全に独学 (周りに使える人がいない…) で、暗中模索の状態が続いていたのですが、何だか 少し光が差してきたような気がします。

名前しか知りませんが、Mavenてそーゆーのには役に立たないんでしょーか?

>レスが大変遅れまして申し訳ありません (雑事に追われた挙句風邪で４日間も寝込んでて…日頃の行い？)。 おや。お大事に。 >これが、「『とりあえず動けばいいや』的な作りでも何とかなる場合も多い」という意味でしたら同意です。 >だからこそ、Java を使用したアプリケーションの構築には、デザインパターンのように一定のセオリーや経験 >則の蓄積があるはずだ、と思っていたのです。 ディレクトリ階層ということなら、JavaによるWebアプリケーションなら、 J2EEによる規定がありますよね。 その他のアプリケーションだと、confとかetcとかdocとか、よく使うディレクトリ名は ありますが… きっちり規定されたルールというと… どうでしょうか。 Cに関しては、GNUプロジェクトには規約がありますが、configureを前提にされると 辛い、ていうか嫌。 http://www.sra.co.jp/wingnut/standards-j_toc.html#Managing%20Releases >が、Java には、Java 実行環境内からのみ参照できる環境変数もどきの「プロパティ」というものがありますか >ら、設定ファイルの値はプログラム内から読み込むというのが普通 (らしい) です。 プロパティファイルは読みにくいので、今ならXMLの方がよく使われている 気がします。

前橋さん、本多さん、レスありがとうございます。 レスが大変遅れまして申し訳ありません (雑事に追われた挙句風邪で４日間も寝込んでて…日頃の行い？)。 こちらでお二人にまとめてレスしようと思います。 前橋さん> いやあ、このあたりは、最近はかなり「若い奴にお任せ」してる部分が大きいので、 前橋さん> 私がこの方面に詳しいかというとそんなことはないと思います (^^; ガーン。そうなのですか…。 前橋さん> 詳しくないなりに思うところを書きますが、こういうのはアプリケーションと 前橋さん> 環境により千差万別なわけですが、実はプログラマが仕事で書くプログラムの 前橋さん> 95%は特定顧客からの受注アプリケーションだという現実があって(※1)、 前橋さん> その場合、特に相手がUNIXワークステーションだったりすると環境はかなり 前橋さん> 限定できますから、「ディレクトリまるごとtarで固めてインストール先で展開。 前橋さん> パスは全て絶対指定」みたいなやり方でもなんとかなっちゃう、という面はあると 前橋さん> 思います。 前橋さん> Windows環境ではさすがにそういうのは避けるべきかと思いますが(PCはきっと 前橋さん> 他のことにも使うので)、業務用の特注アプリケーションだと、Cドライブにしか 前橋さん> インストールできなくてもさほど問題にはならなかったりします。 これが、「『とりあえず動けばいいや』的な作りでも何とかなる場合も多い」という意味でしたら同意です。 例えば、実行モジュールと設定ファイルが同一ディレクトリに置く、なんてことはマトモなアプリケーションで ならやってはいけないことだと思いますが、動かそうと思えば動くわけですし…。 前橋さん> 一般に配布するのでどこでも動くようにしたい、と考え出すと、途端に難しく 前橋さん> なりますよね。Cの場合、かつては#ifdef __SOLARIS__ とか書いてましたが 前橋さん> これはひどいということでautoconfみたいなのが出てきましたけどconfig.hに 前橋さん> 頼ってたらテストが大変(というか不可能)という状況には変わりなく、 前橋さん> 結局は、(Javaが本質的にそうであるように)最初からどこでも動くように書くのが 前橋さん> 正しいのでしょう。 私もそう思います。 だからこそ、Java を使用したアプリケーションの構築には、デザインパターンのように一定のセオリーや経験 則の蓄積があるはずだ、と思っていたのです。 が、お話を聞く限りそういう類のものは無いようですね…。 本多さん> Javaはよくわかりませんが、私はX関係とかで一般に公開されている 本多さん> かなり熟練されている人たちが作ったと思われるプログラムの 本多さん> ディレクトリ構造とかを真似してみたりしてます。 こういうノウハウは、まだ誰もドキュメントとして体系的にまとめてはいないのでしょうね。 X 関係ですか…へっぽこな私には厳しそうだ…。 …と、ここまで考えて、「アプリケーションの構成法を一般的な形に体系化するのは実は無理があるのではない か」と思えるようになってきました。 設定ファイルの読み込み方ひとつ取っても、C だと設定ファイルに記述された値を環境変数に代入し、シェル上 でコマンドに引数として渡すのが普通 (らしい) です。 が、Java には、Java 実行環境内からのみ参照できる環境変数もどきの「プロパティ」というものがありますか ら、設定ファイルの値はプログラム内から読み込むというのが普通 (らしい) です。 パスの指定にしても、C ならカレントディレクトリからの相対指定が可能なのに、Java は基底ディレクトリか らの相対指定しかできませんし…。 Make と Ant では、もう基本にある考え方そのものが違うという気がします。 でもなぁ…せめて個別のビルドツールについて、その設計思想を解説した本やサイトくらいあっても良さそうな ものだとやっぱり思うのですよ。

tasaedaです。ご返信ありがとうございます。 >正直、私としてはあまりこういう質問が来ることは想定していなかったのですが、 私もちょっと筋違いかなとは思ったのですが、引用については様々な本や記事で話題に なっていますし、少しでも自信がなければ（私自身経験不足ですから）しっかり確認を とっておいた方が良いだろうと思いまして。 >ということで、数ページ程度の引用でしたらまったく問題ありません。 なるほど、承知しました。一つの基準として覚えておきます。もっとも数ページも引用 してしまっては、私程度の筆力では間違いなく「主従の関係」が逆転してしまいそうです。 >もし必要でしたら、該当部分の電子ファイルをお送りしますが、どうしましょうか? それは大変助かります。本の文章をネットで掲載するには、自分でキーボードを叩か ねばなりませんしね。（私は遅筆なものですから） ではご厚意に甘えてメールを出させていただきますので、いつでも結構ですからご返信 いただければ幸甚です。 過分なご配慮、ありがとうございました。

>前橋様、皆様、初めまして。tasaedaと申します。 はじめまして。 >そういうわけですので、差し支えなければ前橋さんからの引用に関しての注意点や >不都合とお考えになることについて、お教えいただけたらと存じます。 状況は了解いたしました。 正直、私としてはあまりこういう質問が来ることは想定していなかったのですが、 私自身の都合からすれば、その引用を読んで「もう本は買わなくてもいいや」と 思う人さえ出て来なければ差し支えないわけです(おそらく出版社さんとしても)。 具体的には「1章まるごと」とかの転載をされなければ問題ないと思います。 1ページ程度であれば全然問題ないです。 また、引用部分を読んで、「こんなクソ本買うのやめた」と思う人がいたとしても、 それは仕方がないと思います(立ち読みでも発生し得る話ですし)。 本来、この本を読んでメリットを受ける人が(仮にいるとして)、その引用部分を読んで、 目的を達成してしまうと、私としては(経済的に)嬉しくないわけですけど、 1ページやそこらはもともと立ち読みできる範囲内ですから。 ということで、数ページ程度の引用でしたらまったく問題ありません。 引用した上でボロクソにけなそうがかまいません(再反論はするかもしれませんけどね) ので、ご自由にしてください。 もし必要でしたら、該当部分の電子ファイルをお送りしますが、どうしましょうか? もっとも私の手元にあるのは編集さんの手が入る前の、著者校正もしていないものだけ ですから、漢字の使い方が違っていたり誤植があったりしますけれど。 必要でしたら、そう言っていただければ、1/10中にはメールで送れると思います。

前橋様、皆様、初めまして。tasaedaと申します。 プログラミングに関する話題ではないのですが、掲題に関する質問がございますので 投稿させていただきます。 私のホームページでは雑文のようなものを書いているのですが、近日中の日記に前橋 さんの「センス・オブ・プログラミング」から一部を引用させていただこうと考えて おります。 具体的には、今のところP.10の24行目からP.11の15行目くらいまでを想定しています。 ただ読み始めて間がないので、他に感銘を受けた箇所を見つけた時は、もう少し増える かもしれません。 引用の理由ですが、プログラミングに関することでは全くございません。最近「抽象」 についての駄文を書いているとき、偶然手元にある貴著を拝読し、「これは自分の 考えにピッタリだ！」と思いましたので、早速日記に書こうと思いました。 ただ、引用部分が少々長くなりそう（あるいは増えそう）だな、と感じましたので、 これは前もって著者様に確認しておいた方がよいと判断し、この度お伺いを立てた 次第です。 そういうわけですので、差し支えなければ前橋さんからの引用に関しての注意点や 不都合とお考えになることについて、お教えいただけたらと存じます。 無論、文化庁の言う「引用における注意事項」は当然守りますが、それ以外に留意 して欲しいことがございましたら、ということです。 以上、宜しくお願いいたします。 追記：前橋さんの本には「C言語 ポインタ完全制覇」以降全てお世話になっており ます。もう何年もたちますが「最後は本人次第だなぁ」と痛感しております（苦笑）

ISO C99はすっかり頭から抜け落ちていたので、今調べなおしました (^^; >int32_t を生で使うのがアレなのは賛成ですが、 >typedef int32_t CustomerID; のようにして >int ではなく CustomerID を使うってのは OK >なんですよね？ 私の主張は「低レベルな概念をわざわざアプリケーションにばらなくな」 ということなので、CustomerIDを使うのであれば問題ないと思います。 ただ、ISO C99を前提にするのなら、CustomerIDなら、int_least32_tの 方が移植性が高そうには思います。 が、「どの環境でも同じようにバグって欲しい」とか、 「バイトオーダーがある程度限定されてもよいから生データでやりとりしたい」 とかの状況も当然あるとは思います。移植性という点ではどちらもなんとも 中途半端だと思いますが、全面否定はできません。 >int32_t の定義されてない古い処理系上で、 >上の CustomerID のような typedef を行うために、 >アプリケーションで「typedef int int32_t;」するのも >OK なんですよね？ 上のような意図なので、これもOKですね。 いつもながら軽率な表現ですみません(ご指摘ありがとうございます(_o_)) 意図としてはそのあたりだとご理解くださいませ。

一応、念のため確認です。 int32_t を生で使うのがアレなのは賛成ですが、 typedef int32_t CustomerID; のようにして int ではなく CustomerID を使うってのは OK なんですよね？ あと、int32_t は既に C言語標準に含まれているので、 基本的にはアプリケーションで定義する必要はないわけ ですが、int32_t の定義されてない古い処理系上で、 上の CustomerID のような typedef を行うために、 アプリケーションで「typedef int int32_t;」するのも OK なんですよね？

>> 私は特殊なソフトウエアを作ってる場合が多いので、あれですけど、 >> 色々な環境からハードウエアを直に叩く様なアプリケーションを >> 作っていて、そういう時整数型のビット数とかは非常に重要になっていたりしますが。 >もちろんそういう低レベルな階層を意識しなければならないケースでは、 >ビット数を意識する必要があると思います。それでもできるだけ階層化して、 >下の方に押し込めたいところですが。 私の感覚が特殊な状況にあったようですね。 私の作るアプリケーションが いわゆるICデバイスを生で扱うためのもので、 最上位...つまりユーザインターフェイスにまでビット数やら 各ビットの01情報が見えないといけないという「超特殊」なモノ... 私が特殊な環境のプログラムばかり作っているってことを忘れてました(^^;) しかも、私の環境がWindows⇔UNIXという移植性は(あまり)考える必要がないので バイトオーダと言うことも考えから抜け落ちてました。 そうですねぇ。一般の例えばワープロとかで、使うintが何bitか なんて概念が残ってる必要はないですよねぇ。

件名を変えました。 >># そういう意味で、typedef int int32_t; みたいなのは、少なくともアプリケーション >># プログラムとしては、方向性が間違ってると思う。 … > 一般のアプリではビット数なんか気にしないで作らんとあかんって言うことでしょうか? まあ、簡単に言ってしまえばそういうことです。 > でも、ファイルフォーマットとかでやっぱりビット数って重要になりそうですが。 ファイルにデータを吐き出したいのなら結局バイト列まで面倒を見なければ いけないでしょう。int32_tを、32bitだからってそのままファイルに吐いてたら、 バイトオーダーの問題さえ解決できません。まあ、バイトオーダー(とか負の数の 表現方法とか)が同じ環境に限り移植性が高い、というだけでもメリットは もちろんあるので、全面的に否定はしませんが。 コンピュータの世界では、実に色々な概念が階層的に構成されていて、 ハードに近い「低レベルな」概念を、より抽象的な概念で隠す、という層の 積み重ねになっています。が、typedef int int32_t; は、より低レベルな階層を 剥き出しにする方向の定義になっている。これじゃあ向きが反対です。 その意味で、私は、Javaな人が、「Javaでは、Cなんかと違い、intとかの データ型のサイズがきちんと規定されているから良い」という主張が理解できません。 「intは最低限いくつからいくつまでの数を表現できる」という規定があれば (本来は)十分じゃないでしょうか。実際、Cの規格ではそれは保証していますし。 # intが3万ちょっとであふれるのは嫌だ、ということなら、「俺のプログラムは # intが32ビット以上の環境だけを対象とする」と言ってもよいでしょう。 2147483647に1足すと-2147483648になる、なんてことを仕様で保証しても、 「どの環境でも同じようにバグる」ことが保証できるだけでしょう。 現実問題としては「どの環境でも同じようにバグる」と助かるのは確かですが、 そういう意味で利便を図るなら、実行時エラーにする(できる)ほうが 筋が通ってますよね(C#のように)。 > 私は特殊なソフトウエアを作ってる場合が多いので、あれですけど、 > 色々な環境からハードウエアを直に叩く様なアプリケーションを > 作っていて、そういう時整数型のビット数とかは非常に重要になっていたりしますが。 もちろんそういう低レベルな階層を意識しなければならないケースでは、 ビット数を意識する必要があると思います。それでもできるだけ階層化して、 下の方に押し込めたいところですが。

あけまして おめでとうございます。 少し趣旨の異なる質問ですが ># そういう意味で、typedef int int32_t; みたいなのは、少なくともアプリケーション ># プログラムとしては、方向性が間違ってると思う。 この方向性が間違っていると言うのは, どういうことを意味してるのでしょう? int32_tみたいな型を利用するのは、けっこう便利だと思うのですが。 一般のアプリではビット数なんか気にしないで作らんとあかんって言うことでしょうか? でも、ファイルフォーマットとかでやっぱりビット数って重要になりそうですが。 私は特殊なソフトウエアを作ってる場合が多いので、あれですけど、 色々な環境からハードウエアを直に叩く様なアプリケーションを 作っていて、そういう時整数型のビット数とかは非常に重要になっていたりしますが。 >>ビルドについて詳細に取り上げている書籍、もしくはサイトをご存知の方、ご教授願います。 >これは私も知りたいです。詳しい方、よろしくお願いいたします。 Javaはよくわかりませんが、私はX関係とかで一般に公開されている かなり熟練されている人たちが作ったと思われるプログラムの ディレクトリ構造とかを真似してみたりしてます。 まぁ、新規に作り始めることが少ないので、 既にある環境で何も考えずに やってることがほとんどですが。 なんつうか、頭を使わない私なのでした。

>皆様初めまして、ＨＮ「けろ助」と申します。 はじめまして。 >ビルドを効率的、柔軟に行えるようにするには、makefile (make)、build.xml (ant) の記述ノウハウはもちろ >んのこと、ディレクトリ構成等も慎重に考えて設計しなくてはならないように思います。 いやあ、このあたりは、最近はかなり「若い奴にお任せ」してる部分が大きいので、 私がこの方面に詳しいかというとそんなことはないと思います (^^; 詳しくないなりに思うところを書きますが、こういうのはアプリケーションと 環境により千差万別なわけですが、実はプログラマが仕事で書くプログラムの 95%は特定顧客からの受注アプリケーションだという現実があって(※1)、 その場合、特に相手がUNIXワークステーションだったりすると環境はかなり 限定できますから、「ディレクトリまるごとtarで固めてインストール先で展開。 パスは全て絶対指定」みたいなやり方でもなんとかなっちゃう、という面はあると 思います。 Windows環境ではさすがにそういうのは避けるべきかと思いますが(PCはきっと 他のことにも使うので)、業務用の特注アプリケーションだと、Cドライブにしか インストールできなくてもさほど問題にはならなかったりします。 一般に配布するのでどこでも動くようにしたい、と考え出すと、途端に難しく なりますよね。Cの場合、かつては#ifdef __SOLARIS__ とか書いてましたが これはひどいということでautoconfみたいなのが出てきましたけどconfig.hに 頼ってたらテストが大変(というか不可能)という状況には変わりなく、 結局は、(Javaが本質的にそうであるように)最初からどこでも動くように書くのが 正しいのでしょう。 # そういう意味で、typedef int int32_t; みたいなのは、少なくともアプリケーション # プログラムとしては、方向性が間違ってると思う。 Javaではそういうところは改善されているはずが、Webアプリ構築のために アプリケーションサーバを導入すると移植性なんかどっか行っちゃったりしますし、 JDKのバージョンに泣かされることもあります。 「Tigerはいつになったら仕事で使えるんだろう?」 「あと数年は無理じゃないですかねえ」 という会話を、まさに今日、同僚としてました。 >ビルドについて詳細に取り上げている書籍、もしくはサイトをご存知の方、ご教授願います。 これは私も知りたいです。詳しい方、よろしくお願いいたします。 ※1「魔法のおなべ」より http://cruel.org/freeware/magicpot.html

皆様初めまして、ＨＮ「けろ助」と申します。 職業プログラマ歴３年と９ヶ月のまだまだへっぽこです。 前橋さんのファン歴（？）は「Java 謎＋落とし穴」発刊以来ですから丸３年くらいでしょうか。 で、いきなりですが質問なのです。 本格的なアプリケーションを作る場合、「ソースを書いてコンパイルする」だけではなく、「リリース用のファ イルセット (実行モジュールや設定ファイル等の集合) を作成する」という作業も必要になってくると思います。 そして世間一般ではこの作業を「ビルド」と言い習わしているようです (正確な定義は良く認識できていません。 コンパイル～リリース用ファイルセット作成までの、一連の作業を「ビルド」と言っている場合もあれば、個別 の作業行為を「ビルド」と言っている場合もあるからです)。 ビルドを効率的、柔軟に行えるようにするには、makefile (make)、build.xml (ant) の記述ノウハウはもちろ んのこと、ディレクトリ構成等も慎重に考えて設計しなくてはならないように思います。 プログラマにとってデータ構造やアルゴリズムと同程度に重要な話題に思えるのですが、参考になる書籍やサイ トが見つからずに困っております。 ビルドツールの使い方そのものについては充分な情報が得られるのですが…。 ビルドについて詳細に取り上げている書籍、もしくはサイトをご存知の方、ご教授願います。 特に Java＋ant に向いた情報を必要としています。 「自分は大抵こんな構成で作ってる」「このオープンソースの設計が参考になる」「そんなものはプログラマの 基本教養じゃ。この青二才め」等、何でも構いません。 よろしくお願いします。 個人的には、前橋さんに「本格的なアプリケーションの構築技法」の本を出していただきたいな…と思っていた りするのですが。

Perlに詳しいわけではありませんが、故あって最近Perlのソースを眺めたりも してるので、ちょっと調べてみました。 >perlの場合、関数の引数は全て配列(@_)として扱われます。なので、この場合は、 >一つ目の%sには$_[0]が、二つ目の%sには$_[1]が、三つ目の%sには$_[2]が入ります。 Perlで記述された関数についてはその通りでしょうが、今回のケースのsprintfは Perl組み込みの関数ですから、Cで書かれた実装部分に引数の数が渡っているかどうかが 問題では? で、5.8.6のソースから探したところ、どうもsv.cのPerl_sv_vcatpvfnが sprintfの実装のように見えます(1000行近い巨大関数。sprintfじゃあ しょうがないですが)。 void Perl_sv_vcatpvfn(pTHX_ SV *sv, const char *pat, STRLEN patlen, va_list *args, SV **svargs, I32 svmax, bool *maybe_tainted) doop.cのPerl_do_printf()から追跡すると、このsvmaxが、引数の数のように見えます。 printfかましてminiperlを再構築し、確認しましたが、実際に引数の数が渡って きているようです。 が、この関数の中でsvmaxをどう使っているか見てみると、 if (svix < svmax) { というように「svmaxを超えてないか?」というチェックは何箇所かでしてますが、 上記の箇所でもelse節はなかったりするので、そのために何も起きないんじゃ ないでしょうか。

あけましておめでとうございます。今年もよろしくお願いいたします。 しばらくごぶさたしてましてすみません。 この年末は、風邪ひいて寝込むわ、紅茶ひっくり返して太ももをやけどするわで、 ただでさえ短い正月休みの前半は寝ている間に終わってしまいました。 Webページの更新を含め、やりたいことはいろいろあったはずなので、 3が日の間にぼちぼち進めるつもりです　　　…無理かも。断酒も明けたし。 なお、正月バージョンの壁紙は、 「へなちょこ愚連隊」 http://www6.wind.ne.jp/hena/index.html からお借りしました。

>Perlのようなインタプリタ型の言語は、なぜエラーにならないのでしょうか？ インタプリタだから、ではなくて、perlの言語仕様的な問題です。 perlの場合、関数の引数は全て配列(@_)として扱われます。なので、この場合は、 一つ目の%sには$_[0]が、二つ目の%sには$_[1]が、三つ目の%sには$_[2]が入ります。 このとき、Cあたりだと配列長を超えたらそのままバッファオーバーラン、Javaだと 例外が投げられますが、perlの場合は読むときはundefが返り、書くときは自動で 配列長が拡大されます。 今回の場合は、$_[2]を読もうとして返ってきたundefが文字列化されて空文字列 扱いになったわけです。

>>externで「外部にあるよ！」と宣言してるにも関わらず、 >「プログラマの意図」はそうなのかもしれませんが、言語規格書の主張は違います。 >3.5-6 で、こういう宣言を行うと hoge() は内部結合のままだと書かれています。 ふむふむ。C++だとそう記述があるのですね。 ありがとうございます。

御指摘ありがとうございます。 >sprintf は「可変個引数」な関数です。 >固定な引数＝必ず必要な引数、が無いとエラーになりますが、 >可変個数部分＝有るか無いかは状況次第、が過不足していてもエラー検出することはできません。 >原理的に不可能。 申し訳ありません。すっかり忘れていました。 （前橋さんの本などで、話題になっていたのに・・・） printf系の関数は実引数が不足しているときの動作は未定義でしたね。 >C/C++ では上記コードのエラー検出はされません。 確認せずに記述してしまいました。（VC++でも検出しませんでした） 大変お騒がせ致しました。 （件名のインタプリタとコンパイラとは一切関係ありませんでした (;_;) ）

>my $string = sprintf("%s %s %s\n", $day, $message); perl はぜんぜん知りませんが、この sprintf が C の sprintf と同じ機能と仮定して： C/C++ では上記コードのエラー検出はされません。 sprintf は「可変個引数」な関数です。 固定な引数＝必ず必要な引数、が無いとエラーになりますが、 可変個数部分＝有るか無いかは状況次第、が過不足していてもエラー検出することはできません。 原理的に不可能。 # GNU CC では printf 系関数のフォーマット引数が文字列リテラルな場合に限り、 # 個数や形の不一致を検出してくれますが、一般的には無理。

とりあえず以下 C++ の話に限定 (ISO/IEC 14882:1998) 。 # C 規格書はウチに帰r) >externで「外部にあるよ！」と宣言してるにも関わらず、 「プログラマの意図」はそうなのかもしれませんが、言語規格書の主張は違います。 3.5-6 で、こういう宣言を行うと hoge() は内部結合のままだと書かれています。

いつも楽しく拝見しています。 久しぶりに投稿します。konです。 質問なんですが、 共通機能でログを作成する機能をPerlで作成する事になりました。 その際、ログファイルに情報を1行ずつ書くのですが 必ず最後にスペースが入って改行される現象がありました。 原因は my $string = sprintf("%s %s %s\n", $day, $message); 上記のコードで、2番目の%sの後のスペースが表示されて、3番目の%sが引数のエラー にならない事が分かりました。 Ｃなどのコンパイラ型の言語なら、コンパイルエラーになりますが Perlのようなインタプリタ型の言語は、なぜエラーにならないのでしょうか？ （strictはいれてますが、ワーニングにもなりません） Perlのマスターが言うには、”Perlはアバウトだからね”と意味不明（論理的でない？） 回答が返ってきました。私も、あまりPerlをやっていないのでとても 気持ちが悪いです。

>は、「コンパイラさん、宣言はブロックスコープを越えないで…」というような、私の嘆きの意味合いです。 なるほど、そうでしたか。 私は「ブロックスコープを超えるのはなんで？」と読めたのでその理由を書き足したのです(^-^;) # とりあえず解決！？

>まぁ、コンパイラがリンク処理を行う段階でexternなんていう情報は >すっかり消えうせて関数名だけ残ってしまう。 >しかも、名前の一致する呼び出し元と実体をリンク処理しちゃう。 ここ、私の解釈が間違ってましたね・・・ 本多さんの意図はexternで「外部にあるよ！」と宣言してるにも関わらず、 同一ファイル内に同じ名前があると「外部」を見に行かなくなるってことですね。 # ブロックスコープの「外にある」という風に解釈するのが自然！？

クリスマスバージョン(柄にもなく)ということで背景をいじってみました。 イブの晩が終わったら戻そうと思います。 少し前、板ごとにCSSをいじれるようスクリプトを修正しました。 なので、以前作ったテスト掲示板↓では、古いCSSがそのまま適用されています。 http://kmaebashi.com/bbs/list.php?boardid=testbbs 板ごとに多少の紹介文をページ上部に入れられるような修正もしたのですが、 とりあえず今は時間がないので 今回の素材は以下のページからお借りしました。 http://kisetu.chu.jp/navi_fuyu_xmas.html ところで、クリスマスといえば、最近久々にアクセス記録なぞ見たのですが、 「赤鼻のトナカイ」「赤鼻のトナカイ 歌詞」という検索キーワードで この雑記↓に到達した人が最近結構いらっしゃるようです。さすがはクリスマス。 http://kmaebashi.com/zakki/zakki0009.html#xmas きっとお役には立てなかったと思います。すみませんねえ。

自己レスです。 >>a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 >なのに、既存の宣言(hoge1の関数ブロック内の宣言)との整合性がチェックされているとは…。 は、「コンパイラさん、宣言はブロックスコープを越えないで…」というような、私の嘆きの意味合いです。

れぷさんへ。 > a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 > b)hoge2()の中のpiyoの呼び出しで、宣言がないので暗黙にintを返す関数として >　宣言されて、 > c)その宣言の段階で、既存の宣言との整合性がチェックされ、なぜかこのときは >　hoge1()の中での宣言とのチェックも行っていて、そのためにエラーになった。 なので、 「a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、」なのですが、 最終的には、 「c)その宣言の段階で、既存の宣言との整合性がチェックされ、なぜかこのときは 　hoge1()の中での宣言とのチェックも行っていて、そのためにエラーになった。 」 となるので、前者の文章は「完結していて」が「完結していない」という結論になります。 (チェックされていればhoge1で完結している事にはなりませんので、(ぱ)さんは完結していないと仰りたかったんだと私は解釈しております。間違ってたらごめんなさい。) という訳で(私の解釈が正しければ)、bcc32では774RRさんが仰っている > と思います。C++ と違い C の場合、K&R1 の頃の（いわゆる non-ansi C) との後方互換性を > 保つため、規格書に書かれていない（もしくは規格書が禁じている）後方互換のための機能が > いくつも有効になっている処理系がほとんどのようです。 となります。 という訳でして、hoge1()のextern宣言時では「外部関数はグローバルにあると想定するしかない」ですよね。 で、宣言が完結していていない(コンパイラが余計(?)なことをしてくれるため)ため、「外部関数はグローバルにあると想定するしかない」がhoge2にも摘要されるので、れぷさんの仰る通り、 > なので「外部関数はグローバルにあると想定するしかない」→「だから整合チェックがかかるのでは？」と思ったわけです。 となります。 一応念の為に書いておきます。

>　と仰っているので、C++の名前空間的な機能が無い限り衝突はされられないので、それはできないとい >う結論になると思います(少なくても私の知っている限りでは)。 そうなりますね。 実は私が反応したのはお二方の文、 　　>>a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 　　>なのに、既存の宣言(hoge1の関数ブロック内の宣言)との整合性がチェックされているとは…。 だったりします。 なので「外部関数はグローバルにあると想定するしかない」→「だから整合チェックがかかるのでは？」と思ったわけです。 ちなみにstaticを使ってしまうと、最初のソースの記述では hoge1()もhoge2()もstaticのほうを呼び出してしまうので、 元のソースとは構成を変える必要が出てしまいますね(^-^;)

> 例えば、externする側をa.c、ローカルextern用のpiyo()を定義したものをb.c、 　仰っている意味が分かりました。 　ローカルextern用のpiyo()は、a.cのローカルextern用の関数定義って事だったんですね。 > 例えば、externする側をa.c、ローカルextern用のpiyo()を定義したものをb.c、 > グローバルextern用のpiyo()を定義したものをc.cしたとして、 > どちらのpiyo()をローカルへリンクして、もう一方をグローバルでリンクすれば良いのか、 > コンパイラこれを判断するにはどうすることが良いのでしょうか？ > b.c、c.cの関数定義はいずれにせよグローバルにおかれるでしょうし、 > コンパイラもそれを想定していると考えるなら衝突することになるのかな、なんて思いました。 >　名前空間があれば解決できるのでしょうが、Cは空間分けがザックリすぎて(^-^;) > それができないですよね。 　774RRさんも、 > C の場合は名前空間わけがざっくりすぎるし、オーバーロードは無いので、 > 結局同一名称の関数は１つしか存在し得ないわけです。では 　と仰っているので、C++の名前空間的な機能が無い限り衝突はされられないので、それはできないという結論になると思います(少なくても私の知っている限りでは)。 　ローカルのextern宣言の意味については774RRさんの仰っている通りです。 　一応念の為に書いておきますが、b.cのpiyoをa.cのhoge1専用の作業関数としたい場合にはstaticを付けて、翻訳単位を分けるという方法しかないと思います。

宣言した関数が宣言のあるブロック内でのみ有効と明示したいんでしょうね。 でも、C言語を使っていると型はコンパイル後に情報が残らないので、 同じ名前が二つ残ったら、リンクエラーになるんですね。 宣言を関数ブロックに入れるというのが、かなり異常な使い方だと思いますが。 実際、以下の様になってると宣言は何の効果も発揮しません。 ----test1.c---- #include <stdio.h> static int hoge(void) { printf("static int hoge()\n"); return 0; } int main(void) { extern int hoge(void); hoge(); return 0; } ----test2.c---- #include <stdio.h> int hoge(void) { printf("extern int hoge()\n"); return 0; } ---- % gcc -O2 -Wall test1.c test2.c % a.out static int hoge() まぁ、コンパイラがリンク処理を行う段階でexternなんていう情報は すっかり消えうせて関数名だけ残ってしまう。 しかも、名前の一致する呼び出し元と実体をリンク処理しちゃう。 だから処理内容を考えると当たり前の結果なんでしょうけど。 宣言で自分の結合先を選べるという意図があったとして、結果がこうなったら、 私の例はstaticを使ってるのでちょっと事情は異なりますが ちょっと残念に思うかもしれませんね。

C の場合は名前空間わけがざっくりすぎるし、オーバーロードは無いので、 結局同一名称の関数は１つしか存在し得ないわけです。では >int func1(void) { > extern int piyo(void); > return piyo(); >} の意図はというと、 「この extern を {} 外に出してしまうと同一翻訳単位中の他の関数から piyo() が正しく 　呼び出せてしまって警告にならない」 ことを防止することにあります。 piyo() は func1() 専用の作業関数であることを明示したい、と。 だから func2() からは piyo() を呼び出せない、ないしは、 呼び出そうとすると警告になってほしい、わけですね。 # C++ ではきっちりエラーになってくれる。 ではない？

九龍さん、はじめまして。 　3つに別けたのはa.cのコードが以下のような状況を想定しているように思えたからです。 ---a.c--- void hoge1(void) { extern void piyo(int a); // b.c内を想定 piyo(1); } void hoge2(void) { piyo(2); // c.cを想定 } 　なので、↓こういう状況を考えたわけです。 ---b.c--- // hoge1()ではAさんがくれたこっちを使おうと思った void piyo(int a) { return; } ---c.c--- // hoge2()ではBさんがくれたこっちを使おうと思った int piyo(int a) { return a; } 　この状態でb.c内にあるpiyo()をhoge1()ローカルだけに対して定義できるかというとできないですよね。 従って、hoge1()でローカルexternしたpiyo()はどこにあるのかというと、 コンパイラは「外部にある関数はグローバルに存在すると想定する」としかないのかな、と思います。 そうなると、 　　「hoge1()でローカルexternされてるpiyo()はグローバルにあるはず」 　　「hoge2()のpiyo()はプロトタイプ宣言ないけどこれも多分グローバルにあるはず」 になるので、a.cのコンパイル時に正しいpiyo()をリンクするための情報を作るには 「正しいpiyo()はどれですか？」と整合エラーを吐くしかないような気がしました。 　名前空間があれば解決できるのでしょうが、Cは空間分けがザックリすぎて(^-^;) それができないですよね。

れぷさん、はじめまして。 >例えば、externする側をa.c、ローカルextern用のpiyo()を定義したものをb.c、 「ローカルextern用のpiyo()を定義したもの」とありますが、どのような意味なのか理解しかねております。 具体的にどういうソースかをお書き頂けると嬉しいのですが。

横レスすいません。 >c)その宣言の段階で、既存の宣言との整合性がチェックされ、なぜかこのときは >　hoge1()の中での宣言とのチェックも行っていて、そのためにエラーになった。 ローカルでexternするにしてもグローバルでexternするにしても、 piyo()は外部に定義あるわけですよね。 例えば、externする側をa.c、ローカルextern用のpiyo()を定義したものをb.c、 グローバルextern用のpiyo()を定義したものをc.cしたとして、 どちらのpiyo()をローカルへリンクして、もう一方をグローバルでリンクすれば良いのか、 コンパイラこれを判断するにはどうすることが良いのでしょうか？ b.c、c.cの関数定義はいずれにせよグローバルにおかれるでしょうし、 コンパイラもそれを想定していると考えるなら衝突することになるのかな、なんて思いました。 あー、なんかまた外したこと言ってそう(;_;)

>bcc32ですが、 > > extern void piyo(int a); > >と書いていたのを、 > > extern int piyo(int a); 一応、VC++ 6.0(SP6)でテストしてみました。 --a.c-- void hoge1 (void); void hoge1(void) { extern int piyo(int a); piyo(1); } void hoge2(void) { piyo(2); } --b.c-- int piyo (int a) { return a; } c:\cppsrc\a\a.c(11) : warning C4013: 関数 'piyo' は定義されていません。int 型の値を返す外部関数と見なします。 となりました。 しかし、 >a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 なのに、既存の宣言(hoge1の関数ブロック内の宣言)との整合性がチェックされているとは…。 >あまり関係ありませんが、コンパイラの警告メッセージの翻訳チームは規格書を理解して >細心の注意を払って訳しているのか、かなり疑問。 >宣言と定義は用語の意味が違うのですが、どう見ても混同していると思われます。 同感です。 私もコンパイラの警告メッセージで理解に苦しむ時があります。

>ということでしょうかね。 と思います。C++ と違い C の場合、K&R1 の頃の（いわゆる non-ansi C) との後方互換性を 保つため、規格書に書かれていない（もしくは規格書が禁じている）後方互換のための機能が いくつも有効になっている処理系がほとんどのようです。 VC++ や BCC なんかはその典型ですね。 # 関数宣言のスコープ拡大なんかはその一例。 gcc の場合、後方互換な機能が使われると警告を出すオプションがあったりしますが... あまり関係ありませんが、コンパイラの警告メッセージの翻訳チームは規格書を理解して 細心の注意を払って訳しているのか、かなり疑問。 宣言と定義は用語の意味が違うのですが、どう見ても混同していると思われます。 >エラー E2356 proto2.c 10: 'piyo' の再宣言で型が一致していない(関数 hoge2 ) >エラー E2344 proto2.c 3: 一つ前の 'piyo' の定義位置(関数 hoge2 ) 前者は正しく『宣言』ですが、後者は『定義』ではなく宣言であるはずです。 >hoge.c(7) : warning C4013: 関数 'piyo' は定義されていません。int 型の値を返す外部関数と見なします。 これもヘン。ここは『宣言』でなければならないはずです。 >hoge.c:7: warning: implicit declaration of function `piyo' gcc の英語は正しく「宣言」と言っています。 gcc-3.3.4 の gcc/po/ja.po を見たところほぼ正しく翻訳しているようですが、 一部やはり誤訳を発見。あぁ、フィードバックしないといけないかも？

>C++ 規格書であれば 「JIS X3014:1998-3.3.2 局所的な有効範囲」で、 >ブロック内に宣言された名前はそのブロックに局所的である。 >と書かれています。実際以下のコードはコンパイルエラーです。 C でも、6.1.2.1 を見る限り、ブロック内で宣言された識別子のスコープは ブロック内ですから、プロトタイプ宣言もブロック内だけで有効と考えるのが 自然なように思います。 ただ、ふたつのコンパイラで、単純にそうとは言えない動きをしているので、 どこか別に規定があるのかと、昨晩は規格書をひっくり返していたのでした。 >んで、上記を hoge.c とした場合の挙動ですが >bash-3.0$ hppa2.0w-hp-hpux11.00-gcc-3.3.4 -Wall -c hoge.c >hoge.c: In function `func2': >hoge.c:7: warning: implicit declaration of function `piyo' これはプロトタイプ宣言がない場合の通常の挙動ですよね。 だから、gccでは、ちゃんとブロックでスコープが終了していて、 C++ではだめなのは、C++ではそもそもプロトタイプ宣言がないことを許さないからで。 bcc32ですが、 extern void piyo(int a); と書いていたのを、 extern int piyo(int a); にしたら通りました。 推測するに、 a)hoge1()の中のpiyoの宣言はhoge1()の中で完結していて、 b)hoge2()の中のpiyoの呼び出しで、宣言がないので暗黙にintを返す関数として 　宣言されて、 c)その宣言の段階で、既存の宣言との整合性がチェックされ、なぜかこのときは 　hoge1()の中での宣言とのチェックも行っていて、そのためにエラーになった。 ということでしょうかね。

申し訳ございません。コンパイラの警告レベルを4に上げるの忘れてました…(面目ないです)。 ちなみに、警告レベル3では何も出ませんでした。 >cl -W4 -Za -c hoge.c だと >hoge.c(7) : warning C4013: 関数 'piyo' は定義されていません。int 型の値を返す外部関数と見なします。 >となるのでやはりブロックスコープなのが本来みたいですね。 Microsoft言語拡張機能の無効スイッチですね(全然気にしてませんでした。これからは切るようにします…)。 確かに、これを見るとブロックスコープなのが本来の仕様みたいですね。

おっと自己レス。 cl -W4 -Za -c hoge.c だと hoge.c(7) : warning C4013: 関数 'piyo' は定義されていません。int 型の値を返す外部関数と見なします。 となるのでやはりブロックスコープなのが本来みたいですね。 ブロックスコープを超越して大域に関数宣言が有効になるのは（互換性のための）拡張機能、と。 # 規格書を要確認だなこりゃ。

C 規格書はウチに帰らないと無いのでアレげですが C++ 規格書であれば 「JIS X3014:1998-3.3.2 局所的な有効範囲」で、 ブロック内に宣言された名前はそのブロックに局所的である。 と書かれています。実際以下のコードはコンパイルエラーです。 ---hoge.cpp--- int func1(void) { extern int piyo(void); return piyo(); } int func2(void) { return piyo(); } ---EOF of hoge.cpp--- んで、上記を hoge.c とした場合の挙動ですが bash-3.0$ hppa2.0w-hp-hpux11.00-gcc-3.3.4 -Wall -c hoge.c hoge.c: In function `func2': hoge.c:7: warning: implicit declaration of function `piyo' Microsoft Visual C++ 6.0SP6 だと cl -W4 -c hoge.c hoge.c(2) : warning C4210: 非標準の拡張機能が使用されています : 関数にはﾌｧｲﾙ ｽｺｰﾌﾟが与えられています。 hoge.c(7) : warning C4217: 非標準の拡張機能が使用されています : 以前のブロｯクでの関数宣言です。 となりました。 やはり言語規格がスコープ詳細等を定めていないようです。 # IE6 でも Acrobat Reader を uninstall してから JIS 閲覧するとゲフガフ # って検索が効かない文書なので、むりくり保存してもあまり役に立たない鴨。

774RRさん、度々申し訳ありません。 >リンク先の１２番の解説を文字通りに解釈してください。 >仮定義（初期化子なし定義）だけがあって、初期化子あり定義が無い場合、 >翻訳単位のEOFに達した時点で仮定義は定義となります。 >--hoge.c-- >int x; // 仮定義 >int x; // 仮定義：何回仮定義が現れても（既存の宣言に反しない限り）問題ない >int x; // 仮定義 >--EOF of hoge.c-- >この時点で int x=0; と定義されたことになる。 > >>上記の場合だと、b.cのint a;が仮定義なので、 >この文章はある意味YES、ある意味NO。確かに int a; は仮定義ですが、既に述べたとおり >翻訳単位 (b.c) の EOF に達した時点で、仮定義は「仮ではない『定義』」になります。 >よって提示の例では a.c b.c ともに変数 a が定義されています。 >そこではじめてリンク先１３番目の解説が効いてきます。 > >>a.cで定義されているint a = 1;のオブジェクトとまとめられたと言うことで >「仮定義だからまとめられた」のではありません。 >「C では、定義が複数ある場合の挙動が定められていない」（未定義動作） >→「エラーにするのも、定義を１つにまとめるのも処理系の実装次第」 >→→「多くの C 処理系では定義を１つにまとめちゃう」 >となっただけです。 > >>b.cのint a;がextern int a;と解釈されている訳ではないという解釈で宜しいでしょうか？ >コンパイラは int a; を勝手に extern int a; と解釈しません。 >そのへん関数宣言と変数宣言で文法が違う場所です。 なるほど。理解できました。 ご丁寧な解説、ありがとうございます。

リンク先の１２番の解説を文字通りに解釈してください。 仮定義（初期化子なし定義）だけがあって、初期化子あり定義が無い場合、 翻訳単位のEOFに達した時点で仮定義は定義となります。 --hoge.c-- int x; // 仮定義 int x; // 仮定義：何回仮定義が現れても（既存の宣言に反しない限り）問題ない int x; // 仮定義 --EOF of hoge.c-- この時点で int x=0; と定義されたことになる。 >上記の場合だと、b.cのint a;が仮定義なので、 この文章はある意味YES、ある意味NO。確かに int a; は仮定義ですが、既に述べたとおり 翻訳単位 (b.c) の EOF に達した時点で、仮定義は「仮ではない『定義』」になります。 よって提示の例では a.c b.c ともに変数 a が定義されています。 そこではじめてリンク先１３番目の解説が効いてきます。 >a.cで定義されているint a = 1;のオブジェクトとまとめられたと言うことで 「仮定義だからまとめられた」のではありません。 「C では、定義が複数ある場合の挙動が定められていない」（未定義動作） →「エラーにするのも、定義を１つにまとめるのも処理系の実装次第」 →→「多くの C 処理系では定義を１つにまとめちゃう」 となっただけです。 >b.cのint a;がextern int a;と解釈されている訳ではないという解釈で宜しいでしょうか？ コンパイラは int a; を勝手に extern int a; と解釈しません。 そのへん関数宣言と変数宣言で文法が違う場所です。

>それをやっちゃうと、swap(float *a, float *b)のような関数で困りますし。 なるほど。仰られる通りです。 >もともと、プロトタイプ宣言なんて書かなくても(警告は出ても)動きますから、 >結合はされるとしても、プロトタイプ宣言の有効範囲は微妙な問題のように >思います。 > >以下のソースをbcc32でコンパイルしたところ、 > >void hoge1(void) >{ > extern void piyo(int a); > > piyo(1); >} > >void hoge2(void) >{ > piyo(2); >} > >こんなエラーが出ました。 >エラー E2356 proto2.c 10: 'piyo' の再宣言で型が一致していない(関数 hoge2 ) >エラー E2344 proto2.c 3: 一つ前の 'piyo' の定義位置(関数 hoge2 ) > >hoge2のブロックの先頭に「extern void piyo(int a);」を入れると >ちゃんと通るので、少なくともbcc32においては、hoge1()内部の宣言がそのまま >hoge2()内部で有効になっているというわけではないようです。 > >この件について規格書になにか書いてないかとぱらぱらめくったのですが >見つけられませんでした。 わざわざ規格書まで調べて頂き有り難うございます。 と、ゆうことは処理系依存って事なんでしょうね…。

>　どうせ仮引数でdoubleしか渡せないのなら、void sub_funcの関数宣言での >floatへのポインタの仮引数宣言は、doubleへのポインタに読み替えられて >いるのではないかという勝手な勘違いです。 それをやっちゃうと、swap(float *a, float *b)のような関数で困りますし。 >　例えば、別のモジュールで定義宣言されている関数を、他のモジュールの >関数ブロック内でextern void f (void)とすると(普通はこんなことしませんが)、 >その関数ブロック内だけでその関数への参照が可能だと思っていたのですが、 >それより下の関数定義ブロック内でも参照可能となっていました(VC++ 6.0で確認)。 もともと、プロトタイプ宣言なんて書かなくても(警告は出ても)動きますから、 結合はされるとしても、プロトタイプ宣言の有効範囲は微妙な問題のように 思います。 以下のソースをbcc32でコンパイルしたところ、 void hoge1(void) { extern void piyo(int a); piyo(1); } void hoge2(void) { piyo(2); } こんなエラーが出ました。 エラー E2356 proto2.c 10: 'piyo' の再宣言で型が一致していない(関数 hoge2 ) エラー E2344 proto2.c 3: 一つ前の 'piyo' の定義位置(関数 hoge2 ) hoge2のブロックの先頭に「extern void piyo(int a);」を入れると ちゃんと通るので、少なくともbcc32においては、hoge1()内部の宣言がそのまま hoge2()内部で有効になっているというわけではないようです。 この件について規格書になにか書いてないかとぱらぱらめくったのですが 見つけられませんでした。 ご存知の方がいらっしゃいましたら情報よろしくお願いいたします(_o_)

774RRさん、度々申し訳ありません。 すばやいレスありがとうございます。 つまり、 --a.c-- int a = 1; // 定義 --b.c-- int a; // 仮定義 上記の場合だと、b.cのint a;が仮定義なので、a.cで定義されているint a = 1;のオブジェクトとまとめられたと言うことで、b.cのint a;がextern int a;と解釈されている訳ではないという解釈で宜しいでしょうか？ （774RRさんがお書きになったリンク先の13番目の項目に該当するので、結局それは処理系依存になる為、VC++ 6.0ではまとめられて解釈されたというような解釈で宜しいでしょうか？） 後、くだらない事をお聞きしますが、 -- a.c -- #include <stdio.h> extern void f (void); // a.c の関数 f と結び付く(通常externは付けないけど) int main (void) { f (); return 0; } static void f (void) { printf ("a.c の関数 f\n"); } -- b.c -- #include <stdio.h> extern void f (void) { printf ("b.c の関数 f\n"); } の場合、main関数のf関数の呼び出しは、a.cにある関数fとなりますが、この場合のextern void f (void)の関数プロトタイプ宣言のリンケージ属性はどうなるのでしょうか？ くだらない質問ですが、宜しくお願い致します。

関数宣言と変数宣言では話が違います。 関数宣言の省略時解釈は extern つまり外部結合ありです。 関数定義においても省略時解釈は extern つまり外部結合ありです。 関数定義と関数宣言とでは書式が違うので誤解を生む余地が無く、問題は発生しません。 大域変数の「定義にならない宣言」の場合は extern が必須です。 extern を書かずに大域変数を宣言し、初期化子が無い場合 ・C の場合：変数の仮定義となります。仮定義は複数個あってかまいません。 ・C++ の場合：変数の定義となります。定義は１つしか許されません。 ・C/C++ とも、その大域変数は外部結合となります。 --a.c-- extern int g; /* 定義にならない宣言 */ int g; /* 仮定義 */ int g=1; /* 定義 */ C の場合、言語規格は 「同一翻訳単位中に同一名称の大域変数の複数個の仮定義がある」ことを認めています。 「複数翻訳単位中に同一名称の大域変数の定義がある」ことは定めておらず、 たいていの処理系では全翻訳単位での定義を１つにまとめてしまいます。 ==b.cpp== extern int g; /* 定義にならない宣言 */ int g; /* 定義 */ int g=1; /* 再定義：エラー */ C++ の場合、仮定義などというものはないので 「同一翻訳単位中に同一名称の大域変数の複数個の定義がある」 「複数翻訳単位中に同一名称の大域変数の複数個の定義がある」 の両方が言語規格上、認められずエラー発生となります。 http://www2s.biglobe.ne.jp/~hig/q_a/Programing_QA02.html

774RRさん、はじめまして。 >>>int hoge(void); という関数宣言は extern int hoge(void); と解釈されます。 >>そのため、過去のコンパイラ用に書かれたコードとの互換性のために、 >>「複数個の翻訳単位で同一名称の変数が定義されたら、それを同一の実体とみなす」 >>処理系がほとんどです。 という事は、他の翻訳単位のファイルスコープ(外部宣言)で同一識別子で変数定義宣言をおこなった場合でも、省略時解釈ではexternになるために省略可能(でも普通は区別する為に付けますが)って解釈で宜しいのでしょうか？

>>・どこかで定義されている関数を使う場合、プロトタイプ宣言を行うが、 >>　これにはexternをつけても付けなくても良い(で、たぶん普通はつけない) つけてもつけなくても良い、というか単純に省略時解釈なだけですね。 int hoge(void); という関数宣言は extern int hoge(void); と解釈されます。 void piyo(void) {} という関数定義は extern void piyo(void) {} と解釈されます。 extern がついているので外部結合となるわけです。 あと C と C++ では規則が少し変更されていて --a.cpp-- int g; --b.cpp-- int g; とするとエラーになります (One Definition Rule : ISO/IEC 14882:1998 3.2) C の場合 ODR の規定がありません。 そのため、過去のコンパイラ用に書かれたコードとの互換性のために、 「複数個の翻訳単位で同一名称の変数が定義されたら、それを同一の実体とみなす」 処理系がほとんどです。 # そーいうコードが多く残っているので。

　(ぱ)さん、はじめまして。 　丁寧なご解答ありがとうございます。 >そうです…と答えると一言で終わってしまうわけですが、何か疑問があるので >質問されたのだと思います。そこをもう少し明確にしていただけると、何か回答 >できるかもしれません。 >たとえばfloat 4バイト、double 8バイトの処理系を仮定したとして、fは実は >doubleなので 8バイトです。その領域をfloat *で読めるはずはないわけです。 　 　するどいですね。実は私が最初に思ったのが、どうせ仮引数でdoubleしか渡せないのなら、void sub_funcの関数宣言でのfloatへのポインタの仮引数宣言は、doubleへのポインタに読み替えられているのではないかという勝手な勘違いです。 　それでちょっと心配になったのでご質問させて頂きました。 　後、externとリンケージについての解答もありがとうございます。 >・どこかで定義されている関数を使う場合、プロトタイプ宣言を行うが、 >　これにはexternをつけても付けなくても良い(で、たぶん普通はつけない) 　昔、プロトタイプ宣言にexternをつけていたプログラムがあったので、一時期付けていた記憶があります。 　話はちょっと脱線しますが、http://okuyama.mt.tama.hosei.ac.jp/unix/C/slide82-1.htmlにある解説、表はちょっと分かりずらいと思うのですが…。 　例えば、別のモジュールで定義宣言されている関数を、他のモジュールの関数ブロック内でextern void f (void)とすると(普通はこんなことしませんが)、その関数ブロック内だけでその関数への参照が可能だと思っていたのですが、それより下の関数定義ブロック内でも参照可能となっていました(VC++ 6.0で確認)。 　変数の場合であれば、その関数ブロック内のみ有効な筈ですが…。 　うーん、ややっこしい。 　ちょっと長くなりそうなので、この辺でやめておきます。 　これからもちょくちょく寄らせて頂きますので、宜しくお願い致します。

>　初めまして、九龍と申します。 >　C言語でのプログラム経験は結構長いのですが、ある事が分からなかったので、 > C言語ポインタ完全制覇に購入させて頂きました。 はじめまして。お買い上げいただきありがとうございます。 >　それで、現在読んでいる真っ最中なのですが、p303ページに記載されている >「fは勝手にdoubleに読み替えられているので，当然正しく渡らないことになります.」 > の意味が分かりません。 >　上記は、仮引数float fは、double fと読み替えられているため、fのポインタを >渡しても、void sub_func 関数では、floatへのポインタで間接参照されるため、 >正常に参照されないということでよろしいのでしょうか？ そうです…と答えると一言で終わってしまうわけですが、何か疑問があるので 質問されたのだと思います。そこをもう少し明確にしていただけると、何か回答 できるかもしれません。 たとえばfloat 4バイト、double 8バイトの処理系を仮定したとして、fは実は doubleなので 8バイトです。その領域をfloat *で読めるはずはないわけです。 >　後、もし宜しければexternとリンケージに関する事も教えて頂ければと思います。 >　p80の脚注にも出てきているので、ちょっとインターネットで調べてみたのですが >(http://okuyama.mt.tama.hosei.ac.jp/unix/C/slide82-1.html)、見た瞬間に >定義宣言と参照宣言、関数プロトタイプ宣言がごっちゃになりました。 そのページにあるように、外部結合とは、 | プログラムが複数のソースファイルから構成される場合，それらすべての | ソースファイルにおいて同一のオブジェクト，或いは関数として参照。 ですよね? それに対し内部結合はそのソースファイルの中だけで有効なリンケージです。 関数や変数を内部結合にするためにはstaticを付けますが、 外部結合の場合、定義では何もつけず、宣言ではexternを付ける…と決まっていれば 説明が楽なのですが、実際には、 ・どこかで定義されている変数を参照する場合、externを付けなくても、たいていの 　処理系では何のエラーにもならない(p.317を参照) ・どこかで定義されている関数を使う場合、プロトタイプ宣言を行うが、 　これにはexternをつけても付けなくても良い(で、たぶん普通はつけない) ということで、説明がややこしくなっています。 >　（なにせ今まで、どこかで定義宣言をしている変数を参照する場合には、 > externを付ければ良いぐらいにしか思ってなかったんで。） この認識で正しいと思います。

　初めまして、九龍と申します。 　C言語でのプログラム経験は結構長いのですが、ある事が分からなかったので、C言語ポインタ完全制覇に購入させて頂きました。 　それで、現在読んでいる真っ最中なのですが、p303ページに記載されている「fは勝手にdoubleに読み替えられているので，当然正しく渡らないことになります.」の意味が分かりません。 　上記は、仮引数float fは、double fと読み替えられているため、fのポインタを渡しても、void sub_func 関数では、floatへのポインタで間接参照されるため、正常に参照されないということでよろしいのでしょうか？ 　一生懸命意味を理解しているつもりですか、拙い理解能力で申し訳ありません。 　後、もし宜しければexternとリンケージに関する事も教えて頂ければと思います。 　p80の脚注にも出てきているので、ちょっとインターネットで調べてみたのですが(http://okuyama.mt.tama.hosei.ac.jp/unix/C/slide82-1.html)、見た瞬間に定義宣言と参照宣言、関数プロトタイプ宣言がごっちゃになりました。 　（なにせ今まで、どこかで定義宣言をしている変数を参照する場合には、externを付ければ良いぐらいにしか思ってなかったんで。） 　宜しくお願い致します。

本筋と関係ないですが。 >（ぱ）さん、kit2004さん本当にありがとです。 kitさんはkitさんであってkit2004さんではないわけですが、 神奈川さんが「kit2004」さんだと思ってしまったのは、スレッド表示のとき ハンドル名と日付の間に空白が空いてなかったからだと思います。 これは掲示板の仕様の問題で、要するに私が悪いので、先ほど修正しました。 数日前から気になってはいたのですが、対応が遅くなりましてすみません。

件名を変更しました。 （ぱ）さん、kit2004さん本当にありがとです。 根本的なところから、やり直す必要が多々あるかもしれません。 プログラムを始めてから、はや2週間ぐらいになります。 ここまで成長（といってもまだまだですが）したのも、ひとえに皆さん のお陰だと思っています。 解らない事もたくさんあり、丁寧に教えてくださったり、サイトを教えてくださったり 本当に感謝しています。 プログラム以外の基本的なこと（ぱ）さんが指摘してくださった。質問のしかたなど も勉強になりました。 こんな基本的なことも知らずに皆さんに接していた事は、失礼な事だと承知しました。 皆さんに聞くにしても、ちゃんとしたルールを守る必要があると強く思いました。 私としては、本や参考書などまず自分で調べてみて、解らなかった事は、人に聞くという プロセスを実行しています。そこで安易に「解らなかったから教えてください」という 感じになっていました。もしかしたら皆さんに不快な思いをさせてしまったかもしれません。 もしそうでしたら、申し訳ないです。 もう一つ自分を成長させるためにも、頑張ってみます。そして本当に解らなかった時、 具体的な説明を踏まえ解らない所を説明をします。 また逆に私が皆さんのお役に立てるように皆さんのお話を継承しこの掲示板を利用していきたいと思います。

> こういう場合は、似たようなことを > している他人のプログラムを読んで理解し、真似を > することから始めるのがいいんじゃないでしょうか。 書き忘れましたが、読むプログラムは一つではなく、 多いほうが良いです。勉強ってどういう分野でも そうなんですけど、沢山読んでいるうちに、だんだん どうすれば良いのか分かるようになってきます。

ちょっと気になるのは、神奈川さんがどういう立場で プログラミングをされているかですね。 自力でプログラミングができるようになることが目的で あれば、分からない問題を安易にBBSで聞いて解決する のは考えものです。むしろ、ひとに全く聞かなくても 自分で解けるようになるにはどうすれば良いのかを 考えた方がいいと思います。 最初のうちは、自分で解こうにもどうすればいいのか 見当もつかないことも多いわけですし、神奈川さんの 質問自体、まさにそういう状態にあると思われる質問 なわけですが、こういう場合は、似たようなことを している他人のプログラムを読んで理解し、真似を することから始めるのがいいんじゃないでしょうか。 似たようなプログラムはあるけどどう変えたらいいのか 分からないような場合、それは結局、そのプログラムが どういう動作をしているかちゃんと理解できてないという ことを意味しますから、理解できるようになるまで、 変数の内容表示を行う文を挿入したり、デバッガによる トレースなどを行いながら、他人のプログラムを繰り返し 読むというのが、遠回りに見えて実は近道になると思います。 神奈川さんの質問を見ていると、そもそも他人の書いた プログラムを細部までちゃんと理解して読んだ経験が 少なそうに見える点、そしてもっと大きな問題として、 自分で書くプログラムについても、どう動作するのか、 ちゃんと理解してないように見える点が気になります。 このあたりの問題をきちんと解決しておかないと、当面の 問題は解決できても、いつまでたっても一人だちできない ということになりかねません。 あと、これは基本中の基本なので、わざわざ指摘するのも 何か変な気もするのですが、インデントも変ですよ。 使い捨てのテストプログラムならともかく、人に見て もらう場合、インデントを正しくつけるのは、最低限必要な ことだと思います。

>ここで問題なのは、属性を作成するとエラーが発生してしまうということです。 このプログラムを自分のところでコンパイルして動かすほど私は親切ではないので、 エラーが出たというのなら、どんなエラーが出たかぐらいは書いてください。 もちろん、エラーメッセージを直接コピペする形で。 掲示板やMLに質問する際の質問のしかたについては、以下のページが参考になります。 JavaHouse Topics。この中の「質問のしかたについて」 http://java-house.jp/ml/topics/ 技術系メーリングリストで質問するときのパターン・ランゲージ http://www.hyuki.com/writing/techask.html 真 技術系メーリングリストFAQ http://www.geocities.co.jp/SiliconValley/5656/

件名を変更しました。 またXMLで解らない事が出てきてしまいました・・・ 問題例を以下に記述します。 ---あ.xml---- <愛　id=1> 　　<b> 　　　　<c> 　　　　</c> 　　</b> 　　　　<愛　ID=2> 　　　　</愛> </愛> ------------ 特定のタグの属性の下に -- <k> 　<愛　ID＝７>あああ</愛>　　 </k> を記述しそのタグ＜愛＞に属性を与えるというプログラムです。 ☆例えば、あ.xmlの<愛　ID=2>の下に <k> 　<愛　ID＝７>あああ</愛>　　 </k> を加えたりするなどです。 ここで問題なのは、属性を作成するとエラーが発生してしまうということです。 以下に自作したプログラムを記述します。 static void selectionAppend() throws Exception { DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); DocumentBuilder db = dbf.newDocumentBuilder(); Document doc = db.parse(new FileInputStream("あ.xml")); NodeList list = doc.getElementsByTagName("愛"); for (int i = 0; i < list.getLength(); i++) { Element node = (Element)list.item(i); if (!(node instanceof Element)) continue; String value = ((Element)node).getAttribute("ID"); //ここで対象属性名を指定し if (value != null && value.equals("2")) { //ここで対象属性値を指定する Node child1 = doc.createElement("k"); Node child2 = doc.createElement("愛"); //↑ここのタグに属性を追加したい、setAttribute("ID", "7");このメソッドを代入する //のでしょうがどのように代入すればよろしいでしょうか。 Node child3 = doc.createTextNode("あああ"); child2.appendChild(child3); child1.appendChild(child2); node.appendChild(child1); //↑ここでツリー構成は完了していることになるのでしょうか？できたとしたら、 //NodeList know = node.getElementsByTagName("愛"); //Element knowe = (Element)know.item(0); //knowe.setAttribute("No", "8"); //こうするのでしょうが、 //解らなくなってしまったので、また質問しにきました。宜しくお願いします。 } } FileOutputStream out = new FileOutputStream("あ２.xml"); DOMSource src = new DOMSource(doc.getDocumentElement()); StreamResult dst = new StreamResult(out); Transformer tfm = TransformerFactory.newInstance().newTransformer(); tfm.transform(src, dst); out.close(); }

※この投稿は、現在の裏掲示板に投稿されたものを前橋が転載したものです。 丁寧な，ご返答ありがとうございます．大変，参考になりました．大分，整理がついてきました． 心から，感謝します． 今後も，疑問が沸いてくると思いますが，どうしても，手に負えない場合には，相談させて頂きます．お時間が，ありましたら返答して頂けたら幸いです． > よろしければ、studentさんの最初の投稿から、全て表の掲示板に移行しようと > 思うのですが、よろしいでしょうか? 是非，移行してください．

※この投稿は、現在の裏掲示板に投稿されたものを前橋が転載したものです。 > オブジェクト指向再入門を読ませて頂きました．大変，勉強になりました． ありがとうございます。 > こんな，私が，今，一番悩んでいることは，まさに，関数による再利用性との違いです． そのあたりのことについては、 「オブジェクトに仕事をさせる、ということ」 http://kmaebashi.com/programmer/object/shigoto.html に書いたつもりです。 まとめると、関数による再利用では、関数の呼び出しをまたがって何らかのデータを 保持することができない、ということです。無理に保持しようとすると、 例に出したstrtok()のような困った仕様になってしまいます。 これで回答になっていますでしょうか? ところでお願いですが、 現在、当サイトの掲示板は以下のURLに移転しています。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs ここは裏掲示板でして、ザンボットがどうのZガンダムがどうのといった話ばかり しているのはそのためです。 「オブジェクト指向再入門」のページのリンクが古いままになっていました。すみません。 よろしければ、studentさんの最初の投稿から、全て表の掲示板に移行しようと 思うのですが、よろしいでしょうか? よろしいようでしたら、投稿内容をこちらで貼り直します。

※この投稿は、現在の裏掲示板に投稿されたものを前橋が転載したものです。 オブジェクト指向再入門を読ませて頂きました．大変，勉強になりました． 私は，オブジェクト指向プログラミングを初めて，２ヶ月の初心者であります． こんな，私が，今，一番悩んでいることは，まさに，関数による再利用性との違いです． ここが，どうも，頭の中で整理出来ていません． どうか，教えてください．お願いします．

>>しかしLinkedHashsetやSetなどのシンボルが解決できないとというエラーが >>起こってしまいました。 > >LinkedHashSetやSetはjava.utilパッケージにありますから、 >importしなければそうなって当たり前です。 すみません（TOT） ioのパッケージに含まれいるものだと思っていました。 変な勘違いをしていました。何してんだ私・・・ とりあえず解決は、しました。よくよく考えれば当たり前なのに・・

>しかしLinkedHashsetやSetなどのシンボルが解決できないとというエラーが >起こってしまいました。 LinkedHashSetやSetはjava.utilパッケージにありますから、 importしなければそうなって当たり前です。 SAXなどのパッケージはimportしているわけですから、神奈川さんがimportの 何たるかを知らないとは考えにくいのですが、それでなぜ、java.utilの importを忘れるのかが不思議です。書き忘れるのは別に不思議じゃないですが、 このエラーメッセージを見れば一目瞭然です。 もしかして神奈川さんが、importの何たるかがわかっていなくて、 ネットに落ちてるコードとかを拾い集めてここまでプログラムを書いたのだとすれば、 それはそれでたいしたものではありますが、やっぱり勉強の順番がおかしいように 私には思えます。 >また最後の値｛"け","ちち","た"｝を配列に格納したいのですが 配列に格納したいのなら、すればよいのでは?

>>今度は、txtファイルの読み込みと書き込みについて質問なんですが、 > >APIリファレンスを見ると、InputStreamReaderにはmarkとresetという >メソッドがありますが、markSupportedはfalseのようなので使えませんね。 > >よって、対象とするファイルがよっぽど巨大なのでなければ、 >「最初にいったん全部読み込んでメモリに載せ、いったんclose()し、 >　処理が全部すんだらまとめて書き出す」 >という方法で良いんじゃないでしょうか。 返信送れてしみません。。確かにこの方法しかないようですね。。 これでやってみます。 新たな質問です。 文字列が String[]　a＝｛"あい","うえ","お","かか","きき","こ"｝ String[]　b＝｛"あい","け","お","こ","ちち","た"｝ と二つあるとき,ｂに対してaの文字列を引いた文字列 だけを取得するためのサンプルプログラム作成しようと思っているのですが この場合は、結果的に｛"け","ちち","た"｝のみになります。 以下にプログラムを書きました。 しかしLinkedHashsetやSetなどのシンボルが解決できないとというエラーが 起こってしまいました。 もしよろしければ正しく直していただけるとうれしいのですが、 また最後の値｛"け","ちち","た"｝を配列に格納したいのですが それも含めて宜しくお願いします。 import javax.xml.parsers.*; import org.xml.sax.*; import org.xml.sax.helpers.*; import java.io.*; public class www extends DefaultHandler { public static void main(String[] args) { String[] a = {"あい","うえ","お","かか","きき","こ"} ; String[] b = {"あい","け","お","こ","ちち","た"} ; Set setA = new LinkedHashSet(Arrays.asList(a)); Set setB = new LinkedHashSet(Arrays.asList(b)); setB.removeAll(setA); Iterator it = setB.iterator(); while (it.hasNext()) { System.out.println(it.next()); } }

>はじめまして。 はじめまして。ご指摘ありがとうございます。 >// カーソルの位置の直後の文字を削除 >void backSpace(); > >ですけど >「直後」じゃなくて「直前」ではないでしょうか？ おっしゃる通りです。なにしろbackSpace()ですから、カーソルの前の文字が 消えるのが当然です。 ご迷惑をおかけして申し訳ありません。 正誤表に加えておきました。ご指摘ありがとうございました。

はじめまして。 センス・オブ・プログラミング読ませていただいて気になったのですが、 P.278の真ん中あたりの // カーソルの位置の直後の文字を削除 void backSpace(); ですけど 「直後」じゃなくて「直前」ではないでしょうか？ サンプルコード試すと直前の文字が消えますし。