K.Maebashi's BBS

>管理人様 > >C言語ポインタ完全制覇を熟読しています。単語の出現頻度を表示するプログラムについて、osはwindows7,visualStudio2015でビルドしようとしたところ以下のエラーが出てしまい、解決方法がわかりません。つきましては、解決の仕方をお教え頂きたく思います。よろしくお願いいたします。未解決の外部参照となってしまいます。 > >LNK1120 1 件の未解決の外部参照 word_count2 > >\Documents\Visual Studio 2015\Projects\CPlus\word_count2\Debug\word_count2.exe 1 > >LNK2019 未解決の外部シンボル "int __cdecl get_word(char *,int,struct _iobuf *)" (?get_word@@YAHPADHPAU_iobuf@@@Z) が関数 _main で参照されました。 > >Documents\Visual Studio 2015\Projects\CPlus\word_count2\word_count2\main.obj 1 > 解決しました。つまらんこと聴いてごめんなさい。削除してもらって構いません。

管理人様 C言語ポインタ完全制覇を熟読しています。単語の出現頻度を表示するプログラムについて、osはwindows7,visualStudio2015でビルドしようとしたところ以下のエラーが出てしまい、解決方法がわかりません。つきましては、解決の仕方をお教え頂きたく思います。よろしくお願いいたします。未解決の外部参照となってしまいます。 LNK1120 1 件の未解決の外部参照 word_count2 \Documents\Visual Studio 2015\Projects\CPlus\word_count2\Debug\word_count2.exe 1 LNK2019 未解決の外部シンボル "int __cdecl get_word(char *,int,struct _iobuf *)" (?get_word@@YAHPADHPAU_iobuf@@@Z) が関数 _main で参照されました。 Documents\Visual Studio 2015\Projects\CPlus\word_count2\word_count2\main.obj 1

早々にありがとうございます。すっきり理解できました。 10年（ドッグイヤーなら70年）以上前の本への疑問に、「そこまで面倒見られないよ」と言わず答えて下さり、感謝です。 久野禎子・靖さんの著書など、良い本もあるのですが、これでさえ索引に「参照」がないことに、首を傾げています。 そういうわけで『Java謎+落とし穴』は、メモリモデルで考えるためには、現在も唯一無二の拠り所となっています。

>暑中お見舞い申し上げます。 こんにちは。 >『Java謎+落とし穴』で、二つ質問があります。 >見方によっては、各オブジェクトが、間接的にではありますが、それぞれ実行コードへのポインタを持つように思えるのですが、いかがでしょう。 「間接的に」実行コードへのポインタを持つのはその通りですね。 ここは、メソッドが10個あった時、各オブジェクトが10のポインタを持つ必要はないですし、 オブジェクトごとに実行コードへのポインタが書き換わることはない、という意味で 書きました。 (プロトタイプベースのオブジェクト指向だと、実際オブジェクトごとに持っていたり しますし) >・177ページ「draw()メソッドを呼び出す部分はPolylineやCircleにまったく依存しません（その構造体を宣言しているヘッダファイルを#includeする必要がない）」について。 >このdraw()メソッドは、183ページのdrawShape(shapes[i])メソッドと同じでしょうか。ここではmain.cに、各ヘッダファイルをincludeしているように見えます。 ここはわかりにくかったですね。 createPolyline()等は各図形の.hで宣言されているわけで、 各図形をnewするところでは各ヘッダファイルが必要です。 ただ、描画するところ(「draw()メソッドを呼び出す部分」)は、 Polyline.hやCircle.hにまったく依存しません。 (これはJavaにおいても同じことで、newするところは各クラスに依存します)。 この例では、main.cでnewと描画を両方やってしまっているので、 おっしゃるとおり、「main.cでincludeしているではないか」と疑問を持たれるのは わかります。 main.cの描画部分(17～20行目)を、draw.cとか、別ソースに分けておくべきだったかも しれません。 10年以上前の本ですが、ご指摘感謝いたします。

