2006-01-06 [長年日記]
_ [book] C Magazine2006/1月号
本筋じゃないけど驚いたのはSUN JAVA VM のパフォーマンス。
GCJ(GCC Java:JAVAソースからネイティブコードを生成できるコンパイラ)
の記事でG++(GCC C++)、GCJ、SUN JAVA VMのパフォーマンス比較をしているのだけど、
#「エラトステネスのふるい」というコードとのこと。素数を調べるコードかな。
この3つがほぼ同じパフォーマンスなこと。
C++で書いたものとJavaVMが同じなのがすごいなー。
他の記事はこんな感じ。
・VS2005
・圧縮アルゴリズム
LZMA、PPMD、メタデータに向く圧縮法など新鮮な話題が多かった
・結城さんの連載:疑似乱数生成
乱数を発生させるのが難しいというのはよく聞くけど、
原因の1つは途中で循環小数に陥ってしまうからだそうだ。なるほど。
_ [book] プレゼンテーションの極意
amanyoさんやtmaedaさんが読んでいたので気になっていた一冊。
読んでみると、前半は自分の感覚とそぐわず。
ただ、基本を逸脱すればいいみたいな感じに思えて。
しかし読んでいるとぽつぽつと「なるほど」と思う事柄が出てくる。
よく考えてみれば、
自分の感覚に沿った話ばかり書いてあったらこの本を読む意味はないわけで、
得るものが多い本でした。
しかし、プレゼンの王道というものもあるわけで、
それを把握してから読んだ方がいい本だなと思いました。
例えば、明確に問題提起されたプレゼンは聞きやすいとか、
事実に基づいた考察は説得力があるとか。
この本は、そうした基本を守ったプレゼンでは物足りない人々、
プレゼン上級者を狙う人のヒントになるのではないでしょうか。
この本に書いてある、発表者の人柄を全面に出すプレゼンってのは面白いなぁと思いました。
確かに、それは聞きたいし聞いてて面白いと思う。
最後にもう少し言えば、もっと実際のプレゼン例を紹介して欲しかったかな。
_ [C++] 抽象クラスのデストラクタ
抽象クラス(純粋仮想メソッドを持つクラス)のコンストラクタ/デストラクタはどう書くべきでしょう?
私は最初はこう書きました。
virtual HogeClass() = 0;
virtual ~HogeClass() = 0;
まず、コンストラクタはいらない(実体化しないし)ので削除しました。
次にデストラクタもなんか文句を言われます。
シンボルが未定義とのこと。(実装しなさいと。)そこで、
virtual ~HogeClass() = 0 {} ;
とか書けばいいかなと。しかし、これは文法的に間違い(参考文献参照)とのこと。
virtual ~HogeClass(){}
が良さそうです。または、
virtual ~HogeClass() = 0;
HogeClass::~HogeClass(){}
と2行で書けばこれはOK。(でも、2つの行が離れて見づらいので前者に。)
最終的には、他のデストラクタと同様に例外を投げさせないように
virtual ~HogeClass()throw(){}
としました。
ところで、virtualのデストラクタがなぜ必要なのでしょう。
次の例を見てみましょう。
class A {}; // 親
class B : A { virtual ~B() {} }; //子
main() {
A* a = new B(); delete a;
}
delete a; で呼ばれた時にコンパイラにとっては a は A*です。
A に virtual デストラクタが無いと、
仮想関数テーブルごしの呼出しじゃなくて直接バインディングしてしまいます。
つまりBのデストラクタは呼ばれないのです。
結論:
「継承するなら仮想デストラクタを必ず書け!!」
親のデストラクタにvirtualが無いと、子のデストラクタが呼ばれない。
sheさん、会社のみなさんに多々助言を頂きました。ありがとうございました。
参考文献 virtual ~HogeClass() = 0 {} ; がダメな理由(以下の10.4.2) http://www.kuzbass.ru:8086/docs/isocpp/derived.html#class.abstract
ごめん、自分で調達したのね。。。
Javaのパフォーマンスの話。つい最近もこんな記事が出ていました。<br>Javaの理論と実践: パフォーマンスに関する都市伝説を再検証する<br> http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml<br><br>他にもJITとかHotSpotなんて技術もあるしね。<br><br>C/C++のmalloc/newが遅いってのは結構有名な話で、<br>Modern C++ Design とか、確か Exceptional C++ にも<br>高速化のために自分でアロケータを実装する話が出ていた気がします。
>amanyoさん<br>いえいえ、気になさらず。<br>面白い本だったのでお金を出す価値はありますね。<br><br>>tmaedaさん<br>なるほど、メモリ確保のパフォーマンスが一因(主因?)なんですね。<br>ガベージコレクションの方がまとめて確保開放するから最適化の余地があると。<br>Java観が変わりました。
今どきのOSでは、malloc/freeを高速化するために、slab allocatorという物を使っています。<br><br>このへんが詳しいです。<br>http://os4.hyperion-entertainment.biz/index.php?option=content&task=view&id=22&Itemid=0&limit=1&limitstart=0
おお、情報どもです!>sakuraiさん<br>slab allocator、読んでみたのですがよくわかりませんでした。。。<br>メモリの断片化を防いでどうやって確保するか、くらいまでかな。。。<br>メモリ確保解放まわりは工夫のしどころなんですね。
基底クラスに仮想デストラクタが無い場合の"VC++やg++での現実の被害"はigaさんの書かれている通りなんですけど、規格上は "the behavior is undefined" です。だから、環境によってはもっと酷いことがおきるかもしれません(し 起きないかもしれません)。規格の§5.3.5/3を是非見てみてください!
なるほど、不定なんですね。<br>(確か)EffectiveC++では<br>「不定と言うことは、HDDを初期化してもいいということであり、」<br>とかいう記述で戒めてましたね。<br>ということで、<br>デストラクタにはvirtualとthrow()を必ず付けるようクセにします。
あら。LZMAでぐぐったらここにきましたよ。<br>いやね、ちかぢか圧縮のゼミでもしようかと思ってね。
あら。わらさんいらっしゃいませ!<br>私も時々ぐぐって自分のページに辿りついてしまって、<br>「ああ、何も書いてないんだよなー」としょんぼりします。(^^;)<br><br>圧縮のゼミ、おもしろそうですねー。<br>よかったらぜひ資料公開してください!<br>圧縮というと、私はこの本が好きなんですが、わらさんは知ってそうだなー。<br>http://www.amazon.co.jp/exec/obidos/ASIN/4797325526/
あら。その本知りませんでした!<br>ただ圧縮に関する記事が載ってるCマガはほぼ自宅に網羅していると思われるので、内容次第ですね。<br>ゼミ資料は是非公開したいですね。そのためにはオリジナルを作らないとね。H.264も結局コピペオンパレードで外に出せないものになってるし。