堕天使の煉獄

ちょっぴり風邪ひきっぽい感じで、即ごろ寝。わりとすぐに復調して一息。
最近、寝込むと長引くこと増えたので……。んでもなにげにちょいちょい思い出したらやるようにしてるラジオ体操が効いてるのかもな。
なんでも腕を回す動作が多いのだけど、それが脇のリンパ腺を刺激して病気への抵抗力を上げる効果もあるそうで。それ以前に慢性的な運動不足なので、そっちのがいろいろ影響ありそうだけどｗ

そんなかんじで、再びにこにこＰＧ。

ちょっと煮詰まってモチベーション下がってた所なのだけど、ぷち寝込んでる間にぼーっと考えてるうちに、ちょっとまた全体的に見直さないとなーと言う感じに。

以前から気にはなっていたのだけども、「noexcept」をどうするか……と。

基本的には、例外処理をしない。というオプション指定みたいなものなんですけど。
ゲームＰＧにおいてはほとんど例外って使わないので、なんかもうnoexceptだらけになってまうがなってかんじで。

効果的には、例外を行わないということを明示的に指定することで、noexcept関数は最適化に有利らしい。

んでも付けるべきか、付けるのが適正か、という判断に標準関数を内部で使っているか。というのも関わってくるんですよね。エラーは例外でやってねっていうかんじの標準関数とかあるので。
noexceptは波及するので、noexceptしてる関数の中から呼んでる関数の中で例外吐く標準関数なんかあったりすると、めんどくさい事になる。

残念なC++使い、銀天すばる
ttp://twilog.org/SubaruG/date-140223

SFINAEとかテンプレートとかnoexceptとかconstexprとか そういうのは，「使う必要を説明できる場合にのみ使う」ということを心がけたほうがいいと思うのです

noexcept使うべき所って、自分で書くムーブコンストラクタにはnoexcept。ってのぐらいしかないっぽいんですが。
moveの際に標準のコンテナとかはnoexcept指定あるかないかで処理が変わったりするものがあるので、default指定でない自前で書くmoveにはnoexcept指定を付けましょう。
ってことらしいです。

が、そこ以外、noexcept書く必要あるのかなーと。
恩恵が、ひょっとしたら最適化で有利になるかもよ？　なだけなわけですし。
そもそもゲームＰＧ限定ならそもそも例外を吐かない、吐かせないかんじのコーディングなるので、もうすべてをnoexceptとかしたいところなんですけどね。
んで例外をはく標準関数なんかが問題になっちゃうと。
vectorの[]でのアクセスの範囲チェックなんかは事前に範囲チェックのassertとか入れとけばいいとしても、計算結果がint型の範疇を超えたらout_of_range吐くよとか０除算チェックみたいなのが厄介なんですよね。
例外吐かれてもこまるし、チェックしないわけにもいかないけど、事前チェックも難しい。そういうケースの時にどうするのか。
真面目にやるならそこだけ例外で処理するよりほかないのかなーとか、滅多にでやしないということで、無視するのも一つの手だし。

noexceptの解説文のなかで、noexcept関数の内部でtry-catchを書いて外に例外を出さないなんて記述するのは本末転倒。的な事も書かれているのもあったのだけど。そもそもnoexceptは例外がでないもしくは関数の外まで例外を出すのをやめて、関数の中だけで終わらせて他に影響を与えないことを保証する＝最適化のヒント。みたいなのじゃないのかな。
そうなると、どうしても例外に頼らなければならない場合なんかにはnoexceptして内部でtry～cathで例外処理を関数内のみで完結させるという意思表示という役目も持つわけで。
そういう意味では本末転倒ではなく本来の使い方に適っている気もするぽ。
うーん。なんかまだまだ理解がたりないのかな。

そんな感じで意外にnoexcept付けるべきかどうなのか、また逆に例外を使わなければいけないケースについてとか、迷うところがあって。

うーむ。
意外にめんどくさいnoexcept。


それと、波及するってので似てるのが、const指定ですね。

もうすっかりconst教の信者で、息を吐くようにconst指定を書くようになって長いのですが。noexcept教というのも今後は出てくるのかなぁ。

ソースコード乗っけてるサイトとかで、noexceptがだーっと並んでるソースとか見ると、まだまだ違和感かんじちゃったりして。

うーん。constとおなじでやり始めちゃえば慣れるもんなんだけど、はたしてconstほど徹底して付けるべき物なのだろうか？　というところでも、未だに踏ん切りついてなかったりして。
constも値を書き換えない保証ということで、これも最適化のヒントとなるわけで。
そういう意味ではやはりnoexcept指定はキチンとやるべきなのか……？

