○○とゲームプログラミング Rev 3.0.0

**名前は開発中のものです。** · 04/02/01 20:56

　「OOとゲームプログラミング」から派生したスレです。
　OOも含め、ゲームプログラムの制作に関わる様々なトピックを
語りましょう。

　単なるC++でのクラスの書き方から、設計やパターン、制作手法
まで守備範囲広し。

過去スレ:
OOとゲームプログラミング Role2
http://pc2.2ch.net/test/read.cgi/gamedev/1067458051/

OOとゲームプログラミング
http://pc2.2ch.net/test/read.cgi/gamedev/1005144931/

**名前は開発中のものです。** · 04/03/23 20:45

>>304
基本的には>>288と>>304の言いたい事はわかるし同意するんだけど・・・

>これがキチンと出来ていれば、実装コードは多少汚くても、交換するのが簡単なのだが
それは交換が可能なメンツが集まってる場合の話だと思うが・・・
自分がいなくなったら他の奴にそのコードを再利用してもらえるかってこと。
コードを読んで理解できなきゃ再利用したくないよね。

たしかにインターフェースのデザインがしっかりしてれば交換は可能かもしれないけど
交換するって事は、インターフェースはそのままアルゴリズムの部分を書き直すってことでしょ？
そういう状況で「コードの再利用が出来てる」と言って良いのかは疑問だな。

**名前は開発中のものです。** · 04/03/23 20:53

なんか意味不明な文章になっちまった。
簡単に言うと、
どんなに再利用性を考えたデザインのコードでも
自分以外のプログラマが、一見して理解するのに時間がかかると感じるようなものだと
「このコードを追っかけてバグを見つけるぐらいなら自分で書いちゃえ」
って考えてしまう奴が多いので、なるべく理解しやすいレベルのコードを書くべき。
・・・ってことです。

**名前は開発中のものです。** · 04/03/23 20:54

＞「このコードを追っかけてバグを見つけるぐらいなら自分で書いちゃえ」
それは実績によるんじゃないの？

**名前は開発中のものです。** · 04/03/23 21:05

>>305
やめる前にはドキュメントを残してもらえばいいんじゃないかな。
ソースコードなんてどんなに綺麗に書いた所で、作るより読むほうが三倍手間がかかる訳で、
インターフェイスを見て分らないものは、ソースコードをいじろうなんてあまり考えないですね。
この辺りはまあ趣味の問題としても、オブジェクト指向ではインターフェイスを手抜きすると設計が崩壊する、
肉を切らせず骨を断たれては堪らないと思うので。
ソースコードを丁寧にと言っていたら、いつの間にか重箱の隅を突付いていたなどと言う事が無いように自分に言い聞かせてます。
時々見かけます、やたらに神経質なんだけど本質を突いていないので、メチャクチャになっている人を。(こういう人がいるとチーム内の士気がやたら落ちて迷惑なんですよね)
そんな風な人にだけは成りたくないものです。

**名前は開発中のものです。** · 04/03/23 21:26

テンプレートばかり使う自己満足ダメプログラマと
テンプレートも使う実力派プログラマの両方を見たことがある

テンプレート使ってるからはなから読めないダメだって言ってる
人は勉強が足りない怠け者じゃないかな

**名前は開発中のものです。** · 04/03/23 21:32

