C++エンジニア必見 RustへのPhrasebook

イディオマティックなC++で例外を使わずに、オブジェクトの失敗する可能性のあるコンストラクタってどう対応するの？

標準的なイディオムとしては、オブジェクトが無効だって示すセンチネル状態を持たせることだね。自明じゃないデストラクタを持つオブジェクトとか、ムーブ元から読まれる可能性がある場合（一部のシステムコードでは有効な振る舞い）、C++のムーブは非破壊的だからどっちみちセンチネル状態が必要なんだ。C++は遅延破棄を色々な問題を解決する標準ツールとして使ってるよ。

＞ ムーブ元から読まれる可能性がある場合（一部システムコードでは有効）
std::moveを標準ライブラリ型に適用した場合、オブジェクトは”有効だけど不特定な状態”になるって[1]に書いてあるよ。もしオブジェクトを無効状態（invariantが壊れてる状態）にしてるなら、それはイディオマティックなC++じゃないね。
[1] https://en.cppreference.com/w/cpp/utility/move.html

ここで言ってる”無効”ってのは、意味のある値を持ってないっていうセマンティックな意味合いで使ってるんだ。構造的には無効じゃないよ。

それは、成功したコンストラクタの後でもメソッド呼び出しの結果として同じような無効状態に入りうるオブジェクト（ファイルやストリームとか）には理にかなってるね。でもそういう性質がないオブジェクトの場合、デザインの一種の悪さを別の、でも結局同じような悪さに交換してるだけだね。

じゃあ、その型のオブジェクトが存在すること自体が、状態が有効であることの静的な証明にはならないってこと？

そう（無効はセマンティックな意味だよ）。低レベルシステムでは理論的にも静的証明が無理な場合があり、実行時チェックが必要。プロセス空間はDMAなどで外部変更されうる。C++コンパイラは通常静的証明可能と仮定。これに対処するため、C++は証明不可能を示す機能（例：std::launder）を追加。データベースカーネルは典型例で、オブジェクトの位置と状態は実行時に動的解決が必要なんだ。

システムコードでは静的証明が無理なケースが多いのは完全に同意だよ。だからこそ、静的証明が可能な場所でそれを諦めちゃうのは、さらにタチが悪いと思うね。

その通りだね、「有効だけど未規定な状態」っていうのも起こりうるし、よくあることだよ。

RustとGoが良い判断をした点の一つは、コンストラクタがないことだよ。C#だとこれがすごくウザいんだよね、特に非同期操作が必要な型を構築したい時とか。こういう時は、通常、プライベートなコンストラクタとstatic publicメソッドを使って型を作るしかないんだけどね。

RustとGoには型変換演算子（コンストラクタじゃなくても）がないから、型システムをスクリプトみたいに扱うのは実質不可能だね。これらの言語の数値ライブラリがめちゃくちゃ使いにくいのは、主にこれが原因だよ。

このコメント（10665）が全然理解できないな。Rustにはまさにこの目的のための’as’演算子があるだけじゃなく、失敗しない変換用のFrom、Intoと、失敗する可能性のある変換用のTryFrom、TryIntoっていうトレイト一式もあるんだぜ。

asはinfix operatorだから、異なる型間の関係を示すために暗黙的に呼ばれることは絶対にないんだよ。

イディオマティックなC++は例外を使うもんだ。標準は言語機能を無効にすることを認めてないよ。言語機能を無効にする闇の道を選ぶ奴は、コンパイラ固有の拡張を使って非イディオマティックなC++を書いてるんだ。

組織がC++例外を使うのをためらう、何か良い理由を思いつく？

C++例外をためらう理由？ レガシーコード、C++98以前のコードとか、Orthodox C++の人たちの「遅い／肥大化」って主張（大抵はプロファイルしてないけど）。組込みでは昔のPCよりマシなのにね。例外使わない言語で静的リンクしてサイズ3倍になっても「肥大化じゃない」とか、矛盾してるよな。

もう一つの理由として、C++のmutexは通常、例外を投げてもpoisonしないってことがあると思うよ。

それ、結構大胆な発言だね。
だって、デカいC++コードベースの多くは例外使ってないじゃん？
C++コンパイラの中にも使ってないのあるし。

大胆な発言はいいね！
もしLLVMとかChromeの話なら、GoogleのC++スタイルガイドが特別優れてるわけじゃないのは確か。
そういう主張するなら、スタイルガイドが例外についてどう言ってるかちゃんと知っとくべきだね？
『新規ならいいけど、既存コードへの影響がデカいから使ってない。GoogleのC++コードのほとんどは例外対応してないから、導入は難しい』って書いてあるんだよ。
これって、最初から失敗してて、デカすぎて今さら変えられないってこと。
じゃあ、C++のバイブル『C++ Core Guidelines』はどうかって？
Eセクションに例外のベストプラクティスについてアドバイスがあるよ。

たぶん、C++デベロッパーが慣用的じゃないRustを書く方が、危ないC++を書き続けるより全然マシ、ってことじゃない？
unsafeを使ったりボローチェッカー無視したりしない限り、安全にはなるだろうし。
完璧を目指しすぎないで、って感じ？
慣用的なRustって定義もそんなに厳しくないし。
Clippyが簡単なとこは教えてくれるし、それ以外はあんまり気にしなくていいと思う。
トレイトとか『正しく』使おうとすると、かえってクソ複雑になったりするしね。

この記事みたいなのは、C++とRustの似てるとこ、違うとこを話し合うのに良いね。
まぁ、どの言語にもスタイルはいっぱいあるから、それも踏まえて、って感じだけど。

