> はじめまして、C言語ポインタ完全制覇を読ませていただきました。
はじめまして。
> と書かれてあるのですが、これって『malloc()関数を・・・』
> という印刷ミスなんでしょうか？
そうです(印刷ミスというよりは私のtypoでしょうが)。
以下のURLに正誤表がありますので参照してください。
http://member.nifty.ne.jp/maebashi/seiha/seigo.html
ポカが多くて申し訳ありません。
> 素人故にポインタの理解に苦しんでいます。
よろしければ、どのあたりが難しいと思われるか教えていただけませんか?
同じところで悩んでいる人が他にもいるかもしれませんし。
はじめまして、C言語ポインタ完全制覇を読ませていただきました。
この本に書いてあるP０８１に
『それから｢変数｣ではないですが、Cでは、malloc()を関数を使用して動的な
メモリ確保を行うこともできます。・・・ 』
と書かれてあるのですが、これって『malloc()関数を・・・』
という印刷ミスなんでしょうか？
どうでもいいのでしょうが、素人故にポインタの理解に苦しんでいます。
> どうもJN2FMHです。
おや久しぶり。
> w3mで疑り深いあなたのためのオブジェクト指向再入門を読もうとしたら
> 2から先が読めませんでした。と書き込みをしようとしたら
> 下でも同じ指摘がありました。まぁ本題でないのでいいですが。
修正しました。指摘ありがとうございます。
> でJava謎+落とし穴を買ったので今度サインください。
と言われてもアレなんですが(^^; まあ名前くらいならいつでも書かせて
いただきますので、今度何らかのイベントがあったときにでも。
# あー、またメルシャン行きたいような気が。
## 内輪ネタですみません(_o_) > 他の皆様
> 本筋と全然関係ないところで申し訳ないのですが、
> オブジェクト指向再入門のページでHTMLのコメントが閉じてないため、
> 一部のブラウザ(w3mなど)で表示できないようです。
報告ありがとうございます。対応が大変遅れまして申し訳ありません。
おそらく直ったと思います。<!--で開いたコメントを!>で閉じてました(バカ)。
どうもJN2FMHです。
w3mで疑り深いあなたのためのオブジェクト指向再入門を読もうとしたら
2から先が読めませんでした。と書き込みをしようとしたら
下でも同じ指摘がありました。まぁ本題でないのでいいですが。
でJava謎+落とし穴を買ったので今度サインください。
de JN2FMH
> http://member.nifty.ne.jp/maebashi/programmer/object/response3.html
> でレスが付けたれた284です。
わざわざありがとうございます。返事が遅れましてすみません。
# 一昨日から謎の発熱+下痢で呻吟しておりました。
> >>284の意味は前橋さんの解釈された通りです。
> その後、このWEBを発見してから「それは違う」事には気が付きましたが、
了解です。
これはわりとありがちな誤解であると「私は」思うので、
「インスタンスは複数作れることに意味がある」ということに重点を置いて
例のページを書いたわけでして、その見込みが外れているとすると
私は大変に間抜けなことをやっているということになってしまうわけですが、
その辺については284さんのご意見も参考にしたうえでもう少し様子見、
というところですね。
> /* 文字数のチェック. size - 1 にしているのはナル文字の分 */
> if (strlen(buf) > size - 1) {
これでっしゃろ？
strlenの戻り値であるsize_tは、符号無しです。
size変数はintですから符号ありです。
もうお分かりですね？
キャストしてください。
・・・・・・・って、ここはこういう掲示板？(^-^;
C言語体当たり入門P225「List5-6 input_string()」の
サンプルソースは以下の通りなんですが、
void input_string(char *str, int size, FILE *fp)
{
char buf[1024];
/* 正しく入力されるまで繰り返す */
for(;;) {
/* fgets()で1行入力 */
if (fgets(buf, 1024, fp) == NULL) {
fprintf(stderr,"終了します. \n");
exit(0);
}
/* 改行文字を削除する */
chop(buf);
/* 文字数のチェック. size - 1 にしているのはナル文字の分 */
if (strlen(buf) > size - 1) {
fprintf(stderr, "入力が長過ぎます(最大半角%d文字)\n",
size - 1);
} else {
break;
}
}
strcpy(str,buf);
}
上記のプログラムをP232〜の「List5-10」のサンプルソースへ追記してコンパイルをかけた
所以下のようなエラーが出てしまいました。何が原因なのか教えて頂けませんか？
警告 W8012 input_number1.c 62: 符号付き値と符号なし値の比較(関数 input_string )
http://member.nifty.ne.jp/maebashi/programmer/object/response3.html
でレスが付けたれた284です。
http://pc.2ch.net/test/read.cgi/prog/1060622436/l50
でもそーですが、オブジェクト指向を明確に説明出来る人・書き込みを捜してましたが
見つかりませんで、その時のオブジェクト指向についての貧弱な知識を元に>>284を
書きました。
>>284の意味は前橋さんの解釈された通りです。
その後、このWEBを発見してから「それは違う」事には気が付きましたが、まだ全部に
目を通していません。
また勉強させてもらいに立ち寄りますね。(^-^
本筋と全然関係ないところで申し訳ないのですが、
オブジェクト指向再入門のページでHTMLのコメントが閉じてないため、
一部のブラウザ(w3mなど)で表示できないようです。
会社でヒマを見つけて読もうと思った矢先の出来事でした...
# 隣にあるWindowsマシンでFirebird起動して読みました
こんにちは
しばし帰省してたら、なんかスゴイことになってますね(^^;;
本日打ち合わせの席で、プログラムの品質についての話題が出てたんですが、
その席に居合わせた私を除く全員が、
「lintを知らない」という驚愕の事態が判明しました(*_*)
何か聞かれたらとりあえず、「man lintしてください」
でお茶を濁すことにします・・・
GDBをグラフィカルモードで起動するには、
$ gdb -w
で起動するんじゃなくって
$ insight
でGUI版が起動するんですね（＾＾；
gdbは、コマンドライン版で
insightは、gdbのGUI版ってことなのですね。
GUI版がinsightコマンドであるとは知りませんでした...
> 改訂されて消えましたが最初のうちそう言ってたわけです。
ええと、これは
「「メッセージ」なんて言葉を嬉しがって使ってる奴はたいてい
「知ったか」野郎である。」
という文言についてでしょうか?
mkinoさんへの返信で書きましたが、私の認識では、
| 「メッセージ」なんて言葉を嬉しがって使」うような連中って、
| 言語がC++だろうとJavaだろうと、継承もポリモフィズムもなかろうと、
| 「メッセージ」という言葉を嬉しがって使っているように見えますよ。
という認識がまずありまして(この認識が正しいかどうかは置いといて)、
なんでわざわざ、それも手続き指向上がりのOO初心者相手に
そんな言葉を使うかなあ、ということが言いたかったわけでして。
「たいてい」のあたりが免罪符になりませんか。
と言いたいところですが、やっぱりならないでしょうねえ。
というわけで上記文言は修正しました。不快に思われた方、すみませんでした。
> インパクトを求めるのも大事だけども本のふんどしじゃぁないんだから（笑。
いやあ、本のふんどしも重要ってことで(^^;
# でも、オビの言葉は著者の自由にはならないもんらしい、ということを
# いざ本書いてみて知ったわけですが。
> 「メッセージ送出」と呼ばれているのは、多くのオブジェクト
> 指向言語では、実のところ一種の関数呼び出しです。
> (注: 例外もあります。)
> ぐらいにしておいた方がいいんじゃないですかね？ ＞(ぱ)さん
修正しました。
実のところ「多くのオブジェクト指向言語では」という文言よりも、
「単なる」→「一種の」の修正のほうがインパクトがでかいですね。
インパクトが減るという意味で (^^;
いやまあ、ポリモルフィズムというものがある以上、AppleScript以前に、
JavaやC++の範囲内でもある種ウソのある文章ではあったわけですが…
> (ぱ)さんの文章は「メッセージという呼び方が理解を妨げている」とは
> 書いてますが、「メッセージと呼ぶな」とまでは書いてませんよね。
> したがって、どちらにも取れるわけですが、個人的予想では、(ぱ)さんも
> 「関数みたいなものだと説明する」派であって、「メッセージと呼ぶな」
> とまで言っているわけではないんじゃないかなと思ってます。
> まあ、ここら辺が(ぱ)さんの文章の味というか、論議を呼びやすいところ
> というか。:-)
改訂されて消えましたが最初のうちそう言ってたわけです。そこがヲイ！と反発を呼んだんだろうな？と。
注釈で余分な一言を付けちゃってそちらに重点のある文章でお茶を濁しちゃってる部分とか個性と言えば個性なわけですが。
インパクトを求めるのも大事だけども本のふんどしじゃぁないんだから（笑。
まぁ、餅付け！て奴ですね。
> AppleScriptでは、多くの場合非同期で実行する必要のある機能は
> 複数の命令のセットとして実装されます。オーディオプレーヤのiT
> unesを例に取ると、楽曲の再生は「play」命令、終了は「stop」命
> 令で指示し、楽曲の再生状態は「player state」属性を(暗黙の)Ge
> t Data命令で取得するといった手法が一般的です。この場合、命令
> そのものは同期的に実行されますが、楽曲を再生するという機能自
> 体は非同期に実行されていることになります。
ふむむ… これ自体は
kit wrote:
> ここで注意して欲しいのは、言語仕様としては同期呼びだし (関数
> と等価なもの) しかサポートしていなくても、処理の依頼と結果を
> 待つ間に別の処理をはさむこともできるという点です。これには主に
> 2種類のやり方があります。
> 1つは、依頼と結果待ちに別々の関数呼びだし (同期メッセージ)
> を用いる方法です。ここで、依頼される側のオブジェクトは、
> 依頼された時に (依頼する側の実行スレッドを使って) 処理用の
> 別スレッドを起こします。結果待ちのメソッドは、その中で、この
> 処理用スレッドの完了を待てば良いわけです。もちろん、こういう
> やり方の場合、オブジェクトの実装の方で、依頼と結果待ちの２つの
> メソッドをサポートしている必要があります。
上記の枠内でも説明可能な話ですね。
が…
> この場合の命令は遠隔手続きの非同期呼び出しそのものに見えるの
> ですが、命令(メッセージ)が返ることは保証されていません。この
> ため、AppleScriptには任意の命令に対して任意のタイムアウト時
> 間を指定する機能が標準で用意されています。
任意の命令について、タイムアウトが指定できるわけですか。
でしたら、確かに言語仕様レベルで、関数呼び出しとしてのセマン
ティックスを逸脱してますね。納得しました。確かに、AppleScript
の場合も、「単なる関数呼び出しです」では、表現として問題が
ありそうです。
やっぱり
「メッセージ送出」と呼ばれているのは、 実のところ
単なる関数呼び出しです。
というのは、
「メッセージ送出」と呼ばれているのは、多くのオブジェクト
指向言語では、実のところ一種の関数呼び出しです。
(注: 例外もあります。)
ぐらいにしておいた方がいいんじゃないですかね？ ＞(ぱ)さん
より正確になる分、文章としてのインパクトは減りますが… ^^;
> なるほど、Actor モデルに照らし合わせれば、Smalltalk で
> “メッセージ”をメッセージと呼ぶのは勇み足だという主張ですね。
う、勇み足と言うほど、強い主張じゃないです。
「メッセージと呼ぶ必然性は薄れている」くらいの感じです。
> Actor モデルに立脚しているユーザーが、同期メッセージをして
> その実行モデルが“関数”と等価だからといってそう呼称することを
> 推奨してそれが通るか…という点については議論の余地はあると思います。
僕は関数と「呼称する」ことを推奨しているわけではないです。
そうではなくて、関数だと「説明する」のが、非オブジェクト指向言語から
の移行組には、分かりやすいんじゃないかなと思っているわけです。
(ぱ)さんの文章は「メッセージという呼び方が理解を妨げている」とは
書いてますが、「メッセージと呼ぶな」とまでは書いてませんよね。
したがって、どちらにも取れるわけですが、個人的予想では、(ぱ)さんも
「関数みたいなものだと説明する」派であって、「メッセージと呼ぶな」
とまで言っているわけではないんじゃないかなと思ってます。
まあ、ここら辺が(ぱ)さんの文章の味というか、論議を呼びやすいところ
というか。:-)
> ときに、kit さんは Lisper and/or Schemer ですか？
う、Lisp は大好きな言語ですが、Toy Program くらいしか書かないので…
しかも一番良く使ってたのが20年くらい前、おまけにLispのプログラムを
書くより、Lispの処理系の中身を見てた時間の方が長いという… ^^;
というわけで、Scheme は、教養的レベルの知識しかありません。^^;
> その辺でなんか「実装の都合」があるのかと邪推してしまったわけですが、
> うちゃさんのおっしゃるように、
>
> >UndoManagerがsetFontというメッセージを預かって
> >おいて、実際のUndoが行われたときに、aObjに対して預かっていた
> >メッセージを送る。ということになります。
>
> と考えれば、これが自然なのかもしれません。
> 私としては、「メッセージを預かる」というメッセージを送るのではなく、
> UndoManagerにいきなりメッセージを送ってしまうあたりがどうも不自然に
> 思ったのですが、それは私がObjective-Cの考え方に慣れてないせいかな。
>
"メッセージ"＝"Cの関数呼び出し"として考えると、不自然に思えるでしょうね。
実際、dentomさんのサンプルコードをC++の表記法で書きなおすと、非常に不思議な
コードに見えますから、
C->Objective Cという順序でオブジェクト指向に入る場合は、"メッセージ"＝"関数
呼び出し"という説明はかえって理解を妨げるものになるのではないかと思います。
（同じように、オブジェクトを構造体に毛が生えたものという説明も適切ではありません。）
> > メソッド呼び出しの「実装」が動的束縛になっているからといって、
> > 呼び出す相手が決まっているのであれば、機能的に関数呼び出しと変わらない。
> > むしろこの場合「動的束縛である」ということの方が実装詳細です。
>
> 呼び出す相手(オブジェクト)が決まっていても、メソッドがオーバーロードされて
> いれば呼び出されるメソッドが異なることもあります。
いや、だから、ここで「呼び出す相手」と言っているのは「メソッド」の
ことであり、「オブジェクト」のことではないんですが。
だから、
>動的束縛が入ろうが入るまいが、「呼び出す相手が決まっている」
>場合、つまり、動的束縛があっても所詮相手が一個しかない(かつ、あるに
>決まっている)場合は、動的束縛は実質効かないわけですから、機能的に
>関数呼び出しと変わらない、と言っているのです。
こう書いているのですが…
> > 誰でもいいですね。でも今のままだとかなりCプログラマあがりの人
> > に限定されてますが、限定条件が書かれてないので大変迷惑なページ
> > になっています。
>
> ほんとですね。
> 以前、同タイトル(オブジェクト指向再入門)を持つ、
> http://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak/squeak.html
> というページにはだまされましたよ。
はて。ご指摘のページのタイトルは「Happy Squeaking!!」で、処理系は Squeak
に限定され、しかも再入門云々はサブタイトルのように見受けられますが？
> 誰でもいいですね。でも今のままだとかなりCプログラマあがりの人
> に限定されてますが、限定条件が書かれてないので大変迷惑なページ
> になっています。
ほんとですね。
以前、同タイトル(オブジェクト指向再入門)を持つ、
http://www.ogis-ri.co.jp/otc/hiroba/technical/Squeak/squeak.html
というページにはだまされましたよ。
Smalltalk のオブジェクト指向はちゃんと「Smalltalk の」って
書いておいてほしいですよね。そうすれば区別できるのに。
限定条件って大事。
> 前の反論のふたつ目で書いたんですが、この「メッセージ送出=関数呼び出し」
> に関しては、別に実装の話をしているつもりはないんです。
> 「機能が同じだから」同じだといっているのです。
たぶん、皆さんが何となく引っ掛かっているのは、「関数呼び出し」というのは
メッセージを受信したオブジェクト側の動作であって、メッセージを送出した側
の動作ではないということではないかと思います。
オブジェクトがメッセージを受信した結果として行うことは、ほとんどの言語では
メソッドという手続きの呼び出しとして実装されているので「関数呼び出し」と言
われても強く否定できません。が、メッセージの送出側としては、受信側のオブジェ
クトが手続きを呼び出そうが何しようが知ったこっちゃ無いのです。
> メソッド呼び出しの「実装」が動的束縛になっているからといって、
> 呼び出す相手が決まっているのであれば、機能的に関数呼び出しと変わらない。
> むしろこの場合「動的束縛である」ということの方が実装詳細です。
呼び出す相手(オブジェクト)が決まっていても、メソッドがオーバーロードされて
いれば呼び出されるメソッドが異なることもあります。
C++では決まり切ったメッセージの送出とメソッドの呼び出しは単なる関数呼び出
し(inlineなら呼び出しもしない)に解決してしまいますが、むしろそっちの方が実装
詳細という感じがしますがどうでしょう。
いや、というか、いずれにせよ実装詳細なのですから、やはり「メッセージ送信」は
「メッセージ送信」であり、「関数呼び出し」とはちょっと違うわけで、それを
「関数呼び出し」と称するのはC++にご配慮しすぎという感じがします。
> 「Cプログラマのための」という限定条件を付けるべきだった、ということは、
> 現在は限定がないせいで、対象でない人も対象になっているように見える、
> ということですね。それは誰でしょうか。
誰でもいいですね。でも今のままだとかなりCプログラマあがりの人
に限定されてますが、限定条件が書かれてないので大変迷惑なページ
になっています。
> 別に「サブルーチンコール」でも「プロシジャ」でもよいわけなんですが。
> 似たような機能は、BASICとかはともかくたいていの言語にありますよね。
>
> その機能を知っている人に対し、(動的束縛が入るとはいえ)ほぼ同じ
> 機能について説明するのに、別の言葉を持ち出す必要はないだろう、
> ということです。
サブルーチンコールでもプロシジャでもいいならメッセージでも
いいですね。オブジェクト指向で利用される一般的な用語をあえて
(Cなどに特有の)用語に言い換える必要はないでしょう。
> > setter/getter意味ねーのか全部publicでいいや、と思わせがち
> > なとことか、言葉足らずの部分もわかっててやってるにしちゃ
> > 罪深すぎます。
>
> オセロの例を見れば分かると思うんですが、カプセル化自体、
> 否定しているつもりはありません。
カプセル化になってない例として明記するならともかく、あの
タイトル(これはお気づきになられたようですが)、あの書き方、
あの内容では読む人に誤解を与えるだけです。
> >Cでこれをやろうとすると、関数ポインタを使うところまではいいんですが、
> >引数を動的に積むことができないので困りますねえ。
>
> 普通に可変長引数使うんじゃないですか？
> しょせんランタイムはCで書いてあるので、
> Cでできないことはないはずです。
可変長引数は、引数の分からない関数の実装側で引数を受け取るための
メカニズムであって、実行時まで引数の分からない関数をうまく呼び出す
仕掛けは、Cにはないと思います。
C-FAQの15.13にありますね。
http://www.catnet.ne.jp/kouno/c_faq/c15.html#13
dentomさんへのレスでこう書いたのは、
>わざわざaObjにメッセージを送っているのは、そうしないと
>NSInvocationとやらが手に入らないから? (違うような気がする)
その辺でなんか「実装の都合」があるのかと邪推してしまったわけですが、
うちゃさんのおっしゃるように、
>UndoManagerがsetFontというメッセージを預かって
>おいて、実際のUndoが行われたときに、aObjに対して預かっていた
>メッセージを送る。ということになります。
と考えれば、これが自然なのかもしれません。
私としては、「メッセージを預かる」というメッセージを送るのではなく、
UndoManagerにいきなりメッセージを送ってしまうあたりがどうも不自然に
思ったのですが、それは私がObjective-Cの考え方に慣れてないせいかな。
> おいらの出したUndoManagerの例も関数呼び出しだと
> 決めつけている理由がさっぱりわからないんですけど。
どうもなんか誤解されているようなので一応書いておきますが、
>>呼び出す相手が決まっているのであれば、機能的に関数呼び出しと変わらない。
>これの否定にはなっていないのでは。
この引用部分の元ネタがどうなっていたかというと、
>メソッド呼び出しの「実装」が動的束縛になっているからといって、
>呼び出す相手が決まっているのであれば、機能的に関数呼び出しと変わらない。
>むしろこの場合「動的束縛である」ということの方が実装詳細です。
>
>もちろん相手が決まらない場合は機能も違うわけですが、それについては
>「別に最初に知らなければならないことではない」と思っているわけです。
こうです。動的束縛が入ろうが入るまいが、「呼び出す相手が決まっている」
場合、つまり、動的束縛があっても所詮相手が一個しかない(かつ、あるに
決まっている)場合は、動的束縛は実質効かないわけですから、機能的に
関数呼び出しと変わらない、と言っているのです。
もちろん動的束縛で相手が変わる場合は機能も違うわけですが、
「別に最初に知らなければならないことではない」と言っているわけです。
そこへUndoManagerの話を持ってきても、「これの否定にはなっていないのでは」
と言っているのです。
非同期メッセージの話は散々出てますから、まずそっちを読んでください、
としか言いようがありません。
Lispの言語実装についてはあまり詳しく知らないので上手く比較で
きません。ごめんなさい。その代りに、AppleScriptの非同期命令
について知るところを書きます。
AppleScriptに於て、命令は基本的に逐次同期的に実行されるよう
期待されています。これは、この言語がもともとアプリケーション
のバッチ処理を目的として開発されたものだからです。このため、
同じ命令を同期/非同期で送信する機能は言語仕様に含まれておら
ず、アプリケーション側に両方の命令を実装するといったことも推
奨されていません。
もっとも、アプケーション側の実装そのものはなんら制限されてお
らず、命令の終了を処理のどのタイミングで指示するかはメッセー
ジを受け取る側のアプリケーションの自由となっています。実際、
非同期の命令を持つアプリケーションも存在します。しかし、これ
は一般的な非同期処理の手法としては用いられていません。
AppleScriptでは、多くの場合非同期で実行する必要のある機能は
複数の命令のセットとして実装されます。オーディオプレーヤのiT
unesを例に取ると、楽曲の再生は「play」命令、終了は「stop」命
令で指示し、楽曲の再生状態は「player state」属性を(暗黙の)Ge
t Data命令で取得するといった手法が一般的です。この場合、命令
そのものは同期的に実行されますが、楽曲を再生するという機能自
体は非同期に実行されていることになります。
この場合の命令は遠隔手続きの非同期呼び出しそのものに見えるの
ですが、命令(メッセージ)が返ることは保証されていません。この
ため、AppleScriptには任意の命令に対して任意のタイムアウト時
間を指定する機能が標準で用意されています。
こんなものでどうでしょうか?
kitさん wrote:
> 遠隔手続き呼びだし機構としては珍しくないですが、言語の関数／メソッド
> 呼びだし機構自体に非同期処理が組み込まれていることは、むしろ稀だと
> 思います。(以下略)
なるほど、それは確かにそうですね (^ ^；
私の知る範囲では、どの環境も非同期処理についてはメッセージ機
構を独自実装しています。C++などで非同期なメッセージングを実
現しようと思えば、当然そういった手法に頼らざるを得ない訳で…
そういう意味で、「非同期のメッセージングは関数呼び出しとは考
えにくい」という主張は理解できます。
> dentomさん、本多さん 横レス失礼します。
いえいえ。簡潔明瞭な説明でわかりやすかったです。
> > どこかのobject(drawObject?)用のmethodを借りてきて(?)使うって感じなのかなぁ?
> ”メッセージ”よりの説明すると、UndoManagerがsetFontというメッセージを預かって
> おいて、実際のUndoが行われたときに、aObjに対して預かっていたメッセージを送る。
> ということになります。
そういうことですね。預かっておくっていうimageが
最初のdentomさんの書き込みだけでは私には想像できなかったので、
借りるって感覚なのかと想像しましたが、説明を読んで納得しました。
> こういうところが動的束縛のおもしろいところなのですが、aObjにどんなメソッドが
> あるかとか、送られたメッセージを正しく解釈できるのかとかは、UndoManagerは関知し
> ません。知っているのはコードを書いた人だけです。
たしかにすごく面白い機能ですね。
どういう背景があってこういう機能が組み込まれることになったのか
どういう場面でどの程度威力を発揮するのか、ちょっと想像しにくいですが、
本当に面白い機能ですね。
> あらかじめ知らせておく必要がないため（Undoで行う操作の全てをUndoManagerに教えて
> おく必要がない）UndoManagerに登録できるObjectにもMessageにも制限がありません。
> これを自由でやりやすいと見るか、いいかげんで信用できないと見るかで評価が分かれる
> ところなんでしょう（＾＾；
仕事でcriticalな場面でガリガリ使うにはちょっと勇気がいるような気もしますが
自由があるのは理解できます。
#↑は、もちろん使ったことのない良く知らない私が勝手に怖がってるだけでしょうけど。
> 本多さん申し訳ない。あれは説明不足なところがあるので補足説明します。
説明ありがとうございました。
だいぶ飲み込めました。なるほど、たしかに先物予約ですね。
先物予約といった表現がすごく理解できました。それ以外に表現しにくい。
>ちなみに、NSUndoManagerの仕様は
>http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ObjC_classic/Classes/NSUndoManager.html
斜め読みですがX-Window systemでWindowをcreateしてもmanageするまで
windowが現れないとか、そういうのに似てる感覚かなぁ。
#自分の知ってる範囲に落とさないと理解ができない おバカさんなのです。
> （というかApple社の資料はわかりにくいのが多いんだよなー（笑））
という噂はよく聞きます(^^)
> このときaFutureObjectというのが奇妙なオブジェクトで、こいつに対して
> アンドゥー操作のメッセージを送っているのですが、実はこんなことをしても
> 「setFont:フォント情報 color:色情報」をaFutureObjectは実行することはない。
> 実行されるのは未来の時点でユーザーがアンドゥーメニューを選んだときのみ。
> 要するに現在のメソッド実行ではなく、未来のメソッド実行を指示してます。
> これが“先物予約”と言ったゆえんです。
どんな機能でもそうですが、
具体的にどういう場面でどの程度の威力を発揮するのかは、
実際に使ってみて仕様をあれこれ検討して、
色々経験しないとわかってこないところでしょうが、
印象を言うとすごく柔軟な仕組みができそうで、
特に大きなsystem全体を一度に管理するような場面で威力を発揮しそうですが
逆になんか危なっかしい感じがします。
避けるとは思うのですが他の予約とぶつかったりとか。
> 前橋さん流の関数呼び出しの定義では、あくまで同期的、つまり
> メッセージの発行がただちに関数の呼び出しと戻りを実行させるはずだから、
> こういう“先物予約”は前橋さん流の関数呼び出しとは違うと
> 私は解釈したので例示したのですが。
私は前橋さん流の関数呼び出しが厳密にどういうものかはわかりませんが、
message送信≒関数って説明はわかりやすいなって思ってます。
もちろん、わかりやすい＝正しい ではないし、わかりやすい＝良い でもないのも
承知しておりますが。
先物予約もその関数自身を呼ぶんじゃなくて予約systemに登録する関数を読んでる
様に見ようと思えば見えなくもないですし。
わかりやすい故に物議をかもしているって言うのもあるのかもしれませんね。
厳密さに欠けるとか、全てを網羅していないとか。
わかりやすくて、厳密さに欠ける文章のせいで
理解が浅いとか狭いものの見方しかできない偏った人が
できる危険性があるのかもしれませんが、
そんな人はわかりやすい文章を読まなくたって狭い世界しか持ってないし。
これをきっかけに理解を深める最初のstepにできる人もいるかもしれません。
まぁ、その分 ここでたくさん補足されてるし。
私としては、こうやって盛り上がって知らない世界を見せてもらえるのが
楽しくてしょうがないので、もっと(ぱ)さんには「煽って」欲しかったりして。
#一番たちが悪い?(^^)
##もちろん技術的な話で盛り上がって欲しいって意味です。
>ところでいきなりオセロ盤の話に戻りますけれど、私が書いたオセロの実装
>http://member.nifty.ne.jp/maebashi/javaworld/index.html
>では、複数のBoardインスタンスを作っています。今日思い出したんですが。
>コンピュータの思考ルーチンで、先読みのためどんどん盤を生成するからです。
>だから、staticに根元を押さえたBoardを1個作ってもいいけど、
>グローバル変数じゃ困りますね。
オセロに関しては、アプリケーションの仕様次第ですね。
そういう仕様ならば納得です。
>「ポインタという概念がないので不可」はさすがに気になりますが… (^^;
>「関数ポインタ」ならそうだと思うんですが。
これは、C++との違いを明確にしたいということで。
Javaでは、メソッドというかメソッドの名前と、
メソッドの実装との区別がうまくできないんですよね。
（ぱ）さんが考えるメッセージと関数呼び出しの定義はなんとなくわかりましたけど、
その場合、メソッドというかメソッドの名前、とメソッドの実装、は
なんて呼びますかね？
わたしは、メソッドというかメソッドの名前、をメッセージと捉えるんですけど。
>いや、だから、動的束縛については、最初に知らなければならないことでは
>ないだろう、ということです。
ここが面白いところなんですよ！
これを意識するとしないとで、けっこう違いがでてきます。
dentomさんがいっていたundo managerもその一つですし。
いい機会なので、これもまとめてみますね。
ちょっとお待ちを。
>Cでこれをやろうとすると、関数ポインタを使うところまではいいんですが、
>引数を動的に積むことができないので困りますねえ。
普通に可変長引数使うんじゃないですか？
しょせんランタイムはCで書いてあるので、
Cでできないことはないはずです。
書き込みが多くて、お返事お疲れさまです。