9-Laboratory –

わざわざ記事にしよう。
『バイオニックコマンドー』が売上不振、製作者の熱意が伝わるだけに悲しいものがある:はちま起稿
PS3版　4700本
箱〇版　3300本
らしい。おいおい、おいらは1/3300だったのか。。。。
ちょくちょくこのブログでも、まだかまだかと期待している記事を幾つか書いたのに。。
ちょっと前のエントリにも書いているけれど、すごい丁寧に作られている作品で、
本当に元ネタに対するリスペクトとか、情熱とかは凄まじいものを勝手に感じていたんだけどなぁ。

ちょっと6/25というタイミングが悪かったのと、宣伝をあまりやっていなかったせいだろうか？
まだ遅くないので、皆さん買いましょう。
尖ったところもないけれど、安心して楽しめるかと思いますヨ。

C++を触れない状態なのに、｢C++FAQ｣を読み直していた。
仮想関数のポリモフィックさが同じに保たれない場合があるみたい。

/**/
class Base
{
public:
	virtual ~Base()
	{
		puts("~Base()");
		Func();/*これは何を呼ぶ？*/
	}
	virtual void	Func()
	{
		puts("Base::Func()");
	}
};
/**/
class Deri1 : public Base
{
public:
	virtual ~Deri1()
	{
		puts("~Deri1()");
		Func();/*これは何を呼ぶ？*/
	}
	virtual void	Func()
	{
		puts("Deri1::Func()");
	}
};
/**/
class Deri2 : public Deri1
{
public:
	virtual ~Deri2()
	{
		puts("~Deri2()");
		Func();/*これは何を呼ぶ？*/
	}
	virtual void	Func()
	{
		puts("Deri2::Func()");
	}
};
/**/
int main()
{
	Deri2 d;
	d.Func();/*これは間違いなくDeri2::Func()を呼ぶ*/
	puts("start destruct");
}

子のデストラクタが呼ばれた時点で、その子は仮想関数のリストから削除されているという事らしい。
そりゃあ、子が消えた状態で子を呼べてしまったら不味いですね。
#別にこんなことは知らなくても良さそうではありますが。

今に始まったことではないけれど、このブログ、reblogが多すぎでないかと。
ので、reblog的行為は今後減らします。参照とかはするけど。

リスタートの位置は確かに腹が立つが、それを補って余りある程丁寧に作られた作品。
｢BionicComando｣のキャンペーン、クリアしました。イージーだけど。

以下、多分ネタバレの可能性があるので注意。
more »

ためになりそうなので紹介。

･直感的である。
･シンプルである。
･間違った使い方をしづらい。
･副作用が無い。
･矛盾が無い。
･よく枯れている。
API Principles:LightSleeper

あと考えられるのは、
･書式やコンセプトが統一されている。
･間違って使っても何とかしてくれる。
(090628追記:一概にそうとも言えないか。なんらかの方法で、間違いを指摘してくれるとかの方が適切か。)
とかか。

世界的人気を誇る至高のエンターテイナー、マイケル・ジャクソン氏が死去
おい、まじかよ。。。。。。
ご冥福をお祈りします。

飽きっぽい人達: オタク商品研究所plus
わかります。
自分の適応力の問題もあるんだけど、この手の潮流の変化はどうも目まぐるし過ぎるような気がする。
作り手側がこれと決めたものを、ずっと丹念に作り続ければそのうちみんなわかるかも知れないと妄想。

供給が追いついちゃう(いろんなものを簡単に出せちゃう)から、｢真新しさ｣に対しての消費側の感覚が薄れちゃって
浮動層ができてしまうのかなぁ？と今思った。

#例えばゲームとかだとアニメ作品などに比べればホイホイとはだせないから、
#結果的に大体同じような潮流がずっと続いているとか？

mmioとか滅多につかわないのだけれど。
PlaySound(xxx, SND_MEMORY | SND_ASYNC) is almost always a bad idea.
Windows 7 fixes the PlaySound(XXX, SND_MEMORY|SND_ASYNC) anti-pattern

PlaySound(,SND_MEMORY | SND_ASYNC );はよろしくないらしい。

SND_MEMORYは、メモリから再生するのだけれど、WaveのAPIから読んだものでなくても、
良くてAPIユーザのメモリのポインタを渡すこともできる。
SND_ASYNCは、非同期で再生を行う。例え前の音声を再生中でも呼び出しを即座に帰す。
つまり実際の終了タイミングを知る方法もない。

で、この二つを同時に使ってしまうと、実際に再生が終了するタイミングがわからないものに
メモリを渡しているので、運が悪いと再生中の音源のメモリを解放してしまいクラッシュしてしまう。
解決策としては、PlaySound(NULL,0,0)をそのメモリの解放前に呼べば
本当に再生が終わるまでブロックしてくれるので、これから戻ってきたときに解放すればいいらしい。

この手の｢APIの実装に依存するコード｣はかっこよくないと考えたのかは知りませんが、
Windows7の実装からは、バッファのコピーをAPI内部で持つようにしたので安心安心。

というWindows7の宣伝。

体調が思わしくなさ過ぎるので、紹介だけして寝る。
Dan Kogai さんの404 Blog Not Found にてLua本が紹介されている模様。
→なんてめんこい言語 – 書評 – 入門Luaプログラミング

fatal error: method definition not in @implementation context – macosx.com
｢method definition not in @implementation｣とか出るんだけど意味がわかりません。
→循環参照じゃね？
→id使えば解決さ
→お前ら、idで誤魔化さずにちゃんと型つけて返せよ。。。

なんかgccが出すObjectiveCのエラーは問題の本質がわからなくするようなエラーばかり出す気がする。
確かに循環参照しているときは面倒なのでidにしたら何も考えずには済みますが。

Hoge* hoge = [[[Hoge alloc]init]autorelease];
id*hoge2 = hoge;
[hoge2 func];/*Hogeにfuncがあったらこれでいけちゃう*/

この手のダックタイプ的なコードとかって個人的には好きではないのです。
・protcolが実装されていない場合。
・implementsがちゃんと入っていない場合。
・型に存在しないプロパティ、関数を呼ぶ場合
は問答無用でコンパイルを止めて欲しいものです。

BestSoftwareWriting では、動的言語であろうが、静的言語であろうが関係なくて、
テストをいかに堅牢に作成するかが鍵です。みたいなことを書いていましたが今は
あんまり信用していなくて、関数のシグネチャが変わったとき等はちゃんとコンパイラは
全てに対して警告を出すべきだと思うようになりました。
シグネチャが変わった際にそれが影響を受ける実装部は宣言部分からは明らかではないから。
結局記憶力便りになってしまっている気がする。

オチ無し。

追記:
じゃあどうやって解決しているのさ？という話です。
余りキレイだとは思えないかもしれませんが、
・ヘッダには構造体orプロトコルをimportする場合に限りimportを書く
・そうでない場合は全て前置宣言で済ます。
・ヘッダのimportは.m内でのみ行う。
こうすると各.mがimportだらけになってしまいますが、
大してコンパイル速度が落ちるということは無いのでひとまずこれでといったところ。