K.Maebashi's BBS

ご自由に書き込んでください。雑談も可。
テスト書き込みの類はテスト用掲示板にどうぞ

[日付順表示] [日付順インデックス] [スレッド順インデックス]

新規投稿 | 開設者ホームページへ戻る | ヘルプ

[1521] Re:PHPとMySQLで掲示板を作る
投稿者:(ぱ)こと管理人
2010/03/26 02:28:55

>PHPとMySQLで掲示板を作るの掲示板のプログラムを圧縮して配布していただけませんか? >あと、パーミッションの設定も教えていただけませんか? そういう要望があり得るとは当初より思っていましたが、そのつもりはありません。 あのページではあくまで作り方の解説をしているだけであり、掲示板のプログラム そのものをリリースしようとは考えていないためです。 すぐにインストールできるようなパッケージとして配布すると、インストールできない 等の質問が来る可能性がありますし、そのサポートをする気もないからです。 プログラムの作り方に関する質問やクレームであれば受け付けます。そういう情報を 共有することは価値があると思えるからです。 あしからずご了承ください。 あとまあ正直なところ、あのプログラムはPHP4として書いたものですし(5でも 動いてますが)、記事中で言い訳してますがサニタイズ言うなポリシー的にも よろしくないものですので。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1519] Re:疑り深いあなたのためのオブジェクト指向再入門
投稿者:(ぱ)こと管理人
2010/03/16 02:08:48

>C言語出身の私としては「オブジェクト指向」で言うところのウリ(カプセル化や再利用性など)が、C言語でやってきたこととどこが違うのか!と反発することが理解できない原因だと思ってきましたが、このサイトでは「反発して当然」のように書かれており、かつ説明が非常に具体的でよく理解できました。 ありがとうございます。 >「オブジェクト指向も裏を返せばただの・・・」と思えただけで今後は前回と違った理解ができそうな気がしています。 >再チャレンジするきっかけを与えて頂いてありまとうございました。 孫悟空さんは再チャレンジ中ですので誤解はないと思うのですけれど、 一応補足しますと、私はオブジェクト指向について「役に立たない」とか 「くだらない」と思っているわけではありません。 # 仕事では、あまり使わないケースはあるかもしれないと思っていますが。 http://d.hatena.ne.jp/kmaebashi/20090427/p1 (継承の乱用とかしないで)ちゃんと使えば強力な概念だと思いますので 再チャレンジが成功することをお祈りしております。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1518] Re:lexicalanalyzer.c について
投稿者:(ぱ)こと管理人
2010/03/16 00:48:08

>「入力が char_buf のサイズ(1024)を超えていて fgets がナル文字を付けた場合」 >を想定しておりましたです。 「1024文字もあるんだから普通はオーバーしません!」 とか言い切ってしまうとそれはそれで問題ありかとは思うのですが。 実際、こういう意見↓もあるのですが、 http://www.kijineko.co.jp/tech/superstitions/gets-can-be-replaced-with-fgets-simply.html この程度の用途のプログラムでどこまで想定するかは難しいところだと思います。 私の場合、たとえばポインタ完全制覇のp.79でも 「自分で使う程度のプログラムだったらまず大丈夫でしょう」 とかいって逃げてしまっています。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1517] 疑り深いあなたのためのオブジェクト指向再入門
投稿者:悟空
2010/03/15 18:04:23

こんにちは。 かなり以前にオブジェクト指向に挫折したものです。 私の「オブジェクト指向」への反発は、このサイトに書かれている事、一つ一つに該当し全文を読み終えてしまいました。 目からうろこです!大変感謝しております!! C言語出身の私としては「オブジェクト指向」で言うところのウリ(カプセル化や再利用性など)が、C言語でやってきたこととどこが違うのか!と反発することが理解できない原因だと思ってきましたが、このサイトでは「反発して当然」のように書かれており、かつ説明が非常に具体的でよく理解できました。 「オブジェクト指向も裏を返せばただの・・・」と思えただけで今後は前回と違った理解ができそうな気がしています。 再チャレンジするきっかけを与えて頂いてありまとうございました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1516] Re:lexicalanalyzer.c について
投稿者:yuya
2010/03/15 05:27:03

