K.Maebashi's BBS

>こんにちは、@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 > >処理系をお持ちであれば、実際に試してみて、プリプロセッサの出力を >見てみるのが一番わかりやすいと思いますが、手元に実行できる環境は >ないのでしょうか? > >まあ、私も子どもの頃は、パソコン買ってもらえなくてペーパープログラマー >だったので、だとすればその苦労はわかります。 > 理解できました ありがとうございます。

>「u行目で定数DOCUMENT_ROOTを設定しています」の「u行目」は、 >7行目の事のはずなので、typo と思われます。 ご指摘ありがとうございます。修正しました。 誤解が起きようがないtypo場所の指摘方法がさすがといいますか、 いろんな人に読まれてますね (^^;

本当の基礎からのWebアプリケーション入門 ――Webサーバを作ってみよう―― Webサーバを作る ひとつのHTMLファイルを返す webserver.html の225行目 「u行目で定数DOCUMENT_ROOTを設定しています」の「u行目」は、 7行目の事のはずなので、typo と思われます。

>単純にカンマ演算子が評価されて debug_write(hoge); と同値になるだけでしょう。 うひ。その通りです。カンマ演算子をすっかり忘れていました。 ご指摘ありがとうございました。

一通り質疑応答はきれいに終わったようなので、要らぬ一言を >debug_write(("hoge..%d\n", hoge)); >これは構文エラーです。 単純にカンマ演算子が評価されて debug_write(hoge); と同値になるだけでしょう。 hoge が整数型なら引数の型不一致エラーになるものと思われます。 hoge が char* ならエラーなく通ってしまうはず。

ありがとうございます。 理解できました。

>>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 処理系をお持ちであれば、実際に試してみて、プリプロセッサの出力を 見てみるのが一番わかりやすいと思いますが、手元に実行できる環境は ないのでしょうか? まあ、私も子どもの頃は、パソコン買ってもらえなくてペーパープログラマー だったので、だとすればその苦労はわかります。

>DEBUG_WRITE(("hoge..%d\n", hoge)); を DEBUG_WRITE("hoge..%d\n", hoge); と書きたい場合は、 >>#define DEBUG_WRITE(arg) debug_write(arg) と書くことで同じになりますか？

>>>#define DEBUG_WRITE(arg) debug_write arg　 >の書き方は、 >#define DEBUG_WRITE(arg) debug_write(arg) >と書くのと同じことになりますか？　 なりません。 下の書き方で以下のように呼び出すと、 DEBUG_WRITE(("hoge..%d\n", hoge)); マクロが展開された時点でこうなります。 debug_write(("hoge..%d\n", hoge)); これは構文エラーです。 DEBUG_WRITEの括弧内、つまり DEBUG_WRITE(ココ) にあるものがargの場所に配置されるのですから、当然そうなります。

返信ありがとうございます。 追加でもう一点お願いします。 >>P108の上半分の >>#ifdef DEBUG >>#define DEBUG_WRITE(arg) debug_write arg　 >… の書き方は、 #define DEBUG_WRITE(arg) debug_write(arg) と書くのと同じことになりますか？　

>P108の上半分の >#ifdef DEBUG >#define DEBUG_WRITE(arg) debug_write arg　 … >でdebug_writeのうしろに空白があって、argがあるのがどういうことか理解できません。 このDEBUG_WRITEの使い方についてはその続きで説明しており、以下のように書いています。 DEBUG_WRITE(("hoge..%d\n", hoge)) これをプリプロセッサにかけたときにどうなるかは、やってみれば一番わかると思いますが、 この2重の括弧の内側が、括弧ごと展開されますので、こうなります。 debug_write ("hoge..%d\n", hoge) これで可変長引数を取るデバッグライト用関数debug_write()を 呼び出すことができるわけです。

P108　デバッグライト用の関数を作ってみよう に関して質問があります。 P108の上半分の #ifdef DEBUG #define DEBUG_WRITE(arg) debug_write arg　 #else ・・・・ でdebug_writeのうしろに空白があって、argがあるのがどういうことか理解できません。 説明いただけないでしょうか。 よろしくお願いします。

>アルゴリズムについてろくに知らないくせに軽視するという傾向がありました。 あう。すみません。 勉強はなんであっても重要ですよね。それこそフロチャートだって、記号の 意味くらいは知っていたほうがよいかと思いますし。 >それと、「インタプリタは翻訳しない」（インタプリタ自身が命令セットを持っている） >ことを他書がどう書いているか、一時期、気になってました。「翻訳する」などとなって >いても、表面上は誤りとも言い切れない表現の本が多いようです（そもそもあまり意識 >していないような）。その点、村瀬康治さんは、さすがに正確に書かれています。 とりあえず手元にある本では、 パソコンプログラミング入門以前 伊藤華子著 初版(1998年) 第10刷(2001年) | 中には、オブジェクトプログラムを生成しない「インタープリタ方式」で、 | ソースプログラムを一括変換しないで、一部分ずつを翻訳し直接実行する | スタイルもあります。 この本ではこの後、通訳に原稿をまるごと翻訳してもらう方法(コンパイル方式)と 比較して、同時通訳をインタプリタにたとえています。これはさすがに言い訳 できないと思います。 プログラムはなぜ動くのか 知っておきたいプログラミングの基礎知識 矢沢久雄著 1版7刷 (1刷ともに2001年) | Q.:コンパイラとインタプリタの違いは何ですか? | A.:コンパイラは、実行前にソースコードをネイティブ・コードに一括して | 翻訳します。インタプリタは、実行時にソースコードの内容を1行ずつ | ネイティブ・コードに逐次変換します。 「これが驚異のべすとせらあ?」とセンス・オブ・プログラミングに書いた本は 実はこれです。 改訂版が出ているので立ち読みしましたが、該当の記述はなくなっているようです。 どちらも増刷を繰り返している、かなり売れている本なんですよねえ。 >「Java謎+落とし穴」、第二版を期待しつつ。 残念ながらその予定はないのですが、この本は、amazonのレビューとかでも 書かれているとおり、今となっては古い本になってしまっていると自分でも思います。 でもなー、あの時点で、Genericsや列挙の不在はもちろん、引数と戻り値の 共変、反変まで書いたってのは、手前味噌ながらなかなかのものだと思うんですよ。 Web上で書評を見ても、2章のポインタ議論あたりまでしか言及されてないのが 多くてですね(愚痴)

前橋様 お忙しい中、丁寧にご回答いただき、ありがとうございました。 お答えを自分なりに咀嚼し、今後に活かしたいと思います。もちろん、フロチャートは書かない（こだわらない、忘れる）ようにします。 ちなみに、柴田芳樹さんという方も、「人月の神話」でフローチャートが否定されていることについて「当然のこと」と書かれていました（「ソフトウェア開発の名著を読む」P46）。 「センス・オブ・プログラミング」の感想をあと少し書きますと、これも、影響を受けやすい（読者たる）私自身の責任ですが、アルゴリズムについてろくに知らないくせに軽視するという傾向がありました。最近それを自覚するに至り、まずは人並みにマスターしてから、と思っています。 それと、「インタプリタは翻訳しない」（インタプリタ自身が命令セットを持っている）ことを他書がどう書いているか、一時期、気になってました。「翻訳する」などとなっていても、表面上は誤りとも言い切れない表現の本が多いようです（そもそもあまり意識していないような）。その点、村瀬康治さんは、さすがに正確に書かれています。 「Java謎+落とし穴」、第二版を期待しつつ。

こんにちは。本を購入いただきありがとうございます。 >一方で、大滝みや子さんの「かんたんアルゴリズム解法」では、副題に「流れ図」と >あるように、フローチャートを扱っています。この本は、基本情報技術者試験の >テキストであるわけですが、国家試験である（らしい）同試験で、初心者に >フローチャートを学ばせていることと、先の常識との関係を、どのように整理すれば >よいでしょうか。 国家試験だからといって必ずしも適切な問題を出しているとは限りませんし、 ひとまず「基本情報 フロチャート」で検索したらまず出たのが以下の過去問でしたが、 http://www.k4.dion.ne.jp/~type_f/FE_18S_AM/FE_18S_AM_42.html この問題は、何についての理解を試しているのでしょう…… フロチャートの書式? それとも、アルゴリズムの基本的な考え方? フロチャートの書式を問う問題には見えないですよね。記号の意味自体は、 それこそ初めて見る人でも、だいたい見当がつきそうです。 この問題はアルゴリズムの考え方を問う問題で、たまたまそこでフロチャートを 使っていると見るべきであるように思います。それが適切かどうかはさておき。 (「Pascal風擬似言語」でもよいと思うのですが、言語非依存にしておかないと 都合が悪い事情はあるかも) >「センス・オブ・プログラミング」でも、基本情報技術者試験の試験範囲と >重なる入門的話題（基数、加算器など）も多く取り上げられていますことから、 >フローチャートはそのレベル以前、とも考えられず、フローチャートには >どういう態度で接すべきか、分かっていません。基本中の基本としては、 >必要なのでしょうか？ 実のところフロチャートの記号なんて数種しかありませんし、記号の意味を 覚えておいて無駄になるということはないと思います。 ただ、入門者がおもちゃプログラムを作るときを含め、設計の役にはまったく 立たないと思います。理由は、「センス・オブ・プログラミング」にも書きましたが、 フロチャートは、いまどきの普通のプログラミング言語と比べても「機械語寄り」の 低レベルな記法であるからです。こんなものを書くくらいなら、対象の言語で 直接書くほうがよっぽどマシですし、その方が、コンパイラに怒られたり 動かしてバグを出したり等、勉強にもなります。 ただし、私もフロチャートを書くことはたまにはあって、それは、たとえば システムの運用担当者さん向けに、「エラーが発生したときにどうすべきか」といった 説明資料を作るような時です。これは、フロチャートにしたがって運用担当者さんが それこそCPUのように機械的に動けるように指示するものなので、より「低レベル」な 記法の方が好ましいわけです。 そのようなケース以外で、設計のためにフロチャートを書くことは、もちろん 実務ではありませんし、入門時にどうだったかといえば、私自身はBASIC時代に 入門しているわけでフロチャートも書きましたが、会社に入ったとき同期の連中は まるっきり初心者の人もいましたが、フロチャートなしで入門していました。 動坂亭さんが今までどんなプログラムを作ってこられたかわかりませんが、 何らかのテーマを決めてコードをガリガリ書いていけば100行くらいすぐですし、 100行のコードは、既にフロチャートで表現するのは難しいのではないでしょうか。 フロチャートを書くかどうか迷っている暇にどんどんコードを書いたほうが有益だと 思います。

はじめまして。 私はプログラミング初心者ですが、前橋様のご著書は、「プログラミング言語を作る」を含め、全て所有しています（読めてはいません）。つまりファンということになり、影響も受けていると思います。 さて、「センス・オブ・プログラミング」でフローチャートを書いてはいけない、とされています。他の著者の本でも、このことは常識とされているものも見かけますし、素人たる私としても、疑問の余地がない事実なのであろうと推測します。（ごくごく単純な、構造化プログラミングぐらいの世界で、実務の役に立たないという趣旨なのかなと思ってます） 一方で、大滝みや子さんの「かんたんアルゴリズム解法」では、副題に「流れ図」とあるように、フローチャートを扱っています。この本は、基本情報技術者試験のテキストであるわけですが、国家試験である（らしい）同試験で、初心者にフローチャートを学ばせていることと、先の常識との関係を、どのように整理すればよいでしょうか。 「センス・オブ・プログラミング」でも、基本情報技術者試験の試験範囲と重なる入門的話題（基数、加算器など）も多く取り上げられていますことから、フローチャートはそのレベル以前、とも考えられず、フローチャートにはどういう態度で接すべきか、分かっていません。基本中の基本としては、必要なのでしょうか？ ご教示いただけましたら幸いです。

おそらく3/22～3/25にかけて、本Webサイトkmaebashi.comが停止しておりました。 管理人である私が、忙しさにかまけてレンタルサーバの利用料金の振込みを失念していたのが原因です。3/23(土曜)に振り込み、月曜に復旧していただきました。 利用者の皆様にはご迷惑をおかけしまして申しわけありませんでした。 1年前… orz http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1812&range=1

管理人様、ご回答ありがとうございます。 ようやく実現できました！

774RR様 ご回答ありがとうございます． 納得です．そういえば，昔そういう話を授業で聞いたことを思い出しました． ありがとうございました． >>char *str >>switch(type) { >> case XXX_EXPRESSION: >> str = "文字列" >>} >> >>return str; >>これだと，リターンされる文字列は自動変数なので，関数を抜けたらメモリが開放されるため，バグになる可能性があるのではないでしょうか？ > >この例では、実は リターンされる文字列は自動変数 ではないのです。 >消滅するのは、自動変数 str というポインタ変数のためのメモリ領域 >return の前後で str に入っていた値 が複写される >ポインタ変数の値、すなわち str が指す先は "文字列" という [ストリングリテラル] である >ストリングリテラルはプログラム終了まで消滅しない >ので、この例は１００％合法です。 > >以下の例だと 文字列 str が真に自動変数であるためバグります。 >const char* buggy_sample_func() { >　char str[100]; >　strcpy(str, "文字列"); >　return str; >} >

>char *str >switch(type) { > case XXX_EXPRESSION: > str = "文字列" >} > >return str; >これだと，リターンされる文字列は自動変数なので，関数を抜けたらメモリが開放されるため，バグになる可能性があるのではないでしょうか？ この例では、実は リターンされる文字列は自動変数 ではないのです。 消滅するのは、自動変数 str というポインタ変数のためのメモリ領域 return の前後で str に入っていた値 が複写される ポインタ変数の値、すなわち str が指す先は "文字列" という [ストリングリテラル] である ストリングリテラルはプログラム終了まで消滅しない ので、この例は１００％合法です。 以下の例だと 文字列 str が真に自動変数であるためバグります。 const char* buggy_sample_func() { 　char str[100]; 　strcpy(str, "文字列"); 　return str; }

管理人様 ご回答ありがとうございます．下記了解いたしました． >ちょっとありえないミスです。申しわけございませんでした。 >該当の実装は、以下で正しいです。 > >>気になって探してみたところ，ver.4のソースコードに >> >>struct CRB_Object_tag { >> ObjectType type; >> unsigned int marked:1; >> union { >> CRB_Array array; >> CRB_String string; >> CRB_Assoc assoc; >> ScopeChain scope_chain; >> NativePointer native_pointer; >> } u; >> struct CRB_Object_tag *prev; >> struct CRB_Object_tag *next; >>}; > >ご報告いただきありがとうございました。週末あたりに正誤表に入れさせて >いただきます。 ありがとうございます．ミスを全部潰すのは大変ですよね．．． 私もまだver.2までしか進んでいませんが，大変勉強になっています．ありがとうございます． また，もう一点気がついたことがあるので報告させて頂きます． util.cに，crb_get_operator_string関数があるかと思います． 以下のようなコードになっているのですが， --------------------------------------------- char *str switch(type) { case XXX_EXPRESSION: str = "文字列" } return str; --------------------------------------------- これだと，リターンされる文字列は自動変数なので，関数を抜けたらメモリが開放されるため，バグになる可能性があるのではないでしょうか？ char *op_str = crb_get_operator_string(operator); こんな風に使っているので．．． ちなみに，実際にバグが起こっているわけではありません(エラー処理に使っているので，実際には実行されない)．

774RRさんが答えてくださっていますが(いつもありがとうございます) >というのも、掲載されているソースでは、どうしても左よりとなってしまう為、 >なんとかして見栄え良く、この掲示板のような形にしたいと考えています。 この掲示板のCSSは、ソースを見ればわかるように、以下にありますので よければ参考にしてください。 http://kmaebashi.com/bbs/bbs.css

>「プログラミング言語を作る」を購入し，勉強させていただいております． ありがとうございます。はじめまして。 >著書の4-4-5において，以下のようにネイティブポインタ型の改修を記載されて >おりますが，ご提供されているソースコードのcrowber_book_0_2では，実際の >実装はされていないように思われます． まさかと思ってcrowbar_book_0_2をダウンロードして確認しましたが、 確かに、このバージョンでは、ネイティブポインタ型が値型になっています。 以下のようになっているのは、おっしゃるとおり、ver.0.4からのようです。 >ネイティブポインタ -> CRB_Object->FILE型などの構造体 「プログラミング言語を作る」は、もともとWeb上の連載で、 いろいろ試行錯誤しながら作っておりました。 書籍化にあたり、後になって失敗したと思い改修した箇所を、 前のバージョンに取り込む作業をしており、この件も、ver.0.4から ver.0.2に移動させたつもりだったのですが…… ちょっとありえないミスです。申しわけございませんでした。 該当の実装は、以下で正しいです。 >気になって探してみたところ，ver.4のソースコードに > >struct CRB_Object_tag { > ObjectType type; > unsigned int marked:1; > union { > CRB_Array array; > CRB_String string; > CRB_Assoc assoc; > ScopeChain scope_chain; > NativePointer native_pointer; > } u; > struct CRB_Object_tag *prev; > struct CRB_Object_tag *next; >}; ご報告いただきありがとうございました。週末あたりに正誤表に入れさせて いただきます。

はじめまして． 「プログラミング言語を作る」を購入し，勉強させていただいております． 著書の4-4-5において，以下のようにネイティブポインタ型の改修を記載されておりますが，ご提供されているソースコードのcrowber_book_0_2では，実際の実装はされていないように思われます． ネイティブポインタ -> CRB_Object->FILE型などの構造体 気になって探してみたところ，ver.4のソースコードに struct CRB_Object_tag { ObjectType type; unsigned int marked:1; union { CRB_Array array; CRB_String string; CRB_Assoc assoc; ScopeChain scope_chain; NativePointer native_pointer; } u; struct CRB_Object_tag *prev; struct CRB_Object_tag *next; }; このような記述を見つけました．こちらが正しい定義でしょうか？ お手数おかけしますが，ご確認よろしくお願いいたします．

掲示板ソフトがどうこう、という話ではない、と思うが。 １．最終的に閲覧者の手元に届く HTML ファイルの中にて CSS を使う指定がなされていて ２．同じく閲覧者（の使っている UA）が CSS にアクセスできる ようになっていればいい。 インライン要素で CSS を指定しても良いし ここの掲示板みたいに、掲示板ソフトの出力が別ファイルの CSS にアクセスしてもいい HTML 自体の話であるとか Web server 上の htdocs に CSS ファイルを置くとか そういう問題だと思う。

管理人様、いつも大変参考にさせて頂いております。 現在、管理人様が掲載しているプログラムをベースに掲示板を作成しており、 おおよそ完成しておりますが、管理人様のこの掲示板のようにどうしてもスタイル シートを使用したいと考えています。 というのも、掲載されているソースでは、どうしても左よりとなってしまう為、 なんとかして見栄え良く、この掲示板のような形にしたいと考えています。 どのようにしたら良いのでしょうか？？？ 教えて下さい。

管理人様、ご回答ありがとうございます。 返事が遅くなり大変申し訳ありませんでした。 ご指摘頂いた内容で問題なくやりたい事が実現しました！ ありがとうございました。