K.Maebashi's BBS

>うーん、私が狙ったのは、複数のpointオブジェクトから共通に参照できる >ひとつのクラスフィールド、です。 >まあ、create_point_class()を複数回呼んでしまえば複数作れてしまいますが、 >それは利用者側の問題にしてよいのではないかと。 それだとprivateなインスタンス変数な気がします...。間違ってたらすいません。 但し、パフォーマンスはともかく、利用者側から見れば、 やりたいことは実現できますので現時点では十分かもしれません。 >あくまで「静的な」(ひとつしかない)データが、グローバル変数以外の方法で必要だ、 >ということであれば、Cのstatic指定したローカル変数のようなものを付けると >いうのはひとつの手かもしれませんが。 staticのローカル変数でも実現可能ですね。どう設計するかですね。 あと、制御構造の抽象化としてiteratorのようなものを表現する場合、 Ruby(のeachメソッド)みたいにクロージャをメソッドに渡す形でサンプルを書いてみたのですが、 もっとうまいやり方がありますか？ あと、C#のforeachやJava5の拡張forのようなものを実装する予定はありますか？ function Array(arr_data) { this = new_object(); this.arr_data = arr_data; this.iterate = closure(c) { for (i = 0; i < this.arr_data.size(); i = i + 1) { c(this.arr_data[i]); } }; return this; } a = {1, 2, 3, 4, 5, 6, 7, 8}; c1 = closure(i) { print("" + i + " "); }; a1 = Array(a); a1.iterate(c1);

