OOとゲームプログラミング

**名無しさん＠お腹いっぱい。** · 01/11/07 23:55

OOをどのように用いれば美しくゲームプログラミングを
行うことが出来るのか語り合うスレです。

2 · 01/11/07 23:56

**名無しさん＠お腹いっぱい。** · 01/11/07 23:57

掃除機、OOは素人にはお勧めできない。

**名無しさん＠お腹いっぱい。** · 01/11/07 23:59

むう、正直、こっちを使って欲しひ。
http://game.2ch.net/test/read.cgi/gamedev/1005040025/

**名無しさん＠お腹いっぱい。** · 01/11/08 00:10

まずは、データ構造とモジュールについて、しっかり勉強して下さい。
でなければ挫折します。

**名無しさん＠お腹いっぱい。** · 01/11/08 10:17

PS2のコンパイラ、クソすぎて複雑なクラス構造理解してくれないYO!

**名無しさん＠お腹いっぱい。** · 01/11/08 11:57

YO! とか使う奴多いよね。開発者に。いまだに

**名無しさん＠お腹いっぱい。** · 01/11/08 12:27

>>6
PS2ってgccでないの？

>>7
そういうのを突っ込むのは板違い

**名無しさん＠お腹いっぱい。** · 01/11/08 13:35

＞6
OO的思考はイイんだけど
いざ実装するときにC++とかだと
コンパイラ腐っててできねえ！とかあるわよねえ。
コンパイラ特有の変な制限あったり。
マニュアル見たらテンプレートクラスはファイル1つにブチ込めゴルア！
・・・だそうな。鬱死

**名無しさん＠お腹いっぱい。** · 01/11/08 16:53

そうだね。テンプレートはOOとはあまり関係ないにしてもだ(コンパイルタイムポリモーフィズムって言われることもあるけど)。

**アマプログラマ** · 01/11/09 04:02

ループを回して、その中でゲームの状態により
switch文とかで分けて処理するとかしたらなーんかいつもながーい
ループが出来上がっちゃうんですが、
みなさんどうされてるんですか？

**名無しさん＠お腹いっぱい。** · 01/11/09 04:08

>>11
この辺とか
ttp://www.hh.iij4u.or.jp/~peto/Games/games_top.html

タスクシステムって、原始的なOOかも。

**名無しさん＠お腹いっぱい。** · 01/11/09 06:22

>>11
状態をオブジェクトにする。
そうすると、ゲームのメインループは有限状態マシンとしてモデル化できて
ゲームに依存しないフレームワークを作ることができる。

有限状態マシンのモデル化は、ちょっとしたオブジェクト指向入門書になら
書いてあるでしょう。

**名無しさん＠お腹いっぱい。** · 01/11/09 09:06

>>13 に加えて、デザインパターンのStateパターンとか
その辺を参考にするといいかもです、はい。

**名無しさん＠お腹いっぱい。** · 01/11/09 19:35

今までは 12 のサイトに書かれていた処理が多かった。
アマプログラマと名乗っているなら似非タスク処理を作るのが良いと思う。

**名無しさん＠お腹いっぱい。** · 01/11/09 20:52

OOを使えばタスクは使わなくなるの？

**アマプログラマ** · 01/11/09 21:51

ふーむ、なるほど。>>12-15ありがとです。
ぜんっぜん思いも寄らなかったけど
>>15読むと時代の流れは先に行ってるようですが、
どないなんでしょう？

**名無しさん＠お腹いっぱい。** · 01/11/09 21:53

まあ、最初は古典的？っていうか原始的？っていうか
自分なりに力技な方法でやってもいいんじゃないでしょうか。
あまり考えすぎると、理屈倒れのなんとやらになるかもです。

**名無しさん＠お腹いっぱい。** · 01/11/09 22:05

最近WinSDKプログラミングをはじめたんですが、
WndProcでコールバックされた後やるswich文をMessageHandle用クラスに
持たせて多態化させて、デザパタのStateパターンっぽくやろうと試みてます。
Menu選択とか、ダイアログとかのMessageHandle関係全般につかえるよう
ある程度汎用的に・・・と構想してます。

とりあえずの目標はシンプルである程度汎用的なフレームワークを作って、
DirectXやOpenGLをいじくろうと思っているんですが・・・・

こういうことって、既にみんなやってるモンでしょうか？

**名無しさん＠お腹いっぱい。** · 01/11/10 01:13

>19

やってると思いますよ。
ゲーム作るのなら必須でしょう。

19 · 01/11/10 02:02

いま>>12のリンク先のタスクシステムを見てます。
面白いです。確かに原始的なＯＯＰという感じです。
ＴＣＢを見てるとクラス化したくなってしまいますが、
長年培われてきた（？）型だけに、下手な設計ではＯＯ化は
逆効果になりそうですね。

デザパタではState,Strategy,Flyweightあたりがまず不可欠
でしょうねー。

19 · 01/11/10 02:05

ところで実際のところゲーム開発の現場ってＣとＣ＋＋の比率はどのくらい
なのでしょうか？
C++でやってるのは余裕のある大手くらいってかんじですか？

**名無しさん＠お腹いっぱい。** · 01/11/10 03:17

C++は遅くて使い物にならんと思うが

＿ · 01/11/10 03:21

>>23
マジ？
XboxはVC++がデフォだって聞いたけど。

**名無しさん＠お腹いっぱい。** · 01/11/10 03:24

>>23
こういうことを言う奴はｼｯﾀｶ君

19 · 01/11/10 03:25

てことは>>23は C++でゲーム開発してるって話は見たことも聞いたことも無い？

**名無しさん＠お腹いっぱい。** · 01/11/10 03:26

>>25
そうか？
継承するとパフォーマンスが悲惨なんだが
そんな事はないか？

**名無しさん＠お腹いっぱい。** · 01/11/10 03:29

VTBLのオーバーヘッドなんかもう無視できるっしょ。

**アマグラマ** · 01/11/10 03:33

スターオーシャン2ndストーリーのトライエースのロゴの下に
try-Ace PlayStation Foundation Class Library
とかなんか誇らしげに表示されてるのは見たですが。

**名無しさん＠お腹いっぱい。** · 01/11/10 03:34

そりゃぁXboxはそうかも知れんが、
我がマシンでは数倍違う

19 · 01/11/10 03:49

C++が遅いのではなくて、Classライブラリに問題があるのでは？
私もＯＯやC++崇拝者なわけではないんだけど。
C++がCと比べてオーバヘッドあるのは事実だと思うけど、Cの手法だって
インライン関数だってインラインアセンブラだって使えるわけだし。
深すぎる継承を使わないとかクリティカルなところでは伝統的な手法を
使ってゆけば、使い物にならん、ってことはないいんじゃないかと。

**名無しさん＠お腹いっぱい。** · 01/11/10 03:59

>>27
まさにｼｯﾀｶ君
全然何も分かってないらしいな
プラットフォームとは関係ない

しょうがないから本を一冊薦めといてやる
「C++/C プログラム改善法」
ただしトッパンはもうつぶれてしまった

仕方ないので
「Efficient C++」
で代用
こちらはピアソン・エデュケーションだからまだ
売ってるだろう

**名無しさん＠お腹いっぱい。** · 01/11/10 04:19

そうかプラットフォームとは関係ないのか。
そうだとすればC++は使い物にならないという事だな。

**名無しさん＠お腹いっぱい。** · 01/11/10 04:27

かたくなだな。

**名無しさん＠お腹いっぱい。** · 01/11/10 04:29

>>31
同じ会社の(クラス)ライブラリが
CとC++でそう違うものなのか？

とむ ◆TMwDpCZo · 01/11/10 05:10

なんとなくだけど、Ｃ＋＋のようなＯＯと、ゲームのプログラミングって
相性良くないような気がしています…。
昔はいいと思ったんだけどね…。

＿ · 01/11/10 05:36

