堕天使の煉獄

なにげにまだちまちまＰＧやってたり。

vc++2008のsp1から使える様になったc++11の先取りライブラリtr1で
とりあえずregexとshared_ptrがboost無しで使える様になった～ってので
それだけで満足してたのですが。

なにげにその辺の調べ物をしてると、イヤでも他のc++11の新機能の情報も
目に入ってくるわけで。

んでも、vc++2008だと入ってないってのも多くて
結局絵に描いた餅なんですよね。

それを眺めてヨダレを垂らす感じになりそうで、なんとなく目を背けてたのですが。

と言うのも、vc++2010がかなり出来が悪いんですよね。
xpだと全体的にもっさり動作（wpfの所為）
インテリセンスが糞重い。
c++0xの対応も中途半端。
と、悪い要素が多くて。

win7マシンに買い換えてvc++2012にした方がよさげなかんじだなーと。

ところが、いつのまにやらvc++2010をＸＰで高速化する方法。
みたいなのが出てきてて。

「Windows Automation API 3.0」とかいうのを入れれば
速くなるらしい、と。

どうもwpf関係のxpでの描画速度が向上……（というか正常化と言うべきか？）するそうな。

入れて見ようと思ったら、なんかすでにWinUpdateですでに入ってるっぽい。
てことでｖｃ++2010を久しぶりに起動。
相変わらず初回起動時のみ重いのはＷＰＦの仕様だとして
起動後は確かにあの妙なもっさり感というかレスポンスの悪さは改善している模様。

が……インテリセンスがまったく出ない。

ちょっとググると、vc++2010ではc++/CLIではインテリセンスが使えないそうな。
CLIなんて使ってないんだけど？？

さらにググってみると、CLIを使わない設定にすればインテリセンスが使える様に。
っていう記事もあったのだけども
一向にウンともスンとも……

他の記事では、普段は使えてるけど急に使えなくなったっていう記事が何件かＨＩＴ。
その現象はvc++2008とか昔のＶＣでも良くある話なのでアレなのですが
一度は使えてるのは確かな模様。
うーん。スタンダード版以上だけで、ＥＥだと使えないとかなの？？

いまさらインテリセンス無しで開発とかヤダー！
ってかんじで致命的ですよね。

が、未練がましくいろいろググってると
セキュリティ関係のアップデートパッチKB2876217を入れると
ｘｐのｖｃ++2010でインテリセンスが効かなくなる現象が起こる。
という2ｃｈのカキコがヒット。

しかもｖｃ2010起動時に他のブラウザの画面とかに切り替えると
マウスカーソルがちらちらと砂時計アイコンに変る現象も症状として上がってて
もろおんなじ現象がうちでもおこってたり。

たぶんなんか裏でインテリセンスのＤＢテーブルみたいなの作成してるから
そんなんなんてんだろーなとかおもってたのですが
（インテリセンス使えないのにそれで使用するために
作成されるファイルは作られてるんですよね。
なのにCLI切ったら使えるという記事もあるし何で使えないんだろう？　とおもてた）

したらKB2526044という上の不具合のパッチが見つかる。
んでそれ入れて見たら、インテリセンスがようやく表示されたっ！
さらに砂時計点滅の現象も消えたし。

アップデートのパッチがセキュリティ関係でなんかしてて
インテリセンスを阻害していたというファッキンな結果で
そのパッチは自動では入ってないという。

糞ファッキンＭＳめ……。

んでまあ、とりあえずまともにvc++2010は使える様になったり。
今のところ速度的にも以前つかってた時はもう、イライラが募ってとてもじゃないけど
継続して使うのは無理ってレベルだったのが、ほとんど気にならないレベルになってたり。


ということで、c++11の新機能を盛り込んでまた組み直しをはじめたですｗ

んでも、肝心のRange-base for文がvc++2012からとか、残念なところもまだあるのですが。

型推論のautoが使える様になるのは嬉しいかな。

とくにイテレータまわりで使えるのがうれしい。
vector<int>::iterator it = v.begin();
が
auto it = v.begin();

と、さくっと短いタイプで書けるのと
コンテナの中身のデータ型とかいちいち書くのもめんどくさかったんですよね。
今まではtypedefで少しでも楽を……とかちまちまやってたので。

今まで何でなかったのかの
std::unordered_map
ハッシュマップ

auto_ptrの後継
unique_ptr

shared_ptrの補助機能？
std::make_shared

あとはラムダ式と右辺値参照あたり。

有用だと思ったのはこの辺でしょうか。

とくにunique_ptrは結構つかう機会が多そうです。
今のところスマートポインタ欲しいような所はみんなshared_ptrにしてたのですが
shared_ptrは重たいというのは昔から言われていたことなので。

そんでもって、寿命が限定的であったり、コピーが行われないような
限定的な部分にまでshared_ptrは重装備すぎるので無駄が多い。

と言う部分は気になっていた所ではありましたし。

かといってauto_ptrは残念な感じので、ついに非推奨機能のレッテルを貼られるまでに。
でかわりに追加されたunique_ptr。

shared_ptrのとくに重い部分は生成の部分なのですが
それを高速化するmake_sharedなのですが
こんなかんじでつかうらしい
shared_ptr<Hoge> sp = std::make_shared<Hoge>();

通常のmake_shared使わない時は
shared_ptr<Hoge> sp(new Hoge());
こんなふうに書くのですが
この場合だと、オブジェクトの生成と参照カウント用のなんかの二回newが行われるのが
make_sharedをつかうとnewが一回ですむのだとか。

