From 9c6dc46c6d11474b8d24f719193f8b1c7b844b92 Mon Sep 17 00:00:00 2001 From: "kwiberg@webrtc.org" Date: Wed, 8 Oct 2014 12:19:56 +0000 Subject: [PATCH] CHECK/DCHECK: Explicitly state whether the condition can have side effects R=andrew@webrtc.org Review URL: https://webrtc-codereview.appspot.com/24889004 git-svn-id: http://webrtc.googlecode.com/svn/trunk@7394 4adac7df-926f-26a2-2b94-8c16560cd09d --- webrtc/base/checks.h | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/webrtc/base/checks.h b/webrtc/base/checks.h index 821b75be17..a25d808bc6 100644 --- a/webrtc/base/checks.h +++ b/webrtc/base/checks.h @@ -35,6 +35,9 @@ // she recognizes that if she is wrong, abrupt and unpleasant process // termination is still better than carrying on with the assumption violated. // +// CHECK always evaluates its argument, so it's OK for x to have side +// effects. +// // - DCHECK(x) is the same as CHECK(x)---an assertion that x is always // true---except that x will only be evaluated in debug builds; in production // builds, x is simply assumed to be true. This is useful if evaluating x is @@ -46,6 +49,10 @@ // at night knowing that the process will suicide instead of carrying on in // case you were wrong, use CHECK instead of DCHECK. // +// DCHECK only evaluates its argument in debug builds, so if x has visible +// side effects, you need to write e.g. +// bool w = x; DCHECK(w); +// // - CHECK_EQ, _NE, _GT, ..., and DCHECK_EQ, _NE, _GT, ... are specialized // variants of CHECK and DCHECK that print prettier messages if the condition // doesn't hold. Prefer them to raw CHECK and DCHECK.