マジで一番ヤバい落とし穴は、RustのリファレンスをC++のポインタと同じって思っちゃうこと。
ポインタとして実装されてるけど、役割は一時的で（よく排他的に）静的にわかるスコープだけのアクセスを与えることだから、C++のポインタやリファレンスの一部にしか当てはまらないんだ。
C++でポインタはコピー避けるためだけど、Rustのリファレンスはデータをそのまま持たないため。
この目的が違うと、『does not live long enough』ってエラー地獄にハマるんだよね。

さっきのコメントの人、リファレンスは静的なスコープに限られるって言ってたけど、そうじゃない場合もあるよ。
同じライフタイムなら、ヒープデータの参照をvectorに入れられる。
ツリーイテレータをvectorでスタックとして作る時とかね。
これは静的なスコープを超える話。
ただ、ミュータブルなイテレータだと話は別。
ミュータブルな参照はユニークじゃないといけないから、ミュータブルなポインタのスタックが必要で、デリファレンスする時はunsafeコードになる。
それはちょっと辛い制限かも。

C++の構文とか意味はC++のイディオム向けに作られてるけど、Rustは違うんだよね。
RustってMLファミリーの言語に近くて、C++とかOOPとはちょっと違うから、C++のイディオムを『真似る』必要があるんだ。
でもこれ逆も言えて、RustのEnumのパターンマッチとか、C++だとすっごく長くて使いにくいコードになるし。

ってことは、この記事のアプローチって、C++ユーザーにRustで変なイディオムを使わせることになるの？

「間違い」って言うのは言い過ぎかな。C++プログラマー向けにC++の考え方で書いてるんだから、コードは全然悪くないと思うよ。ゼロからRustを教える記事じゃないしね。

C++やってる身としては、最初はこれでも全然OK。いろんな言語やってると、ifとかforとか基礎の説明はマジでだるいんだよね。これは「C++erがrustcに潰されない方法」って感じ。まずこれでRustの書き方を覚えて、それから「Rustらしい考え方」に進めるのが良いんだと思う。

このやり方で慣れてきたら、早めにRustのリンター「clippy」を使う習慣をつけるといいよ。「cargo clippy」で実行できる。clippyはRustらしいコードが好きで、非イディオマティックな部分を提案してくれる。機械コードは同じでも、人間にとって読みやすいのが大事だからね。人間みたいに気の利いたレビューはできないけど、タダだし、習ってる途中で気まずくならないのがいいところ。

C++のコード、わざと冗長にしてない？普通は「class Person { int age = 0; };」みたいに書くでしょ。Rustのstructでもデフォルト値がこんなに簡単に書けたら楽なのにね。

それ、もうすぐできるようになるらしいよ！承認されたRFCがあって、安定化も近いみたい。詳しくはここ見てみて！ https://github.com/rust-lang/rust/issues/132162

traitsとclassesの話、大事な違いを無視してるよ。Rustのtraitにはデータを持てないし、親traitのデータにもアクセスできないんだ。RustでOOP真似ようとするとすぐ混乱するよ。C++をRustで書こうとするならマジ問題。所有権の話も全くないしね。記事の「APIの2バージョン」の話も変じゃない？普通はResultに関数呼んで.unwrap()とか.expect()するだけだよ。RustとC++の違いは、書き方よりデータの繋げ方や所有権設計。C++でも難しいけど、実行時まで気づかないだけ。

記事の元の意図とは逆だけど、これ良いね。Rustが色々と改善してる点を学んで、それをC++書くときに活かせたらもっと良くなるかも。

Rustを少し学んで、これからもC++メインで書くって人たちが、この記事でC++に役立つ知識を得たってよく言ってるのを見かけるよ。C++委員会の提案書でも、「Rustはこれができてる」って言うのは、Pythonみたいな言語だけじゃなくて、C++みたいな「ちゃんとした」言語でも実現可能だって示すのに使われてるんだ。C++のstringにcontainsが入った時も、例としてRustが挙げられてたよ。

これ見たんだけど、C++を知ってること前提みたいだなー。少なくとも両方の言語に同じくらい時間かけてるから、C++のやばいとこ（foot guns）は教えてくれないね。

確かに「C++を知ってる人」目線で書かれてるね。でも「知ってる」には（少なくとも）2つの意味合いがあると思うんだ。全く知らない人には役立たずだし、ベースは知ってるけどモダンC++を知らない人には、Rust部分は無視してC++のモダン化の参考になるかも。どっちにしても、C++のやばいとこは警告してくれないね（Rustを勧める以外は ;-））。

この記事にあるパターンがモダンC++って言ってるけど、C++11以降って意味でしょ。それもう14年前だよ。今時C++17に対応してないツールチェイン探す方が難しいって。Debian old-stableとか古ーいRedHat向けにビルドしてる不幸な人もいるだろうけど、そういう場合はモダンなやり方してないって分かってるはずだし、それなりの理由があるんだろうしね。

あと議論したいんだけど、多くの人がC++11のおかげだと思ってる「モダン」C++機能って、C++ARMからC++03の時代にはもう可能だったんだよ。ただ多くの人が注意してなかったか、ファイル名を.cppとかに変えてただけ。MFCみたいな低レベルなやり方と比べて、CSet++, OWL, VCLがいかに人間工学的に優れてたか、みたいな話と同じでさ。

これってチュートリアルとか学習ガイドって感じじゃないな。C++とRustの対応パターンをざっくり調べられるルックアップテーブルだね。学習を始めるにはあんまり向いてないかも。

最高。これマジで良いじゃん。

しばらく見てなかったんだけど、DrysdaleのEffective Rustは本当に素晴らしい本だったよ。似たような読者層向けだね。
https://www.lurklurk.org/effective-rust/

いいね、C++経験がないRust開発者にも役に立つよ。