んで最初はこんなかんじ？
std::shared_ptr<Hoge> sp = std::make_shared<Hoge>(new Hoge());
とか書いてコンパイラに怒られたりしてｗ
std::shared_ptr<Hoge> sp = std::make_shared<Hoge>(コンストラクタの引数);
と、make_sharedのあとの()にはコンストラクタの引数を書くみたい。

なにげにtr1もそうだけど、日本語の解説サイト少なすぎ……。
その辺、c++もう過去の遺物？　という空気を感じたり感じなかったり……。

んで、そこで迷ったのですが
std::make_shared<クラス名>(コンストラクタの引数);
となっているのですが、派生クラスをぶっ込むときはどうするのだ？　と。
すまぽ代入時に暗黙のキャストしてくれるのだろうか？？
そんでもって、

void SetHoge(Hoge* hoge){
shared_ptr<Hoge> sp(hoge);
}

なんて言う関数があって
SetHoge(new HogeMoge());

なんてやる場合（HogeMogeはHogeクラスの派生クラスだとおもいねぇ）

この場合、すでにオブジェクトはnewされた後なので
make_sharedを使う意味はないですよね。
そもそもmake_sharedの生成時にポインタを渡す事できないし。

てか生成をmake_sharedで行うことによって
newの回数へらして速度ＵＰなのに
事前にnewしてオブジェクトを先に生成してる場合
なんのアドバンテージもないよなぁ。

そうなると、make_sharedっていつ、どういう状況で使うんだよ？　とか思ったり。
基本、スマートポインタが必要なのって
オブジェクトをnewしてコンテナにぶち込んだりして
コンテナの中身を消したりしたときにdeleteも勝手にやってくれるっていうのが
よく使う事例だったりするわけで。
そんでもってその時には大抵、ファクトリパターンとかが使われるのですが
基本、生成したオブジェクトを返す形になるので
make_sharedは使うに適してないのですよね。
んでもそれ以外の用途でshared_ptrを使うところがない……。

限定的な使用（単一のスコープ内で使い捨てるようなケース）
では軽量なunique_ptrがあるわけだし。

なにげに右辺値参照と合わせ技で
コンテナに入れるのでもunique_ptrが使えるし。

その場合は、unique_ptrの定義である
複数のunique_ptrのインスタンスが同一のメモリ領域を管理することはない。
ていうので、operator=で代入することが出来ないのですけども
そのかわりc++0xで追加されたstd::move()という関数があって
右辺値を破壊してくれるものがあってそれで
インスタンスが常に一つであることが保証されてて
むしろコンテナにオブジェクトのポインタ入れてるときって
基本的にshared_ptrの弱点でもある循環参照を起こさないためにも
無闇にいろんな所にスマートポインタをコピーする事なんて
前提条件として設計的に行わないので、実際、たった一つしか存在しないっていうのは
むしろそうであって欲しい状況のが多いような気がする。

単純に、コンテナからはずしたら勝手にdeleteしてくれるっていう部分の機能だけ
あれば良くて、なおかつそれが低コストで行えれば言うこと無いわけで。

そうなると、無駄にコスト高い上に、無闇にコピー出来てしまうshared_ptrよりも
積極的にunique_ptrを使っていく方向になりそうな予感。

わりと今組み直してるところでも、
これってホントにshared_ptrである必要あるのか？
unique_ptrで十分じゃね？
っていう状況が多くて戸惑っているところだったり。

以下インターフェースをつかってコンテナに登録して、
コンテナまわしてオーバーライドされたDrawメンバ関数を読んでる例

//情報クラス登録
void SetInfo(IDxInfo *info){
　　　　unique_ptr<IDxInfo> sp(info);
　　　　INFO_LIST.push_back(move(sp));
}
void Draw(){
　　　　//情報クラスリストから描画
　　　　for_each(INFO_LIST.begin(),INFO_LIST.end(),[](const unique_ptr<IDxInfo>& p){
　　　　　　p->Draw();
　　　　});
}

ポインタのコピーが出来ないため
コンテナに入れた物をまわして使う場合は
参照で行う必要があるのだけども

for_eachにラムダ式と新しい機能ガツガツ使う感じになってて
なんかもう、以前のc++03とかの頃には戻れそうもないかんじぽ。

馴染んでくると便利すぎるですc++11。

そのうち、いろいろ覚え書き兼ねて
新機能まわりまとめてページにしたいところ。
日本語の解説も少ないことだし。

んでも
vc++2010のstd::to_stringが片手落ちどころじゃない欠陥実装でワラタ。
どうにもCLIにインテリセンスがないのは開発が間に合わなかったなんて話もあるし
c++0xの対応も中途半端ってところからも
vc++2010はどうにも慌てて無理に出した急場しのぎの欠陥ｖｅｒだという印象が
さらに強くなったり。

てか10年前にあっても普通だろto_string的な機能って。
これがstdに追加されたっても、今頃感が半端無いのですが。

なのに、中身が
long long
unsigned long long
long double
の三つの型しか受け取らないという……
ただのintも使えないとかアホかと。

んまあ、とっくに数値←→文字列みたいな汎用性の高い物は
みんな自前で作った関数使ってるか
boostのlexical_castとか使ってるので
べつに困ることも全くないとおもわれるのですが。

そんなんよりも、まともなforeachとかＵＮＩＣＯＤＥとか文字コード周りとか
もっと基本的な所をしっかりとしてもらいたいところ。