暑中お見舞い申し上げます。 『Java謎+落とし穴』で、二つ質問があります。 ・46ページ「メソッドの実行コードへのポインタは、オブジェクトごとではなくクラスごとに持てばよい」について。 他方、175ページでは、「各オブジェクトにクラスディスクリプタへのポインタを持たせる」こととされています。 見方によっては、各オブジェクトが、間接的にではありますが、それぞれ実行コードへのポインタを持つように思えるのですが、いかがでしょう。 「①オブジェクトの持つポインタ→②クラスディスクリプタの持つポインタ→③メソッドテーブルの持つポインタ」となっていて、確かに②と③（リフレクションを考えない限り、実質区別なし）は、オブジェクトごとではなく、クラスごとなのかもしれませんが… ・177ページ「draw()メソッドを呼び出す部分はPolylineやCircleにまったく依存しません（その構造体を宣言しているヘッダファイルを#includeする必要がない）」について。 このdraw()メソッドは、183ページのdrawShape(shapes[i])メソッドと同じでしょうか。ここではmain.cに、各ヘッダファイルをincludeしているように見えます。 （これは、たぶん私の誤解、誤読だと思いますが） ご教示をお願いできましたら幸いです。

>本題に入りますが、投稿内容を<PRE>タグで囲むということ(仕様を考えるのページ)ですが、それでは ><br /> >タグが使用できず改行ができなくなる、ということになります。 まず、この掲示板は、用途的にプログラムソースを貼ることが多いので、 基本等幅フォントで表示する必要がある、というのが<PRE>で囲むようにした 理由です。ただし、等幅フォントにするだけなら<TT>で囲めばよいので、 現状ではそうしています。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&thread=25 <PRE>で囲むと、投稿者が改行を入れなかった場合、画面が際限なく 右に伸びて崩れてしまうので改善したわけです。 というわけで、<PRE>タグ云々の話はすでに現状の実装とはずれているわけですが、 >そこで思ったのですが、そもそも<PRE>タグを使用せずに<や>の記号を無効にすればいいのでは、ということです。 <PRE>タグの中であっても、<や>の記号は普通に特殊文字としての 意味を持ちます。たとえば以下のページに載せているサンプルソースでは、 ソース全体を<PRE>で囲んでいますが、行番号は<FONT>タグで青字にしていますし、 ソース内で<やら>やら"やらを使うときには&lt;とか&gt;とか&quot;とかに しています。 http://kmaebashi.com/programmer/bbs_dev/newbbs.html >そして思ったのが、phpのhtmlspecialchars()関数です。HTMLにとって特別な意味の<>をすべて単なる文字に変換してくれるという非常に便利な関数です。詳しいことは検索などお願いします。 よって、この手のエスケープは、どちらにせよ必要であり、 htmlspecialchars()もすでに随所で使っています。 例) http://kmaebashi.com/programmer/bbs_dev/list.html >要するに、 >$test = $_GET["test"]; >を、 >$test = htmlspecialchars($_GET["test"]); >のようにしてしまおう、という考えです。こうすれば、<PRE>を使わずに済むため、改行が実現できると思います。 ところで、この例だと、入力の時点でhtmlspecialchars()をかけていますが、 これはそもそも考え方が間違っている、ということをこちらで書いています。 http://kmaebashi.com/zakki/zakki0042.html htmlspecialchars()をかけるのは入力時ではなく出力時にすべきです。 で、上記の記事でも言い訳を書いていますが、そして「PHPとMySQLで掲示板を作る」 内にも注釈を足していますが、 http://kmaebashi.com/programmer/bbs_dev/index.html 現状の「PHPとMySQLで掲示板を作る」のプログラムは(実際にここで動いている 掲示板もそうなのですが)、PHP4の時代のデフォルトであるmagic quoteを使って いるので、今となってはよくないプログラムなんですよねえ。 本記事、注釈を付けつつ公開を続けてきましたが、初心者を惑わせるのも よろしくないので、そろそろ消すべきかもしれません。

