○○とゲームプログラミング 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/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すら使わずに書かなければならない、と。

・・・・あれ？

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

おいらの場合、ＳＴＬ使ってるけど、極端に使い込んでるわけではない。
list map vector 程度だし、使ってるメソッドもごく一部。
それらを網羅するだけのテンプレートなら、自作してしまったほうが
なにかトラブルがあったときに対処しやすいかも。

パチンコ系の仕事だと、メモリ少ないし、C++は使えるけどSTLは
使えないなんて環境がザラなので、自作するですよ。
ま、昨今のPS2の3Dゲーが普通な世間についていけなくてスピンアウトした
負け組みな自分の意見など参考にならんかもしれんけど。

でも、ゲーム用途で使用するSTLのメソッドなんて、やはり片手で
数えれる程度なんではないでしょうかねぇ？

標準でSTLが添付されているなら迷わずそちら使うんですけど

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

windows系のゲーム開発ならSTL使っても全然問題ないかな？

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

問題はWindowsかどうか（リソースがたくさん取れる環境か）ということじゃなくて
使う人間がどうか、どんなゲームを作るつもりなのかの方が何十倍も影響する

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

んなアホな。

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

ここ見てると、STL=テンプレートベースのコンテナ集
みたいな見方しかしてない椰子がたくさんいるような気がするのは
俺だけなのだろうか

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

>>409
ぜひ、そうじゃないと言う意見を教えて欲しい。
実際のところコンテナ集程度の認識でしか使えていないので・・・

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

STLにしても、mallocにしてもゲームじゃ普通に自前で書くだろ。
でもって、状況判断して、標準・自前・使わないを使い分ける罠。
キモいiteratorの自作は結構楽しい罠。

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

>>410 <iterator> <algorithm> <functional> <utility>

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

>>412
それらは全部コンテナと関連してる気がするが…

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

コンテナと関連はしてるけどコンテナ集じゃないでしょ。
ただの配列とかにも適用できるんだから。

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

んでもって、そこがSTLの(ジェネリックプログラミングの)一番キモいとこだな。
bind系なんて見てらんない。

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

コンシューマは大変ですね
プログラマさんの日記見てても、いちいちアセンブラに落として比較してたり、
よくそんなことやってるな、と
なんでもかんでも自作したり、ミイラ取りがよくミイラにならないか不思議です。

PCだと、軽くプロファイルとって大抵はそのまま終了だからなー

このスレみてると自分はなんて恵まれてるのかと思えてくるよ

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

>410
STLはただのコンテナ集ではない
データ構造とアルゴリズムの汎用化を実現した（正確には目指した）ライブラリと捉えるべき

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

>>417
でも、使いときの認識はコンテナ集なんでしょ？

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

>418
わかってない子だね
STLのアルゴリズムは、STLに含まれてる標準コンテナじゃなくても
自作のコンテナや、プリミティブな配列にも適用出来るんだよ

自分の考えでは
狭義のSTL：データ構造・アルゴリズムなどを含む標準「ライブラリ」
広義のSTL：汎用的なデータ構造・アルゴリズムを使う際の「プロトコル」
ちょっと無理あるかもしれんｶﾞﾅ

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

>>416
俺もPCだけだけど、どんなC/C++コード書けばどんなアセンブリコードが出てくるかは
だいたい把握しとくもんだと思うけど。
>>379見てちゃんと配列同様のコードに落ちるとか予測できるくらいにはさ。

別に四六時中アセンブリ出力眺めるわけじゃなし、ちょっと地ならししとくだけで、
リーズナブルなコードを吐くC++コードを自信を持って書けるんだから。
プロファイル取って遅かったら原因は100％アルゴリズムなわけだし。

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

>>420

>>>379見てちゃんと配列同様のコードに落ちるとか予測できるくらいにはさ。

>>379って、オプティマイザで本当に、>>393になるの？
それはそれで凄いコードだよね。

