オブジェクトが const しかないクラスの作成を C++ がサポートしていないように見えるのはなぜですか? つまり、const 以外のオブジェクトを作成しようとすると、コンパイル時にエラーが発生するクラスです。多くの場合、これは当然のことのように思えますが、C++ では許可されていません。この背後にある理由は何ですか?
頭に浮かぶ最初の質問は、すべてのオブジェクトがconst
自然なことである型を持つ場合です。自然にimmutable な型があり、一部の言語ではできるだけ多くの型を不変にすることが推奨されていますが、それはすべてのオブジェクトが であることを強制することと同じではありませんconst
。
クラス設計では、メンバー関数のいずれかがオブジェクトの状態を変更して不変オブジェクトを実現するかどうかを制御するのは簡単です。カプセル化はその魔法を行い、変更関数を公開しない場合、型は不変であり、const
. また、(追加の安全性が必要な場合) すべてのメンバーデータを修飾しconst
て、独自のコードで独自の制約に違反しているかどうかをコンパイラに通知させることもできます。すべてのオブジェクトをconst
暗黙的に強制すると、すべてのメンバー データが beconst
にマークされ、非 const 関数がuselessになることに注意してください。
さまざまな方法でほとんどコストをかけずに高レベルの効果を達成できることを考えると、なぜ複雑な言語を付加価値なしでさらに複雑にするのでしょうか?
上記の質問はレトリックに見えるかもしれませんが、そうではありません。言語の拡張を検討する基準の 1 つは、投資収益率です。この機能なしでは不可能だったことが、この機能で何ができるようになるでしょうか? (つまり、これは有効な機能ですか?) 答えが何もない場合、次の質問は、現在の状態と比較して、この機能を使用するとプログラマーの生活がどれだけ簡単になるかということです。(機能を有効にしない場合、それらを追加する価値は何ですか?)
有効化カテゴリでは、例はrvalue -referencesになります。その言語機能がなければ、 Perfect-Forwardingもmove-semanticsも実装できません。2 番目のカテゴリでは、ラムダを考慮することができます — ラムダなしでは実行できなかったラムダで実行できることは何もありません — その価値は、ユーザー コードを単純化することにあります (複雑にする必要があるコード: ファンクターを作成し、関数のすべてのメンバーを宣言します)。適切な型、初期化するコンストラクターを提供する — キャプチャ — メンバー…) しかし、コードはラムダを使用するとはるかに単純になります。ラムダに価値があることを Stroustrup に納得させるには、Sutter からかなりの議論が必要だったことに注意してください。
あなたの場合、あなたが求めているのは有効化機能ではなく、機能なしでユースケースをサポートするコストは十分に低いため、それをコア言語機能として提供することはできません。