>>ずいぶん昔、私もマルチスレッドではないのですが、複数のCPUで一つのデバイスに >>アクセスするようなプログラムではまったことがあって、その原因はこんな行でした。 >> x |= y; >なんかモロにマルチスレッドのように思うんですが… (^^; 全く異なる複数のCPU上で動作する2つのプロセスが同じリソースにアクセスする様なものも「マルチスレッド」と言うのかどうか、ちとわからんのですが、 >でも、組み込みなどだとまた事情が違いそうですね。 組み込みの癖に複数のCPUがあるなんていう贅沢な組み込み環境なのですが、複数のCPUがあるくせに排他制御や割り込みをあげるハードウエアがプア...というか、存在しなくて(CPUは汎用品だけど、CPU間をつなぐ部分が社内製だった)、しかたなく同時にアクセスできるメモリにフラグを立てる形で実現していたとかいう状況だったりします。 で、フラグが何種類か必要なので、ビット対応にした(だからORしてる)というなんとも間抜けな設計でスタートしていて。 そもそも通信をガシガシやる部分だったので「ほとんどの情報は共有されてる」ために「複数のスレッドで共有するオブジェクトを限定する」っていうのは意味がなくて「入り口に管理用のオブジェクトを置くとかしてちゃんと管理する」のまさに管理用のオブジェクトが、こんなのだったんですね。あのころは若かったと言い訳して...(^^;)

>ずいぶん昔、私もマルチスレッドではないのですが、複数のCPUで一つのデバイスに >アクセスするようなプログラムではまったことがあって、その原因はこんな行でした。 > > x |= y; なんかモロにマルチスレッドのように思うんですが… (^^; これぐらいミクロなレベルでバグを入れてしまうと、もうたいていはデバッグどころか 再現するのも不可能でどうしようもなくなりますから、Webアプリケーションなんかでは、 ・そもそも複数のスレッドで共有するオブジェクトを限定する。 ・それでも共有するオブジェクトは、入り口に管理用のオブジェクトを 　置くとかしてちゃんと管理する。 ってことだと私は思っています。 でも、組み込みなどだとまた事情が違いそうですね。

>ソースの5行目は、 >this.constructor = closure() { >でなく、 >class.constructor = closure() { >だと思います。 です。すみません間違えました。 あと、「closure(x, y) {」のように引数が必要ですね。 >上のコードでは、new_object()でオブジェクトを作成しないと >「#このへん」の変数を参照できないと思いますので、 >結局インスタンス変数に見えるような気がします。 うーん、私が狙ったのは、複数のpointオブジェクトから共通に参照できる ひとつのクラスフィールド、です。 まあ、create_point_class()を複数回呼んでしまえば複数作れてしまいますが、 それは利用者側の問題にしてよいのではないかと。 あくまで「静的な」(ひとつしかない)データが、グローバル変数以外の方法で必要だ、 ということであれば、Cのstatic指定したローカル変数のようなものを付けると いうのはひとつの手かもしれませんが。

こんにちは。 >「今の(crowbarの)仕様」ということだと、そもそもクラスがないのに、 >クラスメソッド、クラス変数とは何ぞや? という話になるかと思いますが、 確かにその通りですね。クラス「らしきもの」ですね。 >function create_point_class() { > class = new_object(); > # このへん > > this.constructor = closure() { > this = new_object(); > this.x = x; > this.y = y; > > this.print = closure() { > print("(" + this.x + ", " + this.y + ")\n"); > }; > … > return this; > }; > return class; >} > >とか書けばできそうに思うのですが、どうでしょうか(すみません試してないです)。 >「#このへん」で作ったローカル変数や、ローカル変数に代入したクロージャは、 >コンストラクタの中で定義されているメソッドからだけ参照できるはずです。 ソースの5行目は、 this.constructor = closure() { でなく、 class.constructor = closure() { だと思います。 上のコードで名前空間らしきものが表現できているように思いますが、 私の考えていたのは、オブジェクトを作らないでグローバルと名前空間が違う、 でも静的な寿命を持つ変数が使えるかを考えていました。 上のコードでは、new_object()でオブジェクトを作成しないと 「#このへん」の変数を参照できないと思いますので、 結局インスタンス変数に見えるような気がします。 >私としては、クラス変数やクラスメソッドというものに、わざわざ言語仕様で >対応するだけの価値を感じていません。 >crowbarにはそもそもクラスがないですが、クラスベースのOO言語を作るとしても、 >クラス変数やクラスメソッドはつけず、グローバル変数のようなものにして、 >名前空間を選択的に開示できるような形にすると思います。 たぶんその辺は言語の特徴になってくると思いますので、クラス変数らしきものを どう表現するのか(あるいはしないのか)は難しいかもしれません。 ただ、Javaとかに慣れているとクラス変数はストレートで分かりやすい気がします。

>◎getとsetが分かれていたり… ～中略～ >ふたつのスレッドA, Bが以下のようにxをインクリメントしようとすると、 > x = p.getX(); // スレッドA ←(1) > x = p.getX(); // スレッドB ←(2) > p.setX(x+1); // スレッドA ←(3) > p.setX(x+1); // スレッドB ←(4) ～中略～ >結局、マルチスレッドで正しくプログラムを動かしたいのであれば、 >Pointのような低レベルなクラスで、個々のメソッドに機械的にsynchronizedを >つけても意味がなく、アプリケーションのレベルで対処しなければなりません。 ～中略～ >あんまり理解されてないことなんですかねえ。 こういうのって、マルチスレッド プログラムで再現性の低いバグで悩んだ経験がないとなかなか思いつかないことかもしれませんね。 ずいぶん昔、私もマルチスレッドではないのですが、複数のCPUで一つのデバイスにアクセスするようなプログラムではまったことがあって、その原因はこんな行でした。 x |= y; xの値をCPUレジスタに読み出して、その値にyの値を加えたものを、xに書き込む...前に別のCPUからxに書き込みがあったんです。 このときは高い確率で再現できるプログラムが偶然用意できたのが幸いでしたが。

>「プログラミング言語を作る」をいつも楽しみにしています。 ありがとうございます。 >クラスメソッドとクラス変数は、今の仕様で実現は可能ですか？ 「今の(crowbarの)仕様」ということだと、そもそもクラスがないのに、 クラスメソッド、クラス変数とは何ぞや? という話になるかと思いますが、 現在、create_point()のような関数を作ることでクラスじみたことを 実現しているように、何とか似たことを実現したい、ということであれば、 「クラスもまたオブジェクトである」 「インスタンスは、クラスのconstructorメソッドで生成する」 ということにして、 function create_point_class() { class = new_object(); # このへん this.constructor = closure() { this = new_object(); this.x = x; this.y = y; this.print = closure() { print("(" + this.x + ", " + this.y + ")\n"); }; … return this; }; return class; } とか書けばできそうに思うのですが、どうでしょうか(すみません試してないです)。 「#このへん」で作ったローカル変数や、ローカル変数に代入したクロージャは、 コンストラクタの中で定義されているメソッドからだけ参照できるはずです。 >また、実現不可能な場合、追加の仕様としてはどういうのを考えていますか？ >グローバル変数で代用するのはちょっと…と思います。 私としては、クラス変数やクラスメソッドというものに、わざわざ言語仕様で 対応するだけの価値を感じていません。 crowbarにはそもそもクラスがないですが、クラスベースのOO言語を作るとしても、 クラス変数やクラスメソッドはつけず、グローバル変数のようなものにして、 名前空間を選択的に開示できるような形にすると思います。

こんにちは。 「プログラミング言語を作る」をいつも楽しみにしています。 個人的には、オブジェクトとクロージャ辺りからだんだん面白くなってきたと思います。 まだ機能的に色々追加していくのだと思いますが、クラスメソッドとクラス変数は、今の仕様で実現は可能ですか？色々考えたのですが、思いつきません。 また、実現不可能な場合、追加の仕様としてはどういうのを考えていますか？ グローバル変数で代用するのはちょっと…と思います。

>こんにちは。はじめまして。 はじめまして。書き込みありがとうございます。 >もしよろしければ、可能性として起こりうる"変なこと"をご教示願えませんでしょうか？ >getとsetが分かれていたり、setのXとYが分かれていたりしていたのでは、 というのが一応ヒントというか根拠のつもりです。 簡単な方から。 ◎setのXとYが分かれていたりしていたのでは… 現在(100, 100)であるPointを、(200, 200)に移動させたかったとしましょう。 そのために、 p.setX(200); p.setY(200); と書くと、setX()してからsetY()するまでの間、一時的に(200, 100)という状態になり、 この状態が他スレッドから見えてしまいます。 ◎getとsetが分かれていたり… ふたつのスレッドA, Bが以下のようにxをインクリメントしようとすると、 x = p.getX(); // スレッドA ←(1) x = p.getX(); // スレッドB ←(2) p.setX(x+1); // スレッドA ←(3) p.setX(x+1); // スレッドB ←(4) (3)でスレッドAがインクリメントした結果が(4)で上書きされてしまい、 ふたつのスレッドがひとつずつインクリメントしているはずなのに、 結局xは1しか増えないことになります。 ひとつめの問題は仕様だと言い張ることも可能かもしれませんが、 ふたつめの問題はおそらく致命的でしょう。 結局、マルチスレッドで正しくプログラムを動かしたいのであれば、 Pointのような低レベルなクラスで、個々のメソッドに機械的にsynchronizedを つけても意味がなく、アプリケーションのレベルで対処しなければなりません。 この手の問題は標準のクラスライブラリにもあって、古いコレクションクラス (Vectorなど)は、メソッドごとにちまちまとsynchronizedを付けていますが、 現実問題としてこれは無意味であり、後継のArrayListなどでは外されたわけです。 // ループが回っている間に別スレッドでremove()とかされると例外が発生する size = v.size(); for (int i = 0; i < size; i++) { Object o = v.get(i); } でも今Googleしてみたら、「シングルスレッドでよいときは効率向上のために ArrayListを使い、スレッドセーフにしたければVectorを使うべし」と解説している ページの多いこと… あんまり理解されてないことなんですかねえ。

こんにちは。はじめまして。 楽しく拝読させて頂いております。 「オブジェクト指向再入門/なぜわからなくなってしまうのか？」の中の記述に判らないところがありましたのでご質問させてください。 ～引用ここから～ ところで「Javaの格言」という本では、 Pointのx, yをprivateにするメリットとして、マルチスレッド時の排他制御を挙げています。しかし、getX(), getY(), setX(), setY() を作ってそれぞれをsynchronizedにしたところで、この仕様ではマルチスレッドには対応できません。ちょっと考えてみればわかるように、 getとsetが分かれていたり、setのXとYが分かれていたりしていたのでは、複数のスレッドで実行されたら結局変なことが起きます。 ～引用ここまで～ synchronizedメソッドをコールすると、コールしたスレッドがインスタンス(メソッドのレシーバ)のモニタを取得するために、別スレッドが当該インスタンスのsynchronizedメソッドを呼び出しても安全(スレッドセーフ)であると認識しております。 上記の引用のなかの"変なこと"というのが、私の認識であるところの"スレッドセーフ"でないことを指すのか、または別のことを指すのか判りませんでした。 もしよろしければ、可能性として起こりうる"変なこと"をご教示願えませんでしょうか？ よろしくお願いします。

はじめまして。 >前橋さんのリンク先にある >「中野康明の雑学ペ－ジ(2003/11/30追加)」 >は下記に移動しました。 わざわざご連絡いただきありがとうございます。修正しておきました。

前橋さんのリンク先にある 「中野康明の雑学ペ－ジ(2003/11/30追加)」 は下記に移動しました。 http://www001.upp.so-net.ne.jp/yasuaki/misc.htm その関連で引かれている「チョン」についての雑文のページも移動しました。 http://www001.upp.so-net.ne.jp/yasuaki/misc/lang/lang35.htm 修正戴ければ幸いです。

>これは、「Linkable」の定義に対する修正ですから、ひとつめの方です。 >Linkableは、その前のページのFig.5-15におけるLinkableShapeに対応する型で、 >ポインタを3つ持ち、双方向連結リストを構成します。 > >こちらは、双方向連結リストの先頭と末尾を保持することで、「リスト全体」を >表現する構造体です。 > これらが間違っていないのであれば、 私の勉強不足だとわかりました。 じっくりと勉強していきます。 >int a; >int *p; >p = &a; > >とあったとき、pに1加算するだけなら問題ないが、2加算すると規格違反である、 >という意味です。 ># ただし、たいていの処理系では、2だろうと3だろうと、加算するだけなら動きます。 わかりました。 ありがとうございました。

>>まず、「クラスのポインタ」が何を指すのか不明です。 >「Board* board = new Board()」の様にnewしたポインタ変数の事です。 クラスとインスタンスは別物なので、その違いは強く意識したほうがよいかと。 new Board()ではBoardクラスのインスタンスが生成(new)され、 「new Board()」という式はそのインスタンスへのポインタを返します。 上の「board」にはそれが代入されるわけですから、boardは、 インスタンスへのポインタであって、「クラスのポインタ」ではありません。 また、「newしたポインタ変数の事です」とのことですが、上の例にある ポインタ型の変数といえば「board」ですが、ここではboardがnewされている わけではありません。 細かいことを言うようですが、 「わかっている人が、厳密さを求められない局面で、適当に省略しながら話す」 のと、 「本当にわかってない」 のでは大違いですので一応念のため。 >僕の憶測ですが、Javaのリバーシゲームでthisを多用していますが、 >これは特に使用しなくていいんですね。 はい。インスタンスフィールドとローカル変数の区別をつけるため、 私はthis.をつけるようにしている、というだけです。 言語がthisを強制していてくれれば、こういう事故も起きないんですけどねえ。 http://d.hatena.ne.jp/higepon/20050329

>こんにちは、はじめまして。 はじめまして。ミスが多く申し訳ありません。 >「 >p.285 >誤 > > typedef struct Linkable_tag { > void *object; > Shape *prev; > Shape *next; > } Linkable; > >正 > > typedef struct Linkable_tag { > void *object; > struct Linkable_tag *prev; > struct Linkable_tag *next; > } Linkable; >」 >とあります。 >しかし、P285にあるプログラムは２つあるのですが、 これは、「Linkable」の定義に対する修正ですから、ひとつめの方です。 Linkableは、その前のページのFig.5-15におけるLinkableShapeに対応する型で、 ポインタを3つ持ち、双方向連結リストを構成します。 >となっていて、２つめは >「 >typedef struct{ > Linkable *head; /* 先頭の要素 */ > Linkable *tail; /* 末尾の要素 */ >}LinkedList; >」 こちらは、双方向連結リストの先頭と末尾を保持することで、「リスト全体」を 表現する構造体です。 >それと、P43のところで、正誤表では、 >「 >と書いてありますので、ふたつ超えた所に向けない限り問題なさそうです。 >」 >となっていますが、本では、 >「 >と書いてありますので、２以上加算しないかぎり問題なさそうですが。 >」 >とあります。 同じ意味のつもりで書いていますが… int a; int *p; p = &a; とあったとき、pに1加算するだけなら問題ないが、2加算すると規格違反である、 という意味です。 # ただし、たいていの処理系では、2だろうと3だろうと、加算するだけなら動きます。

>「静的コール」というのが何を指しているのかわかりませんが、 「Board::move(～)」の様な呼び出しの事を指しています。名称は間違ってるかも知れません。 >まず、「クラスのポインタ」が何を指すのか不明です。 「Board* board = new Board()」の様にnewしたポインタ変数の事です。 「オブジェクトに仕事をさせる、ということ」を読ませて貰って、上記の様に一々ポインタ変数をnewせずにパラメータにポインタ変数を持たせて引き継がせればいい事が分かりました。 僕の憶測ですが、Javaのリバーシゲームでthisを多用していますが、これは特に使用しなくていいんですね。 現在、はさみ将棋プログラムに修正をかけていますが、まだまだメモリリークが起きている状態です。 指摘された修正をほぼ全て行なってメモリリークが起きるかどうかテストしたいと思います。 ご回答の程ありがとうございました。

こんにちは、はじめまして。 早速ですが、「C言語 ポインタ 完全制覇」を購入して 読んでいるのですが、正誤表を見てみると、 「 p.285 誤 typedef struct Linkable_tag { void *object; Shape *prev; Shape *next; } Linkable; 正 typedef struct Linkable_tag { void *object; struct Linkable_tag *prev; struct Linkable_tag *next; } Linkable; 」 とあります。 しかし、P285にあるプログラムは２つあるのですが、 １つめは、 「 typedef struct{ void *object; Shape *prev; Shape *next; }Linkable; 」 となっていて、２つめは 「 typedef struct{ Linkable *head; /* 先頭の要素 */ Linkable *tail; /* 末尾の要素 */ }LinkedList; 」 となっていてどこをどのように訂正すればいいかわかりません。 それと、P43のところで、正誤表では、 「 と書いてありますので、ふたつ超えた所に向けない限り問題なさそうです。 」 となっていますが、本では、 「 と書いてありますので、２以上加算しないかぎり問題なさそうですが。 」 とあります。 どちらが正しいのでしょうか？ すべてをみたわけではありませんので、ほかはどうなっているのかわかりません。 出版は平成１５年７月１日　初版　第７刷発行です。

>VC++はメソッドの静的コールをしようとすると怒られるので、 「静的コール」というのが何を指しているのかわかりませんが、 staticメソッド以外は、インスタンスがなければ呼び出すことはできないでしょう (Javaと同じです)。 >メソッドを呼び出す場合、そのクラスのポインタをnewしてますが、 >それがマズイ様です。 まず、「クラスのポインタ」が何を指すのか不明です。 Boardなりのクラスの「インスタンスのポインタ」の意味であるとすれば、 「メソッドを呼び出す場合、そのクラスのポインタをnewしてます」 というのは、私がこっちのページに書いた新人君の失敗と同じ失敗を しているように見えます。 http://kmaebashi.com/programmer/object/shigoto.html | そして、とある新人君は、(AWTの)Canvasに線を引きたい、という時、 | その場でCanvasをnewしてそのCanvasに線を引いてくれました。 | もちろんそのCanvasと、実際に画面に貼られているCanvasは違う | Canvasですから、画面に線は表示されず、彼は悩んでいたわけです。 | また別の新人君は、描画した図形を保持する「ShapeCollection」という | クラスについて、画面の再描画のため必要になったところでいきなりnewして | くれました。当然、新たに作り出されたShapeCollectionは空っぽなので、 | 画面には何も描画されませんでしたけど ※4。 手前味噌ですが、一度通して読んでみてはいかがでしょうか。 >クラスのポインタ変数を使用せずにこのプログラムを構築することは >出来るのでしょうか。 インスタンスへのポインタを使わずにこのプログラムを構築することは、 対戦用のBoardを静的に1個だけ持つようにして、先読み用のBoardを スタックに確保するようにすれば、不可能ではないでしょう。 でも、「対戦用のBoardを静的に1個だけ持つ」というのではせっかくの OO言語のメリットを捨てることになるので、あまりお勧めはしません。

指摘のあったcppをインクルードするのをやめ、プレイヤーもBoardのポインタを持つ様にしたのですが、メモリリークを起こしてしまってます。 VC++はメソッドの静的コールをしようとすると怒られるので、メソッドを呼び出す場合、そのクラスのポインタをnewしてますが、それがマズイ様です。 クラスのポインタ変数を使用せずにこのプログラムを構築することは出来るのでしょうか。 ご回答の程よろしくお願いします。

はじめまして。 >「配列とポインタの完全制覇」のページを見ていたところ、 >“技術評論社さんによる書籍案内はこちら”のリンク先が移動しているようです。 ご指摘ありがとうございます。修正しました。 センス・オブ・プログラミング以外すべて貼り替えですね。 # ASPをPHPに切り替えたのか…

「配列とポインタの完全制覇」のページを見ていたところ、 “技術評論社さんによる書籍案内はこちら”のリンク先が移動しているようです。 http://www2.gihyo.co.jp/books/bookinfo.asp?ID=4-7741-1142-2 だったのが、 http://www.gihyo.co.jp/books/syoseki.php/4-7741-1142-2 に、移動したようですね、、、

>>ところで、「配列とガベージコレクタ」の「配列は参照型である」の説明で、 >>コードと図の配列の添字の値が食い違っているみたいです。 修正しました。 ついで…と言ってはなんですが、[329]で教えていただいた「ほげほっぽ」の件を、 「ほげを考えるページ」に追記しました。すっかり忘れていまして、対応が 遅くなりまして申し訳ありません (_o_)

>オレンジニュースというサイトで、crowbarが紹介されていました。 > >http://secure.ddo.jp/~kaku/tdiary/20050426.html 情報ありがとうございます…が、さっきから試してますが、あっちのサーバが コケてるようですね。 >ところで、「配列とガベージコレクタ」の「配列は参照型である」の説明で、 >コードと図の配列の添字の値が食い違っているみたいです。 ご指摘ありがとうございます。 すみません、ちょっと今すぐは直せないので、連休に入ったら修正しておきます。 # 私も「1から数える」呪縛から開放されてないようです。

オレンジニュースというサイトで、crowbarが紹介されていました。 http://secure.ddo.jp/~kaku/tdiary/20050426.html > ■ 前橋和弥氏、新プログラミング言語「crowbar」を作る(現在ver.0.2) > http://kmaebashi.com/programmer/devlang/index.html ところで、「配列とガベージコレクタ」の「配列は参照型である」の説明で、 コードと図の配列の添字の値が食い違っているみたいです。

>C++ は「必ずしもオブジェクト指向である必然が無い言語」ですからね。 >better C として使っても一向に構わないわけで。 > >template なんかも「オブジェクト指向」とはまったく反対方向からの >generic programming を目指す代物ですし。 > >std::vector<char> v; >std::copy(std::istreambuf_iterator(is), std::istreambuf_iterator(), std::back_inserter(v)); >とかなんとか。 >ジェネリック関数＋ジェネリック部品、ってのはオブジェクト指向とは言いがたいし。 なるほど。あまり意識してなかったのですが、genericの機能は、オブジェクト指向とはあまり関係ないのかもしれませんね。 上記のリストのデータをトラバースするのにiteratorを使うのは、少なからずオブジェクト指向的であると思いますが、「genericの機能の部分」がオブジェクト指向であるとは言えないかもしれません。 でも、オブジェクト指向と連携すると強力な機能だと思います。 774RRさんのご指摘のように、オブジェクト指向を意識しない使い方でも、C++はかなり使えそうですね。 逆に私は、例えばCを使うときにはモジュール化を意識して、オブジェクト指向風なプログラミングをしています。

C++ は「必ずしもオブジェクト指向である必然が無い言語」ですからね。 better C として使っても一向に構わないわけで。 template なんかも「オブジェクト指向」とはまったく反対方向からの generic programming を目指す代物ですし。 std::vector<char> v; std::copy(std::istreambuf_iterator(is), std::istreambuf_iterator(), std::back_inserter(v)); とかなんとか。 ジェネリック関数＋ジェネリック部品、ってのはオブジェクト指向とは言いがたいし。

>Ｃ言語上級ＰＧですが、ＶＣ＋＋を使い始め、オブジェクト指向のさわりを勉強して >いる最中ですが、今までなかなか理解できませんでしたが、こちらのホームページを >穴が開くほど見つめて（＝読んで）みたところ、一行一行、激しく首を振りながら、 >やっと理解し始めました。同時に、今まで読んでいた入門書、解説書等に腹が立って >きました。ただし、もう、それらの入門書、解説書を読んでもすらすらと読めるよう >になると思います。ありがとうございます。 C++関連の書籍では、オブジェクト指向の考え方を分かりやすく解説した本があまりありません。 どちらかと言うと、文法や実装面での解説の本が多いような気がします。 余計なお世話かもしれませんが、オブジェクト指向の基本を勉強したいのであれば、C++でもJavaでもオブジェクト指向の知識は同じなので、(ぱ)さんの書かれた、「Java謎+落とし穴徹底解明」をお勧めします。この本は、実装は確かにJava言語ですが、オブジェクト指向の基本的な考え方を扱っていると思います。 例えば、「Effective C++」では、オブジェクト指向を体系的に解説していないため、オブジェクト指向の基本を身につけるのは難しいかもしれません。 GoF本でも同様だと思います。 ちなみに、匿名さんが読まれた入門書、解説書は何というタイトルの本ですか？

Ｃ言語上級ＰＧですが、ＶＣ＋＋を使い始め、オブジェクト指向のさわりを勉強して いる最中ですが、今までなかなか理解できませんでしたが、こちらのホームページを 穴が開くほど見つめて（＝読んで）みたところ、一行一行、激しく首を振りながら、 やっと理解し始めました。同時に、今まで読んでいた入門書、解説書等に腹が立って きました。ただし、もう、それらの入門書、解説書を読んでもすらすらと読めるよう になると思います。ありがとうございます。

>ｈｈ なんでしょう。これ。 テスト書き込みならテスト用掲示板のほうにお願いします。 http://kmaebashi.com/bbs/list.php?boardid=testbbs

ｈｈ