それはいいとして、
The insertion (called inline expansion or inlining) occurs only if
the compiler's cost/benefit analysis show it to be profitable.
Inline expansion alleviates the function-call overhead at the
potential cost of larger code size.
ってあるように、コンパイラのコスト/利益分析次第で展開もされる
こともされないこともあるってことで、完全に処理系（オプティマイザ
オプションも含め）依存だよね？
もしコンパイラがインライン展開がコストに合わないと判断すれば、
>>379になっちゃうんだよね？

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

まあいまどきはgcc派生だろうからそこまで心配しなくても良いとは思うがね。
ＳＴＬでダメだったら自作ってのが一番無難な流れなんだろう。

つーかＳＴＬっつーかテンプレート使えないCPPが（略

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

>>418
型があっていさえすれば相手はコンテナである必要はないよ

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

俺やお前らが、こうしたらいいのにーなんて思う最適化は
ふつーにやってくれる罠。
VC++のthiscallでは、thisポインタはECXに保持されるのだが
昔それを知らないで、「mov eax, this」と
eaxにthisポインタを持たせたプログラムを書いたことがあるが
最適化で見事にeaxが全部ecxにすげ替えられてた。

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

>>419
どっちにしてもそれで設計が変わることはないし
別に何が便利になるわけでもないんでしょ？
ささいな問題じゃん。

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

というか、STLのアルゴリズムは激しく使いにくい。
beginとendでsortするくらいならいいけどさ…。

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

>>424
ＭＳのコンパイラは最高峰だろ・・・。gccの10倍はがんばってる。

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

> >>379って、オプティマイザで本当に、>>393になるの？

疑う前に試してみなさいって。あんなもんがちゃんと最適化されないコンパイラあったら
俺はベンダに殴りこみかけるぞ。マジで。

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

>>428

そうかぁ。オレのは.NET Standardなもんで、オプティマイザーを
かけられない。なんかいじるとオプティマイザーをアンロック
したりできないかな？やっぱ安物買いの銭失いだったか・・・。

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

>やっぱ安物買いの銭失いだったか・・・。
まぁ、今のCPU性能ならよっぽど変なことやら無い限り問題ないんじゃね？
問題が出てから買い換えても遅くない罠。独自実装で最適化でもいいけど。

・・・いや、もし学生なら安いんだから買い換えとくべし。

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

>>429
試すだけならGCCでもいいんじゃないかと。

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

今時はgccも頑張ってますよ

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

86の最適化はかなり良い感じだよね、
大局が分らないと出来ない最適化や、
作った人間には分るがコードからは分らない種の最適化以外は
ほぼ限界までやってくれる。

それに引き換えミップスは・・・・はぅ～

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

86のgccはLinuxあたりでもやらない限り使う機会はそうそうないからなぁ。
MIPS系でgccの最適化マズーとか思うのも、使ってるgccが古いせいか。

枯れたハード使ってるんだけど、メーカーのサポートも枯れてるんだよね・・・。
ライブラリリコンパイルすればちょっと速くなったりするんだろうなぁ。

**名前は開発中のものです。** · 04/04/02 15:27

Linuxならiccがあるから無理してgcc使うことも無いと思うけど

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

iccって86だけでしょ?

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

>86のgccは

とむ ◆0MTMwDpCZo · 04/04/03 00:46

サーバ移転してたんだね…。気づかなかった。

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

雑談スレじゃねーぞ

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

たいして意義があるスレでもないので案外大丈夫。

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

コテ叩きスレだろ？
コテが出たからとりあえず叩かないと。

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

　　　　　　　　　☆ ﾁﾝ　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ～
　　　　　　　　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ～
　　　　　 ☆　ﾁﾝ　　〃　 Λ＿Λ　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　ヽ　＿＿_＼（＼・∀・）　＜　次の話題まだ～？
　　　　　　　＼＿／⊂　⊂＿ )　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　／￣￣￣￣￣￣／|
　　　　　　　　|￣￣￣￣￣￣￣|　 |
　　　　　　　　|　愛媛みかん　 |／