さっそく正誤表で対応して頂き、ありがとうございます。 >改行なしの行を食わせるためにはファイルからリダイレクト等しなければならないので うぐぅ、私は単純に 「入力が char_buf のサイズ(1024)を超えていて fgets がナル文字を付けた場合」 を想定しておりましたです。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1515] Re:lexicalanalyzer.c について
投稿者:yuya
2010/03/14 22:22:06

ああそうか、レクサの問題というより、 テストドライバをそんなに厳密に書いていないというだけの話ですね。 ありがとうございました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1514] Re:lexicalanalyzer.c について
投稿者:(ぱ)こと管理人
2010/03/14 21:49:17

>となっています。'\0'に出会ったら BAD_TOKEN として処理するという意図だと思いますが、 >現状だと'\0'が現れた時点でwhileを抜けてしまうので、 >st_line_pos がインクリメントされないまま再び get_token() が呼ばれてしまい、 >実行時に無限ループに陥ります。 BAD_TOKENが返ってきているのにまたget_token()を呼ぶほうが変なんじゃ、と 思って本に掲載されているソースのテストドライバを確認したのですが、 END_OF_LINE_TOKENのチェックはしていてもBAD_TOKENのチェックをしていないので、 たとえば改行で終わらないファイルをリダイレクトで食わせたときに、 確かに無限ループになりますね。 電卓のパーサと組み合わせる限りではそんなにおかしなことにはならないような 気もします。 バグかというと微妙ではないかと思いますが、補足を入れておきます。 ># ただいま「プログラミング言語を作る」を骨の髄までしゃぶる勢いで読んでます。 ># 面白すぎて睡眠不足(笑)。 ありがとうございます。また何かあればご指摘ください。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1513] lexicalanalyzer.c について
投稿者:yuya
2010/03/13 09:10:00

「プログラミング言語を作る」p.59の、 lexicalanalyzer.c の23~24行からの構造を見ると、 token->kind = BAD_TOKEN; while(st_line[st_line_pos] != '\0'){ /* メインの処理 */ } となっています。'\0'に出会ったら BAD_TOKEN として処理するという意図だと思いますが、 現状だと'\0'が現れた時点でwhileを抜けてしまうので、 st_line_pos がインクリメントされないまま再び get_token() が呼ばれてしまい、 実行時に無限ループに陥ります。 一度ご確認ください。 # ただいま「プログラミング言語を作る」を骨の髄までしゃぶる勢いで読んでます。 # 面白すぎて睡眠不足(笑)。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1512] Re:「1回以上の繰り返し」の定義
投稿者:yuya
2010/03/10 14:48:02

ご回答ありがとうございます。 >-が降ってきた時点でそれまでの分をreduceしないと左結合にならないわけですが、 >現状、ここでshift/reduce conflictが起きており、shiftが優先されるため >結合規則が逆順になっています。 なるほどー、よく分かりました。もし右結合を明示したければ expression /* 「式」とは… */ : primary_expression /* 「一次式」、 */ | primary_expression ADD expression /* または、「一次式」 + 「式」 */ と書くべきなわけですね。 そもそも件名に「『一回以上の繰り返し』の定義」なんて書いちゃいましたが、 ただ単にそう定義するだけならレクサのレベルの話であって、 階層的な解析木を築くための構文規則を定めるのがパーサの役割だから、 結合規則によって規則の書き方が変わって当然なのですね。 結果的には誤植(?)がきっかけで非常に勉強になりました。引き続き読み進めていきます。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1511] Re:「1回以上の繰り返し」の定義
投稿者:(ぱ)こと管理人
2010/03/10 03:09:06

>expression /* 「式」とは… */ > : primary_expression /* 「一次式」、 */ > | expression ADD expression /* または、「式」 + 「式」 */ > (以下略) >だと、 >yacc: 4 shift/reduce conflicts. >となりますね。 申しわけありません。これはやはり間違いと判断すべきだと思います。 >どうしてそうなるのかは、まだ自分で説明できません……。 1 - 2 - 3 - 4 - 5 のような式のとき、 -が降ってきた時点でそれまでの分をreduceしないと左結合にならないわけですが、 現状、ここでshift/reduce conflictが起きており、shiftが優先されるため 結合規則が逆順になっています。 この構文規則は、優先順位を気にしなくてよいのなら…という文脈で出てきていた はずですし、その趣旨は構文規則を簡単にしたかったためなのですが、 結合規則まで気にしないとは書いてないですし、警告が出るのはそれ自体まずいですね。 数日中にWeb上で補足を入れます。ご指摘ありがとうございました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1510] Re:「1回以上の繰り返し」の定義
投稿者:yuya
2010/03/09 10:18:47

