What does ASSERT do?

assert() throws an exception at run time in debug mode. It is used in defensive coding. It is also compile out when building in debug mode. It doesn't cleanup after you.

ace

Assert is used like this:

ASSERT(some_expression_that_is_always_true_unless_you_have_a_bug);

In debug mode, it catches bugs by seeing when something which you have asserted to be true is in fact false, and making the program crash when that happens. In release mode, it's a no-op (and doesn't evaluate its argument).

ASSERT is a tool to help the programmer debug. If the expression being asserted evaluates to false, the program will generate an (IIRC, because I know next to nothing about assembly) int 0x3 instruction, which proceeds to terminate the program according to how the operating system specifies (this should include freeing up heap and stack memory, closing file handles, etc.). ASSERT is used to check for internal coherence -- to make sure the programmer is using the program correctly, rather than the user. A debugger often catches the assert failure.

For example:

int MyFunction(const char *some_path, int some_flag){    ASSERT(path && "MyFunction was passed a null path!");    ASSERT(some_flag != 0 && "MyFunction needs x flag!");    // do stuff}

This, of course, would make sure that MyFunction was being used correctly by checking that a path and a flag is being passed to the function. If they aren't, the programmer gets an informative error message he designed himself, rather than having a hard-to-trace exception happen further down the line, in MyFunction or in some other function called from it, that relied on the path and the flag being valid.

Hope that helps,
Twilight Dragon

EDIT: Beaten, as usual :D

Quote:

Original post by WhatEver You'd think NULL returned by 'new' would be a solid enough way to catch if a memory allocation failed. That's what I've always done

Assuming you're talking about C++, 'new' doesn't return 0 (or NULL for that matter) when it fails - it will throw an exception (std::bad_alloc IIRC). C's 'malloc' and VS6's broken compiler both do return 0 on fail though.

OK, that makes sense. But what about the cleanup? TDragon, you say it cleans up, but ace_lovegrove, you say it doesn't?

OrangyTang, what version of C++ are you talking about? I use VC++ and the proposed ANSI standard for C++ states that 'new' should return a NULL pointer if an allocation fails. Do the newer compilers not return NULL or something?

Quote:

Original post by WhatEver OrangyTang, what version of C++ are you talking about? I use VC++ and the proposed ANSI standard for C++ states that 'new' should return a NULL pointer if an allocation fails.

Huh? No it doesn't. Got a reference for this? It may have been the case in very early versions of the standard.

Quote:

Original post by WhatEver OK, that makes sense. But what about the cleanup? TDragon, you say it cleans up, but ace_lovegrove, you say it doesn't?

The sort of cleanup TDragon was referring to is performed by the OS. ASSERT doesn't throw an exception (at least, the ASSERT that most people use), so it doesn't destroy scoped objects.

Quote:

Original post by WhatEver OrangyTang, what version of C++ are you talking about?

Any standard.

Quote:

I use VC++ and the proposed ANSI standard for C++ states that 'new' should return a NULL pointer if an allocation fails. Do the newer compilers not return NULL or something?

Do you have a reference to back that up? IIRC an initial draft suggested sticking with the C style, but all actual standards have used an exception.

If you're still using a broken compiler (VS6) however, then all bets are off. [razz]

I do :)

Osborn Publishing, Herbert Schilt, C++ the Complete Reference (Second Edition) page 335

"Like malloc(), new allocates memory from the heap. It returns a null pointer if there is insufficient memory to fulfill the allocation request."

Has the ANSI C++ proposition been droped or revised since that book?

EDIT: the book was published in 1995.

Crapola! I found this at msdn: "If unsuccessful, by new returns zero or throws an exception". I need to update my reference material :P.

EDIT:

Here's more:

Beginning in Visual C++ .NET 2002, the CRT's new function (in libc.lib, libcd.lib, libcmt.lib, libcmtd.lib, msvcrt.lib, and msvcrtd.lib) will continue to return NULL if memory allocation fails. However, the new function in the Standard C++ Library (in libcp.lib, libcpd.lib, libcpmt.lib, libcpmtd.lib, msvcprt.lib, and msvcprtd.lib) will support the behavior specified in the C++ standard, which is to throw a std::bad_alloc exception if the memory allocation fails.

Quote:

Original post by WhatEver EDIT: the book was published in 1995.

The standard wasn't finalized until the end of 1997.

Yeah. Remember how long it took them to get for-scoping right, though.

Thanks for you help guys. I'm learning very quickly from this forum that I'm a little behind when it comes to compilers and standards :O. I didn't realize, or even know that C++ was still growing and changing when it came to standards.

Quote:

Original post by WhatEver Thanks for you help guys. I'm learning very quickly from this forum that I'm a little behind when it comes to compilers and standards :O. I didn't realize, or even know that C++ was still growing and changing when it came to standards.

Indeed. Programming really still is a new industry, even if it is older than me. A few key resources to get you started in catching up (IMO):

MSDN: Standard C++ Library Reference - covering the very useful and powerful standard library.

The Boost C++ Libraries - The (as far as I'm concerned) third party collection of libraries. Many of their libraries have been integrated into TR1, and even more proposed for TR2.

TR1 - Technical Report 1, a prototype for the next standard's new features if you will [clicky].
TR2 - Technical Report 2, the next Technical Report.
C++0x - The next version of the standard. The "0x" indicates a target release of this decade, before 2010.

I'm taking wagers that they won't make it before 2010.

In any case, the current version of the standard is ISO/IEC 14882:2003, published in 2003. It's available in hardcover from Wiley publications, which last time I checked was actually cheaper than buying a copy of the PDF.

Thanks MaulingMonkey, I have a lot of reading up to do!