K.Maebashi's BBS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

aaaaaa

aaaaaa

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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