堕天使の煉獄
2013-10
23
02:22:43
うーん、意外にもう戻れない感じぽ
なにげにまだちまちまPGやってたり。
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をXPで高速化する方法。
みたいなのが出てきてて。
「Windows Automation API 3.0」とかいうのを入れれば
速くなるらしい、と。
どうもwpf関係のxpでの描画速度が向上……(というか正常化と言うべきか?)するそうな。
入れて見ようと思ったら、なんかすでにWinUpdateですでに入ってるっぽい。
てことでvc++2010を久しぶりに起動。
相変わらず初回起動時のみ重いのはWPFの仕様だとして
起動後は確かにあの妙なもっさり感というかレスポンスの悪さは改善している模様。
が……インテリセンスがまったく出ない。
ちょっとググると、vc++2010ではc++/CLIではインテリセンスが使えないそうな。
CLIなんて使ってないんだけど??
さらにググってみると、CLIを使わない設定にすればインテリセンスが使える様に。
っていう記事もあったのだけども
一向にウンともスンとも……
他の記事では、普段は使えてるけど急に使えなくなったっていう記事が何件かHIT。
その現象はvc++2008とか昔のVCでも良くある話なのでアレなのですが
一度は使えてるのは確かな模様。
うーん。スタンダード版以上だけで、EEだと使えないとかなの??
いまさらインテリセンス無しで開発とかヤダー!
ってかんじで致命的ですよね。
が、未練がましくいろいろググってると
セキュリティ関係のアップデートパッチKB2876217を入れると
xpのvc++2010でインテリセンスが効かなくなる現象が起こる。
という2chのカキコがヒット。
しかもvc2010起動時に他のブラウザの画面とかに切り替えると
マウスカーソルがちらちらと砂時計アイコンに変る現象も症状として上がってて
もろおんなじ現象がうちでもおこってたり。
たぶんなんか裏でインテリセンスのDBテーブルみたいなの作成してるから
そんなんなんてんだろーなとかおもってたのですが
(インテリセンス使えないのにそれで使用するために
作成されるファイルは作られてるんですよね。
なのにCLI切ったら使えるという記事もあるし何で使えないんだろう? とおもてた)
したらKB2526044という上の不具合のパッチが見つかる。
んでそれ入れて見たら、インテリセンスがようやく表示されたっ!
さらに砂時計点滅の現象も消えたし。
アップデートのパッチがセキュリティ関係でなんかしてて
インテリセンスを阻害していたというファッキンな結果で
そのパッチは自動では入ってないという。
糞ファッキンMSめ……。
んでまあ、とりあえずまともにvc++2010は使える様になったり。
今のところ速度的にも以前つかってた時はもう、イライラが募ってとてもじゃないけど
継続して使うのは無理ってレベルだったのが、ほとんど気にならないレベルになってたり。
ということで、c++11の新機能を盛り込んでまた組み直しをはじめたですw
んでも、肝心の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());
とか書いてコンパイラに怒られたりしてw
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の回数へらして速度UPなのに
事前に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はどうにも慌てて無理に出した急場しのぎの欠陥verだという印象が
さらに強くなったり。
てか10年前にあっても普通だろto_string的な機能って。
これがstdに追加されたっても、今頃感が半端無いのですが。
なのに、中身が
long long
unsigned long long
long double
の三つの型しか受け取らないという……
ただのintも使えないとかアホかと。
んまあ、とっくに数値←→文字列みたいな汎用性の高い物は
みんな自前で作った関数使ってるか
boostのlexical_castとか使ってるので
べつに困ることも全くないとおもわれるのですが。
そんなんよりも、まともなforeachとかUNICODEとか文字コード周りとか
もっと基本的な所をしっかりとしてもらいたいところ。
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をXPで高速化する方法。
みたいなのが出てきてて。
「Windows Automation API 3.0」とかいうのを入れれば
速くなるらしい、と。
どうもwpf関係のxpでの描画速度が向上……(というか正常化と言うべきか?)するそうな。
入れて見ようと思ったら、なんかすでにWinUpdateですでに入ってるっぽい。
てことでvc++2010を久しぶりに起動。
相変わらず初回起動時のみ重いのはWPFの仕様だとして
起動後は確かにあの妙なもっさり感というかレスポンスの悪さは改善している模様。
が……インテリセンスがまったく出ない。
ちょっとググると、vc++2010ではc++/CLIではインテリセンスが使えないそうな。
CLIなんて使ってないんだけど??
さらにググってみると、CLIを使わない設定にすればインテリセンスが使える様に。
っていう記事もあったのだけども
一向にウンともスンとも……
他の記事では、普段は使えてるけど急に使えなくなったっていう記事が何件かHIT。
その現象はvc++2008とか昔のVCでも良くある話なのでアレなのですが
一度は使えてるのは確かな模様。
うーん。スタンダード版以上だけで、EEだと使えないとかなの??
いまさらインテリセンス無しで開発とかヤダー!
ってかんじで致命的ですよね。
が、未練がましくいろいろググってると
セキュリティ関係のアップデートパッチKB2876217を入れると
xpのvc++2010でインテリセンスが効かなくなる現象が起こる。
という2chのカキコがヒット。
しかもvc2010起動時に他のブラウザの画面とかに切り替えると
マウスカーソルがちらちらと砂時計アイコンに変る現象も症状として上がってて
もろおんなじ現象がうちでもおこってたり。
たぶんなんか裏でインテリセンスのDBテーブルみたいなの作成してるから
そんなんなんてんだろーなとかおもってたのですが
(インテリセンス使えないのにそれで使用するために
作成されるファイルは作られてるんですよね。
なのにCLI切ったら使えるという記事もあるし何で使えないんだろう? とおもてた)
したらKB2526044という上の不具合のパッチが見つかる。
んでそれ入れて見たら、インテリセンスがようやく表示されたっ!
さらに砂時計点滅の現象も消えたし。
アップデートのパッチがセキュリティ関係でなんかしてて
インテリセンスを阻害していたというファッキンな結果で
そのパッチは自動では入ってないという。
糞ファッキンMSめ……。
んでまあ、とりあえずまともにvc++2010は使える様になったり。
今のところ速度的にも以前つかってた時はもう、イライラが募ってとてもじゃないけど
継続して使うのは無理ってレベルだったのが、ほとんど気にならないレベルになってたり。
ということで、c++11の新機能を盛り込んでまた組み直しをはじめたですw
んでも、肝心の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());
とか書いてコンパイラに怒られたりしてw
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の回数へらして速度UPなのに
事前に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はどうにも慌てて無理に出した急場しのぎの欠陥verだという印象が
さらに強くなったり。
てか10年前にあっても普通だろto_string的な機能って。
これがstdに追加されたっても、今頃感が半端無いのですが。
なのに、中身が
long long
unsigned long long
long double
の三つの型しか受け取らないという……
ただのintも使えないとかアホかと。
んまあ、とっくに数値←→文字列みたいな汎用性の高い物は
みんな自前で作った関数使ってるか
boostのlexical_castとか使ってるので
べつに困ることも全くないとおもわれるのですが。
そんなんよりも、まともなforeachとかUNICODEとか文字コード周りとか
もっと基本的な所をしっかりとしてもらいたいところ。
2013-10
13
08:26:29
寒っ
昨日は昼間、室温が31度とかになってて、
「真夏かよっ!」
とかおもってエアコンつけてたりしたのですが。
今朝は室温が一気に23度とか。
いきなり寒くなってるし。
熱帯魚なら死んでるぞコレ。
相変わらずPGやってるのですが
なにげに今作ってるゲームのエンジン部分というかフレームワークみたいな物を
ライブラリ化して公開してみようかとおもってるのですが
それと平行して、c++のトピック集みたいなサイトも平行して作ってたりして。
その所為か、1クラス設計&コーディングして、1ページ解説ページを作ってると
それで一日が終わってしまってちっとも進まねー。
ライブラリ自体は、以前作ってた奴をリライトしながら作ってるので
全体の工程は見通し経っているのですが。
なにげに、他人に見られることを前提としたソースコードを書くのって
たいへんだなーとか。
とはいえ、公開しない場合でも、
ソースコードを見る最初の他人は自分な場合がほとんどなワケですし
(数ヶ月も間あいたら自分で書いたコードも他人のコードにみえるよねというネタ)
見られることを意識したコーディングというのもまた勉強にはなるなぁ。
そんで、いろいろ直しながらのところで
テンプレートに置き換えられそうなところはおきかえて
コードの量を減らしたりとかもしてるのですけども
std::mapの参照渡しでちょっと嵌る。
他のコンテナと違ってkeyがないときに勝手にkeyを作ったりするっていう機能が
constと相性が悪いのですよね。
そのへんで調べてるときに、ぐーぐるの検索ワードを打ち込んでたときの話。
「惨状私」
参照渡しをミスタイプしたら出てきた誤変換w
惨状っちゃ惨状だよ最近w
しかし、ぐーぐる検索でc++関係しらべてると、
なんかもう古い情報が多いなーとか気付く。
わりと最近(てほどでもないか)追加されたTR1関係でさえ
数えるほどしか情報出てこないし。
そんななか、
ttp://d.hatena.ne.jp/faith_and_brave/
珍しく、c++の最近の動向とかをメインに取り上げてるサイト発見。
意外にこういう情報って全然入ってこないんだよなぁ。
調べようにもまずその基点となる情報というかとっかかりのような物が入ってこないので
調べる動機がまず見つからないので。
そういう状況からしてやっぱc++は
古い言語みたいなイメージが定着してきてるのかなぁ。
てかTR1自体が、c++11の先取りライブラリだったわけですが。
いまってc++14そしてc++17までの話が出てるのですね。
そんでもってTR2なんてものまで。
んでもぜんっぜん話題にもなってねぇですね。
てか今でも普通に、regexやshared_ptrがboostからstdに加わったことすら
知らないc++プログラマー結構いそうですよね。
かくいう私も
vector<int> vec;
・・・
for each (int value in vec) {
cout << value << endl;
}
これでvectorの中身をforeachで回せるっての最近知ったぐらいだし。
boostのBOOST_FOREACHとかは知ってましたけど。
でもこっちのはマクロだしなーと。
んでも上のfor each文は、vc独自の拡張だそうで。環境依存系です。
しかも読み取り専用かつ最初から最後まで回す専用で(範囲決めて回すとかできない)
使いどころは限られる感じですが。
とっとと標準でfor eachぐらいつけて欲しい物です。
環境依存については…どうなんだろう。
「クロスプラットフォームなんて幻想ですよ」
とかどっかのc++系のサイトでかかれてたなw
将来的にはクロスプラットフォームに……なんていう淡い幻想は
まず実現しない妄想だというのが現実ですしね……w
んでも、c++のコンテナ系まわすのにいちいちイテレータがどうこうってのは
うんざりしてるのも事実で。
もっと簡潔に書けるというのは魅力なんですよね。
あとはなにげにもう、c++14とかになってくると
そろそろvc2008は見切られるかな・・・とか。
んでもxp環境だと、vc2010以降はWPFの所為で
もっさり重くてストレスたまるんですよね。
現状でもvc2010以降っていう追加機能もちらほら目にしたりするしなぁ。
あとはc++14になると新しいファイルシステム関係が追加されるかも? とか。
pathとかディレクトリの指定やらその辺が文字コードとか気にしないで
単一の方法で簡単に扱えるようになるのだとか。
winの環境依存系とかだとlpstrとかごちゃごちゃしてたからなぁ。
んまあそんなんよりもfstream系でunicodeのファイルに対応してないのとか……。
もっと基本的なファイル入出力の辺りを文字コード意識しないで
扱えるようにして欲しいのう……。
c++の抱える問題として、
過去おおくのシェアを持っていたため
大きな改変をすると過去のソースコードとの互換性が無くなるため
とくに業務系なんかでは、新しくビルドし直したら動かなくなったじゃ困るわけで。
その辺で、古く悪い部分を切り捨てられない部分というのが足を引っ張り続けているのですよね。
あとはなんとなく、unityとかみてると
ちまちまゲームのエンジン部分とかフレームを作ってると
無駄なことしてるのかなぁ?
という疑問がわいてくる今日この頃。
んでも逆にunityでも内部はc++で書かれているそうで
やはり速度かんがえるとゲームはc++だよなっ。
と励まされたりもする(ぉ
砂を噛むような毎日です。
「真夏かよっ!」
とかおもってエアコンつけてたりしたのですが。
今朝は室温が一気に23度とか。
いきなり寒くなってるし。
熱帯魚なら死んでるぞコレ。
相変わらずPGやってるのですが
なにげに今作ってるゲームのエンジン部分というかフレームワークみたいな物を
ライブラリ化して公開してみようかとおもってるのですが
それと平行して、c++のトピック集みたいなサイトも平行して作ってたりして。
その所為か、1クラス設計&コーディングして、1ページ解説ページを作ってると
それで一日が終わってしまってちっとも進まねー。
ライブラリ自体は、以前作ってた奴をリライトしながら作ってるので
全体の工程は見通し経っているのですが。
なにげに、他人に見られることを前提としたソースコードを書くのって
たいへんだなーとか。
とはいえ、公開しない場合でも、
ソースコードを見る最初の他人は自分な場合がほとんどなワケですし
(数ヶ月も間あいたら自分で書いたコードも他人のコードにみえるよねというネタ)
見られることを意識したコーディングというのもまた勉強にはなるなぁ。
そんで、いろいろ直しながらのところで
テンプレートに置き換えられそうなところはおきかえて
コードの量を減らしたりとかもしてるのですけども
std::mapの参照渡しでちょっと嵌る。
他のコンテナと違ってkeyがないときに勝手にkeyを作ったりするっていう機能が
constと相性が悪いのですよね。
そのへんで調べてるときに、ぐーぐるの検索ワードを打ち込んでたときの話。
「惨状私」
参照渡しをミスタイプしたら出てきた誤変換w
惨状っちゃ惨状だよ最近w
しかし、ぐーぐる検索でc++関係しらべてると、
なんかもう古い情報が多いなーとか気付く。
わりと最近(てほどでもないか)追加されたTR1関係でさえ
数えるほどしか情報出てこないし。
そんななか、
ttp://d.hatena.ne.jp/faith_and_brave/
珍しく、c++の最近の動向とかをメインに取り上げてるサイト発見。
意外にこういう情報って全然入ってこないんだよなぁ。
調べようにもまずその基点となる情報というかとっかかりのような物が入ってこないので
調べる動機がまず見つからないので。
そういう状況からしてやっぱc++は
古い言語みたいなイメージが定着してきてるのかなぁ。
てかTR1自体が、c++11の先取りライブラリだったわけですが。
いまってc++14そしてc++17までの話が出てるのですね。
そんでもってTR2なんてものまで。
んでもぜんっぜん話題にもなってねぇですね。
てか今でも普通に、regexやshared_ptrがboostからstdに加わったことすら
知らないc++プログラマー結構いそうですよね。
かくいう私も
vector<int> vec;
・・・
for each (int value in vec) {
cout << value << endl;
}
これでvectorの中身をforeachで回せるっての最近知ったぐらいだし。
boostのBOOST_FOREACHとかは知ってましたけど。
でもこっちのはマクロだしなーと。
んでも上のfor each文は、vc独自の拡張だそうで。環境依存系です。
しかも読み取り専用かつ最初から最後まで回す専用で(範囲決めて回すとかできない)
使いどころは限られる感じですが。
とっとと標準でfor eachぐらいつけて欲しい物です。
環境依存については…どうなんだろう。
「クロスプラットフォームなんて幻想ですよ」
とかどっかのc++系のサイトでかかれてたなw
将来的にはクロスプラットフォームに……なんていう淡い幻想は
まず実現しない妄想だというのが現実ですしね……w
んでも、c++のコンテナ系まわすのにいちいちイテレータがどうこうってのは
うんざりしてるのも事実で。
もっと簡潔に書けるというのは魅力なんですよね。
あとはなにげにもう、c++14とかになってくると
そろそろvc2008は見切られるかな・・・とか。
んでもxp環境だと、vc2010以降はWPFの所為で
もっさり重くてストレスたまるんですよね。
現状でもvc2010以降っていう追加機能もちらほら目にしたりするしなぁ。
あとはc++14になると新しいファイルシステム関係が追加されるかも? とか。
pathとかディレクトリの指定やらその辺が文字コードとか気にしないで
単一の方法で簡単に扱えるようになるのだとか。
winの環境依存系とかだとlpstrとかごちゃごちゃしてたからなぁ。
んまあそんなんよりもfstream系でunicodeのファイルに対応してないのとか……。
もっと基本的なファイル入出力の辺りを文字コード意識しないで
扱えるようにして欲しいのう……。
c++の抱える問題として、
過去おおくのシェアを持っていたため
大きな改変をすると過去のソースコードとの互換性が無くなるため
とくに業務系なんかでは、新しくビルドし直したら動かなくなったじゃ困るわけで。
その辺で、古く悪い部分を切り捨てられない部分というのが足を引っ張り続けているのですよね。
あとはなんとなく、unityとかみてると
ちまちまゲームのエンジン部分とかフレームを作ってると
無駄なことしてるのかなぁ?
という疑問がわいてくる今日この頃。
んでも逆にunityでも内部はc++で書かれているそうで
やはり速度かんがえるとゲームはc++だよなっ。
と励まされたりもする(ぉ
砂を噛むような毎日です。
2013-10
09
02:25:19
変な夢みるし…
なんか二日続けて変な夢。
何処か明確な場所に行こうとして、その行き方も判っていて。
その手順通りに進んでもなぜか途中から進めない。
そんな感じのを、シチュエーションだけが違うタイプのを
二日連続で。
具体的にかくと一つめは、
エレベータに乗って、行きたいのは地下一階。
んでもなぜかエレベータに乗ると地下一階のボタンを押してるのに
なぜかエレベータは上に行く。
んで最上階に着くとこんどは一階まで下がる。そこでドアが開く。
もっかいそこで地下一階のボタンを押すが、またさっきの繰り返し。
いつまでたっても地下一階に行けない。
ってこところで目が醒めた。
二つめは忘れてしまったけど、
たどり着けるはずの所にたどり着けないもどかしさだけが
強烈に残ってるのです。
なーんか最近の状況を反映してる感じで
いろいろといやん。
話はかわって。
11月のコミック発売一覧みてたらば。
完全版「低俗霊狩り」1,2巻
てのが目にとまる。
奥瀬サキの「低俗霊狩り」結構すきな作品だったりw
んで2巻の途中で中断してるエピソードがあって
三巻はその続きはなく、別の話が始まってたりで。
ファンの間では中断された「自動人形編」の続きを求める声は根強かったわけで。
それが今回、完全版として新作続編、それも自動人形の続きも描かれるとかで。
へー。
なにげに「火閻魔人」の新作もでてた……
ぐぐってみるとセルフリメイクらしく
すでに2巻まででてるらしい。
ほへー。
いつの間に。
んでも新しい方の火閻魔人の絵をみると
ちょっと微妙なような……。
今の絵で新作……。うーん。
んでも火閻魔人のほうは絵が他の人でも受け入れられそうだけど
低俗霊狩りの魔魅さんは他の人が描いたら魔魅さんじゃないっていう
違和感がぬぐえないだろうなという気もするぽ。
なんだかんだいって低俗霊狩りの続きは楽しみである。
古いの持ってるんだけど
完全版かっちゃおうかなぁ。
てか「コックリさんが通る」も微妙な終わり方だったし
「低俗霊MONOPHOBIA」はこれから面白くなってきたってところで打ち切り。
結構未完作品多い作家さんですよね。
「低俗霊DAYDREAM」
「夜刀の神つかい」
原作2作は完結してるものの
「低俗霊DAYDREAM」のほうはどっちかってと目黒三吉ワールド全開なかんじでしたし
(いやそれはそれで好きなんですけど)
「夜刀の神つかい」のほうはちょっと後半ストーリー展開が破綻してたし
主人公じゃない剣士の人がかっこよすぎて他がどうでも良くなったり(ぉ
でもほんど独特の世界観をもった作家さんだなぁ。
…あれ?
低俗霊DAYDREAM
諸事情により漫画家の目黒三吉氏が降板 休載
え? 普通に完結してるとおもったのだけども
未完扱いだったの??
と初めて知った。
本紙の掲載順は判らないのですが
番外編?の市役所?のおねーさんが可愛かったです。
低俗霊MONOPHOBIAに世界観繋がってるのはその残滓だったのか……?
んでもどっちも魔魅さんいつかはでるのかなーと
よんでたっけか。
他の人が描いた魔魅さん見たいような見たくないようなアレなのですが。
久しぶりに読み返してみようかな低俗霊狩り。
何処か明確な場所に行こうとして、その行き方も判っていて。
その手順通りに進んでもなぜか途中から進めない。
そんな感じのを、シチュエーションだけが違うタイプのを
二日連続で。
具体的にかくと一つめは、
エレベータに乗って、行きたいのは地下一階。
んでもなぜかエレベータに乗ると地下一階のボタンを押してるのに
なぜかエレベータは上に行く。
んで最上階に着くとこんどは一階まで下がる。そこでドアが開く。
もっかいそこで地下一階のボタンを押すが、またさっきの繰り返し。
いつまでたっても地下一階に行けない。
ってこところで目が醒めた。
二つめは忘れてしまったけど、
たどり着けるはずの所にたどり着けないもどかしさだけが
強烈に残ってるのです。
なーんか最近の状況を反映してる感じで
いろいろといやん。
話はかわって。
11月のコミック発売一覧みてたらば。
完全版「低俗霊狩り」1,2巻
てのが目にとまる。
奥瀬サキの「低俗霊狩り」結構すきな作品だったりw
んで2巻の途中で中断してるエピソードがあって
三巻はその続きはなく、別の話が始まってたりで。
ファンの間では中断された「自動人形編」の続きを求める声は根強かったわけで。
それが今回、完全版として新作続編、それも自動人形の続きも描かれるとかで。
へー。
なにげに「火閻魔人」の新作もでてた……
ぐぐってみるとセルフリメイクらしく
すでに2巻まででてるらしい。
ほへー。
いつの間に。
んでも新しい方の火閻魔人の絵をみると
ちょっと微妙なような……。
今の絵で新作……。うーん。
んでも火閻魔人のほうは絵が他の人でも受け入れられそうだけど
低俗霊狩りの魔魅さんは他の人が描いたら魔魅さんじゃないっていう
違和感がぬぐえないだろうなという気もするぽ。
なんだかんだいって低俗霊狩りの続きは楽しみである。
古いの持ってるんだけど
完全版かっちゃおうかなぁ。
てか「コックリさんが通る」も微妙な終わり方だったし
「低俗霊MONOPHOBIA」はこれから面白くなってきたってところで打ち切り。
結構未完作品多い作家さんですよね。
「低俗霊DAYDREAM」
「夜刀の神つかい」
原作2作は完結してるものの
「低俗霊DAYDREAM」のほうはどっちかってと目黒三吉ワールド全開なかんじでしたし
(いやそれはそれで好きなんですけど)
「夜刀の神つかい」のほうはちょっと後半ストーリー展開が破綻してたし
主人公じゃない剣士の人がかっこよすぎて他がどうでも良くなったり(ぉ
でもほんど独特の世界観をもった作家さんだなぁ。
…あれ?
低俗霊DAYDREAM
諸事情により漫画家の目黒三吉氏が降板 休載
え? 普通に完結してるとおもったのだけども
未完扱いだったの??
と初めて知った。
本紙の掲載順は判らないのですが
番外編?の市役所?のおねーさんが可愛かったです。
低俗霊MONOPHOBIAに世界観繋がってるのはその残滓だったのか……?
んでもどっちも魔魅さんいつかはでるのかなーと
よんでたっけか。
他の人が描いた魔魅さん見たいような見たくないようなアレなのですが。
久しぶりに読み返してみようかな低俗霊狩り。
Sun
Mon
Tue
Wed
Thu
Fri
Sat
01
02
03
04
05
06
07
08
09
■
■
変な夢みるし…
10
11
12
13
■
■
寒っ
14
[体育の日]
15
16
17
18
19
20
21
22
23
■
■
うーん、意外にもう戻れない感じぽ
24
25
26
27
28
29
30
31
total:2080192 t:2562 y:180
■記事タイトル■
■年度別リスト■
2024年
2024年12月(0)2024年11月(0)
2024年10月(1)
2024年09月(2)
2024年08月(1)
2024年07月(1)
2024年06月(5)
2024年05月(2)
2024年04月(1)
2024年03月(6)
2024年02月(4)
2024年01月(3)
2023年
2023年12月(3)2023年11月(1)
2023年10月(2)
2023年09月(3)
2023年08月(3)
2023年07月(3)
2023年06月(7)
2023年05月(8)
2023年04月(2)
2023年03月(1)
2023年02月(2)
2023年01月(3)
2022年
2022年12月(4)2022年11月(3)
2022年10月(1)
2022年09月(3)
2022年08月(3)
2022年07月(2)
2022年06月(1)
2022年05月(3)
2022年04月(2)
2022年03月(2)
2022年02月(1)
2022年01月(6)
2021年
2021年12月(8)2021年11月(3)
2021年10月(4)
2021年09月(6)
2021年08月(2)
2021年07月(1)
2021年06月(3)
2021年05月(2)
2021年04月(2)
2021年03月(3)
2021年02月(1)
2021年01月(4)
2020年
2020年12月(3)2020年11月(7)
2020年10月(2)
2020年09月(3)
2020年08月(1)
2020年07月(3)
2020年06月(7)
2020年05月(5)
2020年04月(8)
2020年03月(4)
2020年02月(2)
2020年01月(4)
2019年
2019年12月(1)2019年11月(1)
2019年10月(2)
2019年09月(1)
2019年08月(3)
2019年07月(2)
2019年06月(2)
2019年05月(2)
2019年04月(4)
2019年03月(1)
2019年02月(7)
2019年01月(1)
2018年
2018年12月(1)2018年11月(1)
2018年10月(5)
2018年09月(1)
2018年08月(5)
2018年07月(1)
2018年06月(1)
2018年05月(1)
2018年04月(2)
2018年03月(2)
2018年02月(1)
2018年01月(1)
2017年
2017年12月(2)2017年11月(1)
2017年10月(2)
2017年09月(5)
2017年08月(8)
2017年07月(2)
2017年06月(1)
2017年05月(1)
2017年04月(3)
2017年03月(5)
2017年02月(7)
2017年01月(8)
2016年
2016年12月(7)2016年11月(2)
2016年10月(3)
2016年09月(7)
2016年08月(8)
2016年07月(10)
2016年06月(17)
2016年05月(6)
2016年04月(8)
2016年03月(10)
2016年02月(5)
2016年01月(10)
2015年
2015年12月(7)2015年11月(7)
2015年10月(13)
2015年09月(7)
2015年08月(7)
2015年07月(5)
2015年06月(4)
2015年05月(5)
2015年04月(2)
2015年03月(4)
2015年02月(1)
2015年01月(7)
2014年
2014年12月(12)2014年11月(8)
2014年10月(4)
2014年09月(6)
2014年08月(7)
2014年07月(4)
2014年06月(2)
2014年05月(5)
2014年04月(4)
2014年03月(8)
2014年02月(4)
2014年01月(8)
2013年
2013年12月(15)2013年11月(8)
2013年10月(3)
2013年09月(3)
2013年08月(8)
2013年07月(0)
2013年06月(0)
2013年05月(0)
2013年04月(0)
2013年03月(0)
2013年02月(0)
2013年01月(0)
■レス履歴■
■ファイル抽出■
■ワード検索■
堕天使の煉獄
https://rengoku.sakura.ne.jp
管理人
織田霧さくら(oda-x)
E-mail (■を@に)
oda-x■rengoku.sakura.ne.jp