タグ付けされた質問 「invariants」

私はCoders at Workを読んでいますが、その中には不変条件について多くの話があります。私が理解した限りでは、不変式とは式の前後両方に当てはまる条件です。Logicコースを正しく覚えていれば、ループが正しいことを証明するのに役立ちます。 私の説明は正しいですか、何か見落としていませんか？プログラムでそれらを使用したことがありますか？もしそうなら、彼らはどのように利益を得ましたか？

48 invariants 

これは、値が配列内にあるかどうかを確認する最も一般的な方法です（私には思えます）。 for (int x : array) { if (x == value) return true; } return false; しかし、私が何年も前におそらくWirthやDijkstraによって読んだ本では、このスタイルのほうが優れていると言われました（中に出口があるwhileループと比較した場合）。 int i = 0; while (i < array.length && array[i] != value) i++; return i < array.length; このように、追加の終了条件はループ不変式の明示的な部分になり、ループ内に隠された条件と終了はありません。すべてがより明確で、構造化プログラミングの方法でより明確になります。私は一般的に、この後者のパターンできるだけ好ましいと使用forからだけ反復する-loopをaしますb。 それでも、最初のバージョンはそれほど明確ではないとは言えません。少なくとも初心者にとっては、さらに明確で理解しやすいかもしれません。だから私はまだどちらが良いのか自分自身に質問していますか？ たぶん誰かが方法の1つを支持して良い根拠を与えることができますか？ 更新：これは、複数の関数の戻り点、ラムダ、または配列自体の要素の検出の問題ではありません。それは、単一の不等式よりも複雑な不変式を持つループを書く方法についてです。 更新：OK、答えてコメントする人々のポイントがわかります：ここでforeachループをミックスインしました。これは、whileループよりもはるかに明確で読みやすいものです。私はそうするべきではありませんでした。しかし、これも興味深い質問なので、そのままにしておきます。foreach-loopと内部の追加条件、または明示的なループ不変条件とpost-conditionの後のwhileループです。条件と終了/ブレークのあるforeachループが勝っているようです。foreach-loopを使用せずに追加の質問を作成します（リンクリストの場合）。

17 coding-style  search  loops  invariants  structured-programming 

文字通りの意味で「不変」を理解しています。コードを入力するときにも認識します。しかし、コンピューターサイエンスの文脈でこの用語の重要性を理解しているとは思わない。 有名なプログラマーやコンピューター科学者からの言語設計に関する会話やホワイトペーパーを読むたびに、「不変」という用語が専門用語として登場し続けます。それは私が理解できない部分です。何がそんなに特別なのですか？

16 programming-languages  language-agnostic  invariants 

ずっと前にC ++を学んだとき、C ++のポイントの一部は、ループに「ループ不変式」があるように、クラスにもオブジェクトの存続期間に関連する不変式があることを強く強調しました。オブジェクトが生きている限り。コンストラクターによって確立され、メソッドによって保持されるべきもの。カプセル化/アクセス制御は、不変条件を強制するのに役立ちます。RAIIは、このアイデアでできることの1つです。 C ++ 11以降、ムーブセマンティクスがあります。移動をサポートするクラスの場合、オブジェクトからの移動はその寿命を正式に終了することはありません-移動は「有効な」状態のままにすることになっています。 クラスの設計において、クラスの不変式が移動元までしか保持されないように設計するのは悪い習慣ですか？または、高速化できるようになれば大丈夫です。 具体的にするために、コピー不可だが移動可能なリソースタイプがあるとします。 class opaque { opaque(const opaque &) = delete; public: opaque(opaque &&); ... void mysterious(); void mysterious(int); void mysterious(std::vector<std::string>); }; そして、何らかの理由で、おそらく既存のディスパッチシステムで使用できるように、このオブジェクトのコピー可能なラッパーを作成する必要があります。 class copyable_opaque { std::shared_ptr<opaque> o_; copyable_opaque() = delete; public: explicit copyable_opaque(opaque _o) : o_(std::make_shared<opaque>(std::move(_o))) {} void operator()() { o_->mysterious(); } void operator()(int …

13 c++  object-oriented-design  c++11  invariants 

不変条件の概念が複数のプログラミングパラダイムに存在することを知っています。たとえば、ループ不変式は、オブジェクト指向プログラミング、関数型プログラミング、手続き型プログラミングに関連しています。 ただし、OOPにある非常に便利な種類の1つは、特定のタイプのデータの不変条件です。これをタイトルで「型ベースの不変条件」と呼んでいます。たとえば、Fractionタイプが持つかもしれないnumeratorし、denominatorそのGCDは常に1であることを不変で、（すなわち画分が減少した形です）。これを保証できるのは、そのタイプを何らかのカプセル化して、データを自由に設定できないようにすることだけです。その見返りに、削減されているかどうかを確認する必要がないので、等価性チェックなどのアルゴリズムを簡略化できます。 一方、Fractionカプセル化によってこの保証を提供せずに単純に型を宣言した場合、将来、他の誰かがやって来て方法を追加する可能性があるため、分数が減ると仮定してこの型の関数を安全に書くことはできません非還元分数を取得する方法。 一般に、この種の不変条件がないと、次のような結果になる可能性があります。 前提条件を複数の場所でチェック/保証する必要があるため、より複雑なアルゴリズム これらの繰り返される事前条件は同じ根本的な知識を表すため、DRY違反（不変条件が真であること） コンパイル時の保証ではなく、実行時の失敗を通じて事前条件を適用する必要がある だから私の質問は、この種の不変条件に対する関数型プログラミングの答えは何かということです。ほぼ同じことを達成するための機能的慣用的な方法はありますか？または、利点をあまり関連性のないものにする関数型プログラミングの側面はありますか？

9 functional-programming  language-agnostic  paradigms  invariants