人に聞く前に、実験してみるべきでした。 expression /* 「式」とは… */ : primary_expression /* 「一次式」、 */ | expression ADD expression /* または、「式」 + 「式」 */ (以下略) だと、 yacc: 4 shift/reduce conflicts. となりますね。 どうしてそうなるのかは、まだ自分で説明できません……。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1509] 「1回以上の繰り返し」の定義
投稿者:yuya
2010/03/08 09:19:49

「プログラミング言語を作る」p43~p44にかけてのソースに、 expression /* 「式」とは… */ : primary_expression /* 「一次式」、 */ | expression ADD expression /* または、「式」 + 「式」 */ (以下略) とあるのを見て、はたと疑問に思いました。 これって、 expression /* 「式」とは… */ : primary_expression /* 「一次式」、 */ | expression ADD primary_expression /* または、「式」 + 「一次式」 */ (以下略) としなくてもよいのでしょうか? 他のソースではそうなっているので、反射的に「あっ、間違いだ!」と思ってしまったのですが、 よく考えると、これでもいいような気がします。 一般に、「hoge は piyo の1回以上の繰り返しである」という定義を、 hoge : piyo | hoge piyo と書かずに hoge : piyo | hoge hoge と書いてはいけない理由って、何かありますでしょうか?
[この投稿を含むスレッドを表示] [この投稿を削除]
[1508] 管理者により削除されました
2010/02/23 18:57:42

>前橋さん >ふさわしくなければ削除を 名指しでこんなこと書いてくるふざけたspammerは 初めて見た。
[この投稿を含むスレッドを表示]
[1507] Re:疑りぶかいあなたのための・・・
投稿者:たいやき
2010/02/22 11:06:30

こんにちは。 どうもありがとうございます。 私はSEですが、ゲームが嫌いで一切ゲームをしませんので、どういう想定で 書かれているのか理解できませでした。 このサイトは7年程前から知っていたのですが、7年来の疑問がやっと晴れました。 ありがとうございました。 >そうです。 >ネットワーク対戦オセロのサーバを立てるなら、そりゃ複数の対戦を同時に >行えるようにするでしょ、と思ってこう書いているのですが、確かにここで >引っ掛かりを覚える方もいらっしゃるかもしれませんね。 >ちょっと表現を考えてみます。 >
[この投稿を含むスレッドを表示] [この投稿を削除]
[1506] Re:疑りぶかいあなたのための・・・
投稿者:(ぱ)こと管理人
2010/02/20 01:33:50

こんにちは。 >この例は、ネットワーク対戦=複数の対戦が同時に行われる という意味で >書かれていると理解すればよいのでしょうか。 そうです。 ネットワーク対戦オセロのサーバを立てるなら、そりゃ複数の対戦を同時に 行えるようにするでしょ、と思ってこう書いているのですが、確かにここで 引っ掛かりを覚える方もいらっしゃるかもしれませんね。 ちょっと表現を考えてみます。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1505] 疑りぶかいあなたのための・・・
投稿者:たいやき
2010/02/18 11:12:49

「疑りぶかいあなたのためのオブジェクト指向再入門」を読ませていただきました。 そこで、疑問に思ったのが、ネットワーク対戦でオセロをする話なのですが、 どうして、ネットワーク対戦になると「複数のオセロの盤面を管理しなければならない」のかです。 ネットワーク対戦であっても、常にAさんとBさんというような一組だけが対戦する のであれば、オセロ盤は一つ管理すればいいだけですよね。 AさんとBさん、CさんとDさん、EさんとFさんというように複数の対戦が 同時期に行われる場合に、初めて複数管理する必要があると思いますが。 この例は、ネットワーク対戦=複数の対戦が同時に行われる という意味で 書かれていると理解すればよいのでしょうか。 よろしくお願いします。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1504] Re:「プログラミング言語を作る」のURL
投稿者:(ぱ)こと管理人
2010/02/17 00:41:47