つうかCオンリーで組むのも相当キツイと思うけど。
延々とグローバル関数作りまくり・・
STL無いし・・

**名無しさん＠お腹いっぱい。** · 01/11/10 06:46

継承のコストって x86 でいえば
call [v_table+n]
程度じゃない？

どちらかといえば、インスタンスの生成破棄を
無頓着に行うと効率さがるよね。そんなことは
Effecient C++ レベルにでも書いて有るようなことだし。

**名無しさん＠お腹いっぱい。** · 01/11/10 06:56

Ｃ＋＋をＣと比較した場合、クラスの使い方を間違えると、
コード量が約２倍になる。コードの書き方を間違えなければ、
Ｃと等速のコードも書ける。

**名無しさん＠お腹いっぱい。** · 01/11/10 07:12

オブジェクト指向が本領発揮するのってやっぱ共同開発において、でしょ
一人でシコシコ作る分には無理に移行する必要無しと思われ。

**名無しさん＠お腹いっぱい。** · 01/11/10 09:20

もうOO抜きで組めない俺は就職不可能ですか？（´д｀；）

**名無しさん＠お腹いっぱい。** · 01/11/10 09:49

>>41
ＯＯを完全にマスターしているか、必要以上に使わないなら、
大丈夫かと。中途半端に使うと非効率なんで。

**名無しさん＠お腹いっぱい。** · 01/11/10 11:20

>>36
なんとなくって書いてるところにつっこむのはｱﾚだけど、
どのへんが相性よくないと思ってる?

**名無しさん＠お腹いっぱい。** · 01/11/10 12:11

>>42
オレはむしろＯＯは中途半端がいいと思う。
業務アプリみたいに、完璧なＯＯＰではやはり速度的に厳しいんじゃないか？
ＯＯは中途半端にいいとこだけ使って、古いやり方をラッピング＋部品化ってのが
いいじゃないか。
効果的にやるのにＯＯの理解は中途半端じゃ困るが。

**名無しさん＠お腹いっぱい。** · 01/11/10 12:15

C、C++、さらにObjective C。
最後のはなんじゃい、ってのはナシね。アポーに言ってくれ

とむ ◆TMwDpCZo · 01/11/10 12:47

>>43
難しいなあ…。本当に感覚的な問題なんだけども…。

私は、ＯＯＰは何かを分散的に処理するのに向いているような気が
している。分散的ってのは、例えばＷｉｎｄｏｗｓのように、多数のタスク
を同時に動かしたりするようなものね。
で、ゲームもまさにそういう分散的なアプリケーションで、確かにそう
いう面ではＯＯＰと良く親和する部分もあると思います。でも、ゲーム
の場合突如として様々なタスクを一元的に管理する（つまり分散的の
逆）必要が出てくる場合があります。このような時、Ｃのような単純な
言語に比べてちょっとめんどくさいような気がするのですよ。ほんとに
なんとなくなんだけど。

ま、Ｃ＋＋は言語仕様上ＯＯＰというスタイルが可能になっているだけ
で、Ｃと全く同じスタイルで組む事は出来ますし、逆にＣでもある程度
まではオブジェクト指向なスタイルで組む事も可能は可能ですから、
要は組み方の問題なんですけどね。

単に私の腕がヘボだからそう思うのかも知れません。クラスのスコー
プを考えて、何をどのファイルに入れるかで死ぬほど悩みますから（笑）。
Ｃの時はここまで悩まなかったのに…って。

**名無しさん＠お腹いっぱい。** · 01/11/10 13:19

速度に関して経験がないので分かりませんが、
正直、私もＣでゴーリゴリやっていた（今でもそう）んで、
ＯＯ的設計に馴染めない自分ってのが居る（笑）
ＯＯに限らず、場合によっては中身が見えないハコって
不安でしょうがない（笑）

**名無しさん＠お腹いっぱい。** · 01/11/10 13:28

