面白かったので怖い話の反応に反応してみる

id:Dr_Caligariさんから面白い反応があったので、
俺も思ったことに対してつらつら反応してみます。
普通にコメントしようと思ったのですが長くなったのでTB返しで。

私が書くのはゲーム業界のプログラマーという狭い世界で生きている人間が思った事

ということで、俺もゲーム業界の片隅で生きていた事はあるのでその観点で反応してみます。

ディレクトリ構成が機能単位でなくプログラマの名前幽霊

これ実際に見たことあります。

アセンブラを使っていて、プロジェクトの規模が小さかった時代の名残らしいです。

恐らく俺が見たプロジェクトもアセンブリの頃の名残でした。
プロジェクト管理とかソース管理という構成管理の概念がなかったころなら、
別に良いとは思うのですが、今でもこれを引き継いでいてこれを「本気で」良いと思っている人がいることが恐ろしくもあります。

バージョン管理システムを使わない幽霊

そろそろ分散バージョン管理も試してみたいのですが、昔と違ってプロジェクトの規模が大きくなっているので、動きが鈍くなってしまったので、難しいですね。

今俺はgitで超便利ですが、頻繁にバイナリファイルをコミットすることが多いゲーム関連だとリソースをロックしたい、
という話もありますし、難しいかもしれませんね。
ゲーム業界だとPerforceやAlienbrainも検討の余地があると思います。

コミットは朝しろ　帰る前にするなと言う幽霊

コミットの谷間でたまたま通らないコードをコミットしたらしょうがないけど、どう見ても通らないソースをコミットして帰られたら、ムカつかないっすか？

いや、いるんですよ、マジで。

普通にマジで居るのは知っているので、寧ろそのためのHudsonです。
ビルド通らなければメールで通知が来ますし、
Hudsonをいれていてビルド通らないソースコードをコミットしたまま帰られた事は殆どありませんです。

不定アドレス塗りつぶしとか判りづらいバグ仕込まれたときに、本人居ないのはキツイ

のは確かですが、それがそのタイミングで仕込まれたバグならdiffみれば普通にわかりますし、
潜在的バグならとっておければ後々楽なので、俺はあまり気にしません。
勿論、イラッとしないことはないでしょうが、他人のバグもとれないプログラマはどうかとも思いますし。
（結構自分のソースしか読まない、他人のバグはとれない、という人もいますが）

手動でビルドテストしなければならない幽霊

ちなみにCEDEC2010の「タダで始めるゲーム開発自動化のススメ」というセッションで、Hudsonが紹介されます。

これからのゲーム開発には欠かせなくなりそうです。

残念ながら諸事情でCEDECはいってないのですが、去年もテスト系のセッションでHudsonは紹介されていたと思います。
自動ビルドは必須になりますが、ゲーム業界は感覚とか見た目のところもあるのでなかなか難しいですね。
GDCのセッションでも苦労している感がありますし。

オレオレコンテナしか信じない幽霊

これは難しいですね。

うちのプロジェクトはコンテナライブラリ自作してますし、EAもEA-STLというSTLに似たインターフェイスをライブラリ自作してますね。

ちゃんとインターフェイスとか規格を決めて、全社で使うとかプロジェクト共通で使うというのなら良いと思います。
EA-STLみたいにゲームに考慮した感じにつくってあるとか。
EA-STLとか普通にしらない人もいて、インターフェイス無茶苦茶で１人１人がかってに作ってるというのが最悪です。

で、STLは中華包丁という話ですが、STLは組み込み向けに最適化されているので、
protected継承などで使い勝手を買えることもできますし、
実際DS上でも実用になっています。
もしSTLがDSで使えないというのであれば使う側に問題があると思います。
例えば、どのあたりがtoo muchかあれば知りたいです。（vectorならメモリを勝手に確保するところとかですかね）
コードの展開をみても、そうそうおかしな処理をしないと思うのですが。
俺は配列もboost::arrayで統一してましたよ。

あと、勿論ハンドルクラス（weak_ptr的なもの）を自前で書いたり、
intrusiveなものを自作することはあります。ありますが、それはどうしても必要と言うときだけで、
それが汎用的な用途ではない、ということは多いです。

C++で「よくわからんから」多重継承は禁止すべしという幽霊

禁止はやりすぎたけど、積極的には使ってほしくないですね

「C++ 設計と進化」に書かれていある「多重継承は脱出用のパラシュートである。普段はいらないが必要なときには不可欠だ」というGrady Boochの意見に賛成です。

それと、ゲーム屋しか関係なくて申し訳ないですが、__m128のようなアライン必須のメンバ変数を持つクラスが多重継承すると管理が面倒なんですよね。

勿論、意味も分からず菱形継承したり、バリバリ多重継承OKというわけではないのですが、
「インターフェイス継承」がわからないのでそれも禁止という人がいたりするからです。
横断的にクラスにインターフェイスを提供した場合、どうしてもインターフェイス継承したい、ということがありますし、
vptrが問題になるようなアライン必須のメンバ変数を持つようなクラスはクラスをそもそも分離すべきです。

例えば、インターフェイスを継承する例として
「操作できる」や「フォーカスをあてることができる」というインターフェイスを差し込んだりする場合に、
インターフェイスを横断的に継承をすることがあります。
これら、インターフェイスを実装することで、等価なオブジェクトとして扱うための多重継承です。

ゲームだと、例えばキャラクタとその辺にある障害物は継承関係にないですが、
カメラフォーカスをあてられるので、カメラフォーカスに応答するインターフェイスはインターフェイス継承して、実装します。

C++は遅いしか言わない幽霊

確かにC++は遅くないのですが、前のエントリーにも書きましたが、遅くなる罠が埋まりやすいのが難しいんですよね。

実際にDSのタイトルでC++使ってないチームも居ました。

DSはメモリは少ないしCPUは遅いからキツイんだよねー。

言っていることは大変よくわかりますが、
DSの4M中、実際に使える実ヒープの2Mちょいの殆どをしめるのはメディアリソースなので、
クラス構造が持つ数byteがそのヒープを圧迫することは殆ど考えられないです。
それできついなら、リソース構造やアロケータを見直した方が良いです。
メモリがないない、といっている人はメモリの使い方が大抵無茶苦茶です。

あとARM946E-Sは結構早いと思いますよ。
67.024MHzというのは今では遅い部類に入るでしょうが、
DSレベルでやれることを考えれば普通に書いていれば遅いと感じることはないと思います。

描画周りで重いということはありますが、それはそれで不相応なことをやっているケースが殆どですし。

Luaとか既存のものより優れたスクリプトを作れるとか言い出す幽霊

コルーチン最高ですよね！

あれ無しでAI組むとか、もう無理です。

コルーチンは超便利ですね。
C++でもマイクロスレッドでいけなくはないですが。
ゲーム用スクリプトというのは社内で普通につくられたりしますが、
愚にも付かないものが騙し騙し使われていることも多く、
使い勝手が悪いが、Luaとか信用できないという理由で糞言語を使わされている感が満載なので、
LuaやSquirrelは普通に実用レベルとして使っていくと良いと思ってます。
糞社内スクリプトをつくる人はLuaを見て早く絶望して欲しいです。

……と、俺も思ったことを書きつつ反応してみました。
スライドからは省いた事もありますし、俺はこう思っていますよ、という感じです。
DSとかの開発経験は普通にありますしね。ｷﾘｯ