>> 本に掲載したURLにリダイレクトを置くことで対処いたしました。 >と書かれていますが、エラーページが表示されているようです。 まさかと思って試してみたところその通りでした。 どうやら、リダイレクトのページをhttp://kmaebashi.com/devlang/ 直下(bookの 下でなく)に置き、置いたときの動作テストもそこを確認してしまったようです。 さきほど修正いたしました。 ここに書いても仕方がないのかもしれませんが、辿りつけなかった方には 重ね重ね申しわけありませんでした。お詫び申し上げます。 通りすがり様、情報ありがとうございました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1502] 「プログラミング言語を作る」のURL
投稿者:通りすがり
2010/02/16 08:14:14

こんにちは。 > 本に掲載したURLにリダイレクトを置くことで対処いたしました。 と書かれていますが、エラーページが表示されているようです。 私はドメイン名からトップに飛び無事に辿り着けましたが…
[この投稿を含むスレッドを表示] [この投稿を削除]
[1501] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
投稿者:(ぱ)こと管理人
2010/02/14 00:08:06

青餓鬼さん、yuyaさん、ありがとうございます。 管理人が放置してしまいましてすみません。 この結論を関連ページに追記しました。ありがとうございました。 >とりあえず、Macの人に対しては >「とりあえずUTF-8版を試してください。 >駄目なら export LANG=ja_JP.UTF-8 としてからUTF-8版を再度試してください。」 >って指針で、多くの人に使ってもらえそうですね。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1500] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
投稿者:yuya
2010/02/11 22:20:01

青餓鬼さん、試していただいてありがとうございます。 とりあえず、Macの人に対しては 「とりあえずUTF-8版を試してください。 駄目なら export LANG=ja_JP.UTF-8 としてからUTF-8版を再度試してください。」 って指針で、多くの人に使ってもらえそうですね。 私のほうも、ここらで追究を一段落させていただきます。 ありがとうございました。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1499] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
投稿者:青餓鬼
2010/02/11 16:04:04

>(1)10.5のほうはUTF-8版Diksamが無修正で動いた、と理解してよいのでしょうか? Mac OSX 10.5の方はコマンドの追加もなく、ちゃんと動きました。 >(2)10.4でLANGが設定されていないとなると、LC_ALLが設定されているのでしょうかね。 >差し支えなければ echo $LC_ALL も試してみてください。 echo $LC_ALL の実行結果は、Mac OSXの10.4、10.5共に(空文)でした。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1496] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
投稿者:yuya
2010/02/03 18:05:11

>私のPPCMac G5には、Mac OS X 10.4と10.5の二つのバージョンをインストールして使い分けていますが、10.4の方で実行した echo $LANGの結果は(空文)でした。 >ついでに覗いた10.5のほうは ja_JP.UTF-8 でした。 返信ありがとうございます。 (1)10.5のほうはUTF-8版Diksamが無修正で動いた、と理解してよいのでしょうか? (2)10.4でLANGが設定されていないとなると、LC_ALLが設定されているのでしょうかね。 差し支えなければ echo $LC_ALL も試してみてください。 MacOS X のことは全然分かんないや……。FreeBSDベースらしいということと、 http://homepage3.nifty.com/toshi3/osx2t.html の最後に >Mac OS Xではファイル名はUTF-8、Unixに由来する部分では日本語EUC、 >従来のMac OSに由来する部分ではShift-JISと、複数の文字コードが混 >在して使用されている。 と書かれていて、とにかく複雑なことになってる、ってことは分かりました。 あと、Unicode正規化の方式も違うようで、 http://labs.unoh.net/2007/09/unicode-on-mac.html 手元で実験できない私としては混沌とするばかりです。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1495] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
投稿者:青餓鬼
2010/01/31 16:05:29

>export LANG=ja_JP.UTF-8 > >で正常動作するということは、もとのLANGはUTFじゃなかったということですね。 >ちなみに、上のコマンドを実行する前の echo $LANG の結果は何だったのでしょうか? 私のPPCMac G5には、Mac OS X 10.4と10.5の二つのバージョンをインストールして使い分けていますが、10.4の方で実行した echo $LANGの結果は(空文)でした。 ついでに覗いた10.5のほうは ja_JP.UTF-8 でした。 環境変数LANGに何も指定されてなくても日本語が表示されるところを見ると別の環境変数があるのでしょうが、それについての解説は見つけることはできていません。 以上
[この投稿を含むスレッドを表示] [この投稿を削除]
[1494] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
投稿者:yuya
2010/01/24 17:04:03

