○○とゲームプログラミング 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/11 22:45

>>256
よう、とむ、久しぶりｗ

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

そもそも○○(まるまる)って付けたのがとむだってことがわかってねーようだな。
>>1と>>6、プロクシまで使ってご苦労なこった。

とむ ◆0MTMwDpCZo · 04/03/12 00:22

>>254
時々見てるけどね。
なんかね。
アレだよね。

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

なにいってんだとむ
どっかのクソコテがアレなことするからアレなんじゃないか
アレ気取ってないで少しはアレしたらどうなんんだ

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

コテハンが出てくるたび切れてる奴がうざい。
お前はコテハンにレイプされた過去でもあるのか？

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

コテハンうざいって言ってる奴がうざいって言ってる奴もうざい。

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

以下ループネタ禁止。

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

俺はこれまで一度も「うざい」などとガキがやるような無意味な不快感の表明をしたことはない
ただ最初は俺ひとりだったはずが、最近叩いてる奴が一人増えたみたいだ。
こっちは頭があんまりよくなさそうだな。

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

午後は○○ゲームプログラミング♪

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

おまいらのためのスクリプトです。活用してください。

<?php
print("コテハン");
for($i=0;$i<1000;$i++)
{
print("うざいって言ってる奴が");
}
print("うざいって言ってる奴もうざい。");
?>

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

>>266
凄く便利ですね

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

>>264
うざっ

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

凄く便利って言う奴が便利

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

じゃあここいらで

FC版サンサーラナーガとゲームプログラミング

いってみようか！
まずね、くそ。
いけね、おわっちゃった。

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

技術と関係ない雑談とゲームプログラミング Rev 3.0.0

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

>>270
牛、なにもわからずレーザー光線で牛を殺しまくるゲームと認識した。
街から出ると死がまってるｗ

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

GBAとOO(C++)とか。
あのメモリでSTLを使うのは、やっぱ無謀か…

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

議論とかしてねーで
○ender○are
のヘッダうｐとか

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

>>273
なんでカスタムアロケータ書かないの？

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

カスタムアロケータ書けば問題ないのかな？
というか、試してないです！ごめんなさい。
先行の実例があれば参考にしたいな、と。

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

前略
#ifndef RWCORE_H
#define RWCORE_H
中略
#endif /* RWCORE_H */

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

>>273
木になる
全部、動的確保なしでやんのもうやだ

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

最近のC++の方向性ってどう思う？
ジェネリックプログラミングって無駄にテクニカルになっているだけで
再利用性はともかく、書いたやつ以外理解できないコードになりがちな気がする・・・

うちじゃメインＰＧがテンプレートを駆使してゴリゴリ書いてて、
とりあえず動くんだけどその部分は本人しか理解できないから保守できないとか、
そういうチトやヴぁい状況になってきてるんですけど・・・
なんか、可読性という面だけ見るとアセンブラで開発してた頃みたいだ。
＃ちなみにメインの人はやねうらおとModernC++Designをこよなく愛しているようでつ・・・

こういう状況ってうちだけ？おまいらの所はチーム全員がC++完全に理解してる？

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

>こういう状況ってうちだけ？
>おまいらの所はチーム全員がC++完全に理解してる？

ウチのメインPGは、
C++そのものに関する理解度は卓越してるかもしれないけど
STLや標準ライブラリは控えめにしろだの、継承は控えろだの
意味不明なコスト感覚の持ち主で疲れる。
だったら素直にC言語にしろよとｗ

その癖、妙で半端な仕様のへんてこmapだのへぼへぼvector
をテンプレートで自作っては、その使用を推薦する。

かんべんしてくれよ、オヤジ。

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

>>279
>ジェネリックプログラミングって無駄にテクニカルになっているだけで
>再利用性はともかく、書いたやつ以外理解できないコードになりがちな気がする・・・
これは確かにある。
もう、オブジェクト指向がどっかいっちゃって
やたら難解なコードになってるだけで大した効果が得られなくなっているのも特徴だと思う。

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

関数内無名関数とかクロージャとかあればもう少しすっきりするのにね、とか。

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

昔：アセンブラでゴリゴリ書かれてて書いた奴以外理解不能。
ちょい前：Ｃでポインタとキャストとマクロを駆使してゴリゴリ（ｒｙ
現在：C++でテンプレートを駆使してゴリゴリ（ｒｙ

ようは、ゲームじゃ再利用性なんて考えてる奴はいないってことでＦＡ？

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