んでもconstと同様に、使っちゃいけない、使うべきではないケースもあるわけで。

その辺の見極めは実際に使って経験積んでみないと判らない所だったりするのはconstもおんなじか。
なんか標準関数の挙動とかにもある程度精通してないといけないといけなくなってきて、ハードルあがってるかんじ。

なにげにSTLのvectorのソースなんか覗いてみたらば、がっつりnoexcept指定してありますね。
うーん。
noexcept付けるのはこれからはスタンダードなのか……。でもこういうケースだと

virtual void moge() const noexcept override { ... }

とかオプションが三つも……じゃまくせぇｗ
ちなみに
virtual void moge() const override noexcept {}
だとエラーらしいです。
記述の順番もあるみたい。（コンパイラにも寄るらしいけどまだvc++2015では試してない）
どんどんごてごてとオプションが増えていくのも邪魔くさいなあという感じもあったりするんですよね……。



あとはconstexprにできるクラスはconstexprクラスにするべきだなというのもあったりして。

c++14以降の対応とか、過渡期にある現在はいろいろとコーディングスタイルも移り変わっていくので、ちょいちょい組み直しとか増えちゃうけど、無視してるとあっという間においてかれちゃってstaticおじさんみたいになっちゃうからなぁ……。

とはいえSFINAEとかはやり始めると、きりがない感じで。可読性も落ちるし。
プリミティブな改変も少なそうなクラスにはごりごりやっちゃってもイイかもだけど、汎用的には使わない方が吉な感じだしなぁ。
SFINAEに関しては、おとなしくconceptがやってくるまで待ってた方が吉だというのもありますが。

上記のURLの記事の

SFINAEで「条件に該当しないケースをはじく」のは，やろうと思えば際限なくやれるけど，型変換コンストラクタとかそういう限られたケースのみにした方がいい

と

引数が〜の場合にはこういう処理を，〜の場合にはこういう処理を，っていう切り分けをするより，多少冗長でも別関数に分けたりコンストラクタならタグをつけたりした方がいい

基本的にはクラスの性質付けてきに使うの限定とかにした方がいいのかなーとか。
で、そうなるとタグつけとかで、明示的に振り分けちゃった方がわかりやすいというのも、たしかにそうだなーとか。

結局、汎用性って無駄に終わることおおいんですよね。

この辺の自分なりの明確なルールとか早い目に構築できてないと、１から組み直し～とかいうことに～。

んでも最近思うのが、ネット上にいまだ散見するc++03以前のレガシーコードと、c++11以降のコードがあまりにも様相が違いすぎてて、これから0からｃ++学習するってひとは大変だろうなーとかおもたり。

大昔のｃからｃ++に移行出来なかった人みたいな感じでｃ++03からｃ++1ｘに移行出来なかった人とかもでてくるんだろうなぁ。

オブジェクト指向なんて助長で無駄なだけですよっみたいな感じで、ｃ++1ｘなんて、言語マニアの趣味的改変で実務じゃ役に立ちませんよっ、とか言っちゃったりとかするひとでてきそうｗ

んでも確かに、設計的な美しさを追求した余り、ちょっと残念な見栄えのstd::chronoとか揶揄されてるのとかもあるしなぁ。
ラムダ式もそんなに美しいとはおもえないし。

趣味的マニア的部分が増えたのは事実のようにも思えるｗ

でももともと今時ｃ++なんてそれ自体がマニアックな部類の言語だしなぁ。

そっちの方向に先鋭化したというべきなのか……

切れすぎるカミソリ＝ｃ++ってかんじ？ｗ

以下追記
記事書き終わった後にもうちょっと調べてたら出てきたサイト

Item 14: 例外を投げない場合はnoexceptで関数を宣言しよう
ttp://code-mynote.blogspot.jp/2015_12_01_archive.html

例外を投げないのにnoexceptをつけない関数は悪いインターフェースデザイン。
constと同じように例外を投げない関数には常にnoexceptを指定すべき。

Wnoexceptオプション
ttp://d.hatena.ne.jp/yohhoy/20150926/p1

C++, gcc
gcc(g++)では、C++関数へのnoexcept修飾子付け忘れを警告するオプションが提供される。Clangでは未実装。

どうもconst教と同じくnoexceptは布教を進めている模様。
せっせと追加するしかないか……。