In what cases should we include cassert?
-
5@close-voters: please vote only on questions that you understand. your lack of understanding does NOT imply a lack of meaning, or that it's impossible to answer a question. your lack of understanding only indicates that you don't understand, which is the opposite of being competent to vote on the matter. – Cheers and hth. - Alf May 16 '12 at 20:09
-
4How is this *not a real question*? Because it's short? This is a legit question. It's not off topic, it's real, not too localized at all and not unconstructive. It *might* be a dupe, but I'm not sure. If this gets closed, I'll reopen it *immediately*. – May 16 '12 at 20:19
-
7this's one of the reason why sometimes I don't want to ask something here, because many people think that is so stupid to ask so easy questions here. Yes, I quite agree with them, but I really can't understand what's strange if I want to know the answer to this easy question. – Jane May 16 '12 at 20:36
-
3One answer implies that the question was about why to include `
` as opposed to ` – Keith Thompson Dec 22 '13 at 07:28`. If that was the OP's intent, the question should say so. If the question was about what ` ` or ` ` is used for, any C or C++ reference or tutorial should answer that.
4 Answers
In short, don't use it; use <assert.h>
.
C++11 removed any formal guarantee of a "c...." header not polluting the global namespace.
It was never an in-practice guarantee, and now it's not even a formal guarantee.
Hence, with C++11 there is no longer any conceivable advantage in using the "c...." header variants, while there is the distinct and clear disadvantage that code that works well with one compiler and version of that compiler, may fail to compile with another compiler or version, due to e.g. name collisions or different overload selection in the global namespace.
SO, while cassert
was pretty meaningless in C++03 (you can't put a macro in a namespace), it is totally meaningless -- even as a special case of a general scheme -- in C++11.
Addendum, Dec 22 2013:
The standard defines each C++ C header <X.h> header in terms of the <cX> header, which in turn is defined in terms of the corresponding C library header.
C++11 §D.5/2:
“Every C header, each of which has a name of the form
name.h
, behaves as if each name placed in the standard library namespace by the corresponding cname header is placed within the global namespace scope.”
C++11 §D.5/3 (non-normative example):
“The header
<cstdlib>
assuredly provides its declarations and definitions within the namespacestd
. It may also provide these names within the global namespace. The header<stdlib.h>
assuredly provides the same declarations and definitions within the global namespace, much as in the C Standard. It may also provide these names within the namespacestd
.”
Stack Overflow user C.R.’s comment made me aware that some versions of g++, such as MinGW g++ 4.7.2, are quite non-standard with respect to the <X.h>
headers, lacking the overloads of e.g. sin
that the C++ standard requires:
I already knew that MinGW g++ 4.7.2 also entirely lacks functions such as swprintf
, and that it has ditto shortcomings in the pure C++ library such as lacking C++11 std::to_string
. However, the information about it lacking the C function overloads was new to me.
In practice the lacking overloads with g++ means
ignoring the g++ issue, or
avoiding using the missing g++ overloads,
e.g. using onlydouble sin( double )
, orusing the
std
namespace overloads
(one then needs to include<cmath>
to guarantee their presence with g++).
In order to use the g++ std
namespace overloads unqualified, one practical approach is to define headers wrappers for this compiler. I've used that approach to address g++ shortcomings wrt. to the printf
family. For as David Wheeler once remarked, “All problems in computer science can be solved by another level of indirection”…
Then things can be arranged so that standard code that uses g++'s missing overloads, also compiles with g++. This adjusts the compiler to the standard, with a fixed amount of code.

- 1
- 1

- 142,714
- 15
- 209
- 331
-
I'm using Visual Studio 10 Professional. Do you mean, that using
is better instead of – Jane May 16 '12 at 20:26? -
It's more meaningful and the general practice of using [*.h] headers (regarding the C library) makes the code a bit more robust, less likely to be problematic with other compilers. – Cheers and hth. - Alf May 16 '12 at 20:30
-
-
@C.R. Perhaps you can give an example of a guaranteed difference, that one can rely on in a small program with full control over which standard library headers are included? – Cheers and hth. - Alf Dec 22 '13 at 07:58
-
1@Cheersandhth.-Alf: `std::sin` have overloads for `double`, `float` and `long double` and `std:complex`, while `sin` only accepts `double` argument. `sinf` for `float` and `sinl` for `long double`. – Siyuan Ren Dec 22 '13 at 08:09
-
@C.R. The standard defines each C++ "C header"
header in terms of the – Cheers and hth. - Alf Dec 22 '13 at 09:01header (which in turn is defined in terms of the corresponding C library header), C++11 §D.5/2 "Every C header, each of which has a name of the form name.h, behaves as if each name placed in the standard library namespace by the corresponding cname header is placed within the global namespace scope.". E.g. C++ is NOT the C header of the same name, it's not a header that can be consumed by a C compiler. However, while e.g. Visual C++ 12.0 gets this right, MinGW g++ 4.7.2 doesn't, so there is an issue. -
1The standard's examples are non-normative, but clarifying. E.g. §D.5/3 "[Example: The header
assuredly provides its declarations and definitions within the namespace std. It may also provide these names within the global namespace. The header – Cheers and hth. - Alf Dec 22 '13 at 09:07assuredly provides the same declarations and definitions within the global namespace, much as in the C Standard. It may also provide these names within the namespace std. —end example]"
Just like any other header file, you #include <cassert>
when you use something declared in that header file, such as assert()
.

- 951,095
- 183
- 1,149
- 1,285
See an easily accessible reference
#include <iostream>
// uncomment to disable assert()
// #define NDEBUG
#include <cassert>
int main()
{
assert(2+2==4);
std::cout << "Execution continues past the first assert\n";
assert(2+2==5);
std::cout << "Execution continues past the second assert\n";
}

- 69,038
- 19
- 164
- 304
-
8*Nitpicking*: cppreference.com is **a reference**, not **the reference**. If you want to refer to **the reference**, refer to "International Standard ISO/IEC 14882", or one of its editions: "14882:1998", "14882:2003", or "14882:2011". – Robᵩ May 16 '12 at 20:06
-
Thank u very much for help! I'm ssory for such stupid question. I'll do it now. – Jane May 16 '12 at 20:07
-
1@Jane You're welcome. Also please take a look at the FAQ: http://stackoverflow.com/faq – TemplateRex May 16 '12 at 20:12
assert.h defines one macro function that can be used as a standard debugging tool.

- 2,413
- 1
- 23
- 28