утверждайте и NDEBUG

Мне нравится определять мои собственные макросы утверждения. Я делаю два - всегда УТВЕРЖДАЮТ тесты (даже для оптимизированных сборок), и DASSERT только имеет эффект для сборок отладки. Вы, вероятно, хотите принять значение по умолчанию для УТВЕРЖДЕНИЯ, но если что-то дорого для тестирования, или утверждения во внутренних циклах производительности чувствительных областей могут быть изменены на DASSERT.

Кроме того, помните, что утверждения должны только использоваться для полностью бессмысленных условий, которые указывают на логическую ошибку в Вашей программе и с которого Вы не можете восстановиться. Это - тест Вашей правильности программирования. Утверждения никогда не должны использоваться вместо обработки ошибок, исключений или устойчивости, и Вы никогда не должны утверждать ничего связанного с уродливым или неправильным вводом данных пользователем - такие вещи должны быть обработаны корректно. Утверждение является просто управляемым катастрофическим отказом, где у Вас есть возможность произвести некоторую дополнительную информацию об отладке.

Вот мои макросы:

/// ASSERT(condition) checks if the condition is met, and if not, calls
/// ABORT with an error message indicating the module and line where
/// the error occurred.
#ifndef ASSERT
#define ASSERT(x)                                                      \
    if (!(x)) {                                                         \
        char buf[2048];                                                 \
        snprintf (buf, 2048, "Assertion failed in \"%s\", line %d\n"    \
                 "\tProbable bug in software.\n",                       \
                 __FILE__, __LINE__);                                   \
        ABORT (buf);                                                    \
    }                                                                   \
    else   // This 'else' exists to catch the user's following semicolon
#endif


/// DASSERT(condition) is just like ASSERT, except that it only is 
/// functional in DEBUG mode, but does nothing when in a non-DEBUG
/// (optimized, shipping) build.
#ifdef DEBUG
# define DASSERT(x) ASSERT(x)
#else
# define DASSERT(x) /* DASSERT does nothing when not debugging */
#endif

Ну, провальное утверждение является ошибкой, ни больше, ни меньше. То же как разыменование нулевого указателя, за исключением того, что Вы сами дали Вашему программному обеспечению палку для удара Вас. Храброе решение, Вы заслуживаете кредита на него!

Выпрыгивание из проблемы за исключением едва помогает, это не исправляет ошибку. Таким образом, я рекомендовал бы реализовать Ваше собственное, УТВЕРЖДАЮТ () макрос, который:

• Попытки собрать как можно больше данных об отказе (выражение утверждения, отслеживание стека, среда пользователя, и т.д.)
• Очень старается сделать его максимально легким, чтобы пользователь сообщил об этом Вам, и
• Подбрасывает окно сообщения, приносящее извинения за неудобство, и жестоко прерывает приложение.

Если производительность является проблемой, можно считать наличие некоторого SOFT_ASSERT () макросом, который исчезает из сборок конечных версий.

Я постарался бы не полагаться, утверждают для кроме случайного способа проверить предположения во время отладки. В коде выпуска Ваши переопределенные утверждают, будет обработанным случайным катастрофическим отказом, это не удобно для пользователя

Если во время отладки, вашего предположения, говорят, что данное условие никогда не будет верно, оказывается недопустимым. Измените свой код обработки ошибок accodingly для принятия во внимание того условия.

Иначе имейте более удобное для пользователя средство для обработки условий нарушения предположения. Создайте исключение под названием CAssumptionViolated, бросьте его, где Вы иначе утверждали бы. Поймайте его в своей основной стандартной программе и предоставьте средство пользователю предупредить Вас об ошибке. Еще лучше предоставьте отладочной информации за исключением. Еще лучше автоматически передайте отладочную информацию своей организации так или иначе.

Возможно, я не понял Вас правильно, но IMO утверждают (), не должен использоваться в коде выпуска, чтобы сделать то, что Вы описываете т.е. осуществляете инварианты.

Если бы предварительные условия функции являются неправильными, что Вы хотели бы сделать? Как был бы Вы хотеть передать это к:

• интерактивный пользователь?
• Ваш персонал поддержки?

В обоих случаях необходимо было бы вызвать некоторый код обработки ошибок, и (это кажется мне), исключениями является просто билет.

Однако, если Вы все еще хотите пойти этим путем, Вы могли бы поместить следующее во главе каждого исходного файла:

#undef NDEBUG

Я НЕ рекомендую это. Не делайте этого. Никто не поблагодарит Вас :-)

Seb

Я видел, что программы реализовать их собственное утверждают и проверяют макросы. Где утверждает, используются в режиме отладки и verify's и в отладке и выпускают режим. Конкретно verify's может использоваться для корректного выхода (или скорее более корректно, чем прямой катастрофический отказ) из программы, когда проверка перестала работать. Вероятно, один из первых, и лучше всего использует это, я видел, находится в Нереальном коде (я полагаю, что можно все еще заставить Нереальные заголовки смотреть на).