断言原则上 [英] Assertions in principle
问题描述
这可能不是一个设计问题，而是一个C ++语言问题本身，
但我有断言问题。我的意思是，他们的工作当然。
但是有些东西让我很不舒服，因为我从来没有这么说过，我很满意。 />
我最近读了这个解释。 有一个有效的试金石测试
来区分你需要使用断言的情况，当你需要使用真正的错误检查时：你使用错误检查
可能发生的事情，甚至非常不可思议。对于你认为在任何
情况下不可能发生的事情，你只使用断言
。一个失败的断言总是表示一个设计或一个
程序员错误 - 而不是用户错误。
好的我可以买到它。但是没有提到的是
断言只是调试模式。好吧，它已被提及，但通常在
的运行时提高效率的上下文因为它们被编译了
out。
我理解即使你认为理所当然的事情是真实的，也可能不是真的。软件有错误，今天几乎每个体面的应用程序使用第三方补充和
接口。接口更改，代码版本更改，代码版本
不匹配。硬件和软件组合的新排列不断发生。
这些都表现在哪里？在开发人员的盒子里？
有时。但是在一个现代大型应用程序中的大部分时间与许多用户一起使用b / b $ b $很可能会在
字段中出现错误。这正是断言不存在的地方。即使
大多数测试部门都使用发布代码，而不是调试代码。究竟是什么
是检查不可能的点。仅在
开发人员的桌面上出现错误情况？这对我来说没有意义。代码得到
在那个环境之外执行得太多了，原来开发人员可能没有想到的那样，因为那个很好
够了。
我会说原来开发人员的盒子恰好是
，不需要断言，因为那个'这是
调试器可用的唯一地方。 （我知道它们如何派上用场，并且强迫你做出假设。）但是你真的需要在调试器没有的环境中断言（或者说b
）不可用。
This might be less of a design issue than a C++ language issue per se,
but I have a problem with assertions. I mean, they work, of course.
But there''s something I''m uncomfortable with that''s never been
explained to my satisfaction.
I recently read this explanation. "There is an effective litmus test
to differentiate the cases in which you need to use assert and when
you need to use genuine error checking: you use error checking for
things that could happen, even very improbably. You use assert only
for things that you truly believe cannot possibly happen under any
circumstances. An assertion that fails always signals a design or a
programmer error - not a user error."
OK I can buy that. But what keeps going unmentioned is that
assertions are debug-mode only. Well, it''s mentioned, but usually in
the context of increased efficiency at runtime since they''re compiled
out.
I understand the idea that even the things you take for granted as
being true might not be true. Software has bugs, and today almost
every decent sized application uses third party supplements and
interfaces. Interfaces change, code versions change, versions of code
get mismatched. New permutations of hardware and software mixes are
constantly occurring.
And where does all this manifest itself? At the developer''s box?
Sometimes. But the majority of time in a modern large application
with many users, it''s very likely for a bug to show itself in the
field. And that is exactly where the assertion does not exist. Even
most test departments use release code, not debug code. What exactly
is the point of checking for "impossible" error situations only at the
developer''s desk? That just doesn''t make sense to me. The code gets
executed far too much outside of that environment, in ways the
original developer might not even have imagined, for that to be good
enough.
I would go so far as to say the original developer''s box is precisely
where assertions are NOT needed, because that''s the only place where a
debugger is available. (I see how they can come in handy, and force
you to resist making assumptions.) But you really need assertions (or
something) in environments where the debugger isn''t available.
推荐答案
< je ****** @ yahoo。在消息中写道
新闻：11 ********************** @ s48g2000cws.googlegr oups.com ......
< snip>
<je******@yahoo.comwrote in message
news:11**********************@s48g2000cws.googlegr oups.com...
<snip>
我最近读了这个解释。 有一个有效的试金石测试
来区分你需要使用断言的情况，当你需要使用真正的错误检查时：你使用错误检查
可能发生的事情，甚至非常不可思议。对于你认为在任何
情况下不可能发生的事情，你只使用断言
。一个失败的断言总是表示一个设计或一个
程序员错误 - 而不是用户错误。
好的我可以买到它。但是没有提到的是
断言只是调试模式。嗯，它已被提及，但通常在
的运行时提高效率的上下文，因为它们被编译了
out。
I recently read this explanation. "There is an effective litmus test
to differentiate the cases in which you need to use assert and when
you need to use genuine error checking: you use error checking for
things that could happen, even very improbably. You use assert only
for things that you truly believe cannot possibly happen under any
circumstances. An assertion that fails always signals a design or a
programmer error - not a user error."
OK I can buy that. But what keeps going unmentioned is that
assertions are debug-mode only. Well, it''s mentioned, but usually in
the context of increased efficiency at runtime since they''re compiled
out.
< snip>
<snip>
我会说原始开发者的's' box正好是
，其中不需要断言，因为这是唯一可以使用
调试器的地方。 （我知道它们如何派上用场，并且强迫你做出假设。）但是你真的需要在调试器没有的环境中断言（或者说b
）不可用。
I would go so far as to say the original developer''s box is precisely
where assertions are NOT needed, because that''s the only place where a
debugger is available. (I see how they can come in handy, and force
you to resist making assumptions.) But you really need assertions (or
something) in environments where the debugger isn''t available.
我同意。我认为断言应该留在发布代码中，你可以通过编写自己的断言宏来实现这一点（适用于你的
平台）：
#define断言（p）（（p）？（void）0：_assert（＃p，__ FILE __，_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ $ $>
当然，可能有断言条件是一项耗时的任务，你不希望你的用户在现场遭受损失。我不是
确定我知道如何最好地处理这种情况，但是一种方法可能是启用
断言，并带有可以在用户启用的运行时标志酌情决定。
这样做的好处是断言代码可以在你需要的时候使用，但
的缺点是当你拥有它时没有任何帮助a
难以重现的错误情况。幸运的是，大多数条件为
断言是有益的，实际上是程序员错误，并且可以很容易地转载。
- 丹尼斯
I agree. I think asserts should be left in release code, and you can
accomplish this by writing your own assert macro (appropriately for your
platform):
#define Assert(p) ((p) ? (void)0 : _assert(#p, __FILE__, __LINE__))
Of course, there may be cases where the assert condition is a time-consuming
task that you would not want your users to suffer in the field. I''m not
sure I know how best to handle that case, but one way might be to enable
asserts with a runtime flag that can be enabled at the user''s discretion.
This has the advantage that the assert code is available if you need it, but
has the disadvantage that it doesn''t help when you have a
difficult-to-reproduce error condition. Fortunately, most conditions for
which assert is beneficial are in fact programmer errors, and can be
reproduced readily.
- Dennis
3月2日上午8:08，jeffc ... @ yahoo.com < jeffc ... @ yahoo.comwrote：
On Mar 2, 8:08 am, "jeffc...@yahoo.com" <jeffc...@yahoo.comwrote:
这可能不是一个设计问题，而是一个C ++语言问题本身，
但我的断言有问题。我的意思是，他们的工作当然。
但是有些东西让我很不舒服，因为我从来没有这么说过，我很满意。 />
我最近读了这个解释。 有一个有效的试金石测试
来区分你需要使用断言的情况，当你需要使用真正的错误检查时：你使用错误检查
可能发生的事情，甚至非常不可思议。对于你认为在任何
情况下不可能发生的事情，你只使用断言
。一个失败的断言总是表示一个设计或一个
程序员错误 - 而不是用户错误。
好的我可以买到它。但是没有提到的是
断言只是调试模式。好吧，它已被提及，但通常在
的运行时提高效率的上下文因为它们被编译了
out。
我理解即使你认为理所当然的事情是真实的，也可能不是真的。软件有错误，今天几乎每个体面的应用程序使用第三方补充和
接口。接口更改，代码版本更改，代码版本
不匹配。硬件和软件组合的新排列不断发生。
这些都表现在哪里？在开发人员的盒子里？
有时。但是在一个现代大型应用程序中的大部分时间与许多用户一起使用b / b $ b $很可能会在
字段中出现错误。这正是断言不存在的地方。即使
大多数测试部门都使用发布代码，而不是调试代码。究竟是什么
是检查不可能的点。仅在
开发人员的桌面上出现错误情况？这对我来说没有意义。代码得到
在那个环境之外执行得太多了，原来开发人员可能没有想到的那样，因为那个很好
够了。
我会说原来开发人员的盒子恰好是
，不需要断言，因为那个'这是
调试器可用的唯一地方。 （我知道它们如何派上用场，并且强迫你做出假设。）但是你真的需要在调试器没有的环境中断言（或者说b
）不可用。
This might be less of a design issue than a C++ language issue per se,
but I have a problem with assertions. I mean, they work, of course.
But there''s something I''m uncomfortable with that''s never been
explained to my satisfaction.
I recently read this explanation. "There is an effective litmus test
to differentiate the cases in which you need to use assert and when
you need to use genuine error checking: you use error checking for
things that could happen, even very improbably. You use assert only
for things that you truly believe cannot possibly happen under any
circumstances. An assertion that fails always signals a design or a
programmer error - not a user error."
OK I can buy that. But what keeps going unmentioned is that
assertions are debug-mode only. Well, it''s mentioned, but usually in
the context of increased efficiency at runtime since they''re compiled
out.
I understand the idea that even the things you take for granted as
being true might not be true. Software has bugs, and today almost
every decent sized application uses third party supplements and
interfaces. Interfaces change, code versions change, versions of code
get mismatched. New permutations of hardware and software mixes are
constantly occurring.
And where does all this manifest itself? At the developer''s box?
Sometimes. But the majority of time in a modern large application
with many users, it''s very likely for a bug to show itself in the
field. And that is exactly where the assertion does not exist. Even
most test departments use release code, not debug code. What exactly
is the point of checking for "impossible" error situations only at the
developer''s desk? That just doesn''t make sense to me. The code gets
executed far too much outside of that environment, in ways the
original developer might not even have imagined, for that to be good
enough.
I would go so far as to say the original developer''s box is precisely
where assertions are NOT needed, because that''s the only place where a
debugger is available. (I see how they can come in handy, and force
you to resist making assumptions.) But you really need assertions (or
something) in environments where the debugger isn''t available.
这绝对是一种平衡行为，而不是黑白分明的东西。
我通常有（至少）两种断言定义的宏（所以我将b $ b定义为我自己的而不是仅仅使用标准''断言''）。其中一个
这些将被关闭以进行发布/优化构建，其中一个保持
。通常你想把断言放在所有地方 - 它是
通常在每个函数检查参数的开头有一个
和在结尾处功能检查''后置条件''。随着
如此多的断言，性能可能会被称为
很多的代码。所以具有高风险的地方，如主要接口，其他人的代码，我可能会使用一个始终保持活动的断言，其他
更多内部属于我自己的代码我将禁用
版本构建的断言。
当然，我在更多内部发布后仍然会遇到问题
代码，但我通常会看到，如果我可以在发布之前做好测试，那么这个代码可以接受的风险费用。
顺便说一下，我经常有一个调用特殊调试模式的第三种断言
检查数据结构不完整的函数。这些都非常昂贵，但对于解决一些问题非常有用。即使在调试过程中我也可以保持这些
以保持性能提升。
It''s definitely a balancing act rather than a black and white thing.
I normally have (at least) two kinds of assert macros defined (so I
define my own rather than just use the standard ''assert''). One of
these will be turned off for a release/optimized build and one kept
on. Typically you want to put asserts all over the place -- it''s
common to have one at the start of every function checking arguments
and at the end of the function checking the ''post condition''. With
so many asserts the performance can suffer for code that gets called a
lot. So places with high risk like major interfaces to other people''s
code I might use an assert which stays active all the time, other
places more internal to my own code I will disable the asserts for a
release build.
Sure I could still suffer problems after release in my more internal
code, but I generally see the risk verses cost acceptable for that
code if I can do good testing before release.
btw, I often have a third type of assert that calls special debug mode
functions that check the inegrity of data structures. These are very
expensive, but are great for catching some problems. I may keep these
disabled even during some debugging to keep performance up.
3月2日，12：19 pm，Dennis Jones ; < nos ... @ nospam.comwrote：
On Mar 2, 12:19 pm, "Dennis Jones" <nos...@nospam.comwrote:
我同意。我认为断言应该留在发布代码中，你可以通过编写自己的断言宏来实现这一点（适用于你的
平台）：
I agree. I think asserts should be left in release code, and you can
accomplish this by writing your own assert macro (appropriately for your
platform):
我喜欢这个主意。
I like that idea.
>我不是
我肯定知道如何最好处理这种情况，但一种方法可能是使用运行时标志启用
断言，可以由用户自行决定启用。
>I''m not
sure I know how best to handle that case, but one way might be to enable
asserts with a runtime flag that can be enabled at the user''s discretion.
我也喜欢这个主意。
I like that idea too.
>幸运的是，大多数条件为
哪个断言是有益的，实际上是程序员错误，并且可以很容易地转载为b $ b。
>Fortunately, most conditions for
which assert is beneficial are in fact programmer errors, and can be
reproduced readily.
实际上我特意想到了我遇到的所有情况
*不能再转发回来开发人员的办公桌，由于今天的一些情景中的大量变量和排列
（我说情景而不是简单的应用程序，因为现在这个日子变得越来越有效，根据整个
系统进行思考，其中应用程序只是其中的一部分。）但是在发布代码中添加
自定义宏，当有更多反馈需要打开时，现场问题需要
，这听起来是一个很好的解决方案。
Actually I was specifically thinking of all the cases I''ve run into
that *can''t* be reproduced back at the developer''s desk, due to the
vast number of variables and permutations in some of today''s scenarios
(I say "scenario" instead of simply "application" because it''s
becoming increasingly valid these days to think in terms of the entire
system, of which the application is just one part.) But putting
custom macros in release code, to be turned on when more feedback is
needed for a problem in the field, sounds like a good solution.
这篇关于断言原则上的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