突然失礼します。 ホームページ拝見いたしました。phpで掲示板を作るという発想はありませんでした。 本題に入りますが、投稿内容を<PRE>タグで囲むということ(仕様を考えるのページ)ですが、それでは <br /> タグが使用できず改行ができなくなる、ということになります。 そこで思ったのですが、そもそも<PRE>タグを使用せずに<や>の記号を無効にすればいいのでは、ということです。 そして思ったのが、phpのhtmlspecialchars()関数です。HTMLにとって特別な意味の<>をすべて単なる文字に変換してくれるという非常に便利な関数です。詳しいことは検索などお願いします。 要するに、 $test = $_GET["test"]; を、 $test = htmlspecialchars($_GET["test"]); のようにしてしまおう、という考えです。こうすれば、<PRE>を使わずに済むため、改行が実現できると思います。 -追伸- ほとんどのユーザーは、改行を投稿の中でしたいとき<BR>ではなく単にEnterキーを使って改行をします。これを掲示板上で再現するためには<BR>を使わなければいけないので、そこが私が掲示板作りをしたときの悩みどころでした。 そこで、便利なPHPの関数を見つけましたので紹介します。 nl2br() 改行記号の前に<br />を挿入してくれるというありがたいものです。 $test = nl2br( htmlspecialchars( $_GET["test"] ) ); 一行にするとこうなりますが、わかりやすく書くと $test = $_GET["test"]; //取得 $test = htmlspecialchars($test); //<>の無効化 $test = nl2br($test); //<br />挿入 長文失礼しました。 ※先日誤ってメールで送信してしまいましたが、やはり掲示板に書き込むべきだと、掲示板の方に再投稿しました。

>Javaだとこの場合ははオーバライドにはならないで、オーバーロード、 >引数型が違う同名の別メソッドが増えただけと見なすことでガードするという実装なんですね。 こう言っては何なのですが、たぶんこれはJavaを「買いかぶりすぎ」だと思うのです。 引数については、反変はOK、共変はNG、 戻り値については、共変はNG、反変はOK なのですが、 JDK1.4までのJavaでは、 引数については、型が違えばオーバーロード、 戻り値については、型が違えばコンパイルエラー でした。戻り値については共変は許されるべきなのに、古いJavaではコンパイルエラーに してしまっていたのです。 Javaでは、JDK1.5(Tiger)において、「共変戻り値」が許されるようになりました。 後になってこれを許すようになったということは、 当初は、共変とか反変とかそんなことはJavaの作者はあんまりまじめに考えていなくて、 後になって、共変戻り値はOKにすることができたけれど、反変引数は、既にそれを オーバーロードという機能で使ってしまっていたためにOKにできなかったのではないか、 と思います。 メソッドオーバーロードがすごく便利だから反変引数を捨ててでもそちらを取った、 というのは言語設計者の選択肢として理解できますが(私はオーバーロードが便利だと 思わないのでその選択肢は取りませんが)、 本来使えるべき共変戻り値を当初エラーにしてしまっていた(しかも1.5でそれを 撤回した)というのは、あまりこう、ちゃんと考えた結果には見えないんですよねえ。

本質問に関してもご回答ありがとうございます。 8-4-9章に記載あるAとBがクラスの場合の条件の意図をつかめず、 少し混乱しておりましたが、 実行時にチェックする価値があるという視点で読み直すと理解できました。

ご丁寧にご回答ありがとうございました。 理解できました。 確かに、引数時はダウンキャストになりますね。 Javaだとこの場合ははオーバライドにはならないで、オーバーロード、 引数型が違う同名の別メソッドが増えただけと見なすことでガードするという実装なんですね。 前橋さんの書籍で共変、反変という言葉を知ったのですが、 非常に一般的な概念のようでした。 直接Diksamとはご関係のない質問になってしまい大変恐縮です。

>"プログラミング言語を作る"の8-4-9章の >A instance of B >の記載に関してです。 > >A、Bがクラスの場合、 >AとBが同じクラスか、AがBのスーパークラスの場合のみ、 >真になる可能性がある、 >とあります。 こちらは説明が不適切な気がしてきました…… たとえばShapeクラスのオブジェクトshapeがあったとき、 shape instanceof Circle という式は、「真になる可能性がある」と言えます。 instanceofは、こうしてクラスをチェックするために使うものでしょう。 全然違う、circle instanceof Windowなら、そもそもコンパイルエラーです。 ここで「真になる可能性がある」と書いているのはそういう意味です。 逆に circle instanceof Shape は、常に真です。常に真ならそれもやっぱり真になるのではないか、 というところですが、その下の説明にあるように、そもそもDiksamは こういうコードは無駄なのでコンパイルエラーにしています。 そういう意味で、実行時にチェックする価値がある、ということで 「真になる可能性がある」と書いたのかもしれませんが、それにしては 「AとBが同じクラスか」部分が余計です。クラスが同じならやっぱり 無駄だからです。 今は時間が時間なので、後日(週末をめどに)正誤表に載せるなり対応を考えます。 ご指摘ありがとうございました。

