K.Maebashi's BBS

>lex/yaccで独自言語を作った場合、gccのフロントエンドにして各種Linuxディストリ >ビューションに標準で組み込まれるのが、もっともよいあがりですか。 現状で、個人作の独自言語で成功しているものというと、私としては PerlとかRubyとかPythonとかが浮かぶわけですが、このへんはたいてい ネイティブコードに落とさずインタプリタで実行していますよね。 # Dは違いますけど。 でも、多少なりとも速度を求めるのなら、JITでJavaやC#に勝負を挑むのは無謀なので、 gccのバックエンドを使ってネイティブコードを吐かせるというのは妥当な手段の ような気もします。というわけで自分用のメモ。 GCC Frontend HOWTO http://www.tldp.org/HOWTO/GCC-Frontend-HOWTO.html >JavaCCの場合は、Java VM上で動くようなバイトコードを吐いてWrite Once, >Run Anywhereなんでしょうか。 JVMのバイトコードを吐くのは簡単だと思うのですが、JVMはJavaの言語仕様に 強く依存しているのがなんとも… CLRはよく知らないのですが、JVMより制限が緩いようなら、勉強しようという 気になります。 >Dで独自にパースする場合は、D言語フロンティアになる、ってところでしょうか。 「フロンティア」は「あがり」なのか「ババをひく」係なのか… いやその第三者的には是非ともがんばっていただきたく(ひでぇ) >まだlex/yaccかJavaCCか確定していませんが、理解度からすると8:2でlex/yaccですね。 了解です。もしよろしければ公開を希望、という意思表示だけしときます、 ということにさせていただきたく存じますです。

こんばんは。緒方です。 >>前橋さんがlex/yaccで作られるので、やっぱりそうかぁ～、ということで >>僕もそうしようと思います。 > >いやどうせならここは敢えて違う方法をとってみるということでひとつ。 ># 別にプレッシャーかけるつもりはないですが… (^^; それぞれで作った場合の「あがり」について考えるわけです。「あがり」というのはサラリーマンなら社長、政治家なら総理大臣、フリーターなら発明家、という人生ゲームのそれです。 lex/yaccで独自言語を作った場合、gccのフロントエンドにして各種Linuxディストリビューションに標準で組み込まれるのが、もっともよいあがりですか。 JavaCCの場合は、Java VM上で動くようなバイトコードを吐いてWrite Once, Run Anywhereなんでしょうか。 Dで独自にパースする場合は、D言語フロンティアになる、ってところでしょうか。 他にもSmalltalkで書いてSmalltalk VM上で動作するようにしようかとか、C#で書いて.NET上で動作するようにしようかとかも考えたのですが、現実的なのはコンパイラコンパイラで作る方法なので、というかフルスクラッチはさすがにげんなりですね。 まだlex/yaccかJavaCCか確定していませんが、理解度からすると8:2でlex/yaccですね。

>こんばんは、はじめまして。緒方と申します。 　どうも。はじめまして。書き込みありがとうございます。 >新しく始められた「プログラミング言語を作る」は僕にとってすごく >タイムリーな話題です。僕も今年に入ってから独自言語の「構想」を練っています。 　独自言語の構想を練るのも楽しいですよね。 　欲張りすぎると発散するケースが多いのですが… (経験上) >前橋さんがlex/yaccで作られるので、やっぱりそうかぁ～、ということで >僕もそうしようと思います。 いやどうせならここは敢えて違う方法をとってみるということでひとつ。 # 別にプレッシャーかけるつもりはないですが… (^^; >連載楽しみにしています。 　それがその、最近体調が優れないのと、仕事のほうがアレなので、あまり時間が 避けそうにない状況です。 　ただ、まぬけなバグが2件、残ったままになっているのは気持ちが悪いので、マイナー バージョンアップ版(配列なしでbooleanとネイティブポインタ型を組み込んだ版)を、 さっさと出そうと思います。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ディスカバリーネットのSOHOアルバイター急募要項 ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ 夢のパソコンライフで副収入を得てみませんか？ ノルマやペナルティーはなく、１日３０分から１時間程度のお仕事です！ 風俗的、反社会的な業務を委託することは一切ございません。 一攫千金は無理ですが、少しずつ確実に収入を得たい方は必見です！ ディスカバリーネットは、SOHOで高収入を得るお手伝いをいたします！ お申し込みの際には紹介者ＩＤ【ＨＳ‐８７】が必要になります。 ↓このHPに登録してみましょう！(詳細はこちら) http://discovery.sub.jp/

