K.Maebashi's BBS

>>例えば六角形のマスでも >>普通に二次元で値を保持しておけばいいんですね。 >六角オセロの場合は、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がわざわざネコのキャラで作成したから話がややこしくなったような。 まったくネタを知らない人からすればネコである必要性がないわけですから。 # もっとも、「のまねこ」というのは語感・語韻が良いというのもあるでしょうけれど。

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