>>46
＞でも、ゲーム
＞の場合突如として様々なタスクを一元的に管理する（つまり分散的の
＞逆）必要が出てくる場合があります。
いや、俺は逆にこの辺のことをスマートにできるからOOPLがいいと思ってるんだが。
タスクって要するに抽象クラスなわけで、そういうことをするのに言語の支援が受け
られるなら、そっちのほうがいいと思うし。
まぁ、もちろん、OOは概念なんだから、実装は一番やりやすいのでやればいいんだけどね。
(Cでも、ゲーム作ってるとOOに近くならない？

＞クラスのスコー
＞プを考えて、何をどのファイルに入れるかで死ぬほど悩みますから（笑）。
＞Ｃの時はここまで悩まなかったのに…って。
これは激しく同意。
宣言の順序とか考えなきゃならないときもあって激しく萎える。
C++はこれだから…。

**名無しさん＠お腹いっぱい。** · 01/11/10 13:35

>>47
中身が見えないのはＯＯとは関係ないなぁ。
C++だってソース公開すればブラックボックスじゃないし、
システムが複雑になってくるとクラス図にしやすい分C++の方がよさげ。

とむ ◆TMwDpCZo · 01/11/10 13:37

うーん、恐らく私が言っているめんどくささというのは、基本的に私が
まだＣ等の非オブジェクト志向言語での制作スタイルから脱しきれて
いないからでしょう。これらの言語を何と呼ぶのかな？　良くわからな
いけど、とりあえず私は「処理志向」なんだよね。

本来、ＯＯＰというのは、オブジェクトが先にあって、それが動作すべき
処理が従になるのが正しいのだと思います。
しかし、私は頭が古いから、実現したい処理の方ばかりに考えが行って
しまうのですね。で、例えば今動作しているオブジェクト（ここで言うオブ
ジェクトは、ゲームにおけるオブジェクトね）全てに影響する処理、など
というものを考えた時に、処理が主で、クラスが従という考え方をしてし
まうのです。ある処理のためにクラスを使おう、などと思ってしまうと、
処理がプログラム全体のあちこちに散らばっていると、問題とするクラス
をどこにインクルードするかというスコープの問題で頭を抱えてしまう
のです…。

ああ、なんか自分で書いてて良くわからなくなってしまった（笑）。
ヘボコテハンの独り言だと思って下され。

とむ ◆TMwDpCZo · 01/11/10 13:44

中身が見えない、というのは私も感じるよ。

Ｃで遊んでた時は、書いたコードが、アセンブラで言うところのどんな
コードに直されるか、うっすら予測しながら書いてたよ。もちろん完璧
じゃないけどね。大体どう書けばどういうループが組まれるか、とかそん
な感じでなんとなーく考えながらコードを組んでた。提供されるライブラ
リも、何がどう処理されるかとか半分くらい予測つくしね。

でもＣ＋＋の場合、パッと見で「現実にはどういう処理がなされるか」と
いうのが分かりづらいんだよね。パッと見っつーか、良く見てもさっぱり
わからない。あるコードを書いた時、どこをどう参照してどういうコード
にコンパイルされるのか、ほとんど予測つかない。
「別にアセンブラのコードを予測しなくていいよ」というのが正解なんで
しょうが、例えばハードにちょっと近い処理をしたい時に、書かれるコード
の応答性がどうかとか、メモリ管理がクリティカルになる可能性があるの
かどうか、ワイルドな入力に対して堅牢なのかどうかとか、予測つかない
と不安なんだよね…。古い人だから（笑）。

**名無しさん＠お腹いっぱい。** · 01/11/10 13:45

>>50
はは。
俺も、まだメインループ等全体にかかわることは、OOの外だよ。
どこまでをOOにするのかは意見の分かれる処なのかもしれん。
コリジョンの処理とかどこでやろう？とか、いまだに悩むよ。

**名無しさん＠お腹いっぱい。** · 01/11/10 13:50

>>50
たぶんそれはオブジェクト指向の「すべての対象はオブジェクトです」みたいな
理想論を見てひいてしまってる感じじゃない？
そういう理想論は結局理想であって、ＯＯＰでやっても「全てに影響する」なん
てのは「処理ルーチンをクラス化して順番に解決する」という結局本質的には
>>50のやり方と大差ないものだったりするよ。

とむ ◆TMwDpCZo · 01/11/10 13:53

>>52
>>53

そうだね、現実的に考えれば、そういった広範囲に及ぶ処理はＯＯ
の外に追い出すのが普通だね。

でも私は理想主義者なのかな？（笑）　例えば設計時に、色んな
物を美しくクラス化して、完全なヘッダを設計したりするでしょ。
けど、結局上記のような問題にぶち当たり、仕方なくそれらのクラス
を呼び出す関数を作り、広範囲な処理時にはその関数を更に呼び
出すような仕掛けにしてしまい、「これじゃＣ＋＋の意味ないじゃん！」
と机を叩くわけです（笑）。

**名無しさん＠お腹いっぱい。** · 01/11/10 14:27

>>53
「すべてがオブジェクト」ってのはOOPL自身の設計の話なので、
(しかも言語の効率とか、複雑性とかの話なので)ちょっとちがうかも。
>>54
「すべてに影響する」ってのを実現するにはVisitorパターンを使うわけだけども、
あれは、諸刃の剣だからあぁ。
どっちにしろ、「処理」だってオブジェクトなわけで、そのように設計するかしないかは
あとは慣れだろうな。

**名無しさん＠お腹いっぱい。** · 01/11/10 15:40

C++が遅いって言っている人がいるよー。
そら、Cよりもオーバーヘッドがあるかもしれないけど、そんなに問題にならんでしょうに。
もしなるとしたら、それは実装に問題ありと思うが。

それに、無理して全部C++で書く必要もないでしょう。
最下位レベルだけアセンブラでかけばいいのでないのか。

とむ ◆TMwDpCZo · 01/11/10 15:58

…その書き込みを読んだだけでも、「Ｃ＋＋は遅い」という事自体は
間違ってない気がするのですが…。

**がばろん＠Ｍたんちゅきちゅき** · 01/11/10 16:02

>>50 とむたん。
たぶんCなどの言語の総称は「構造化プログラミング言語」。

C++が、どんなマシン語のコードに変換されるかは、
いちどCでオブジェクト指向的なプログラムを組んでみると、
理解しやすいんじゃないでしょうか。

たしかプログラム板のどこかのスレに、そういう話題があったとおもいます。
virtual function tableとかで検索かければ見つかるかも。

あとオブジェクト指向の内部よりな話なら下の本が、おすすめ。
「ゲーム&&オブジェクト指向プログラミング」塚越一雄

>>27たん。
継承より問題は多態性じゃない？
それにしたって考慮するほどのものじゃないけれど。

// スレと関係ないけど、いま名前をいれて書き込んだら
// 「ＥＲＲＯＲ：名前いれてちょ。」って言われたよ。(TT

とむ ◆TMwDpCZo · 01/11/10 16:08

>>58
>たぶんCなどの言語の総称は「構造化プログラミング言語」。

あ、いや、「オブジェクト志向」に対する言葉として何か適当な言葉が
あるのかな、と。「構造化～」は対義語というより、C++の土台になって
る概念でしょう。

**名無しさん＠お腹いっぱい。** · 01/11/10 16:09

>>51
> でもＣ＋＋の場合、パッと見で「現実にはどういう処理がなされるか」
> というのが分かりづらいんだよね。

具体例を挙げてみてください。
分かりづらい部分が想像できないんです。

とむ ◆TMwDpCZo · 01/11/10 16:14

>>60
いや、私は頭が悪いので、ちょっといくつかのクラスを継承してると
「？」になるよ。もう中で何が行われてるかわかんない（笑）。

いや、分かる人も多いとは思うんだけどね。

**名無しさん＠お腹いっぱい。** · 01/11/10 16:15

>>60
例外処理とRTTI

**名無しさん＠お腹いっぱい。** · 01/11/10 16:18

friendでみんな友達（鬱

**名無しさん＠お腹いっぱい。** · 01/11/10 16:26

多重継承で（以下略

**名無しさん＠お腹いっぱい。** · 01/11/10 16:28

>>61
それはソースだけ見てるから。
クラス図を横に置いておけば吉。

47 · 01/11/10 16:29

47だけど、アタシもとむさんと同じで、想像できない方のタイプ。
ＯＯって、メモリ上がどのように書き換えられつつ走っているのか
想像しにくい。
なんで？とかどこが？と言われても困る（笑）
一度抽象化された、オブジェクトの意味合い的なイメージでは
もちろん流れが掴めるけど、その具体的な処理の中身の話。
とむさんも同じではないかしら？

だからどっちがどうした、っていう話ではないので誤解なきよう。

60 · 01/11/10 16:31

>>61
>ちょっといくつかのクラスを継承してると
>「？」になるよ。もう中で何が行われてるかわかんない（笑）。

継承したことによって、どのメソッドが呼ばれているか
ぱっと見わからないと、そうおっしゃる
その分かりづらさは、C++だからってわけじゃないですね

#include <stdio.h>
void test0() {printf("0\n");}
void test1() {printf("1\n");}
int main() {
struct {void (*method0)(); void (*method1)();} T;
T.method0 = test1;
T.method1 = test0;
(T.method0)();
(T.method1)();
return 0;
}

こういうことでしょ？

とむ ◆TMwDpCZo · 01/11/10 16:36

いや、パッと見でわからないというのは、処理の流れ自体ではなくて
（むしろ処理自体はブラックボックス化されて考えなくて良い分わか
りやすいところもある）、「実際にどういう命令になって、ＣＰＵがどういう
動作をしているか」がわかりづらい、って事を言いたいのよ。

例外処理はもちろん分かりづらいけど、それはＣの頃からちょっとわ
かりづらかった（笑）。アセンブラが一番わかりやすい。

**名無しさん＠お腹いっぱい。** · 01/11/10 16:37

>>67
まぁ、そんなに問い詰めることもなかろ。
文化の違いに戸惑ってる程度の話でしょ。
ﾏﾀｰﾘいぐべや。

60 · 01/11/10 16:37

>>62
例外処理はCに比べてC++の方が
むしろ見た目わかりやすくなってると思うけど

**がばろん＠Ｍたんちゅきちゅき** · 01/11/10 16:41

>>59 とむたん。
んじゃ「手続き型プログラミング」
http://yougo.ascii24.com/gh/21/002131.html

60 · 01/11/10 16:43

>>68
> 「実際にどういう命令になって、ＣＰＵがどういう動作をしているか」がわかりづらい

class B : public A;
class C : public A;
B.virtual_method() -> (*(vtbl + 0x50))();
C.virtual_method() -> (*(vtbl + 0x70))();

こんなもんですが

>>69
ﾏﾀｰﾘとこりかたまった頭をほぐしてさしあげましょう

とむ ◆TMwDpCZo · 01/11/10 16:43

>>71
うーん…「手続き型」が「オブジェクト志向」に対立する言葉かどうか
は微妙だなあ…。

とむ ◆TMwDpCZo · 01/11/10 16:45

何か私および47さんと、60さんとの間で考えのズレが起きている
気がしないでもない…。

23 · 01/11/10 16:51

何度やっても遅いって

それはそうと他人の作ったクラスを利用するのは気持ち悪い

60 · 01/11/10 16:53

Cでこう書くとこういう命令になるだろう
C++ではこう書いてあるけどどういう命令になるかわからん

それがどのようなソースコードなのかをすごく知りたいんです。

**名無しさん＠お腹いっぱい。** · 01/11/10 16:56

そうそうCはアセンブラの代わりという感覚で使えたけど
C++はそうは行かないんだよね。
名前が似ているだけのまったく違う言語になってしまっている。
Cの単純さを備えて欲しかった

とむ ◆TMwDpCZo · 01/11/10 17:00

うーん、だからさ…。
Ｃの場合は、ちょっとしたプログラムなら、向こうにアセンブラのソース
が透けて見えるでしょ。ローカルで作った変数なら、きっとこのへんの
レジスタに割り当てられるな、とか。こういう条件式を書くと、こんな形
のループにコンパイルされるな、とか。主にシングルタスクＯＳの場合。
多少関数を呼んだって、順次スタックに積んで下ろして、という感じじゃ
ない。
ところがC++の場合、ちょっといくつかの親クラスを継承したクラスの
場合、「どの時点で実体が確保されるか」つまり、メモリが割り当てられ、
あるいはレジスタが割り当てられたのかとかが良くわからなくなるのよ。

Ｃってのは、ある意味ＣＰＵが順次実行している命令のプロセスをほとん
どそのまま追っている言語だと思う。だから、実際のＣＰＵの動作がわか
る。
ところが、C++ってのは実際に実行される順番に命令を並べているのと
はちょっと違うスタイルのプログラミングを（基本的には）する言語でしょ。
だから向こうに実際のコードが見えない、という事なのよ。

**名無しさん＠お腹いっぱい。** · 01/11/10 17:07

最下位まで気にしなくていいのが良い点なのだと思うが。
ボトルネックになっている部分をインラインアセンブラで書けばいいじゃん。

60 · 01/11/10 17:09

> Ｃの場合は、ちょっとしたプログラムなら、
> 向こうにアセンブラのソースが透けて見えるでしょ。

本当にわかってますか？小一時間問い詰めていいですか？

> メモリが割り当てられ、
> あるいはレジスタが割り当てられたのかとかが良くわからなくなるのよ。

int a; はレジスタに割り当てられてー
char b[25]; はスタックでーとか？
Cでstruct {int a; char b[25];} t;はどう配置されるの？

60 · 01/11/10 17:12

> C++ってのは実際に実行される順番に命令を並べているのと
> はちょっと違うスタイルのプログラミングを（基本的には）する言語でしょ。
> だから向こうに実際のコードが見えない、という事なのよ。

Cでもコンパイラによるリオーダリングはありえると思いますが
それは除いたとして
C++で実際に実行される順番が異なってしまう状態例を
あげてくれると非常にうれしいです。感激しちゃう。

**がばろん＠Ｍたんちゅきちゅき** · 01/11/10 17:12

>>73 とむたん。
うーん>>50で、とむたん自身が言ってた「処理指向」と
手続き型っていうのは、まさに同じものだと、おもうんだけど。

いかなる言語にしても過去の有効な手法は取り入れているわけだから、
C++や、ほかのオブジェクト指向型の言語が、まったく土台に取り入れていないもので、
純粋にオブジェクト指向と対になるパラダイムなんて、ないんじゃない？

ちょうどエージェント指向に
オブジェクト指向の考え方が取り入れられているようなもので。

// 手続き型プログラミングについては、こっちのほうがわかりやすかも。
// http://www.e-words.ne.jp/view.asp?ID=2397

>>75 23たん。
実行のたびにネイティブコードにコンパイルしているJavaよりは、
C++のほうが、はるかにましだよ。(TT

// あ。ただJITやHotSpotなどでネイティブコードにコンパイルされたあとなら
// JavaはC++よりも高速という話はあるけど、ほんとかな。

とむ ◆TMwDpCZo · 01/11/10 17:13

>>80
>本当にわかってますか？小一時間問い詰めていいですか？

　まあ前にも書いたけど、完全に頭でコンパイルできてるわけでは
なくて、なんとなくだってば。小一時間問い詰められたらボロが出るよ。

　あと構造体だけど、それは別にそのまんまメモリに配置されるだけ
では…。構造体の直接読み取りとかやったことない？
　コンパイラによっては間にパディング入れたりするけど…。

とむ ◆TMwDpCZo · 01/11/10 17:15

８１を読むと、やっぱり私と60さんの間で話がきちんと通じてないと
思った…。うーむ。ジェネレーションの差かなあ（笑）。

60 · 01/11/10 17:19

>>83
そこまでわかってればC++でもおんなじだと思うんですよ

メモリだけ考えると
structとclassの違いは virtual method がある場合に
vtblへのポインタが入るかどうかだけなんだから

で逐次実行ってのはCでもC++でもかわらないので
classのコンストラクタが呼ばれるタイミングは
Cでstructを使うのとかわらない
Cにはnewがないけどmallocしたあとコンストラクタが呼ばれるだけ

60 · 01/11/10 17:23

>>85
じゃあじゃあ
> C++ってのは実際に実行される順番に命令を並べているのと
> はちょっと違うスタイルのプログラミング
ってどんなのか聞かせてほしいですー

60 · 01/11/10 17:24

ちゃい >>84 の間違い

とむ ◆TMwDpCZo · 01/11/10 17:24

まあちょっとＰＣの前を離れるんで、色々お答えはできませんが、
多分私の言いたい事をわかってくれた人も何人かはいたようなので、
きっと誰かが代弁してくれるでしょう。すまそ＞60さん。

**名無しさん＠お腹いっぱい。** · 01/11/10 17:31

Cは書いた通りに処理されるけど、
C++ではソースコードでは明示されないポインタのやり取りとか、
プロセスの移行とかがあって気持ち悪い。

60 · 01/11/10 17:37

> C++ではソースコードでは明示されないポインタのやり取りとか、

一番簡単な例はメソッド呼び出しで
インスタンスのポインタが this が行きますね
これは納得

> プロセスの移行とかがあって気持ち悪い。

これはﾅﾝｿﾞ??

**名無しさん＠お腹いっぱい。** · 01/11/10 17:40

コンストラクタとか
オペレーターとか

**名無しさん＠お腹いっぱい。** · 01/11/10 17:41

ボーランドC++のプロパティとかは末期的

**がばろん＠Ｍたんちゅきちゅき** · 01/11/10 17:42

じゃ。まとはずれかもしれないけど代弁してみよう。

>>86 60たん。
とむたんの言う「ちょっと違うスタイルのプログラミング」とは、
たぶんオブジェクトどうしがメッセージをやり取りして物事を処理していく
アクターモデル的プログラミングスタイルのことじゃない？

// おれドキュソだから、そこまで複雑に、ものごと考えたことないけど。

**名無しさん＠お腹いっぱい。** · 01/11/10 17:45

＞Cにはnewがないけどmallocしたあとコンストラクタが呼ばれるだけ
なんか誤解を招きそうだな。
まるで、mallocでインスタンスを作成してもコンストラクタが実行されるみたいだ。
こんな誤解をする人間はここにはいないか…。

外野 · 01/11/10 17:55

結局、どこまでブラックボックスを許容するかで、すれ違っているような
気がする。
「Cでアセンブラソースが透けて見えないと気持ち悪い」って人も、CPUの
内部動作自体は気にしないでしょ？トランジスタ１つ１つの働きとか、実際に
は気にしないし、そこまで考えたらやってられない。
OOの場合、プログラムの抽象化のレベルが上がるので、その分ブラック
ボックスとして扱わないとやってられない敷居が上がって、アセンブラレベル
の動作まで考えたらやってられないので、気にしないのが一番って事に
なるのでは？
（ちょっと例えが極端かも。ま、意味は判るのね？）

**名無しさん＠お腹いっぱい。** · 01/11/10 17:56

http://life.2ch.net/test/read.cgi/psy/991265343/518

60 · 01/11/10 18:00

> まるで、mallocでインスタンスを作成しても
それはインスタンスと言っていいものなのか聞いていいですか

vtblなしのclassなら実害なし？

**名無しさん＠お腹いっぱい。** · 01/11/10 18:12

ブラックボックスのレベルをどこまで許せるかということですな。
アセンブラ上がりの人で、勝手にナニやってるかわからないってC言語嫌がる人だっているわけだし。
俺は、まあオブジェクト指向レベルは許せるかなって感じで。
当然ピンポイントでインラインアセンブラは使うけどさ。

まあ、言語のメタ化が進んできてるっとことなんでしょう。
新しいメタ化の手法が普及し始めたら、OOは許容できた俺でもキモチ悪がるかもしれない。

**名無しさん＠お腹いっぱい。** · 01/11/10 18:26

オブジェクト指向ってのは開発方法論であって
使用する言語は関係ないと思うがどうか。
オブジェクト指向方法論に基づいてアセンブラでコーディングってのは
いまどき特別なことじゃないでしょ。

**がばろん＠Ｍたんちゅきちゅき** · 01/11/10 18:26

>>96たん。
全部たどっていったら下のレスからのリンクで
ウイルスがみつかったよ。
// もしかして全板にリンクはりまわってるの？

Ｊｒ．ファンのみなさんへお願い
http://music.2ch.net/test/read.cgi/jr/994988000/264

**名無しさん＠お腹いっぱい。** · 01/11/10 18:33

モジュールを少しでも勉強した事があるなら、
どの部分をブラックボックス化すればいいか？
なんて事は、そこそこ分かる事なんだが・・・

なんでモジュールやデータ構造を勉強せずに、
ＯＯＰに手を出すかな？

60 · 01/11/10 18:50

>>93

それが
> C++ってのは実際に実行される順番に命令を並べているのと
> はちょっと違うスタイルのプログラミング
なの？

順番に命令をならべてそれがそのとおりに実行されるのは
変わってないと思うんだけど

それともあれか、C++でクラス作ってインスタンス作ると
それが勝手に並列実行されるのか？

とりあえず http://www.njk.co.jp/otg/Study/　を読みなはれ >> 93

＿ · 01/11/10 18:56

みんな中途半端な知識しか持ってないから
こんな中途半端な議論になっちゃうんだよね
意味無し

**名無しさん＠お腹いっぱい。** · 01/11/10 19:01

>>103
そう思うんなら君も中途半端に煽らずにもっと突っ込みをいれなさい

19 · 01/11/10 20:19

>>101
「モジュールの勉強」とは何ですか？
この業界では一般的な用語？

19 · 01/11/10 20:29

>>99
それは解るし正論だけど、だからといってC++でのゲーム開発の有効性
の議論が無意味ってわけじゃないでしょう。
今ここでは、だれも概念レベルと実装レベルのＯＯを混同している人は
いない。誰が見ても明らかに実装レベルの議論でしょ。
オブジェクト指向言語についての議論だよ。

**アマグラマ** · 01/11/10 20:45

C++でも十分に出力されるアセンブラコードが透けて見えるよん。
ちょっと複雑なだけで。

ていうか、私がC++に移行したのは、
Ｃで自己流似非OOPモドキ（ていうかモジュール化の延長線上か）やってて
ある日C++の仕組みについてあれこれ読んで
これ俺がやってることとまったく同じじゃ～ん、
しかも遥かにシンプルに書ける！マンセー！って動機だったですが。

19 · 01/11/10 20:51

>>90

>> C++ではソースコードでは明示されないポインタのやり取りとか、
>一番簡単な例はメソッド呼び出しで
>インスタンスのポインタが this が行きますね
>これは納得

それ納得しちゃうの？
ソースで明示的に書かれていなくても、言語仕様を知っていれば
自明なことでしょう。
裏で何をやっているか本当にわからないような言語でプログラミン
グなんて不可能だと思うけど。

19 · 01/11/10 21:05

亀質問だけど。
>>23==>>75 さん。

遅い遅いというけれど、何を実行しての感想なの？

60 · 01/11/10 21:05

>>108
>それ納得しちゃうの？
んー
「C++のメソッドってソースコードに書いてないのに、
　本当は引数１個多いんだよねー気持ち悪いよねー」
「うん、そーだね　C言語だけの知識では想像できないね」
だしょ

> 言語仕様を知っていれば自明なことでしょう。
そりゃそのとおり

**がばろん＠Ｍたんちゅきちゅき** · 01/11/10 21:33

>>102 60たん。
とりあえず「オブジェクト指向入門」まで読み終わったよ。

並列実行といえば話の流れは、かわるけど、
むかしJavaでゲームに登場させるすべてのキャラに
ひとつひとつスレッドをわりふって、いっせいに動かしてみたよ。
こういう時こそオブジェクト指向は、べんりかも。

オブジェクト自身が自分の状態を保存してくれるし、
ことなるクラスのオブジェクトを同一のメッセージで処理できるし。

// ただ、それでも「順番に命令をならべてそれがそのとおりに実行される」
// というのは、おれも基本的に変わってないとおもう。

// ところで>>102のリンク。60たんのおすすめのページは、どこ？
// たくさんありすぎて、つぎなに読めばいいのか、わかんないや。(TT

**名無しさん＠お腹いっぱい。** · 01/11/10 21:47

>>105
・モジュール
構造化プログラミングで、ある機能を有する小部分をモジュールという。
容易に交換し得るような機能単位のプログラムを指す。プログラムを
モジュール化して作れば、次のような利点があり開発効率の向上が期待できる。
１）開発時に分業化できる
２）誤りの部分発生を特定できる
３）機能改善に部分変更で対応しやすい

60 · 01/11/10 21:54

入り口までは案内した扉は自分で開け

って感じ
自分が興味を感じたタイトルから読んでくのが吉と思われます

明日の自分は今の自分より強いですか？

**名無しさん＠お腹いっぱい。** · 01/11/10 21:58

>>111
Ｃ++のページで半年ほど独学すれば？

**名無しさん＠お腹いっぱい。** · 01/11/10 22:11

>>109
何をって何？

C++は仕様が汚くて後々再利用するものをC++で書く気にはなれない。

＞言語仕様を知っていれば自明なことでしょう。
もちろん自分で作ったものに関しては自明で大変便利な機能だが
他人のものを読む時にはくだらない労力が増える。
裏で行われているかどうかではなくて、
行われている事を調べるのが大変
継承を繰り返しているともはやあほくさくてやってらんない。

＞裏で何をやっているか本当にわからないような
＞言語でプログラミングなんて不可能
そんなことはない

**19=105** · 01/11/10 22:11

>>112
サンクスです。
要するに構造化プログラミングを勉強しろということですね。

**名無しさん＠お腹いっぱい。** · 01/11/10 22:17

>>105
モジュールの概念は、開発時にバグを減らすための技法
覚えておけば、かなりバグを減らせる

一応、情報処理技術者試験で出るんだが・・・

**名無しさん＠お腹いっぱい。** · 01/11/10 22:18

>>115
＞継承を繰り返しているともはやあほくさくてやってらんない。

藁。もうプログラミングやめた方がいいんじゃない？

**名無しさん＠お腹いっぱい。** · 01/11/10 22:20

たぶん最初からやってないと思われ。

**名無しさん＠お腹いっぱい。** · 01/11/10 22:20

だから、C++使うな！

**名無しさん＠お腹いっぱい。** · 01/11/10 22:21

>>116
ま、そーゆー事やね。

**名無しさん＠お腹いっぱい。** · 01/11/10 22:22

>>120
・・・それでも使っちゃう・・・♪

**名無しさん＠お腹いっぱい。** · 01/11/10 22:22

こういう本筋とは関係無いどうでもいいスレッドばっかり育ってるなここ

◆XAJ1OOH6 · 01/11/10 22:22

ゲーム機などのリソースが限られていたときの
伝統が残っていて，どのようにソースを書けば
最適コードになるか意識するという強迫観念が
あるからコードの吐き方がイメージできないと
怖いのではないのでしょうか？

**名無しさん＠お腹いっぱい。** · 01/11/10 22:26

>>124
でも思ってるほど、最適なコードなんて書けてないのがゲームプログラマ

**名無しさん＠お腹いっぱい。** · 01/11/10 22:26

アセンブラで最適化って最高に楽しいよね。
浮動小数点演算のあの糞なスタックをやりくりする
楽しさといったら！

**名無しさん＠お腹いっぱい。** · 01/11/10 22:27

>>124
単に、プログラムの設計を勉強してないだけの話
そりゃ、命令を適当に組み合わせるだけでも、
プログラムを作る事は出来るケドね

つーか、プログラムの設計を理解してない人に
ＯＯＰなんぞを使わせても、猫に小判。

**名無しさん＠お腹いっぱい。** · 01/11/10 22:30

Ｃなら向こうにアセンブラソースが透けて見える？？
cpuが違っただけで、例えばペンティアムⅡとⅢの違い
で全く別言語のような環境と化してしまうアセンブラを
どうやって”透かして見る”んだ？教えて！！

**名無しさん＠お腹いっぱい。** · 01/11/10 22:34

>>127
いや、そういう人が使うためのＯＯＰでしょ。
汗職人には汗職人のための職場がありますよ。
多分。（藁

**名無しさん＠お腹いっぱい。** · 01/11/10 22:41

>>129
ライブラリが充実しているなら、同意するケドね・・・

**名無しさん＠お腹いっぱい。** · 01/11/10 22:41

>>128
78はプログラミング経験が皆無か、
超環境依存型のクソプログラム書いてるんでしょ。
なんに使うのか謎だけど。気にしないでいいよ。

**名無しさん＠お腹いっぱい。** · 01/11/10 22:43

ここはアホぷるぐらまのスレか？

**名無しさん＠お腹いっぱい。** · 01/11/10 22:46

＞ペンティアムⅡとⅢの違い
＞で全く別言語のような環境と化してしまう
オイオイ、
そんなに最適化されたコードはくコンパイラあるのかYO！

**名無しさん＠お腹いっぱい。** · 01/11/10 22:49

128と131はアセンブラで組んだ経験が皆無

＿ · 01/11/10 22:51

高級言語ってアセンブラを意識しなくて良いように作られたんちゃうの？
生成されるバイドコードが想像出来ないからダメって、そりゃお門違いも甚だしい。
コンパイラに頼りきりになるであろう、IA64のようなアーキテキチャの場合どうすんの？
俺に言わせればわかろうとする方がおかしい。

**名無しさん＠お腹いっぱい。** · 01/11/10 22:51

>>133
だからアセンブリ言語の事言ってるんだよ。
コンパイラとアセンブラの違いは分かるかい？

**名無しさん＠お腹いっぱい。** · 01/11/10 22:51

>＞ペンティアムⅡとⅢの違い
>＞で全く別言語のような環境と化してしまう
>オイオイ、
>そんなに最適化されたコードはくコンパイラあるのかYO！

IntelCは吐き分けてくれると思ったけど、どうでもいい話題なのでsage

**名無しさん＠お腹いっぱい。** · 01/11/10 22:55

>>136
78はコンパイラについてだよ。分かるかい？

＞IntelCは吐き分けてくれると思ったけど、
吐き分けてどうしようって言うんだ、一体？

**名無しさん＠お腹いっぱい。** · 01/11/10 23:04

>>138
コンパイラなのにアセンブラソースが見えると書いてるよ。
分かるかね？
＞吐き分けてどうしようって言うんだ、一体？
どうするのか分からんなら聞かなくていいよ。（藁

**名無しさん＠お腹いっぱい。** · 01/11/10 23:08

ふう。このスレも某3Dプログラミング系ページに晒されそうだな。

**名無しさん＠お腹いっぱい。** · 01/11/10 23:12

>>139
それは実際の実行プロセスに非常に近いという事だろう。

**名無しさん＠お腹いっぱい。** · 01/11/10 23:18

>>141
・・・ハァ？
＞それは実際の実行プロセスに非常に近いという事だろう。
言ってることが（危）レベルに達してますな。

**名無しさん＠お腹いっぱい。** · 01/11/10 23:21

もー全然OOとゲームプログラミングぢゃねーよ
Game Programming Gems並みのネタをｷﾎﾞﾝﾇ

**名無しさん＠お腹いっぱい。** · 01/11/10 23:21

>>142
ハァ？
分からんの？

**名無しさん＠お腹いっぱい。** · 01/11/10 23:33

うう良いスレだったのに

**名無しさん＠お腹いっぱい。** · 01/11/10 23:37

とりあえずアセンブラソースを実行なんたらと
勘違いしている>>144を放置してＯＯＰに関する
話題で再開しましょうか。

60 · 01/11/10 23:37

貴方がなぜC++を使わないゲームプログラミングをしているのか
理由を書いてくれる人　他にはいないの？

**名無しさん＠お腹いっぱい。** · 01/11/10 23:39

>>147
あなたって？

**名無しさん＠お腹いっぱい。** · 01/11/10 23:40

貴方って誰？

**名無しさん＠お腹いっぱい。** · 01/11/10 23:47

>>146
実行なんたらってなんだ？
あほか？

60 · 01/11/10 23:59

「ゲームプログラミングをする時にC++を選択しませんでした。」
という人がいるなら、その理由を聞きたいわけですよ
非常に興味深い

まぁ、「対象となるターゲット用C++コンパイラがありません」つーのは
ご愁傷様としか言えませんが
コンパイラ移植するって手もあるけどね

とむ ◆TMwDpCZo · 01/11/11 00:00

やあ、今ログ読んでました。
すみませんね、荒れる原因みたいになっちゃって。

でも全体的に停滞気味の板だから、たまにはいいかな？（笑）

**名無しさん＠お腹いっぱい。** · 01/11/11 00:33

私、ゲーム専用機対象にプログラミングしたこと無い門外漢ですからサパーリで
興味本位に質問ですけど、C++コンパイラ使えるようになったのって
どのあたりからですか？
　　+->PCE　　 +->DC
FC->SFC->PS->PS2
　　　　　　　　　 +->64->GQ
見たいな流れの中で

**名無しさん＠お腹いっぱい。** · 01/11/11 01:17

3DO,PSあたり?

**名無しさん＠お腹いっぱい。** · 01/11/11 01:30

>>151
C++コンパイラの最適化性能が低くて、糞なコードを量産する
そもそも、まともにC++の言語仕様が実装できていない

なんて理由もあるかもね。

**47で66** · 01/11/11 02:41

>60
該当者なんで、私もレス書きまーす。
前もって書きますが、私自身、流行の思想については使いこなせれば
良いなーと羨ましいですし、ＯＯについて偏見もありません。

私はＣのみでゴリゴリのヒトです。
理由ですが、必要ないから（必要性を感じる局面に遭遇してない）
という事と、やはり
「始めに物ありき」の考え方よりも、
「始めに物事の振る舞いの、法則ありき」の方が、私自身、
皮膚感覚的に馴染めるからです。これは、食わず嫌いではなく、
プログラムに限らず、何かを考える際、「物」（主語、目的語）
ではなく「事」（動詞）から先だって考えてしまう癖が
あるからのようです。

おそらく、このような思考方法の人間が、無理やり似非ＯＯ的
プログラムをしたところで、欠陥のある設計しかできないに
違いありません（笑）
そんなわけで、私は大人しくＯＯには触れずにおります。

**名無しさん＠お腹いっぱい。** · 01/11/11 02:59

>おそらく、このような思考方法の人間が、無理やり似非ＯＯ的
>プログラムをしたところで、欠陥のある設計しかできないに
>違いありません（笑）
>そんなわけで、私は大人しくＯＯには触れずにおります
　押しつけるつもりはないけど、一通り勉強してから
結論出しても遅くないと思うけど・・・。
なんかもったいない

**156** · 01/11/11 03:23

いやいや、現状で「そうだ」というだけで、決して結論を出した
わけではありません（笑）

さらには、まったく勉強してないわけでもありません。
勉強不足の度合いと、それが原因か否かはさておき、
現状では私の仕事に役立っていないというだけの話でして、
今でも関連書籍を読んだり、テストプログラムは書いて
みたりはしております。

**名無しさん＠お腹いっぱい。** · 01/11/11 04:37

>>158
大規模なものを組み始めるとOOな手法が管理しやすいのだけど
もともとOOはSAと対立する技術ではないので、SAの技法もきちんと
勉強するのも大切なことだと思いますよ。
地盤が脆い状態で高層ビルを立てるのが不可能なように
コードを何十万行も書いて、経験を積んでSAもOOD/OOAも実装も
コストも利点も理解したうえでターゲットに最善な手法を
選べるようになれば結構いい感じになるんじゃないでしょうかね。

ぶっちゃけた話、木造二階建てを作るのにツーバーフォーな手法よりも
大工職人がトンカンやったほうが、ツーバイフォーな会社を作るより
小回りが効くし、でも出来てしまえばツーバイフォーは早い納期で
高層ビルだって立てられる。でもそれを設計するには習熟と経験が
必要不可欠なわけで。

うーん。私も勉強しなくては…。
勉強不足な自分への自戒の意味もこめて。

**名無しさん＠お腹いっぱい。** · 01/11/11 04:42

今の会社はCマンセー。

Cを使うにしても、使いまわされることを前提に作られているなら
まだいいが、プロジェクト毎にソースコピペかＹＯ！

３年以内に効率の悪い開発体制を変えられなかったら、
会社辞めることになるな。

ま、Cしか使えない厨房は家でおとなしくしてないさい、ってこった。

**名無しさん＠お腹いっぱい。** · 01/11/11 05:09

プロジェクト毎にソースコピペかＹＯ！

ソースコピペかＹＯ

ＹＯ

**名無しさん＠お腹いっぱい。** · 01/11/11 05:18

160
(･∀･)ｶｺｲｲ! ｹﾞﾗｹﾞﾗ

**がばろん＠Ｍたんちゅきちゅき** · 01/11/11 06:53

>>113-114 60たん。114たん。

とりあえず分散オブジェクトと
デザインパターンのとこから読み進めてみる。

ふたりのおかげで気力が、わいてきたよ。
ありがとう。☆⌒(*＾-°)v Thanks！！
// こんど開発状況報告スレにも、いってみようかな。

>>50 とむたん。>>156たん。

いっそ、その「物事の振る舞い」だけを集めたクラスを作って
オブジェクト指向してみるって、どうかしら。

つまり仮想関数だけで構成される
通常のメンバ関数もメンバ変数も持たないクラス。

で、その「物事の振る舞い」が、
なにかのデータ群(つまりクラス)で必要になったら、

そのデータ群に仮想関数だけのクラスを継承させて、
そのデータ群に特化した処理を実装するの。

Javaにおけるインターフェイス的な考え方だけど、べんりだよ。
このクラスは、いっさいデータをふくまないから、
多重継承になっても、ややこしさが発生しないし。
// ただ問題は処理速度かも。。。

ところでJavaでゲームを作ろうとしてるおれは、
もしかして、ここではスレ違いで逝ってよしなのでしょうか。

// いや、それ以前にJavaの処理速度で逝ってよしという気もする。
// 鬱朶思王。。。でも氏なないで、がんばる。
// でも、おれが逝くまえにJavaが先に逝きそうな気もするよ。(TT

**名無しさん＠お腹いっぱい。** · 01/11/11 07:03

インラインアセンブラを多用したプログラムを組みたい
ヘッダをインラインまみれにしても極限まで自分でチューニングしたい
いわゆる汚い泥作業も厭わない任侠気あふれるOOなら C++

**名無しさん＠お腹いっぱい。** · 01/11/11 07:22

>>163
複数の人が別々にコーディングする場合はその方が吉だろうね。
一人でやる場合はＯＯＰにこだわる必要はあまり無いとは思うけど。
関数の集合クラスを作ったり継承したりっていう余分な作業は一人で
やる時は得るものが少ないんじゃないかな。
ＪＡＶＡはアメリカでは終わりだとか言われてるけど（ＭＳがサポートを辞めた）
日本ではまだ元気があるみたいだし、しばらくは大丈夫かも。
速度は問題だよね。技術が足りないからだとか言われるけどそこそこの
技術力でももう少し速くなればいいのに思うよ。

**名無しさん＠お腹いっぱい。** · 01/11/11 08:14

Cでゴリゴリやってる人にはC++はかなり泥臭くて似合ってると思うのだが。
C言語が好きじゃない俺は、C++はいくらOO言語だからっていやだけど

01/11/11 09:56

先生！とりあえずC++が遅いって言うのは論外だと思うＹＯ！
どうしても速度的に問題ある部分は、モジュール分けてCで書くっていうのじゃまずいの？
俺はそんなことはしませんが。使える環境なら必ずC++を選択するよ。

っていうかC++ワカランってところってまだ結構あるよね。
この前もローカライズ担当してる下請けがC++解りませんって泣きついてきたよ。（ﾜﾗ
C++駄目って奴はとりあえずC++で一本作ってから
反論した方が恥をかかないで済むと思われ。

**名無しさん＠お腹いっぱい。** · 01/11/11 10:38

>>166
プロのゲーム開発の現場に限ったらASM,C,C++以外に選択肢は無いのでは？
C/C++に負けない実効速度を出せるＯＯＰＬってあるのだそうか？
純粋な質問。

**名無しさん＠お腹いっぱい。** · 01/11/11 11:27

>167

どうも、このスレの流れとして
一部をCとかアセンブラで書くと良いじゃないの? -> やっぱり遅いってことじゃない。ｱﾋｬﾋｬﾋｬ
って流れらしい。

おれは楽できるところは楽すれば良いと思うけどな。

**名無しさん＠お腹いっぱい。** · 01/11/11 11:32

一部をCとかアセンブラで書くと良い＝最適化して書く
が前提。

**名無しさん＠お腹いっぱい。** · 01/11/11 11:33

>>168
コンシューマだとないだろうな。そもそも処理系がない。

**名無しさん＠お腹いっぱい。** · 01/11/11 12:32

>>60
>C++で実際に実行される順番が異なってしまう状態例を
>あげてくれると非常にうれしいです。感激しちゃう。

グローバル変数のコンストラクタ／デストラクタ。

**名無しさん＠お腹いっぱい。** · 01/11/11 13:12

それは最初から不定なので問題なし。

＿ · 01/11/11 15:07

>>169
C++が遅いと言われても、そんなことは絶対にないと断言は出来ない。
もしかしたら自分の知らないケースで、めちゃ遅くなるかもしれないし。
そういうことで、逃げうってるだけだと思われ。

**名無しさん＠お腹いっぱい。** · 01/11/11 15:16

C++がCより遅くなる、具体的なコード例を挙げられる人居る?
仮想関数によるポリモーフィズムは遅いと言われがちだけど、
同じ事をCでやるとif文やら関数ポインタやら使うわけで、少なくともC++より高速に動かせるという保証はないと思われる。

**名無しさん＠お腹いっぱい。** · 01/11/11 16:07

どっち派でもいいんだけどさ、互いにコッチだ！って啓蒙しあう
必要ないでしょう。（そーいうのはヨソでやろう）
このスレは、前提としてＯＯで、どの様に良い設計をしていくか
がテーマなんだから、そういう話をしないと
「まったく意味がない」

**名無しさん＠お腹いっぱい。** · 01/11/11 16:18

確かにCで一つ一つ全て別々に作っていたものを
C++で基本部分からの継承で作ると結構遅くなる。

**名無しさん＠お腹いっぱい。** · 01/11/11 16:54

深い継承は、その時点で設計が間違ってることが多い(MFCとか)。
デザインパターンを勉強するよろし。

**名無しさん＠お腹いっぱい。** · 01/11/11 17:53

多少遅くなったぐらいで実際に影響が出る環境で作ってる人が多いみたいですね。
コンシューマの方ばかりなのかな？

19 · 01/11/11 19:53

業界人手あげてー！

現場ではCとC++の使用比率どれくらいですか？
て前にきいたけど、だれも答えてくれない（泣

19 · 01/11/11 20:29

ところで、以前「モジュールの勉強って何？」ときいて恥をかいた漏れです。
結構Ｃは書いてきたので、処理とデータをまとめてドメインの独立性を高める
努力は必然としてやっていたんですが「構造化プログラミンの勉強」っていうのを
真正面からやったことは確かにない。
で「構造化プログラミング」の参考書を探しに本屋にいったんだけど無いですね、
全然。オブジェクト指向ばっかり。
ためしにオライリーの「Ｃ言語実践プログラミング」をぱらぱらと見たら、一応
モジュールとかデータ構造とか書いてあったけどなんか、いまさらなことばかり。
今までやってきた文法以上のＣの訓練が実は構造化プログラミングだったてこと
でしょうか。
構造化プログラミングを極めるための本とか、構造化デザインパターンみたいな
ものってあるのでしょうか？
スレ違いでスマソ。

・・・何も買わないのは癪だったので「Game Programing Games」かってしまった。

**名無しさん＠お腹いっぱい。** · 01/11/11 20:35

>>181
構造化定理って調べてみ

ラム · 01/11/11 20:42

ageるっちゃ。

19 · 01/11/11 20:44

>>182
サンクス、ザクザク出てきた。
この世界も奥深いね。べんきょー！べんきょー！

**名無しさん＠お腹いっぱい。** · 01/11/11 22:05

仮想関数には関数ポインタのような柔軟性がないのが嫌。
以前、
CTask{
virtual void Update();
};
CEnemy extends CTask
CEnemy1 extends CEnemy
CEnemy2 extends CEnemy
CEnemy3 extends CEnemy
みたいな設計をして失敗した。

やっぱりコアは構造体と関数ポインタに限るよ。

**名無しさん＠お腹いっぱい。** · 01/11/11 22:11

>>185
それがどういう不都合があったのか教えてもらえれば、
解決方法を提示できるかも風来のシレン。

**名無しさん＠お腹いっぱい。** · 01/11/11 22:40

>>186
・コーディング量が増え、生産性が落ちる。
関数ポインタの場合、関数を作ってアドレスを渡すだけだが、
仮想関数の場合、最低限classの定義、仮想関数の定義、コンストラクタの定義が入るため
余計なコーディングが必要になる。
ましてやクラスごとにcppとhを作っていた場合ファイル数がたいへんなことになる。

・動的なメモリ確保を強制される
関数ポインタの場合、関数アドレスを変更するだけで動作を変更できるが、
仮想関数の場合delete,newを呼び出す必要がある。
オーバーヘッドとメモリの断片化が問題となる。

・他クラスを参照している場合の解放タイミングの問題
参照先のタスクが解放済みか否かの判断が複雑になる。
静的に確保された構造体では、消去済みフラグを立てておけば
参照先が消去済みかはその参照先のフラグを調べることで判断できるが、
deleteされたクラスにこれをやると、不正なメモリアクセスになり落ちる。
もちろん解決方法はあるが、そのオーバーヘッドがばかにならない。

他にもいろいろあるがとりあえず代表的なものを。

19 · 01/11/11 22:49

ム板のゲーム開発スレでも出てたけど、
オブジェクトは必ずしも不要に成ったらdeleteしなければ成らないわけではない。
まとめてワーク用オブジェクトのプールを作っておいて、フラグ、ID管理をする
こともやろうと思えばできる。
これを実現すれば>>187の２，３番目の問題はある程度解消できるよね。

この変が、ゲーム開発的ＯＯＰの特徴にになってｋるんじゃないかと、
素人ながらに思っています。

**187** · 01/11/11 22:52

後重要なものを忘れていた。
・動的な型情報の取得が簡単にできない。
関数ポインタの場合、function_address == Enemy1?で判断できるが、
クラスの場合CEnemy1クラスであるかどうかの判断が大変面倒になる。

**名無しさん＠お腹いっぱい。** · 01/11/11 22:57

>>187
どういう場合に型情報が必要ですか？
基本的には抽象化された型情報の実際の型
を知らなくても、振る舞いをさせることが出来るのが
理想な気がしますが…。

**名無しさん＠お腹いっぱい。** · 01/11/11 23:04

>>190
特定のタスクを消したい、特定のタスクのみ更新したい。
こうした要求は少なからずある。
MFCでも、IsKindOf(RUNTIME_CLASS())という動的に型情報を取得するための
メソッドが用意されているでしょ？

**名無しさん＠お腹いっぱい。** · 01/11/11 23:07

>180
んー、ツールではC++使うけど、製品には使わないねぇ。
基本的にCでなんでも出来ちゃうわけだから、「圧倒的に開発効率が良くなる」
とかいうシチュエーションにならない限り使わないと思うなぁ。
出来あがったソースコードはC++の方が綺麗だけど、
他の開発メンバーの書いたコードを理解するのはCの方が
しやすかったり、ヤバめのバグをアセンブラソースレベル
で追跡したりするハメになった時Cの方が楽だったり・・・

ちなみに、スレの本題の「ＯＯ」については、言語に
関わらず自然とそうなってる気がしますが。

**名無しさん＠お腹いっぱい。** · 01/11/11 23:15

完全なOOなんて相当な大規模プロジェクトでない限り、
馬鹿げている。

19 · 01/11/11 23:19

>>192
ありがとうございます・・・
やっぱりまだこの業界では「これから」の技術なのでしょうか。
Ｃ＋＋に移行してゆく保証もありませんけど。

>>188でもちょっと書きましたが、ゲーム開発にはゲーム開発の独特の
ＯＯＰが必要なのは間違いないはずです。
ＯＯではデザインパターンというものが重要な地位を占めてますが、
ゲーム開発的デザインパターンがまとめられて、それに基づいた設計・実装
ができるようなクラスライブラリが整えばＣ＋＋への移行もあるかも知れない
というところでしょうか。

**名無しさん＠お腹いっぱい。** · 01/11/11 23:19

>>191
では、そのIsKindOf(RUNTIME_CLASS())（のようなもの）であるとか、
Updateのメソッド自体に更新の判断をさせるほうが良い気がするのですが…。
それではデメリットがあるのですか？

**名無しさん＠お腹いっぱい。** · 01/11/11 23:23

>>195
IsKindOfを実装するには、これまたクラスごとに面倒なコーディングが増えるわけよ。
関数を作って、SetTask(Function)を呼び出すだけとい
お手軽さとは雲泥の差があるわけ。

Updateに判断させる場合、すべてのクラスにその判断処理を実装する必要があるわけでしょ？
それまた面倒でパフォーマンスも悪いわけ。

**187** · 01/11/11 23:29

一応、現在の実装例を書いておこう
CTaskManager{
public:
TASK* SetTask(void* function_ptr);
void Update();
private:
TASK mTask[MAX_TASK];
};

CEnemy{
public:
static void Enemy1(TASK*);
static void Enemy2(TASK*);
static void Enemy3(TASK*);
};

＿ · 01/11/11 23:34

>>192
俺もC++の可読性については、ちょっと同意かなあ。
ちらっと読んでもわからないんだよね、他人のソースが。
継承ツリーの根元にあるメンバなんか、いきなり出されても
作った本人しかわからないよねえ。
グローバル変数使いまくりのCでも、そっちの方が読みやすいというのはあるよねえ。

**名無しさん＠お腹いっぱい。** · 01/11/11 23:34

C++(OO)は圧倒的にデバッグが楽。って思うのは俺だけ？
特に多人数での開発になると顕著だと思うんだけど。
他のプログラマによる不正な操作を制限しやすいのはかなりメリットだと思う。

Cでもキチンと書けば問題無いんだけど、
なんか致命的かつ再現率の低いバグが出やすい気がする。
↑これは自分がへぼいのは自覚してます。

あとまともに動けば例外処理もかなり強力だと思うざんす。

**199** · 01/11/11 23:36

圧倒的ってほどでもないですね。誇大表現でした。