こんばんは、はじめまして。緒方と申します。 新しく始められた「プログラミング言語を作る」は僕にとってすごくタイムリーな話題です。僕も今年に入ってから独自言語の「構想」を練っています。 lex/yaccを使用するか（この場合実装はC/C++）JavaCCを使用するか（これなら実装はJava）、それとも構文解析機は手書きするか（だとすると実装はD）、かなり長い間悩みました（電卓がいくつか出来上がりました^^;）。前橋さんがlex/yaccで作られるので、やっぱりそうかぁ～、ということで僕もそうしようと思います。 連載楽しみにしています。

>「センス・オブ・プログラミング」購入しました。 どうもです。お買い上げいただきありがとうございます。 >ところがこの本は違う！いわば企画モノですがパワーがあります。 (たぶん)おほめいただきありがとうございます。 企画モノAV…　いや別に嫌いなわけじゃないですが(ぉぃ >きちんと読み込みたいです。Cの本も読んでみます。 こちらもよろしくお願いします。

>ほげほっぽなる麦焼酎があるようです。仕事の後に、ほげほっぽ。 　風邪引いて寝込んでいます。返事が遅くなりましてすみません。 　情報ありがとうございました。今やる体力はないですが、後ほど 「ほげを考えるページ」に追記しておきます。

マエバシさん はじめまして。 「センス・オブ・プログラミング」購入しました。 かなり良い本ですね～！！ 書店でぱっと手にとって、つい買ってしまいました。 初心者向けにもかかわらずかなり高度な内容が書かれていて グッジョブ！です。 日経BPに似たようなサイズの本がありますが、あちらはいわば 有名AV女優のようなもの。 なんかお高くとまってイマイチ・・・な気がしていました。 ところがこの本は違う！いわば企画モノですがパワーがあります。 そしてなにより愛がある！！ 技術的に普段どうなんだろうね・・と思っていた点にも明快に 書かれていて非常にコ気味良かった（ハンガリアン表記法など）。 そしてこれだけ笑える技術書というのも珍しい！ 「おかしい・・・・どこもおかしくない」は爆笑す！ ワタクシデビューが遅く小さなシステム屋でaccessVBAでシコシコ作ってました。 このたび、けっこう大きめのところに開発で入ることになり 本格的に勉強せねばと思い本を買いあさっていたところです。 きちんと読み込みたいです。Cの本も読んでみます。 ありがとうございました～。

ほげ症候群から抜け出せません。気が付くと、ほげほげしてしまいます。 ほげほっぽなる麦焼酎があるようです。仕事の後に、ほげほっぽ。

ご回答有難うございます。 遅くなりまして申し訳有りません。 > その mingw\stdio.h は使われていないからです。 > cygwin の gcc のデフォルトは -mcygwin であり mingw ではありません。 > とりあえず gcc -mno-cygwin test5.c とすればコンパイル通るような気もします。 これで出来ました。 実行結果も同じになりました。 「-mno-cygwin」オプションはMinGWランタイムライブラリを使用せよリンクの為のオプションなのですね。 ランタイム…関連するヘッダファイルと対応するライブラリの総称 > ちょっと調べれば判る程度の問題だと思うのですが、聞く前に調べましたか？ 文法エラーとばかり思い込んでいました。 > ただ、\cygwin\usr\include\mingw\stdio.hを見つけることができたなら、 > \cygwin\usr\include\stdio.hを先に見つけてそうですし、ふたつあるなら > どっちか片方が使われているはずで、デフォルトで使われるのは、 > パスの短い方(\cygwin\usr\include\stdio.h)と推論するのが普通じゃないかなあ、 > とは思います。 そういわれてみればそうですよね。 スイマセン。二つあるのもそんなものなのかなと思って疑問視してませんでした。 > \cygwin\usr\include\stdio.hそのものにFILEの定義はないかもしれないですが、 > そこから#includeしているファイルの中にあるはずです。 \cygwin\usr\include\stdio.h内に typedef __FILE FILE; を見つけ ↓ \cygwin\usr\include\sys\reent.h内に typedef struct __sFILE __FILE; を見つけ ↓ \cygwin\usr\include\sys\reent.h内に struct __sFILE { unsigned char *_p; /* current position in (some) buffer */ int _r; /* read space left for getc() */ int _w; /* write space left for putc() */ short _flags; /* flags, below; this FILE is free if 0 */ short _file; /* fileno, if Unix descriptor, else -1 */ struct __sbuf _bf; /* the buffer (at least 1 byte, if !NULL) */ int _lbfsize; /* 0 or -_bf._size, for inline putc */ #ifdef _REENT_SMALL struct _reent *_data; #endif /* operations */ _PTR _cookie; /* cookie passed to io functions */ _READ_WRITE_RETURN_TYPE _EXFUN((*_read),(_PTR _cookie, char *_buf, int _n)); _READ_WRITE_RETURN_TYPE _EXFUN((*_write),(_PTR _cookie, const char *_buf, int _n)); _fpos_t _EXFUN((*_seek),(_PTR _cookie, _fpos_t _offset, int _whence)); int _EXFUN((*_close),(_PTR _cookie)); /* separate buffer for long sequences of ungetc() */ struct __sbuf _ub; /* ungetc buffer */ unsigned char *_up; /* saved _p when _p is doing ungetc data */ int _ur; /* saved _r when _r is counting ungetc data */ /* tricks to meet minimum requirements even when malloc() fails */ unsigned char _ubuf[3]; /* guarantee an ungetc() buffer */ unsigned char _nbuf[1]; /* guarantee a getc() buffer */ /* separate buffer for fgetline() when line crosses buffer boundary */ struct __sbuf _lb; /* buffer for fgetline() */ /* Unix stdio files get aligned to block boundaries on fseek() */ int _blksize; /* stat.st_blksize (may be != _bf._size) */ int _offset; /* current lseek offset */ #ifndef _REENT_SMALL struct _reent *_data; /* Here for binary compatibility? Remove? */ #endif #ifndef __SINGLE_THREAD__ _flock_t _lock; /* for thread-safety locking */ #endif }; を見つけました。

時間がないのでちょっとだけ。 >ちょっと調べれば判る程度の問題だと思うのですが、聞く前に調べましたか？ MinGWとcygwinの関係とかに関する知識がないと、そっち方向を調べることを 思いつかなくても不思議はないかもしれません。 ただ、\cygwin\usr\include\mingw\stdio.hを見つけることができたなら、 \cygwin\usr\include\stdio.hを先に見つけてそうですし、ふたつあるなら どっちか片方が使われているはずで、デフォルトで使われるのは、 パスの短い方(\cygwin\usr\include\stdio.h)と推論するのが普通じゃないかなあ、 とは思います。 \cygwin\usr\include\stdio.hそのものにFILEの定義はないかもしれないですが、 そこから#includeしているファイルの中にあるはずです。

その mingw\stdio.h は使われていないからです。 cygwin の gcc のデフォルトは -mcygwin であり mingw ではありません。 とりあえず gcc -mno-cygwin test5.c とすればコンパイル通るような気もします。 ちょっと調べれば判る程度の問題だと思うのですが、聞く前に調べましたか？

遅くなりまして申し訳有りません。 > というわけで修正プログラムです。 ： > return 0; > } 大変有難うございます。 でもコンパイルすると $ gcc -o test5 test5.c test5.c: In function `dump_buffer': test5.c:7: error: structure has no member named `_cnt' test5.c:8: error: structure has no member named `_ptr' test5.c:11: error: structure has no member named `_ptr' となってしまい、プログラム実行できずじまいです。 cygwinのを(\cygwin\usr\include\mingw\stdio.h)調べてみましたら #ifndef _FILE_DEFINED #define _FILE_DEFINED typedef struct _iobuf { char* _ptr; int _cnt; char* _base; int _flag; int _file; int _charbuf; int _bufsiz; char* _tmpfname; } FILE; となってました。 うーん、どうしてコンパイルエラーになってしまうんでしょうか?

まず前回のコードにポカがあったので再掲します。ついでに色々いじりました。 >　_baseがバッファの根元を押さえ、_cntが現在格納されているデータのサイズだと >想像し(外しているかも)、こんなプログラムを書いてみました。 baseはおそらくバッファの根元を押さえているのでしょうが、バッファから 1文字消費されるたびに中身を移動させていくとは思えないので、 おそらく環状バッファか何かになっていて、現在バッファリングされている 内容の先頭は_ptrが抑えているのでしょう。 というわけで修正プログラムです。 #include <stdio.h> void dump_buffer(FILE *fp) { int i; printf("["); for (i = 0; i < fp->_cnt; i++) { if (fp->_ptr[i] == '\n') { printf("<\\n>"); } else { putchar(fp->_ptr[i]); } } printf("]\n"); } int main(void) { int c; for (;;) { dump_buffer(stdin); c = getchar(); if (c == EOF) break; putchar(c); } return 0; } うちの環境での実行結果。 C:\ctest>buffer [] abcdefg a[bcdefg<\n>] b[cdefg<\n>] c[defg<\n>] d[efg<\n>] e[fg<\n>] f[g<\n>] g[<\n>] [] さて、 >> C:\ctest>buffertest >> aaa >これはエコーバックですよね。 そうです。 >> [aaa] >これはdump_buffer関数でのputchar、printf出力ですね。 そうです。 >> a[aa] >aが一回だけ入力されているのにこのようになるのですかね?? ここに誤解があります。ここで左端に出ている[]に入らないaは、 エコーバックではなく、main()の中でputchar()されている文字です。 つまり、手で「aaa」と入力すると、バッファから1文字ずつ消費しながら putchar()している、という様子を示しているわけです。 # でも、前回のプログラムに「abc」と入れると、変な出方をするのでした(^^;

ご回答大変有難うございます。 > 掲示板では一般にマルチポストは嫌われます。 マルチだと思われたのならお詫び致します。ｍ(＿ ＿)ｍ > 　ただ、今回の例だと、時期がずれていて、質問内容も違うので、マルチポストに > 当たるかどうかはわかりません。 そう思っていただければ大変助かります。ｍ(＿ ＿)ｍ > が、この手の掲示板を見ている人は、同じような > ジャンルの掲示板は見ていることが多い、ということは意識している必要があると > 思います。かずまさんも、たまにこの掲示板にも登場されます。 今後、誤解が生じませぬよう成るべく異なるサンプルリストを提示するよう心がけま す。 >>select関数についての振舞いについて調べています。 > 端末ドライババッファとstdinバッファの振舞いについて調べるのに、 > わざわざselectを使う必要があるのでしょうか。もちろん別にselectでもいいです > が、 > getchar()とputchar()でもよいような。 そうですか。参考にしてみます。ただ、最近、select関数を知ったのでちょっと使っ てみたくなりまして。 > 　端末ドライバのバッファは覗けないと思います(少なくとも標準的な方法では)。 > 　標準入力のバッファは、FILE構造体に紐づいていますから、stdio.hから > 調べればよいでしょう。 > 　私の環境(gcc (GCC) 3.4.2 (mingw-special))ではこうなっていました。 ： > > [実行結果] > C:\ctest>buffertest > aaa これはエコーバックですよね。 > [aaa] これはdump_buffer関数でのputchar、printf出力ですね。 > a[aa] aが一回だけ入力されているのにこのようになるのですかね??

　はじめまして。 >　それはさておいて、なんとなしに同書の正誤表を見ていたら「賭け網」と書かれた >箇所に気づきました。「賭け」でよかったのかな、と思ったもので。ちなみにGoogleで >検索するとこちらのサイトがトップ３にランクインしてました。 　ご指摘ありがとうございます。まぬけなポカでした。修正しました。

　貴著「センス・オブ・プログラミング！」が図書館にあったので今度借りようと思っている者です（著者さんとしてはうれしさ半減？）。 　それはさておいて、なんとなしに同書の正誤表を見ていたら「賭け網」と書かれた箇所に気づきました。「賭け」でよかったのかな、と思ったもので。ちなみにGoogleで検索するとこちらのサイトがトップ３にランクインしてました。

　掲示板では一般にマルチポストは嫌われます。 　ただ、今回の例だと、時期がずれていて、質問内容も違うので、マルチポストに 当たるかどうかはわかりません。が、この手の掲示板を見ている人は、同じような ジャンルの掲示板は見ていることが多い、ということは意識している必要があると 思います。かずまさんも、たまにこの掲示板にも登場されます。 >select関数についての振舞いについて調べています。 端末ドライババッファとstdinバッファの振舞いについて調べるのに、 わざわざselectを使う必要があるのでしょうか。もちろん別にselectでもいいですが、 getchar()とputchar()でもよいような。 ... >端末ドライバのバッファやstdinバッファの中身を覗くにはどうすれば >いいのでしょうか? 　端末ドライバのバッファは覗けないと思います(少なくとも標準的な方法では)。 　標準入力のバッファは、FILE構造体に紐づいていますから、stdio.hから 調べればよいでしょう。 　私の環境(gcc (GCC) 3.4.2 (mingw-special))ではこうなっていました。 typedef struct _iobuf { char* _ptr; int _cnt; char* _base; int _flag; int _file; int _charbuf; int _bufsiz; char* _tmpfname; } FILE; 　_baseがバッファの根元を押さえ、_cntが現在格納されているデータのサイズだと 想像し(外しているかも)、こんなプログラムを書いてみました。 #include <stdio.h> void dump_buffer(FILE *fp) { int i; printf("["); for (i = 0; i < fp->_cnt; i++) { putchar(fp->_base[i]); } printf("]\n"); } int main(void) { int c; while ((c = getchar()) != EOF) { dump_buffer(stdin); putchar(c); } } [実行結果] C:\ctest>buffertest aaa [aaa] a[aa] a[a] a[] bbb [bbb] b[bb] b[b] b[] 　それっぽく動いているように見えます。 　重要なのは、標準入出力ライブラリの関数は、そのバッファリングのメカニズムを 含め、普通にCで、システムコールの上に実装されている、ということです。 実装を想像すると、理解が深まると思います。

http://www3.realint.com/cgi-bin/tarticles.cgi?pointc2+3409 ここの人ですか？ せっかく「とても適切でわかりやすい」回答があるのですから、 １００回くらい繰り返して読むべきです。

select関数についての振舞いについて調べています。 (Win2k+Cygwin) #include <stdio.h> #include <string.h> #include <stdlib.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h> #include <sys/types.h> #include <curses.h> #include <signal.h> #include <unistd.h> //=================== void session_loop(){ fd_set mask; FD_ZERO(&mask); FD_SET(0,&mask); fd_set readOK; int width=1; char c; printf("う\n"); while(1){ printf("あ\n"); readOK=mask; printf("こwidth=%d\n",width); select(width,(fd_set *)&readOK,NULL,NULL,NULL); printf("け\n"); if ( FD_ISSET(0, &readOK ) ){ printf("い\n"); c=getchar(); //getcharはバッファリングあり関数 printf("c=%c\n",c); printf("さ\n"); } } } //================= int main(void){ session_loop(); return 0; } というリストで 端末ドライババッファやstdinバッファの振舞いについて学習しています。 端末ドライバにバッファリングされた文字群がgetchar関数のread要求とかでstdinバッファに排出される様子や stdinバッファの文字群がgetchar関数の読込み毎に減っていく様子を垣間見たく思っています。 端末ドライバのバッファやstdinバッファの中身を覗くにはどうすればいいのでしょうか?

>　ゲームプログラマじゃないですって(^-^;) ありゃりゃ、すみません。旧掲示板でゲームのフレームワークの話をしておられたので ゲーム系の人かと思ってました。失礼しました。 >　あとは「僧侶が使うと魔法が発動するが、勇者が使うと武器になる」とか >「フィールドによっては効果が封印されてしまう」など作り込み次第で例外は >いくらでもありそうです。 … >　あとはリフレクトされるカウンターなんかがあると更に面倒になるのでしょうね。 >そしてそのカウンターに「反応」できるとなると・・・考えるだけで目が回りそう >です。 うわあ。なるほど。 これで、武器や職業の種類が少なければ、いっそif文べたべたでやってしまえという ことになりそうですが、おそらくそうでもないんでしょうね。 大筋はポリモルフィズムで、例外的なのはif文で場合分け、とかするのかな。 何にせよ大変そうです。

　ゲームプログラマじゃないですって(^-^;) 大昔に書いたと思いますがバリバリC/S系です。 # 確かに趣味ではゲーム作ってますけど・・・ 　Cでも関数は書き方、作り方にある程度の定石がありますが、結局のところは適材適所になって例外はいくらでもあるわけで、この辺りは悩みどころかもしれませんね。CADに関してはやったことないのであまり深く言及できませんが、ShapeのZオーダだけで単純に判定できなそう、くらいの認識です。 >　このへんは、ダブルディスパッチ(いや、Character→Arm→Enemyのトリプル >ディスパッチかな)でいけそうな気がしますが、どうなんでしょうか。 　そうですね・・・アイテム攻撃でも「武器を選択すれば殴れる」ような場合とか「魔法が発動してしまう」場合もあるのでもう1回くらいディスパッチが必要になるかもしれませんね。 　あとは「僧侶が使うと魔法が発動するが、勇者が使うと武器になる」とか「フィールドによっては効果が封印されてしまう」など作り込み次第で例外はいくらでもありそうです。 　ひと昔前のRPGであれば、攻撃が0、魔法が1などになっていて、引数でどの武器、どの魔法なんて指定していましたが、それをしっかりOOPで纏めるほどディスパッチの回数が多くなりそうな気がします。 　あとはリフレクトされるカウンターなんかがあると更に面倒になるのでしょうね。そしてそのカウンターに「反応」できるとなると・・・考えるだけで目が回りそうです。

>使う側は全体魔法の場合は、こう書く...かなぁ? > for( i=0; i<number_of_enermy; i++) Attack( enermy[i], magic); 「全体魔法の場合は」というif文が出てくるのが、本来は美しくないんでしょうけど。 現実問題そこの場合分けなしではうまく書けないのかもしれませんし。 >でも、やっぱりattack()がintを返すのは問題かなぁ。 >enermyのステータスなり何なりに効果を与えるのが自然...かな？ ということで、条件分岐は避けられないとするのなら、いっそget_attack_point() にして後の判断は上位に任せるという方法もあるかとは思います。OO的ではないですが。 もちろん、そのメソッド名が「attack()」では全然ダメですけどね。

私はそもそもRPGをろくすっぽやったこともないんですが。 # 家庭用ゲーム機持ってないもんで… # 大昔、PC1500版labyrinthを作ろうとして挫折した記憶が(以下略) >　これもまた面倒で、明らかに敵のグループを選択して魔法を撃つ場合と、 > フィールド上で「ボカーン！」と爆発する魔法を撃つ場合を考えないと > いけないでしょうね。（後者は味方の巻き添えもありえますし） 　プロのゲームプログラマさんの投稿ありがとうございます。 　こういうのは、いわゆる「教科書的なOO」が適用できないケースですよね。 RPGに限らず、CADなどでも、例外的な事象はいくらでもあるわけで。 　ユーザが画面上である座標をクリックしたとき、最寄の図形を選択したいわけですが、 ・「折れ線」の上に「中間点(vertex)」がある場合、vertexを優先して検出したい。 ・せっかく直線を選択したのなら、クリックした座標から下ろした垂線の足も 　検出したい。 　とかの要望も出てきて、 　Shape#distance(double x, double y) 　をいろんなShapeでオーバーライドすれば完璧! とはなかなかならないのが現実です。 >　ですからAttackTo(Enemy)と書いた場合でも、内部的にはEnemy.DamageFrom(This)と >書いて、Enemy側で「その攻撃が本当にダメージになるか」などを判断する必要が >あるのじゃないかと思います。 　このへんは、ダブルディスパッチ(いや、Character→Arm→Enemyのトリプル ディスパッチかな)でいけそうな気がしますが、どうなんでしょうか。

>「はてな」で書くときの癖で改行入れるの忘れました・・・orz これなんですが、この掲示板では当初発言内容をすべて<pre>で囲んでいたため、 手で改行を入れないと改行されなかったのですが、 現在は、<tt>で囲み、かつ空白を&nbsp;に置換することで、 改行を行いつつ、ソースを貼っても極端にインデントが崩れないようにしています。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=25&range=1 # 要するに、OTDの時は<pre>で囲む以外手がなかったんだけど、今はスクリプト # 自体が自作なんだから、空白を&nbsp;に置換することなんて簡単なのに # しばらくそれに気付かなかった私がアホだったわけで。 よって、現在は、ことさら手作業で改行を入れる必要はなくなっています。 私は、返信の際にうまく「>」が入るように、改行を入れていますけど。 ということでお気になさらず。

>　・・・などとOOPでRPGを作成したことがないので自信なしですが(^-^;) 作成したことのある人のほうが少なそうに思えますが。さて。 >　あとはGetAttckPoint()メソッドを作る場合でも、内部ステータス的にアイテム攻撃になる場合もありますし、アンデッドのように属性で効果が変わる場合もあります。 攻撃の効果が相手によって変わるなんてのは 関数Attack()の実装を オブジェクト(攻撃対象)によって 異なる様に記述したいのだから、 継承なり仮想関数なりを使うのが自然なんでしょうかねぇ。 使う側は全体魔法の場合は、こう書く...かなぁ? for( i=0; i<number_of_enermy; i++) Attack( enermy[i], magic); なんかちょっと違う気がする...よーく考えないとあかんかなぁ。 でも、やっぱりattack()がintを返すのは問題かなぁ。 enermyのステータスなり何なりに効果を与えるのが自然...かな？

「はてな」で書くときの癖で改行入れるの忘れました・・・orz

>　Shapeと違ってCharacterは、そのRPGでしか使わないから、attack(Enemy)でも >良いような気もしますが、RPGではきっと「周囲にいる複数の敵にいっせいに >ダメージを与える技」ってのがありそうですし。 　これもまた面倒で、明らかに敵のグループを選択して魔法を撃つ場合と、フィールド上で「ボカーン！」と爆発する魔法を撃つ場合を考えないといけないでしょうね。（後者は味方の巻き添えもありえますし） 　前者も炎とかを出すのであれば後者のルーチンと共通化した関数にすることができそうですが、マインドアタックなどの場合は直接効果を与える処理（ステータスなども弄る処理）になるでしょうし。 　あとはGetAttckPoint()メソッドを作る場合でも、内部ステータス的にアイテム攻撃になる場合もありますし、アンデッドのように属性で効果が変わる場合もあります。 　ですからAttackTo(Enemy)と書いた場合でも、内部的にはEnemy.DamageFrom(This)と書いて、Enemy側で「その攻撃が本当にダメージになるか」などを判断する必要があるのじゃないかと思います。 　・・・などとOOPでRPGを作成したことがないので自信なしですが(^-^;)

>int get_attack_point() const { return power+weapon; } >int get_defence_point() const { return vitality+armor; } >ならとりあえず許します。 　これは同意です。 　私があちこちに書いている「Shapeにdraw()メソッドを入れてはいけない原則」に 則れば、attack(Enemy)よりもget_attack_point()の方が良いような気もします。 　Shapeと違ってCharacterは、そのRPGでしか使わないから、attack(Enemy)でも 良いような気もしますが、RPGではきっと「周囲にいる複数の敵にいっせいに ダメージを与える技」ってのがありそうですし。

attack() を動詞ととるなら確かに「設計がヘン」です。 こんな設計見せられたら、私も却下します。 int get_attack_point() const { return power+weapon; } int get_defence_point() const { return vitality+armor; } ならとりあえず許します。 初心者に最初に見せるサンプルというのはきわめて大事です。 「適切なサンプル」を見せるのなら良い。 「テキトーなサンプル」は見せるだけ有害です。 孵ったばかりの雛鳥と同じく、そのサンプルが刷り込まれてしまいます。 トンデモ系の設計を刷り込まれてしまった初心者のコードは手がつけられなくなります。