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

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

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

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
でも思ってるほど、最適なコードなんて書けてないのがゲームプログラマ