>>280
そーゆーあきらかにアレなのはどうしたもんだろうね。

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

「べたで作る」という行為がありまして、とりあえずその場で動くものを作る
再利用は考えない。

でも、次にあるかもしれない....で関数化＞ライブラリ化＞クラス化と
いろいろ考えるうちに回り道がはじまる。

回り道が回り道を誘発しコードがかえって複雑化する。

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

>283
禿同

テンプレートに凝るバカはアセンブラに凝るバカと同じ匂いがしますので、近寄りたくありません。
つーん

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

再利用、拡張を考えないのはアフォ

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

コードが理解不能かどうかと再利用性は関係ないぞ
再利用できないのはインターフェースの問題でしょ

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

JavaやC++のクラスって、サブクラスを作ると
スーパーのprivateじゃないメソッドが全て使用可能になるよね？
これって、100個のメソッドを持つクラスから100個のメソッドを持つサブを作ると
計200個のメソッドになって激しくウザい状況になるし、
サブで制限出来るようになるとわかりやすくなると思わね？
仮想クラスなんて最大公約数的仕様になってる訳で、大概上のようなウザい様相になる。

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

最大公約数とはおもしろい捉えかたをするなぁ
そんなこと考えたこともなかったよ

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

そういう時は継承じゃなくて委譲でやるんじゃないの？

**ツッコミ中** · 04/03/22 20:02

てーか、100個もメソッド持つクラスを作るなよ。

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

>>289
privateやprotectedで継承してusingでpublicに移せばいいじゃないか

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

アフォか再利用のためのテンプレートだろが
だいたいジェネリックとOOは全然関係ない

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

ジェネリックは関数型言語からだね。
Haskellとか見れば、C++がテンプレートでものすごく汚く解決していることを
普通に(かつ高度に)実現しているのが分かると思うよ。
そのかわり所謂高級アセンブラ的な部分がほとんどなくなってるわけだけど。

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

この辺が参考になるかな
http://www.radiumsoftware.com/0305.html#030516

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

関数型言語でプログラムしたくてもコンシューマだと環境がねーよ
結局、C++でごりごりやるしかないわけだが
いつになっても所詮は組み込み系だよ

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

C++はプログラマーが職を失わない為という理由で
無駄に難しく作られたプログラムだとは本当だろうか？

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

んなアホな

とむ ◆0MTMwDpCZo · 04/03/23 07:26

>>298
ストラウストラップの偽インタビューとかに書いてあったね。

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

「奥が深い症候群」だね。
何でも使えるようにするから、読みやすさも考えずになんにでも使っちゃう
人が出てくるんだ。しかも、何か高度なことをしているような気にさせて
くれるのが、そういうのを加速しちゃう原因か。

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

>>288
コードの再利用性と可読性は一見無関係に思えて
実は非常に重要な関連があると思うぞ。

そもそも再利用性とは何の（誰の）ためのものか？って事を考えると、
チーム開発などで"自分以外の誰か"がコードを使いまわすことで
新たに書き起こす手間を省きましょうというのが本来の目的だと思う。

しかも、その"誰か"が自分と同等以上の能力を持っている保証は無く、
再利用したコードのデバッグは自分以外の奴がやる事になるかもしれないし、
そもそもコードが再利用されるときに自分はその場にいないかもしれない。

そのコードが本当に"再利用可能"であると言うのなら、運用面から見た再利用性も
考えた実装方法を追求する必要があると思う。

開発効率の向上を目指すのならば、単なる技術屋の自己満足ではなく
多くの人に理解でき、デバッグもしやすい書き方をするということは重要だと思う。

そりゃ、自分だけが使いつづける分にはトコトンやっても良いんだろうけど、
テンプレートバリバリのテクニカルオナニーライブラリなんて
誰も引き継げなくて１から作り直すってことも多いので…

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

メインメモリが64KBしかないんですよ。下っ端にはそれがわからんのです。

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

>>288
激しく賛成、再利用が出来ないプログラマのコードは必ずと言って良いほどインターフェイスの重要性を軽視している
実装に対してプログラムをするな、インターフェイスに対してプログラムせよというオブジェクト指向の基本中の基本ができない無い事が多いと思う。
これがキチンと出来ていれば、実装コードは多少汚くても、交換するのが簡単なのだが
いくらコードを丁寧に書いても、この部分がおざなりになっているコードは煮ても焼いても食えないものになる。
テンプレート以前の問題なんだよな。

**名前は開発中のものです。** · 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

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