はじめまして。最近この掲示板もすっかり閑散としてしまっていて、 投稿に気付くのが遅れてしまいました。すみません。 ご質問いただきありがとうございます。 引用の順番を変更しますが、結論から言えば、 >戻りの値の型が共変、引数の型が共変、 >ともにダウンキャストとなる、という認識ですが、 >なぜ、問題の有無の判断が変わってくるのでしょうか。 引数の型が共変なのはダウンキャストですが、 戻り値の型が共変なのはアップキャストだからです。 >”プログラミング言語を作る”内の8-3-5章にて >下の解説を読みました。 p.289のコードですね。 >class ShapeArray{ > Shape get(int index); > void set(int index, Shape shape); >}; > >class CircleArray extends ShapeArray{ > Circle get(int index); ・・・① > void set(int index, Circle circle); ・・・② >}; まず、このコードは、 p.249の補足で、JavaのArrayStoreExceptionの説明をしていますが、 JavaがArrayStoreExceptionを発生させるという実行時チェックを しなければならなくなった、ということについて、共変の考え方からも 説明できる、ということを示すためのコードです。 ここまではよいでしょうか。 p.249の補足のサンプルコードで、 1: Line[] lines = new Line[10]; 2: Shape[] shapes = lines; 3: shapes[3] = new Circle(); というコードがあったとき、Javaでは3行目でArrayStoreExceptionが 発生します。shapesはあくまでLineの配列であり、Circleの配列では ないからです。 これはJavaにおける配列の話ですが、Javaの配列をShapeArrayとか CircleArrayといったクラスで表現すると、p.289のコードのようになります。 ここで、CircleArrayのインスタンスcircleArrayがあったとして、 Shape shape = circleArray.get(i); というコードは、アップキャストなので合法ですが、 circleArray.set(i, shape); というコードは、ダウンキャストになります。CircleArray.set()の第2引数の 型はCircleなので、もしShapeを渡したければダウンキャストが必要になります。 Javaでは、このダウンキャストに相当する実行時例外が、ArrayStoreExceptionに なっている、と言えるでしょう。 この例ではCircleArrayがShapeArrayを継承しているので、もし引数の共変を 許せば、 ShapeArray shapes = circleArray; shapes.set(i, shape); と書けてしまいます。このshapes.set(i, shape);が、 まさにp.249のコードの shapes[i] = new Circle(); に相当するわけです。 これで回答になっているでしょうか?

立て続けに質問して申し訳ございません。 "プログラミング言語を作る"の8-4-9章の A instance of B の記載に関してです。 A、Bがクラスの場合、 AとBが同じクラスか、AがBのスーパークラスの場合のみ、 真になる可能性がある、 とあります。 A instance of B のAというのはオブジェクトという理解で良いでしょうか。 AがBのスーパークラスの場合に真という点に疑問を持ちました。 Aが右辺のBのクラスのサブクラスのオブジェクトであれば 真だという理解ですが、 AがBのスーパークラスの場合に真というのはなぜでしょうか？

”プログラミング言語を作る”内の8-3-5章にて 下の解説を読みました。 class ShapeArray{ Shape get(int index); void set(int index, Shape shape); }; class CircleArray extends ShapeArray{ Circle get(int index); ・・・① void set(int index, Circle circle); ・・・② }; ①は戻りの値の型が共変なので問題無し。 ②は引数の方が共変であるため実行時チェックが必要。 アップキャストは常に可能ですが、 ダウンキャスト時は実行時チェックが必要だと理解しています。 戻りの値の型が共変、引数の型が共変、 ともにダウンキャストとなる、という認識ですが、 なぜ、問題の有無の判断が変わってくるのでしょうか。 一般的な言語のオーバーライドの動作に関することで 本掲示板への質問が適切かどうか分かりませんが、 もしよろしければ細くいただけると助かります。

ご返信ありがとうございました。 著者の方に質問できる場所があるって素晴らしいです。 アルゴリズムへの興味を深めることができました。 （個人的にはこの対話で十分満足です） 掲示板やWebサーバーの作り方も書籍化していただければと思います。

