0.0.1aをリリースしました。i18nの対応もYapc++の機能に含めてしまおうという話でここ数日開発していたのですが、パフォーマンスを落とすかシンプルさを落とすかあるいは両方落とすかの実装しか浮かばなかったので、結局のところi18n対応はYapc++範疇外ということで今回リリースにいたりました。拡張セットとしてのi18n対応は考慮されていますし、今後のバージョンアップは主にそれの対応だと思われます。ここに書くべき記事は本家のほうへ書くことにしましたので、ここでは変わってその実装に関しての考えかたやテクを書いていきたいと思います。}と書くほうがすばらしいよという話。前者の場合はhoge.hをincludeした時点でfoo.hとbar.hまでincludeされてしまって、おまけにfoo.hやbar.hに変更が加えられてしまった場合にhoge.hはもちろんのことそれをincludeしているヘッダファイルまで変更が波及してしまうことになり、結果としてコンパイルが遅くなる。後者の場合はhoge.hの他への依存性はほぼゼロである。前方宣言を使うのは当然のことであるが、ここではそれ以上にpimplイディオムが大活躍している。implのポインタにfooやbarを格納してしまうことにより、それらのサイズや定義を知る必要がないのだ。ゆえにいくらhoge.hをincludeしているヘッダファイルがあろうともfoo.hやbar.hの変更はそれらに波及しえない。これによって変更に対する耐性が保証され、結果としてコンパイルが速くなる。pimplイディオムのメリットはそれだけではない。いやpimplの本質上、メリットがコンパイルの高速化だけでとどまること自体がそもそもおかしい。挙げだすと切りがないのだが(要するにstackにおくこととheapにおくこととの差によるメリット)、個人的に非常に興味深いのは例外安全に対する驚くべき能力である。foo.hが以下のようなアホなコードだったとしよう。};このアホクラスを使ってテストコードを書く。部分で例外が発生する。依存したクラスのおかげで自分のクラスまで非例外安全になるなんてなんてすばらしいのでしょう。pimplイディオムの黒魔術にかかればそんな問題も一発。hoge.hとhoge.cppを以下のように改造する。しようが決して例外が発生することはない。と本来のクラスに実装をわけて構成をわかりやすくしたり、(時と場合によるが)本体のコピーやswapが断然速いなど、pimplにはたくさんのすばらしいメリットがある。そんなにおいしいことばかりでもなく、heapを使う分のパフォーマンス低下は当然考えられる問題だ。メリットとデメリットを計算したとき、最終的にはやはり符号は+になることだろう。rhs.pimpl_;が思った通りにならないはずです。09:57>思った通りにならないはずです。a;//ここでbがデストラクタされる、ポインタ先を解放する}//ここの時点で、aはすでに解放された不正なポインタ指してる。16:06>思った通りにならないはずです。00:29pimpleイディオムでauto_ptrを使うこと自体が拙いです。#ついでに、pimpleにboost::shared_ptrを使うのも危険です。うっかりしたoperator=を実装すると、複数のオブジェクトで同じpimpleを共有してしまうので。.#ついでに、pimpleにboost::shared_ptrを使うのも危険です。うっかりしたoperator=を実装すると、複数のオブジェクトで同じpimpleを共有してしまうので。19:18ふとしたきっかけで、久々にこのページに出会いました。自分のコメントに補足を書き足していきます。Userさんやhiroseさんのおっしゃっているのと同じことを指摘するつもりで最初にコメントを書きました。曖昧な記述で混乱を招きましたら、申し訳ございませんでした。今になって気付いたのですが、実際にはrhsがconstのためコンパイルエラーになりますね(代入元がconstだとauto_ptrはエラーになります)。どちらにせよ、「参照カウントではなく所有権の移動という挙動を持っているためauto_ptrでは問題がある」ということに変わりはありません。最初にコメントをしたとき私はまだ知りませんでしたが、auto_ptrを使ってはならないもう1つの理由があります。fooやbarのデストラクタ(根本的にはhoge::implのデストラクタ)が呼ばれないのです(こっちのほうがよっぽど深刻!)。pimpl_のデストラクタで、hoge::impl(不完全型)へのポインタに対しdeleteするのがその原因です。boost::scoped_ptrだとこれを検出してコンパイルエラーにしてくれます。これの対処は次のいずれかで可能です。第3版を読みました会社にあったので流し読み。1)とかいう仕様(ライブラリ)が紹介されていて改めてC++の進化に期待するようになりました。C++のところを読んでみたりすると実感が持てるわけです。STLの決定的な欠如であるshared_ptrや、functionオブジェクト、気持ち悪いマジックナンバーを取り除いた汎用bind、regex(これはやりすぎ?と個人的に思うのですがあればあったで便利かな)、tuple(pairなんてうんこですよ)など、これでやっと標準ライブラリとしての体裁が整いそうです。Libraryという本を読みました。本の最初の「STLはオブジェクト指向のライブラリではない」(よく覚えてない)という一文には笑いました。この一文から著者のOOPに対する(というよりOOPを最新技術のようにとりあつかい、それを使えなければプログラマじゃないなどと思っている人に対する)思いとSTLに対する愛が感じられます。内容としても各機能ごとに例が示されていてわかりやすく、以前順列の生成が面倒くさくてしょうがないと書きましたが、それはnext_permutationとprev_permutationで生成できるらしいです。1STLってやっぱり偏ってるとしかいいようがない。大好き子なら一度はやりたいと思うはずの文字列テンプレート引数の対応。一応以下のようなことはできるようになっている。0;}まだ未実装だけど以下のような記法も導入したい。0;}大体これだけあれば不自由しないはず。いう仕様だから仕方ないけど。is:http://dev.ariel-networks.com/Members/matsuyama/gcc1/tbping2010/04/15宣伝:C/C++のための開発補助ツール、GCCSenseをリリースしました前回と同じように宣伝です。知っとるわいという人はそのまま閉じてください。GCCSenseはC/C++のための開発援助ツールで、コード補完・自動構文チェックなどの機能を搭載しています。プロジェクトのページは以下になります。ここからソフトウェアやドキュメントを入手できます。http://cx4a.org/software/gccsense/index.ja.html以下のページ(僕の個人ブログ)で簡単な説明とスクリーンショットおよびデモを閲覧することができます。http://d.hatena.ne.jp/m2ym/20100415/1271306690宣伝以上です。