>>309
｜　　 ≡　('A` )
│　≡　～( ～)
↓　　≡ 　ノノ

**名前は開発中のものです。** · 04/03/23 21:35

「日本」のプログラムの仕事は
凡庸な人間が１０人でやる仕事が一番多い。

**名前は開発中のものです。** · 04/03/23 21:59

>テンプレート使ってるからはなから読めないダメだって言ってる
だれもそんな事言ってなさげ

**名前は開発中のものです。** · 04/03/23 22:14

>>309
ほっとけばよいのです
テンプレートばかり使う自己満足を通過しなけりゃテンプレートも使う実力派プログラマにはなれない訳だし。
オブジェクト指向の出立ちの頃もオブジェクトが読めないからダメだという人間はいくらでも居たし。

**名前は開発中のものです。** · 04/03/23 23:44

>>313
いや、そもそもテンプレー厨はＯＯの本質を見抜けず、
とりあえず使い方だけわかるテンプレートで技巧を凝らしてしまうところに問題がある。
テンプレー厨は自分がテンプレー厨であることに気づけない。

**名前は開発中のものです。** · 04/03/24 00:39

>>314
別に構わないと思うけど、始めなければ始まらないし。
それにtemplateを使うならオブジェクト指向にこだわっていると視野が狭くなり過ぎる。
template は行き着くところまで行き着けばプログラミングではなくメタプログラミング
本質的にはプログラムを生成するプログラムでオブジェクト指向は
通常のプログラムでのデータ構造の設計的位置づけになる。
データ構造の設計は重要だからオブジェクト指向は無視できないが、
だからといって操作対象はオブジェクト指向である必要性もないだろう。
たとえば効率的なコードを書きたいが難解だから、
記述内容とは違うコードをそこに書き出して記述内容は
意味的に簡単になるようにやってみようとかね。
Gems にもあったよな気がする。
ゲームに特化しないならboostなどはネタの宝庫だろう。

**名前は開発中のものです。** · 04/03/24 00:46

>>308
下手なソース書く香具師のドキュメントは、
ソース以上に危険な罠。
下手ソースを読む能力もプログラム能力の一部で、
経験等による能力差が大きい罠。

しかし、テンプレばかり使うテンプレ厨なんて見たことないな。
テンプレなんてSTLとBoostとあと汎用的な所に自前テンプレ使うぐらいが
ほとんどじゃ？
Lokiばりのコードを自作して使いまくってる香具師とかいるのか？

**名前は開発中のものです。** · 04/03/24 00:59

>>316
>しかし、テンプレばかり使うテンプレ厨なんて見たことないな。
やねうらおのことかと思たよｗ

**名前は開発中のものです。** · 04/03/24 01:14

>>314
だからテンプレートによるジェネリックプログラミングと
オブジェクト指向プログラミングは
まったく別のプログラミングパラダイムなんだって
STLの設計者はJavaが嫌いだと
RadiumSoftwareに書いてあった

**名前は開発中のものです。** · 04/03/24 01:19

>>316
いやはや、ちとキチガイ神経症ヤロウにグチグチやられていて、
発言煽り気味だったかな

**名前は開発中のものです。** · 04/03/24 01:20

＞STLの設計者はJavaが嫌いだと
＞RadiumSoftwareに書いてあった
Java好きの俺がSTLの関数オブジェクトを多用するコードに
馴染めない理由が分かった気がする。

**名前は開発中のものです。** · 04/03/24 01:30

>320
Java好きなら、Java+Jakarta Velocity　でも
ジェネリックプログラミングは可能なんじゃないか？

とたいして知りもしないのに言い放つﾃｽﾄﾌｧｰｽﾄ。

**名前は開発中のものです。** · 04/03/24 10:40

Javaも1.5からGenericsが導入されるね。
http://objectclub.esm.co.jp/JavaGenerics/
http://www.mamezou.com/tec/Tips/javaGenericsVsCppTemplate/article2.html

C++のとはだいぶ違うみたいだけど。

**名前は開発中のものです。** · 04/03/24 11:18

なかなかよさげだけど・・・
やっぱりジェネリックプログラミングが今後の流れになっていくのかな
構造化→オブジェクト指向→ジェネリック
みたいな。

ちと、真面目に勉強してみるか・・・・鬱

**名前は開発中のものです。** · 04/03/24 14:03

ジェネリックプログラミングの解説って、どれもやたら小難しくない？
いい解説ってないかなぁ

**名前は開発中のものです。** · 04/03/24 14:27

boostのページに書いてあるけど要はコレだけ。
>ジェネリックプログラミングはソフトウェアコンポーネントを汎用化することであり、
>それによってコンポーネントが多様な状況下で簡単に再利用できるようになります。

で、コレを実現するための「(C++の)技法」が一杯あるわけだけど、普通にゲーム作ってる限り
boostとかの成果の一部を使えればいいんであって、そういう技法を真面目に追求なんてべつに
しなくてもいいではないかな？
へたに「技法」を使ってしまうと、糞コード量産してテンプレ厨とか言われかねない罠。

**名前は開発中のものです。** · 04/03/24 18:59

マクロ使って逃げるしかないのかな？
と思ったらテンプレートでできないか検討する
ぐらいでちょうどいいと思われ

**名前は開発中のものです。** · 04/03/29 06:06

復帰age

**名前は開発中のものです。** · 04/03/29 09:52

ところで、STLって使えるけど使えないと思いませんか？
vectorの場合、100要素しかないかもしれないし、１万要素になっちゃう
かもしれないvectorで、reserveしとくのもなんかダサいし、かといって
要素を追加すると1万要素もmemcpyなんて事態も恐ろしい。
かといって、listもmapもsetもなんかヒープに１万個の要素のメモリ断片
を作るかと思うと恐ろしい。
なんて事を考えるとSTLを使ってしまうけど使いにくいです。
iteratorもキモイですね。[]オペレーターもキモイです。
かといってキモさを払拭するために、ジェネリックにする事が存在理由になっている
スパゲッティコードを読むきはおきません。それは怠惰がゆえかもしれませんが、
しかし、そこに、とてつもない不毛感、虚脱感、無益感、あらゆる世の中の無意味さを
感じてしまうのです。なんだろう、複雑さの割には効果がないっていうんでしょうか。
中途半端な理解による誤解かもしれませんが。

**名前は開発中のものです。** · 04/03/29 10:01

要するに、データの設計段階に問題があると。

**名前は開発中のものです。** · 04/03/29 10:09

>>329
というか、何のための"vector"なのかということですね。
最初っからデータ量がわかっているなら、素直にnew type[ numElements]
でいいわけですよ。
予測として余分にリザーブしてある領域を超えると、とてつもない
メモリー帯域の浪費が起こる。
この辺が美しくないでしょう？
かといって何かいい手があるかというと”？”ですけど、だったら
最初っからないほうが潔いんじゃないかって考えたりします。

**名前は開発中のものです。** · 04/03/29 10:40

＞new type[ numElements]
これでサイズ変更時に、メモリの再確保と転送をデータ型に合わせて、
一つ一つ書く方が潔いと思うのならそうすればいい。
ただしデータ設計の問題をSTLの問題にするのは本末転倒。

**名前は開発中のものです。** · 04/03/29 11:34

>>331
データ設計もクソもないでしょう？
問うている問題自体が判ってないよ。

**名前は開発中のものです。** · 04/03/29 11:36

だいたい、データ量が未知＝データ設計の問題かよ？

**名前は開発中のものです。** · 04/03/29 13:18

＞これでサイズ変更時に、メモリの再確保と転送をデータ型に合わせて、
＞一つ一つ書く方が潔いと思うのならそうすればいい。
これが読めないの？

STLはあくまでも特定のアルゴリズムで型の扱いを汎用的にするためのものであって、
メモリーサイズが変化する事に万能に対応できる魔法の道具ではない。
そんな魔法が存在しない以上は、負荷軽減を目的とする場合、
データの転送が最小限で済むように、データをグループ化したりするわけだが。

で、潔い方法とやらは、メモリの再確保に関してSTL以上に簡潔に書けるの？
ぜひ
＞new type[ numElements]
で、どうやって
＞メモリー帯域の浪費が起こる。
が回避されるメモリ再確保に対応するのか、その魔法を見せてもらいたい。

**名前は開発中のものです。** · 04/03/29 13:27

とむの口調がだんだん荒々しくなっていく過程が面白い。

**名前は開発中のものです。** · 04/03/29 13:29

条件を緩め、
＞new type[ numElements]
これは外そう。

・条件
データ設計は直は見直さず、「メモリー帯域の浪費がおこらない」、
メモリーの再確保を行うための魔法の呪文。

**名前は開発中のものです。** · 04/03/29 13:30

＞データ設計は直は見直さず、「メモリー帯域の浪費がおこらない」、
↓訂正
＞データ設計は見直さず、「メモリー帯域の浪費がおこらない」、

**名前は開発中のものです。** · 04/03/29 14:00

>>328
うーむ、こうやってオレコンテナライブラリが増えていくのだろうか…

**名前は開発中のものです。** · 04/03/29 14:08

>>328
そんなの臨機応変に使えば？だれも強制してないよ。
潔いのがいいならＣでもアセンブラでも使えばいいし
C++でもSTL使いたくなきゃ使わないで済むしね。
それなのにキモイから不要とか潔くないって意見を押し付けるのはどうかと。

**名前は開発中のものです。** · 04/03/29 14:53

>>334
>STLはあくまでも特定のアルゴリズムで型の扱いを汎用的にするためのものであって、
>メモリーサイズが変化する事に万能に対応できる魔法の道具ではない。

糞設計は、STL使いの罪。それを許してしまうのは、STLの罪。

**名前は開発中のものです。** · 04/03/29 16:03

>>334
『予測として余分にリザーブしてある領域を超えると、とてつもない
メモリー帯域の浪費が起こる。
この辺が美しくないでしょう？
かといって何かいい手があるかというと”？”ですけど』

って書いているのに、

『潔い方法とやらは、メモリの再確保に関してSTL以上に簡潔に書けるの？』

って反論するかよふつう。完全に論点をはずしているんだよね。
問題を論理的かつ的確に見極めるのもプログラマの能力のうちだよ。

**名前は開発中のものです。** · 04/03/29 16:19

>>341
そこで「本当の論点は何か？」を書かないくせに、
やたらと「論理的・的確な」という言葉を濫用するのも
プログラマの能力って奴ですか？

**名前は開発中のものです。** · 04/03/29 16:31

>>342
>プログラマの能力って奴ですか？
煽りの能力です(文章の荒れ具合を見るともしかしたら天然なのかも知れないけど)。

**名前は開発中のものです。** · 04/03/29 17:28

>>341
＞予測として余分にリザーブしてある領域を超えると、とてつもない
＞メモリー帯域の浪費が起こる。
解決方法は、
＞かといって何かいい手があるかというと”？”ですけど
そして
＞最初っからないほうが潔いんじゃないかって考えたりします。
という、とんちんかんな結論を出すと。

どうしても必要な場合に、いちいち再確保と転送を自分で書くよりは、
テンプレートを使って自動的にやってくれた方が楽でしょ？
それだけの話なのに、いったい何が言いたいのか、
＞論点
がさっぱり見えない。

**名前は開発中のものです。** · 04/03/29 17:37

これをlistに置き換えると、

listを使うと断片化が起こる。
かといって何かいい手があるかというと”？”ですけど
だったら最初から使わない方が潔いのでは？

論点はこれでOK？

**名前は開発中のものです。** · 04/03/29 17:58

論点はここでしょ。
>iteratorもキモイですね。[]オペレーターもキモイです。
>かといってキモさを払拭するために、ジェネリックにする事が存在理由になっている
>スパゲッティコードを読むきはおきません。それは怠惰がゆえかもしれませんが、

つまり愚痴が言いたいだけ、と。

**名前は開発中のものです。** · 04/03/29 19:24

>>345

>だったら最初から使わない方が潔いのでは？

そうそれを言ってんの。やっと言っている事を判ってくれたね。

リストなんかだったらさ、
typedef struct _tagWhatever
{
struct _tagWhatever* next;
struct _tagWhatever* prev;
...
public:
void insert( _tagWhatever* pElem );
void remove( _tagWhatever* pElem );
...
} whatever;
でいいわけさ。

別にSTLを否定しているわけでもないよ。
ただ、そのヒープの原理上、どうしてもSTLの利点が生ききらない
よなって愚痴っているだけ。

それを、「設計上の問題をSTLの問題に摩り替えている」とかいうから
なんなん？って思うわけよ。

**名前は開発中のものです。** · 04/03/29 19:41

>347
おまえの考えている「STLの利点」って何よ？

**名前は開発中のものです。** · 04/03/29 20:17

>>347
＞typedef struct _tagWhatever
断片化が解決されるわけでもなく、手間がかかるようにしか思えないのに、
これを型ごとに毎回書く利点は？

**名前は開発中のものです。** · 04/03/29 20:50

>断片化が解決されるわけでもなく

基本的には、そうだ（文脈的に無視しちゃっていいが、厳密には、
STLでも一要素単位でヒープ領域が割り当てられるわけじゃない）。

＞これを型ごとに毎回書く利点は？

型は関係ないよね。もし問題にするなら汎用コンテナの問題を挙げてくれよ。
templete = STLじゃないよ？わかってんのかな？

Listに限った、コンテナの再利用でいうなら、これでいいわけ。
templete < typename T >
class CList
{
CList* next;
CList* prev;

T CONTAINER;

public:
void insert(...);
void remove(...);
};
ってやりゃいい。

**名前は開発中のものです。** · 04/03/29 20:53

>>350
それでわざわざ自分で実装する利点の説明は？

**名前は開発中のものです。** · 04/03/29 21:17

>>351

＞それでわざわざ自分で実装する利点の説明は？

仕組みを理解している人間だったら、そんなの訊くまでもないでしょ。
STLはvector, list, setなどのデータ構造間の汎用性を追求している
がための複雑さとオーバーへッドがある。
って、１から１０まで書かんとわからんか？

っていうか、確かに煽り半分で書いた事は書いたが、それは
プロが出てきて有意義な話ができるかなと期待したんであって、
こんな意味のない話をしたかったわけじゃないんですが。
もうやめましょうこれ。時間の無駄です。

**名前は開発中のものです。** · 04/03/29 21:23

先生!、>>350の中に、オーバーヘッドを解決する画期的なコードが見あたりません。
お願いですから、まだ逃げないでください。

**名前は開発中のものです。** · 04/03/29 21:29

実際問題、オーバーヘッドを回避するために、
独自のアロケーターを内蔵しているSTLに、
>>350のソースで勝ち目があるようには思えない。

コードの質を落とした車輪の再発明なら、
＞もうやめましょうこれ。時間の無駄です。
確かにその通り。

**名前は開発中のものです。** · 04/03/29 21:41

ゲーム機でSTL使ってるやついるの？
ツールならがんがん使うんだが・・

**名前は開発中のものです。** · 04/03/29 21:48

先生!、コンシューマーのような限られた環境では、
データ量の上限を設定して、想定した範囲内に収めるように作ると思います。

**名前は開発中のものです。** · 04/03/29 22:01

>>347のリンクリストをおとなしく使うのが(･∀･)ｲｲ!!

**名前は開発中のものです。** · 04/03/29 22:30

>>353
ちょっとはSTLのコードを読んでからモノをいおう。

>>354
文脈考えてね。「型ごとにlistクラス」つくんのかよって言われたから、
テンプレートつかってlistコンテナをこうやって組むんだよって
サンプルを書いたんだろうが。

>>354

>独自のアロケーターを内蔵している

newオペレーターオーバーライドだろ。
そんなの実装するの当たり前じゃん。
その他、find,sort等色々なメソッドも実装するよって、こんなとこに
一々書いてられるかボケ。

あのさ、おまえら人が掲示板で具体的に説明するために
ちょろっと書いた（コピペですらないよ）サンプルコードに
いちいちうるさいんだよ。

>>357
きみとなら仕事を一緒にやっていけそうだ。

**名前は開発中のものです。** · 04/03/29 22:39

＞その他、find,sort等色々なメソッドも実装するよって、こんなとこに
つまり結局はSTL同様、複雑になるわけなんだけど、
その車輪の再発名でSTLには無いオーバーヘッドを回避する方策は？

**名前は開発中のものです。** · 04/03/29 22:55

＞newオペレーターオーバーライドだろ。
先生!、オーバーロードとオーバーライドの区別はついてますか？

**名前は開発中のものです。** · 04/03/29 23:16

>>359

>>341
をよめ。何回もﾅﾝｶｲﾓﾅﾝｶｲﾓｵﾅｼﾞｺﾞﾄｦｲﾜｾﾙﾅ。

>>360
ﾀﾏﾆﾂｶﾈｰﾝﾀﾞﾖ。っていうか、まぁ英文C++本でも"overload"になっているがだな、
"override"のほうが現象を的確に表している。"overload"は不正確だ。
英語が堪能なオレにとってはどうしても自然な方を使ってしまうんだな。

**名前は開発中のものです。** · 04/03/29 23:20

おっと、ちょっと待て。
オレのいっているオーバーヘッドは、メモリ帯域の無駄の話じゃない。
データ構造間の汎用性を持たせたことによるメソッドのオーバーヘッドの話。

**名前は開発中のものです。** · 04/03/29 23:26

>>361
つまり、
＞かといって何かいい手があるかというと”？”ですけど
何も解決しないまま、車輪の再発明だけ行うわけなのか。
それが潔いと思えるようになるのは、一生かけても難しい。

**名前は開発中のものです。** · 04/03/29 23:29

＞"override"のほうが現象を的確に表している。"overload"は不正確だ。
＞英語が堪能なオレにとってはどうしても自然な方を使ってしまうんだな。
先生!、かなり苦しいです。

**名前は開発中のものです。** · 04/03/29 23:33

馬鹿だなあお前ら、
ゲームでは再利用可能なコンテナが確かに必要だが、
STLの設計はゲームに最適ではないだけの話じゃないか

ゲーム向け俺コンテナを持ち寄って
boostに寄贈ぐらいすればこのスレも役に立ったといえるな

**名前は開発中のものです。** · 04/03/30 00:03

>>363
潔いの話題違い。
メモリバンド幅の話と、メソッドのオーバーヘッドの話がごっちゃになってるよ。
>>364
あのな、overloadとoverrideを辞書で調べてみ。
http://www.infoseek.co.jp

>>365
＞馬鹿だなあお前ら、
＞ゲームでは再利用可能なコンテナが確かに必要だが、
＞STLの設計はゲームに最適ではないだけの話じゃないか

まぁ、そういうことだな。

**名前は開発中のものです。** · 04/03/30 00:21

pc2が消える前の、生産性とかメンテナンス性とか、そんな話はどうなりましたか？

**名前は開発中のものです。** · 04/03/30 00:25

結局のところ、「メソッドのオーバーヘッド」に関しても、
何の解決方法も示めさず、言い訳で逃げ回り、
用語の誤用に関しても、素直に間違いを認めずまた言い訳。

データの汎用性のオーバーヘッドを問題にしても、
型ごとに書くのかと聞かれるとその時だけサンプルはテンプレート。
複雑さを問題にしても、機能の面を指摘されると、
STL同様の機能を実装するという。

既存のものに対して、利点は特にないけれど、とにかく自分で実装。
滅茶苦茶で突っ込みきれない。

**名前は開発中のものです。** · 04/03/30 00:33

例外投げてるの、みんな・・・。

**名前は開発中のものです。** · 04/03/30 00:48

>>368

>結局のところ、「メソッドのオーバーヘッド」に関しても、
何の解決方法も示めさず、

メモリー最配置の時に発生するメモリバンドの無駄はどうにもならないが、
「メソッドのオーバーヘッド」に関しては、
「STLはvector, list, setなどのデータ構造間の汎用性を追求している
がための複雑さとオーバーへッドがある。」って問題提起し、
ゲーム用に贅肉を削ぎ落としたバランスの取れたコンテナをちょろっと
書けばメソッドのオーバーヘッドは軽減できるっていってんだよ。

＞用語の誤用に関しても、素直に間違いを認めずまた言い訳。

Override 誤用じゃないよ。適切な英語だ。

＞利点は特にないけれど

あるよ。ゲームにとっては重要な利点だよ。
シロートとは付きあいきれん。

**名前は開発中のものです。** · 04/03/30 00:51

>>369

try catch例外うざい。
マクロで↓みたいな例外処理いれてる。
DBG_ASSERT( bool bEval, TCHAR* szMessage, UINT uErrorType );

**名前は開発中のものです。** · 04/03/30 00:51

> STLはvector, list, setなどのデータ構造間の汎用性を追求しているがための複雑さとオーバーへッド

それは興味深いですね。具体例をいただけますか？

**名前は開発中のものです。** · 04/03/30 00:54

アロケータ書いてでもSTL使えってやつは
テストプログラムとかツールとかじゃなくて
本当に商品でSTL使ってるのか？
どこ製のSTL？

**名前は開発中のものです。** · 04/03/30 01:00

>>373
STLport。設定マクロをたくさん提供してくれるのでいいと思います。
例外発生時の挙動や、メモリ管理の設定もいろいろカスタマイズできます。

**名前は開発中のものです。** · 04/03/30 01:00

>＞用語の誤用に関しても、素直に間違いを認めずまた言い訳。
>Override 誤用じゃないよ。適切な英語だ。
え？この場合オーバーライドがC++的にも正しくね？

で、オレは最適でないのは承知の上で楽だから使ってるよ(別にｷﾓｲとかどうでもいいし)。
クリティカルな部分だけ特別に最適なのを作る(ちうのは普通の最適化戦略だが)。

なので、別に愚痴りたくは無いかな。
愚痴りたいのは、STL使わせてもバグ埋め込むし、かといって普通にリスト構造とか作ら
せてバグを埋め込んでしまう新人君(に使わせるためのSTL)。

Effective STLシリーズを読まなきゃ使い物にならないのが一番大きいオーバーヘッドだｗ

**名前は開発中のものです。** · 04/03/30 01:06

ところで、STL（テンプレート）で書かれたコードのうまいデバッグ方法教えてくれ。
トレースとか非常にうざいんだけど、何か良い方法ある？

**名前は開発中のものです。** · 04/03/30 01:08

>>用語の誤用に関しても、素直に間違いを認めずまた言い訳。
>Override 誤用じゃないよ。適切な英語だ。
まぁ、君の意見は正しいと思うよ。君の世界の中ではね・・・
ｺｳﾔｯﾃSTL厨が出来上がっていくわけか。
ｱｾﾝﾌﾞﾗ厨の言ってた事とかわらんなぁ。
何かと言うと「俺が正しい」「俺は間違ってはいない」
ﾔﾚﾔﾚ棚

**名前は開発中のものです。** · 04/03/30 01:15

なんか、もう寝たほうがいいと思うよ。

**名前は開発中のものです。** · 04/03/30 01:20

>>372

なんで書き込む前に自分で調べないかな？これで最後ね。時間のムダだし。
例えば、vectorの[]オペレータ一つとっても

vector <int> vInt;
...
int& r = vInt[idx];

とやるだけで、このようにコードが実行される（読みにくいけど長すぎるので）。
まぁ自分で調べりゃ済む事だし。

reference operator[](size_type _Pos)　{ // subscript mutable sequence　
return (*(begin() + _Pos));}
iterator begin(){ // return iterator for beginning of mutable sequence
return (iterator(_Myfirst));}
iterator(pointer _Ptr) : const_iterator(_Ptr)　{ // construct with pointer _Ptr　}
const_iterator(_Tptr _Ptr)　{ // construct with pointer _Ptr
_Myptr = _Ptr;　}

**名前は開発中のものです。** · 04/03/30 01:20

iterator(pointer _Ptr): const_iterator(_Ptr)　{ // construct with pointer _Ptr　}
iterator begin()　{ // return iterator for beginning of mutable sequence
return (iterator(_Myfirst));　}
reference operator[](size_type _Pos)　{ // subscript mutable sequence
return (*(begin() + _Pos));}
iterator operator+(difference_type _Off) const　{ // return this + integer
iterator _Tmp = *this; return (_Tmp += _Off);　}
iterator& operator+=(difference_type _Off)　{ // increment by integer
this->_Myptr += _Off;　return (*this);　}
reference operator*() const　{ // return designated object
return ((reference)**(const_iterator *)this);　}
const_reference operator*() const　{ // return designated object
return (*_Myptr);　}
reference operator[](size_type _Pos)　{ // subscript mutable sequence
return (*(begin() + _Pos));　}

**名前は開発中のものです。** · 04/03/30 01:20

iterator begin()　{ // return iterator for beginning of mutable sequence
return (iterator(_Myfirst));　}
iterator(pointer _Ptr): const_iterator(_Ptr)　{ // construct with pointer _Ptr　}
const_iterator(_Tptr _Ptr)　{ // construct with pointer _Ptr
_Myptr = _Ptr;　}
iterator(pointer _Ptr)　: const_iterator(_Ptr)　{ // construct with pointer _Ptr　}
iterator begin()　{ // return iterator for beginning of mutable sequence
return (iterator(_Myfirst));　}
reference operator[](size_type _Pos)　{ // subscript mutable sequence
return (*(begin() + _Pos));　}
iterator operator+(difference_type _Off) const　{ // return this + integer
iterator _Tmp = *this;　return (_Tmp += _Off);　}
iterator& operator+=(difference_type _Off)　{ // increment by integer
this->_Myptr += _Off;　return (*this);　}
reference operator*() const　{ // return designated object
return ((reference)**(const_iterator *)this);　}
const_reference operator*() const　{ // return designated object
return (*_Myptr);　}

以上。

**名前は開発中のものです。** · 04/03/30 01:27

実際にどういうアセンブラに落ちるか確かめてみた？

**名前は開発中のものです。** · 04/03/30 01:28

>>375

>で、オレは最適でないのは承知の上で楽だから使ってるよ(別にｷﾓｲとかどうでもいいし)。
>クリティカルな部分だけ特別に最適なのを作る(ちうのは普通の最適化戦略だが)。

だね。オレもそう。STLの問題点がわかってりゃ適材適所で使いこなせるってことだな。

**名前は開発中のものです。** · 04/03/30 01:32

みんな最適化で殺ぎ落とされる部分じゃん
マルチスレッドで使うとロックコードが入るだけ。

**名前は開発中のものです。** · 04/03/30 01:35

全部インラインになって最適化されるとかなり効率的なコードになるってのが
templateの利点のひとつだしね(メタプログラミングというのか？)

STLなんかも、もろコンパイラの最適化前提。

**名前は開発中のものです。** · 04/03/30 01:37

>>382

自分で調べてみなって。上のCコードどおり最悪なことになっているから。
ちなみに普通の配列だったら4stateくらいで済む話です。

**名前は開発中のものです。** · 04/03/30 01:39

>>386
いや、調べてみていってるんだが。
最適化を掛けなきゃすごいことになったが、掛ければ配列と変わらなかったけど。
ちなみにgccの-O2で確認。

**名前は開発中のものです。** · 04/03/30 01:42

>>379
おつかれさまでした。
ちなみに、STLportのHEADでは、

reference operator[](size_type __n) { return *(begin() + __n); }
iterator begin() { return this->_M_start; }
_Tp* _M_start;

以上（@stlport/stl/_vector.h）でした。
そういうことなので、貼っていただいたモノはSTLのオーバーヘッドの具体例とはいえませんね。
おそらく、「中途半端な理解による誤解」でしょう。
STLportの使用をお勧めしますよ。

**名前は開発中のものです。** · 04/03/30 02:45

連続投稿とかいわれてかきこめねーよ。

>>385
>全部インラインになって最適化されるとかなり効率的なコードになるってのが
>templateの利点のひとつだしね(メタプログラミングというのか？)

templateの利点？実行コードの話だよね？
効率的なコードになるのはinlineの利点であって、templateとは関係ないが。
templateはむしろ、複数の実体が生まれるっていう副作用以外、コード効率への影響はない。

>>387
>掛ければ配列と変わらなかったけど。
それはありえないね。

>>388
それじゃまだ甘い。まず＋オペレーター部分が抜けてるでしょ？
そして＋オペレーターから更に続くわな。
その字面通りだったら、char型でもない限り、まともにアドレスとれないよ。
トレースしてみ、ほかにも呼ばれるものがいっぱいあるよ。
字面ほど単純じゃないのがSTL。

**名前は開発中のものです。** · 04/03/30 02:52

>>掛ければ配列と変わらなかったけど。
>それはありえないね。
・・・こいつには何を言っても無駄かと。
久々に真性のヴァカを見たよ。

**名前は開発中のものです。** · 04/03/30 03:09

>>389
あーすいません。抜けてましたね。
typedef valute_type* iterator;
typedef valute_type& reference;
ということで、続く + も * も、共に組み込み演算子ですよ。

**名前は開発中のものです。** · 04/03/30 03:22

＞その字面通りだったら、char型でもない限り、まともにアドレスとれないよ。

えっと、Cの基本が全く分かってない人ですか？

**名前は開発中のものです。** · 04/03/30 06:37

; 14 : int& r = vInt[idx];

00000a1 00 00 00 00 mov eax, DWORD PTR ?idx@@3HA ; idx
000058b 0d 04 00 00
00 mov ecx, DWORD PTR ?vInt@@3V?$vector@HV?$allocator@H@std@@@std@@A+4
0000b8d 04 81 lea eax, DWORD PTR [ecx+eax*4]

; 15 :

**名前は開発中のものです。** · 04/03/30 07:04

お前ら釣られすぎ

**名前は開発中のものです。** · 04/03/30 07:29

重要
・間違えても言い訳はせず、素直に認めることは大切。
・あり得ないと決めつける前に、自分で確かめることも大切。

**名前は開発中のものです。** · 04/03/30 09:44

双方とりあえず汗コード載せろと。

**名前は開発中のものです。** · 04/03/30 09:56

>>389
>効率的なコードになるのはinlineの利点であって、templateとは関係ないが。
型の安全性を保ちつつマクロのようなことが出来るという意味で、両方だよ。
テンプレートメタプログラミングって聞いたこと無い？
(そして、そこがC++の汚さなわけだが。。。)

**名前は開発中のものです。** · 04/03/30 13:17

>>393
そのうちシンボルの長さの分非効率って言い出すからよろしく

**名前は開発中のものです。** · 04/03/30 16:17

(((（ ;ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

**名前は開発中のものです。** · 04/03/30 17:58

自前実装の有利さは移植したときに発揮されるよ。
おまえら知らないかもしれなが、ＳＴＬがサポートされてないＣＰＰがアルンデスヨ。

**名前は開発中のものです。** · 04/03/30 18:07

>>400
世の中には malloc も無い C コンパイラもあるが、
そこら辺、どうよ？

**名前は開発中のものです。** · 04/03/30 21:00

Cコンパイラも無い環境はどうしますか？

**名前は開発中のものです。** · 04/03/30 21:02

昔はそれが普通だった

**名前は開発中のものです。** · 04/03/30 21:29

つまり、移植性を高めるためには、Cすら使わずに書かなければならない、と。

・・・・あれ？