export LANG=ja_JP.UTF-8 で正常動作するということは、もとのLANGはUTFじゃなかったということですね。 ちなみに、上のコマンドを実行する前の echo $LANG の結果は何だったのでしょうか?
[この投稿を含むスレッドを表示] [この投稿を削除]
[1493] Re:DIKSAM_book_0_4のMac/Winでの実行結果について(その2)
投稿者:青餓鬼
2010/01/23 15:03:36

Macで実行する際、UTF-8の場合exportコマンドで環境変数を指定すると、正常に実行することがわかりました。 >export LANG=ja_JP.UTF-8 このコマンドを実行した後に DIKSAM を実行すると、サンプルと同じ結果を得ることができます。 Macの技術解説書にこのあたりを体系的に記述したものが見あたらず、たまたま読んだコマンドリファレンスの、別のコマンドの実行例に、上に掲げた一文があり、早速実行すると、エラーなく実行できました。 なお、EUCの場合は、ターミナル上の日本語表示が文字化けしますので、別の環境変数があるのかもしれません。これ以上、深入りは当面控えておきます。 以上
[この投稿を含むスレッドを表示] [この投稿を削除]
[1492] Re:ホームページと本との違いについて
投稿者:ぽむじぃさん
2010/01/19 10:32:35

>HEAP_THRESHOLD_SIZEが小さいと、頻繁にGCが走って遅くなるのはわかるのですが、 >死んでしまうのはおかしいと思うのですが…… >念のため当方でcrowbar_book_ver.0.2において、HEAP_THRESHOLD_SIZEを元に戻した >上で2000*2000*2の多次元配列を確保したところ、時間はかなりかかったようですが >死にはしませんでした。(Windows Vista環境) > 私もcrowbarcer_ver.0.2をターミナルで実行したところ時間はすごく掛かりましたが正常に終了しました.申し訳ないです.こちらも確認すべきでした. 私が開発環境はMacのXcodeです.GUIにcrowbarを組み込んでいます.ちなみにOS Xの10.6です. どこか実装にミスがあるのかもしれませんね^^;要素が大きくなるときだけGC_mark()で止まってるようなのですが難しいですね.本当にお手数かけました.
[この投稿を含むスレッドを表示] [この投稿を削除]
[1491] Re:ホームページと本との違いについて
投稿者:(ぱ)こと管理人
2010/01/19 03:08:15

>尚,私の環境では200*200*200では4秒ほどなのですが2000*2000*2の多次元配列を利用した場合EXC_BAD_ACCESSで止まってしまいデバッガが起動していました. >実際にHEAP_THRESHOLD_SIZEを変更したところ多少時間はかかるものの正常に実行されました. HEAP_THRESHOLD_SIZEが小さいと、頻繁にGCが走って遅くなるのはわかるのですが、 死んでしまうのはおかしいと思うのですが…… 念のため当方でcrowbar_book_ver.0.2において、HEAP_THRESHOLD_SIZEを元に戻した 上で2000*2000*2の多次元配列を確保したところ、時間はかなりかかったようですが 死にはしませんでした。(Windows Vista環境)
[この投稿を含むスレッドを表示] [この投稿を削除]
[1490] Re:ホームページと本との違いについて
投稿者:ぽむじぃさん
2010/01/17 18:24:47

