K.Maebashi's BBS

だんだんこちらのサイトのコンテンツの内容と関係なくなってきましたので、タイトル変えました。 >横槍、失礼します。 横槍大歓迎です。 >でも、オブジェクト指向って、再利用だけが利点でしょうか？ >オブジェクト指向に限らず、「抽象化すること」によって得られる利点を、適当につらつらと考えてみましたが、 > >・ 設計の向上（データ構造、モジュール間の関連等） >・ 可読性の向上 >・ 保守性の向上 >・ 意思疎通の向上 > >等々、ちょっと考えただけでも色々出てきそうです。 うん、なるほど。 確かに抽象化と再利用を直結させるのは短絡的ですね。 が、もう一歩突っ込んで、 ・何のために設計をはっきりさせるん？ ・可読性や保守性が向上するとどんなメリットがあるん？ ・意思疎通が円滑になるとどのように嬉しいん？ という話になると、結局、「バグが減るから嬉しい」に帰結するんじゃないでしょうか。 ＃とか言ってるとそのうち「より儲かるから嬉しい」に帰結しそうで、身も蓋もなくなってくるんですが。 はじまりは 「わけわからんたとえ話よりも、『オブジェクト指向を使うと何が嬉しいのか』に重きを置いて説明すべきではないか」 にあります。 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が未解決'というエラーが出ます。