Questions tagged «invariants»

我正在阅读《工作中的编码器》，其中有很多关于不变式的讨论。据我了解，不变量是在表达式之前和之后均保持的条件。如果我正确记得我的逻辑课程，那么它们对于证明循环正确是很有用的。 我的描述是正确的，还是我错过了什么？您在程序中使用过它们吗？如果是这样，他们如何受益？

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。 但是我不能说第一个版本不太清楚。至少对于初学者来说，它甚至更清晰，更容易理解。所以我仍然在问自己一个问题哪个更好？ 也许有人可以对其中一种方法给出很好的理由？ 更新：这不是多个函数返回点，lambda或本身在数组中查找元素的问题。这是关于如何编写具有比单个不等式更复杂的不变式的循环。 更新：好的，我看到回答和评论的人的观点：我在这里混入了foreach循环，它本身已经比while循环更加清晰易读。我不应该那样做。但这也是一个有趣的问题，因此我们将其保留为：foreach循环和内部一个额外条件，或者while循环具有一个显式循环不变性和after后置条件。看来带有条件和退出/中断的foreach循环是成功的。我将创建一个没有foreach循环的附加问题（用于链接列表）。

17 coding-style  search  loops  invariants  structured-programming 

我从字面上理解“不变式”。当我键入代码时，我也会识别它们。但是我认为我不理解这个术语在计算机科学中的重要性。 每当我阅读著名程序员\计算机科学家的有关语言设计的对话\白皮书时，“不变”一词就会不断冒出来。那是我不理解的部分。有什么特别之处？

16 programming-languages  language-agnostic  invariants 

很久以前，当我学习C ++时，我就强烈强调C ++的部分意思是就像循环具有“循环不变式”一样，类也具有与对象生命周期相关的不变式-应该是正确的只要物体还活着 应该由构造函数建立并由方法保留的事物。封装/访问控制可帮助您强制执行不变式。RAII是您可以使用此想法做的一件事。 从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 …

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

我知道不变性的概念存在于多种编程范例中。例如，循环不变式与OO，功能和过程编程有关。 但是，在OOP中发现的一种非常有用的类型是特定类型数据的不变性。这就是标题中所说的“基于类型的不变式”。例如，一个Fraction类型可能具有numerator和denominator，并且其gcd始终为1（即，分数为简化形式）是不变的。我只能通过某种类型的封装来保证这一点，而不是随意设置其数据。作为回报，我不必检查它是否减少了，因此我可以简化等式检查等算法。 另一方面，如果我只是声明一个Fraction类型而没有通过封装提供此保证，那么我就不能安全地在该类型上编写任何函数（假定分数减少了），因为将来有人可能会提出并添加一种方法掌握未减少的分数。 通常，缺少这种不变性可能导致： 需要在多个位置检查/确保前提条件的更复杂算法 DRY违规，因为这些重复的前提条件表示相同的基础知识（不变性应为真） 必须通过运行时故障而不是编译时保证来强制执行前提条件 所以我的问题是函数编程对这种不变性的回答是什么。是否有实现或多或少相同功能的惯用方式？还是功能编程的某些方面使收益的相关性降低？

9 functional-programming  language-agnostic  paradigms  invariants