>>サイトの説明:http://kmaebashi.com/programmer/devlang/array.htmlでは下記のコードが追加されています. >>#GCされないようにおまじない >>CRB_push_value(inter, &ret); >> >>CRB_pop_value(inter); > >これは、ネイティブ関数内で確保したオブジェクトがGCされないように >スタックに積んでいるわけですが、この方法は、ネイティブ関数を書く人に >(面倒くさいという意味で)負担をかけますので、 >Webページ版においても以下のページで方法を変更しています。 > >http://kmaebashi.com/programmer/devlang/crowbar_0_4_02.html > >前者の方法が後者の方法に比べて優れているところは特にないと思いますので、 >本の方では、最初から後者の方法で実装しているわけです。 >本では、後者の方法について、171ページで説明しています。 > >>私の実行環境ではnew_array()関数でたまに(要素数が大きくなると)gc_mark()の >>ところで止まってしまいます.私の実装ミスか,その部分のコードが足りない >>せいなのか分からないので質問させていただきました. > >crowbarのGCは単純なstop the world式のmark sweep GCなので、オブジェクト数が >増えてくるとmarkに時間がかかります。1次元の配列なら、多少数が多くても >オブジェクト数はひとつだからよいのですが、多次元ですと、現状の実装では >確保の途中で(無駄に)GCが動くのでかなり遅くなることがあります。new_array()の >中で不要なオブジェクトが増えることはないので、この間GCの発生を抑止する >方がよいのでしょうが、現状ではそうなっていません。 >ひとまずこちらでは、100×100×100の配列程度であればすぐに返りましたが、 >200×200×200だと30秒近く待たされました。 > >簡単にチューニングするには、crowbar.hのHEAP_THRESHOLD_SIZEを増やすという >方法があります。これは、どれだけのサイズのオブジェクトを確保したらGCを >動かすかという閾値で、現状では256KBになっています。 > 早速の返信ありがとうございます. 私はver0.2を参考にしていたのでそれ以降を見ていませんでした.申し訳ありません.最後まで読んで質問するべきでした. >>多次元ですと、現状の実装では確保の途中で(無駄に)GCが動くのでかなり遅くなることがあります なるほど納得しました.実装ミスというわけではないのですね.安心しました. 尚,私の環境では200*200*200では4秒ほどなのですが2000*2000*2の多次元配列を利用した場合EXC_BAD_ACCESSで止まってしまいデバッガが起動していました. 実際にHEAP_THRESHOLD_SIZEを変更したところ多少時間はかかるものの正常に実行されました. どうしても多次元で要素数が多い場合にも対応する必要があるため本当に助かりました. 有り難うございます.
[この投稿を含むスレッドを表示] [この投稿を削除]
[1489] Re:ホームページと本との違いについて
投稿者:(ぱ)こと管理人
2010/01/17 16:03:31

>サイトの説明:http://kmaebashi.com/programmer/devlang/array.htmlでは下記のコードが追加されています. >#GCされないようにおまじない >CRB_push_value(inter, &ret); > >CRB_pop_value(inter); これは、ネイティブ関数内で確保したオブジェクトがGCされないように スタックに積んでいるわけですが、この方法は、ネイティブ関数を書く人に (面倒くさいという意味で)負担をかけますので、 Webページ版においても以下のページで方法を変更しています。 http://kmaebashi.com/programmer/devlang/crowbar_0_4_02.html 前者の方法が後者の方法に比べて優れているところは特にないと思いますので、 本の方では、最初から後者の方法で実装しているわけです。 本では、後者の方法について、171ページで説明しています。 >私の実行環境ではnew_array()関数でたまに(要素数が大きくなると)gc_mark()の >ところで止まってしまいます.私の実装ミスか,その部分のコードが足りない >せいなのか分からないので質問させていただきました. crowbarのGCは単純なstop the world式のmark sweep GCなので、オブジェクト数が 増えてくるとmarkに時間がかかります。1次元の配列なら、多少数が多くても オブジェクト数はひとつだからよいのですが、多次元ですと、現状の実装では 確保の途中で(無駄に)GCが動くのでかなり遅くなることがあります。new_array()の 中で不要なオブジェクトが増えることはないので、この間GCの発生を抑止する 方がよいのでしょうが、現状ではそうなっていません。 ひとまずこちらでは、100×100×100の配列程度であればすぐに返りましたが、 200×200×200だと30秒近く待たされました。 簡単にチューニングするには、crowbar.hのHEAP_THRESHOLD_SIZEを増やすという 方法があります。これは、どれだけのサイズのオブジェクトを確保したらGCを 動かすかという閾値で、現状では256KBになっています。
[この投稿を含むスレッドを表示] [この投稿を削除]
[1488] ホームページと本との違いについて
投稿者:ぽむじぃさん
2010/01/17 05:13:07

配列の確保、およびネイティブ関数の書き方についての質問です サイトの説明:http://kmaebashi.com/programmer/devlang/array.htmlでは下記のコードが追加されています. #GCされないようにおまじない CRB_push_value(inter, &ret); CRB_pop_value(inter); ところがこのコードの部分は本書及び,サンプルソースでも書かれていませんでした. これは必要ないということでしょうか? またそのような関数名はないようなのですが,eval.cのpush_value(),pop_value()のことでしょうか? 私の実行環境ではnew_array()関数でたまに(要素数が大きくなると)gc_mark()のところで止まってしまいます.私の実装ミスか,その部分のコードが足りないせいなのか分からないので質問させていただきました.
[この投稿を含むスレッドを表示] [この投稿を削除]