相关疑难解决方法(0)

通过合同编程时,函数或方法首先检查其前提是否已满足,然后才开始履行其职责,对吗？两个最重要的方式做这些检查是通过assert和exception.

1. 断言仅在调试模式下失败.确保(单元)测试所有单独的合同前提条件以确定它们是否确实失败是至关重要的.
2. 在调试和释放模式下异常失败.这样做的好处是,测试的调试行为与发布行为相同,但它会导致运行时性能下降.

你觉得哪一个更好？

请参阅此处的相关问题

我倾向于在我的C++代码中添加许多断言,以便在不影响发布版本性能的情况下简化调试.现在,assert是一个纯C宏设计,没有考虑到C++机制.

另一方面std::logic_error,C++定义了在程序逻辑中存在错误(因此名称)的情况下抛出的内容.抛出一个实例可能只是一个完美的,更多的C++替代品assert.

问题是,assert并且abort两者都立即终止程序而不调用析构函数,因此跳过清理,而手动抛出异常会增加不必要的运行时成本.解决这个问题的一种方法是创建一个自己的断言宏SAFE_ASSERT,它就像C对应物一样工作,但在失败时抛出异常.

我可以想到关于这个问题的三种看法:

• 坚持C的主张.由于程序立即终止,因此更改是否正确展开并不重要.此外,#define在C++中使用s同样糟糕.
• 抛出异常并在main()中捕获它.允许代码在程序的任何状态下跳过析构函数都是不好的做法,必须不惜一切代价避免,并且调用terminate()也是如此.如果抛出异常,则必须捕获它们.
• 抛出异常并让它终止程序. 终止程序的例外是可以的,并且由于NDEBUG这种情况在发布版本中永远不会发生.捕获是不必要的,并公开内部代码的实现细节main().

这个问题有明确的答案吗？有专业的参考吗？

编辑:跳过析构函数当然没有未定义的行为.

我不明白的目的assert().

我的讲师说断言的目的是发现错误.

例如 :

double divide(int a , int b ) 
{
  assert (0 != b);
  return a/b;
}

以上断言是否合理？我认为答案是肯定的,因为如果我的程序不应该使用0(数字为零),但不知何故零确实进入b变量,那么代码就出了问题.

我对么 ？

你能告诉我一些合理的断言()的例子吗？

问候