こんにちは。 >sorted_count < score_count-1 > >の間だけ（score_count-2の要素まで）ループを回せば、最後の要素score_count-1は >整列された状態になっているのではないでしょうか。 最後の2要素残ったところでその2要素で交換するわけですから、 確かにループ1回無駄ではありますね。 「全部ソートされた」ことを示すのに while (sorted_count < score_count) { という条件式はそれはそれでわかりやすいとは思うのですが、 境界値がらみの説明を延々としているところですので、なんらかの 説明はいるように思います。 今日はちょっと無理ですが、次の週末にはWebにてフォローします。 ご指摘ありがとうございました。

こんにちは。 『Ｃ言語体当たり学習　徹底入門』103ページについての質問です。 終了条件は、「すべてがソートされたとき」 すなわちsorted_countとscore_countが等しくなったとき sorted_count < score_countの間だけ、ループを回せばよい とありますが、 sorted_count < score_count-1 の間だけ（score_count-2の要素まで）ループを回せば、最後の要素score_count-1は整列された状態になっているのではないでしょうか。 単純選択ソートと単純交換ソートでは、ソート済範囲は絶対に動かない。 単純挿入ソートでは、ソート済範囲も動く可能性がある。 という理解です。 よろしくお願い致します。

><補足> supplement を目次へ追加願います。 大変いまさらではありますが、「C言語 ポインタ完全制覇」の補足目次を作成しました。 http://kmaebashi.com/seiha/hosoku_index.html (他の本については、まあ、おいおいと) 元ネタは元原稿のLaTeXファイルから抽出したので、抜けはないはず…… と思ったのですが、 結構最後の最後まで補足の追加とかしていたようで、元原稿になくて本にはある補足が いくつか。補足を書き足してるヒマにちゃんと校正やっとけという話なのですが…… 編集さんご迷惑をおかけしました。

ご意見ありがとうございます。 >p.149 3-2 Cの型モデル について >この章は、大変重要な事が説明されていると思いますが、それが読者にきちんと >伝わっていない可能性があると思います。 読み返してみました。ここはかなり重要な章だと思いますので、 ここが読者に伝わっていないとなると問題です。 ご指摘の件、改訂版の機会があれば検討させていただきます。 # このレベルの修正だと、第16刷とかで手直しできるレベルを # 超えていると思いますので。 ><補足> supplement を目次へ追加願います。 これは、正直、私もちょっと心に引っかかっていました。 (と言いつつ、その後の本でも直っていないわけですが……) いまさらではありますが、こちらについてはWebで補足目次を作るくらいの ことはできそうです。すぐにやるとは言えませんが、検討します。

今更と思われるかもしれませんが、技術評論社「 C言語 ポインタ完全制覇」について、 気がついた事をお知らせ致します。 参照しているのは、2013年10月10日 初版第15刷です。 p.149 3-2 Cの型モデル について この章は、大変重要な事が説明されていると思いますが、それが読者にきちんと 伝わっていない可能性があると思います。この本を順番に読んで行くと、いきなり Fig.3-1 の表が出て来たという印象を受けました。とまどわれた方も多いのでは ないかと思います。私も何を説明しているのかが理解出来ませんでした。また、 その後の派生型の話も全く記憶に残っていませんでした。最近、読み返して、やっ とこの表や、この章全体が 「Cの型」がどの様に決められているかについての説明 である事がわかりました。改めて章のタイトルを見ると、「Cの型モデル」とあり、 わかった後で読み返すと、Fig.3-1 には、『「型」を図で表現すると…』とあり、 確かに説明がされているのがわかりました。 「Cの型モデル」というこの章のタイトルは、この章の内容を端的に まとめられていて、極めて妥当なタイトルであるとは思います。 後日リファレンスマニュアルとしてこの本を利用する場合には、目次 ですぐに見つかりますので良いと思います。 p.149 の上部には、挿絵があり、その中に「3-2 Cの型モデル」とタイトルが入っ ていはいますが、このタイトル部分が挿絵の中で、色も異なり、絵の内容も本の 内容とは関連も薄く、しかもすべての章節の絵が同じなので、このタイトルに気 がつかずに読み進める読者も多いのではないかと思います。また、このタイトル を読んだとしても、はじめて読む読者が内容を知らずにこのタイトルだけを見て、 すぐに内容が思い浮ぶタイトルではないと思います。 その様な、このタイトルの内容が頭に入っていない状態でこの章を読み始めると、 その後の「3-2-1 基本型と派生型」を見ますが、この用語はこの章の中で解説が されているので、何のことかもわかりません。その状態で、本文を読んでも、 これが、Cの型の説明をしているという事が理解出来ないと思います。 せめて、直前の章の終りで、つぎの章予告等があれば話しは違いますが、直前の 章は、型の話ではありますが、間に約2ページの「補足」が入っているので、リフ レッシュされて前の内容は記憶に残っていないかもしれません。やはりこの章に ついては、最初に何の説明を行うかを記載するのが良いのではないかと思います。 <補足> supplement を目次へ追加願います。 補足には、重要な内容が多く記載されています。そして、他の人への説明に利用 させて頂きたい事や、後から読み返したい事が多いのも、補足の部分に書かれて いる内容についてです。ところが、この補足には、目次がなくアクセスが出来ま せん。更に、索引にも出て来ない事がありました。例えば、p.168 「式」に対す るsizeof は、索引で sizeof を見ても、p. 158 が出て来るだけでした。しかも この補足は違う章に入っていましたので、全ページを探す必要がありました。 （sizeof がたまたま漏れていたのかもしれませんが）是非、補足の目次の追加を お願いします。

>例として掲載されているServer01,javaのサンプルコードですが，そのままではコンパイルが通りませんでした． はじめまして。 今手元にjavacがないので貼ったコードを再コンパイル等はしていませんが、 ぱっと見おかしいようには見えません。 コンパイルが通らないとのことですが、 ・コンパイルが通らない際のエラーメッセージ ・ご使用のjavacのバージョン といった情報を教えてもらえないでしょうか。

お世話になっております． 今回，クライアントサーバを１から作ってみようと思い，貴サイトを活用させていただきました． 例として掲載されているServer01,javaのサンプルコードですが，そのままではコンパイルが通りませんでした． ソースコードをここに記載します． import java.io.*; import java.net.*; public class Server01 { public static void main(String[] argv) throws Exception { try (ServerSocket server = new ServerSocket(8001); FileOutputStream fos = new FileOutputStream("server_recv.txt"); FileInputStream fis = new FileInputStream("server_send.txt")) { System.out.println("クライアントからの接続を待ちます。"); Socket socket = server.accept(); System.out.println("クライアント接続。"); int ch; // クライアントから受け取った内容をserver_recv.txtに出力 InputStream input = socket.getInputStream(); // クライアントは、終了のマークとして0を送付してくる while ((ch = input.read()) != 0) { fos.write(ch); } // server_send.txtの内容をクライアントに送付 OutputStream output = socket.getOutputStream(); while ((ch = fis.read()) != -1) { output.write(ch); } socket.close(); } catch (Exception ex) { ex.printStackTrace(); } } }

>たぶんですけど、直すのに影響があんまり出ないやり方があります。crowbarスタックを >一つの配列ではなく、複数の配列をリンクするによりスタックの拡張ができます。 >スタック拡張する場合には新たな配列をmalloc()して、それをもとにあったスタックと >リンクして、それでrealloc()を回避できますますね。これが「chunked stack」とも >言います。 全体を確認していませんが、ざっと見てみると、現状のcrowbarの実装だと スタック操作がpush_value()とかpeek_stack()にカプセル化されているので、push_value()のところで新たにmalloc()してリンクリスト等で管理し、 peek_stack()にて、もし配列の下端より下の領域を参照されたらひとつ前の 領域から算出して返す、ということはできそうですね…… 実のところ同じ現象はDiksamにもあるはずで、こちらはVMの中で直接参照して います。ただし、Diksamは関数呼び出し時にスタックの拡張があるかどうかを 判定していますし、ひとつの関数の実行中だけ連続したスタック領域が見えれば 十分でしょうから、なんとかなるように思います。 (すみません、ちょっとすぐには直せませんが) ご意見ありがとうございました。

>どたばたしておりまして対応が遅れました。すみません。 いえ、大丈夫です。返事を頂いてありがとうございます。 >>realloc()が対象データを移動しかねないので、移動した場合、もしスタックのなかでネイティブ関数に渡す引数があれば、それを指すポインタ（arg_p）が無効化される恐れがありますね。 > >本当ですね……初歩的なミスでした。ご指摘ありがとうございます。 >直すなら、ポインタでなく添字を渡して関数経由でアクセスするようにするのかと思いますが、ネイティブ関数全体に影響が出ます。少し考えさせてください。 >ご指摘ありがとうございました。 たぶんですけど、直すのに影響があんまり出ないやり方があります。crowbarスタックを一つの配列ではなく、複数の配列をリンクするによりスタックの拡張ができます。スタック拡張する場合には新たな配列をmalloc()して、それをもとにあったスタックとリンクして、それでrealloc()を回避できますますね。これが「chunked stack」とも言います。 >>ついでに、CRB_create_interpreter()で、interpreter->stack.stack_alloc_sizeの初期値が0になってますが、それがSTACK_ALLOC_SIZEになったほうがいいではないでしょうか。 > >NULLを第一引数とするreallocはmallocと同じなので、どちらでもよいのではないでしょうか。 はい、どちらでも良いですね。 - Kris

どたばたしておりまして対応が遅れました。すみません。 >realloc()が対象データを移動しかねないので、移動した場合、もしスタックのなかでネイティブ関数に渡す引数があれば、それを指すポインタ（arg_p）が無効化される恐れがありますね。 本当ですね……初歩的なミスでした。ご指摘ありがとうございます。 直すなら、ポインタでなく添字を渡して関数経由でアクセスするようにするのかと思いますが、ネイティブ関数全体に影響が出ます。少し考えさせてください。 ご指摘ありがとうございました。 >ついでに、CRB_create_interpreter()で、interpreter->stack.stack_alloc_sizeの初期値が0になってますが、それがSTACK_ALLOC_SIZEになったほうがいいではないでしょうか。 NULLを第一引数とするreallocはmallocと同じなので、どちらでもよいのではないでしょうか。

前橋様、 もう一つ、crowbarスタックとネーティブ仮引数について聞きたいことがあります。 crowbar_book_0_4では、crowbarスタックはrealloc()を使って拡張します。そしてネイティブ関数に渡す引数の配列がはcrowbarスタックに積んでいます。realloc()が対象データを移動しかねないので、移動した場合、もしスタックのなかでネイティブ関数に渡す引数があれば、それを指すポインタ（arg_p）が無効化される恐れがありますね。 ついでに、CRB_create_interpreter()で、interpreter->stack.stack_alloc_sizeの初期値が0になってますが、それがSTACK_ALLOC_SIZEになったほうがいいではないでしょうか。stack_alloc_sizeの初期値が0なら、最初にpush_value()を呼び出すと、stack_pointer == stack_alloc_sizeので無駄にMEM_realloc()でcrowbarスタック拡張をします。 - Kris

はるほど、納得いたしました。 お忙しい中、丁寧なご返事、ありがとうございました。 - Kris >確認しました。確かに無駄なことをしているように見えます。 >そもそも関数名がrelease_global_stringsなのに、文字列に対して >何かしているように見えません。 > >どうしてこうなったのかと思い、調べたのですが、どうも >ver.0.1のこのコードが原因なのかと思います。 > >http://kmaebashi.com/programmer/devlang/crowbar_src_0_1_01/S/15.html#76 >static void >release_global_strings(CRB_Interpreter *interpreter) { > while (interpreter->variable) { > Variable *temp = interpreter->variable; > interpreter->variable = temp->next; > if (temp->value.type == CRB_STRING_VALUE) { > crb_release_string(temp->value.u.string_value); > } > } >} > >ver.0.1時点では、参照カウンタのGCしかなかったので、インタプリタを >破棄するときには文字列の領域はfreeする必要がありました。その処理が >上記のコードです。 > >ver.0.2でGCを組み込んだので、interpreter->variableをNULLにしておけば、 >文字列の領域もcrb_garbage_collect()の呼び出しで解放されます。 >ただ、ver.0.2を作ったとき、ヘッダファイルを直してコンパイルエラーを取って、 >という作業をしているときに、コンパイルエラーの原因のところだけ削って >関数そのものが不要であることに気付かなかったのではないかと思います。 >すみませんでした。再確認のうえ、正誤表に載せる等対応します。 > >細かいところまでソースを読み込んでいただき、作者冥利に尽きます。 >ありがとうございました。 >

>こんにちは、@rednaxelafxことKrisと申します。 中国からありがとうございます。 (中国語版がもう出版されているということを私も今知りました) >このたびはcrowbarについてちょっと聞きたいことがあります。 … >その中のcrowbar_book_0_4ですが、interface.cでのrelease_global_strings()が >こうなっています： >static void >release_global_strings(CRB_Interpreter *interpreter) { > while (interpreter->variable) { > Variable *temp = interpreter->variable; > interpreter->variable = temp->next; > } >} 確認しました。確かに無駄なことをしているように見えます。 そもそも関数名がrelease_global_stringsなのに、文字列に対して 何かしているように見えません。 どうしてこうなったのかと思い、調べたのですが、どうも ver.0.1のこのコードが原因なのかと思います。 http://kmaebashi.com/programmer/devlang/crowbar_src_0_1_01/S/15.html#76 static void release_global_strings(CRB_Interpreter *interpreter) { while (interpreter->variable) { Variable *temp = interpreter->variable; interpreter->variable = temp->next; if (temp->value.type == CRB_STRING_VALUE) { crb_release_string(temp->value.u.string_value); } } } ver.0.1時点では、参照カウンタのGCしかなかったので、インタプリタを 破棄するときには文字列の領域はfreeする必要がありました。その処理が 上記のコードです。 ver.0.2でGCを組み込んだので、interpreter->variableをNULLにしておけば、 文字列の領域もcrb_garbage_collect()の呼び出しで解放されます。 ただ、ver.0.2を作ったとき、ヘッダファイルを直してコンパイルエラーを取って、 という作業をしているときに、コンパイルエラーの原因のところだけ削って 関数そのものが不要であることに気付かなかったのではないかと思います。 すみませんでした。再確認のうえ、正誤表に載せる等対応します。 細かいところまでソースを読み込んでいただき、作者冥利に尽きます。 ありがとうございました。

こんにちは、@rednaxelafxことKrisと申します。 たぶん「はじめまして」ではないかと、Twitterで検索したところ、たしかにもっと前から挨拶をしました(笑) https://twitter.com/rednaxelafx/status/14597568550 Web連載も結構前から読みましたが、「プログラミング言語を作る」が本になって本当に嬉しかったです。 去年中国の編集さんにこの本を強く薦めました。いまはやっとその中国語翻訳版が買えるようになりまして、自分のブログでこの本を押したいと思います。 このたびはcrowbarについてちょっと聞きたいことがあります。 本のサンプルコードをこちらからダウンロードしました： http://kmaebashi.com/programmer/devlang/book/unix_utf8_20091228.tgz その中のcrowbar_book_0_4ですが、interface.cでのrelease_global_strings()がこうなっています： static void release_global_strings(CRB_Interpreter *interpreter) { while (interpreter->variable) { Variable *temp = interpreter->variable; interpreter->variable = temp->next; } } この関数がもともと何をしようとしてますか？このままだと、ループしなくても、直接に interpreter->variable = NULL でも同じではないですか？ もしかしたらこうしたかったとか： static void release_global_strings(CRB_Interpreter *interpreter) { while (interpreter->variable) { Variable *temp = interpreter->variable; Variable *temp_next = temp->next; temp->next = NULL; interpreter->variable = temp_next; } }

>>>DEBUG_WRITE(("hoge..%d\n", hoge)); >>を >>DEBUG_WRITE("hoge..%d\n", hoge); >>と書きたい場合は、 >>>>#define DEBUG_WRITE(arg) debug_write(arg) >>と書くことで同じになりますか？ > >なりません。引数をひとつしか取らないマクロにふたつの引数を渡しているので >エラーになります。 >というか、そもそもこれでうまくいくのであれば誰も苦労はしないわけで、 >わざわざ二重括弧をつけたりしようとは思いません。 > >ISO C99では新機能により可変長引数を持つマクロが定義できるようになりましたが。 >http://seclan.dll.jp/c99d/c99d02.htm > >処理系をお持ちであれば、実際に試してみて、プリプロセッサの出力を >見てみるのが一番わかりやすいと思いますが、手元に実行できる環境は >ないのでしょうか? > >まあ、私も子どもの頃は、パソコン買ってもらえなくてペーパープログラマー >だったので、だとすればその苦労はわかります。 > 理解できました ありがとうございます。